HamAlert on the Desktop
I love the HamAlert app: it’s an ingenious tool that queries SOTA, POTA, RBN, PSKReporter, etc. spots and pushes them to your phone, and elsewhere, for filters you set up (called “triggers”). It’s a great way to stay abreast of when your ham friends are on the air, a DXCC station you need appears, or if someone is activating a summit or park in a part of the country that you want to chase. It’s very versatile!
However, I don’t enjoy having my phone buzz or make noises all of the time, or having to look at it regularly to make sure I don’t miss someone when they’re on air. I had wished there was some way to view it on my desktop— I knew it was possible, I just didn’t know how to make it happen. But then, the other night, a fellow new ham on Mastodon was posting about how they used ntfy.sh to push HamAlert to their de-googled phone. This caused me to look a little deeper at some of the functionality HamAlert has for pushing notifications to other destinations besides the app, and voila! — resulted in my writing a Python script to make HamAlert notifications appear in a terminal window.
The way it works is that one can configure HamAlert (Under the “Destinations” tab) to send a POST request to a ntfy.sh server each time it gets triggered to send an alert. One can just view this on ntfy.sh itself, but it’s an ugly raw URL parameter hash from HamAlert: it needs to be parsed into something human readable, which is where the Python script comes in. Ntfy.sh has JSON, and other, endpoints with nice instructions on how to write some very simple Python to access it. This served as a great strarting point for the script I wrote, whose main function is to parse out the hash from HamAlert and make it pretty.
It was much easier than I thought it would be! It was also a stark reminder of how rusty I had gotten with Python, especially some of the nuances with how urllib handles dictionaries, dictionary esoterica in general, and the myriad ways Python can parse parameters in POST requests.
The script could be tighter and more efficient, using a function or two to cut down on some of the repetition. Goodness knows it still has bugs that will likely appear when HamAlert sends a type of message that I didn’t anticipate, but it’s up on my GitHub repository if you want to play with it yourself. See the bug reports for things I’m currently attempting to improve.
As an aside, if you don’t want to use the ntfy.sh main server, M0YNG maintains a fediverse.radio ntfy server you can use (and if you do, please drop him a few bucks!). Details are at fediverse.radio
After writing this, it occurs to me I never tested this using non U.S. callsigns, POTA entities, or SOTA summits. I should probably work on that… 😬
Things I will be adding in the near future to the script:
- The country of a callsign isn’t shown if it’s outside the U.S. (this will show the country a POTA park is in, or the country of the call for SOTA, RBN, etc.)
- Clickable links for the callsign (QRZ), POTA entity, or SOTA summit (SOTL.AS)
- Option to show times in local time, via a UTC offset, and not just UTC.
- General cleanup and tidying up of code.
- Bugfixes. The script currently has a few bugs, including it not resetting the state between some notifications, which results in non-U.S. callsigns having the state of the previous notification displayed.
Update: N6CTA pointed out something that I had missed— one can connect via telnet to HamAlert and see notifications in the terminal, or via a logging program, on one’s desktop. I tried this at his suggestion and it’s a lot simpler than my Python script, and doesn’t involve using an intermediary like ntfy.sh. However, the telnet connection supplies much less information than HamAlert’s POST to URL method. That being said, it’s a much simpler way to go about the whole thing, involving less 3rd party stuff, with less dependencies overall.