This is a short tutorial on using HamAlert with Node-Red for the purpose of connecting HAM Radio with the Internet of Things (IoT). HamAlert is an online service by Manuel Kapser (HB9DQM) that allows triggers to be set up when HAM callsigns are spotted on air.

When setting up node-red, an URL path must be made public but node-red should still be private enough in what concerns the flows themselves. Fortunately, this is not a problem and the HTTP-in nodes that are going to be used generate an accessible URL that is exempt from the usual node-red authentication. Having said that, authentication should be enabled for Node-Red.

Authentication can be enabled by editing the Node-Red configuration file, typically named settings.js and by making the following changes:

    adminAuth: {
        type: "credentials",
        users: [{
            username: "...",
            password: "...",
            permissions: "*"
        }]
    },

where:

• username can be set to any string,
• password can be set to a hash that is obtained by running the following command node-red admin hash-pw

After restarting Node-Red and browsing the public URL, Node-Red should popup a typical authentication screen where the username and password defined in the settings.js configuration file can be entered. After entering the username and password, the user is granted access to the Node-Red flows.

With Node-Red set up to prompt for authentication a custom URL path can be set up using built-in HTTP nodes. The beauty of this is that the system will be an integrated system that does not rely on any external dependencies and works just on top of all the well-known protocols.

Furthermore, the build-in HTTP nodes, namely:

• "http in",
• "http response",
• "http request"

are designed to generate and work with URL paths that will be ignored by the overall authentication meaning that external services will be able to reach them while keeping the flows and internal mechanism private. Clever!

The nodes "http in" and "http response" deserve some documentation on their own because they are not too well-known nodes but they are extremely powerful and perform unexpected functions that the user might not be aware is possible in Node-Red.

Specifically, the "http in" node is actually a web-server that can be made to listen for specific requests such as GET, POST, etc, whilst the "http response" node couples directly with the "http in" and provides a response to the externally-connecting client. The beauty here is that the nodes offer a ready-made abstraction such that there is no need to set up a webserver, figure out some message passing, and so on, in order to be able to receive data.

For HamAlert, the "http in" node is configured to listen on the POST method and on the /hamalert URL path. The request itself will be sent by the HamAlert site once one or more of the triggers match. Interestingly, as a peek-preview, the data is fairly rich in terms of what is reported such that it opens up a lot of opportunities for automation.

Note again the usage of "http in" and paired "http response" that are connected to each other directly, one of the being labeled [post] /hamalert and the other Ok - this is not incidental, RFC9110 states that specifically a POST HTTP method must have a terminator response from the servers. Remember that HTTP is stateless such that "posting a resource" which describes the meaning of the POST HTTP method implies that the server should confirm whether the resource is accepted or not. As a counter-example, other methods like PUT do not necessarily need a confirmation from the server. Adding a terminator is not just being pedantic, without a response from the server a standards-compliant HTTP client that makes a POST request will hang forever for a response from the server! In other words, it will generate upstream errors for HamAlert that most likely the author will ignore.

The website allows various conditions to be set up, such as filtering by bands, geographic continent, etc, in order to create a trigger that can be set to emit to an Android application or to an external server. The configuration can be performed in the HamAlert account under the menu item Triggers. After the triggers are set up, external destinations can be configured by following the menu item Destinations.

By default, HamAlert is made to work with its companion Android application, and the user can log-in to HamAlert on the application in order to receive push notifications when the set up triggers take place. However, it is also possible to send the data received by the Android application to a remote server.

There are several connectivity options, namely:

• telnet and,
• URL notifications

telnet itself is almost raw TCP, just with a minor authentication protocol that takes place when the session is started. Even though encrypted telnet does exist, the HamAlert implementation is plaintext, meaning that the password is more like a session token. This is fairly insecure and even if all the data processed is public anyway, using protocols without any encryption outside of a LAN is a bad habit. However, the major pitfall of telnet is not the lack of encryption but rather that TCP is a statefull protocol and whilst that makes a good tool under certain circumstances when data has to be exchanged both ways, on HamAlert there are just a few commands that the telnet implementation accepts and most of them have to do with formatting anyway. In other words, it is wasteful in this situation because the purpose of HamAlert is to push data.

With that said, the "URL notifications" option is much better and an URL can be entered along with the payload type. In the image illustrated the type is set to JSON because it is convenient for a node.js environment like node-red and the URL is set to the public URL that node-red will listen on for hamalert notifications.

Depending on what triggers are set up, the radio can now be keyed to match the callsigns and if all goes well, Node-Red should report an event on the console via the flow illustrated in the Node-Red section.

The HamAlert application is very useful and various ideas come to mind, such as being notified when a friend goes on air, listening to your own call-sign to check if anyone else is using it, and so on. Obviously, given other projects we have completed, you can make the lights go on or off in the house depending on events from HamAlert and the inter-connectivity is endless. Initially, we were thinking of setting up a geographical map, very similar to "GridTracker" or rather implementing something like GridTracker but only in Node-Red with HamAlert.

Following the HAM principle of signals, perhaps the best usage is based on the fact that without a secondary radio, it is not that easy to gauge how good your own signal is. FT-8, for example, is an entire study of how short messages propagate over the planet on the upper / lower sidebands, such that making contact involves exchanging signal reception values (in this case, HamAlert calls this the snr as in, signal-to-noise ratio and the dB mention in the rawText parameter). With HamAlert and Node-Red it is nice to be able to carry out testing without having to necessarily make contact with someone because the emitting station will publish the data automatically when a message is emitted. It's a bit like an all-in-one session where just keying the radio and transmitting a message generates a report from listening stations that will report the signal quality without needing any interaction.