Customized Weather Alerts

Okay, so I probably went overboard with this one. However, I personally don’t own a weather radio. If I need to receive an alert, it needs to come through my phone or Alexa. I do have a nifty smoke detector that connects to the NOAA weather alert system, but since Halo Smart Labs went under several years ago it’s days are numbered. I’m using my home automation hardware to my advantage. This flow provides customized weather alerts to my devices.

So, here’s what we’ve got. There’s a couple moving parts here to get this thing set up.

• A home automation hub with a driver/app to pull in NOAA weather alerts. I use Hubitat and a community driver that pulls weather alerts from OWM or weather.gov. Any hub will do as long as you have a driver that can be exposed as a device to Node-RED and it includes weather alerts. There are limitations to this driver that should be noted (see the end of this post).
• Because the driver I use pulls from OpenWeather you will need a free API. Create an OpenWeather account to get the API.
• A working Node-RED instance. See this article on a RPi4 setup.
• A notification service. I use Pushover, but there are several different options out there.
• Optional for voice announcements: Alexa devices and a working Node-RED/Alexa integration. I use the Alexa-cakebaked nodes (forked from Alexa-remote2 after that author went MIA)

Node-RED Sequence

Set up a Node-RED sequence to get customized weather alerts. This sequence, on receipt of a alert, will send a notification to your phone and speak the alert on your Alexa device(s). The notification will be one of three flavors: regular, medium priority, and high priority.

Device Setup

First set up the device nodes. In Hubitat I have installed the driver for OpenWeatherMap-Alerts and set up the device using my OW API. Once created and set up properly, I exposed the device to Node-RED via the Maker API app in Hubitat. To get both the alert type and the alert content you need to add two nodes.

Remember that Node-RED passes everything as a “payload”. My setup will be different than yours if you use a different service, but the principles will remain the same. Two payloads are of interest: msg.payload.alertDescr and msg.payload.alert.

Figuring out the payload

So how do you go about figuring out the payload of interest?

In this first example, the debug node shows what information comes from the alert attribute of the OW node. You can see the name of the object is “alert” and that I am displaying no current alerts. I’m interested in the value of the message, or the msg.payload.value (or even the currentValue). This is the type of alert (Winter Storm Warning, Flood Warning, etc.).

This second example shows the information coming from the alert description attribute of the OW node. Again, the attribute is named alertDescr and it is passing along a value. If I had an actual weather alert for the area it would describe the information passed along from the NWS.

Next, the type of alert and description will be joined. This will allow us to pass along a complete message in one notification.

Join the payloads

Next, we will join the node outputs. We want this to look nice and make sense.

Drop a join node in the sequence. Normally you would have to precede this with a split node (if you want to split an array). In this case we are manually joining the two payloads. Set up the join node as “manual” mode. You’re combing each payload.value using the payload.name as the key. All this means is that each payload.name is unique and identifies which node the payload.value originated. Because we are waiting on two messages (the alert type and the alert description) we want to send after 2 parts are received. We also want to go ahead and send the message after 5 seconds.

In this image we see what the combined payloads look like. Notice the object that initiated the sequence is listed by msg.payload.name. The payload values are then combined and organized by the name of the sending node. For example, the alert description is msg.payload.value.alertDescr.

Customize the weather alert notifications

The next step is to filter out the alerts. To do this use a switch node. There are two ways to figure out the alert naming: add the alerts as you get them or use the chart at weather.gov.

Drop in a switch node and add in the different alert types. I prefer to organize them based on alert severity. This is handy when sending them on to the notification handlers. Importantly, the switch node is interested in the msg.payload.value.alert. Set the node up to stop after the first match.

Set up the notifications

The last step sets up the notifications for customized weather alerts. This step is where all the customization comes in. I’ve got mine set up as follows:

• Low priority notifications (wind advisory, special weather statements) are sent via Pushover as a regular notification. These alerts are announced on Alexa only during Day mode. Low priority alerts are not important enough to get announced while asleep.
• Medium priority notifications are sent as a notification. The priority is increased and they are announced regardless of mode. These alerts include High Wind Watches, Severe Thunderstorm Watches, etc.
• High priority alerts are sent as a high alert notification. Announcements are made on all Alexa devices regardless of mode. These alerts include Tornado Warnings, Winter Storm Warnings, etc.

Alexa devices are optional. However, I find that when Alexa randomly starts talking my entire household listens for some reason.

The function node

The function node is where some of the magic happens. The Pushover node looks for specific parts of a message to format the notification. The function node transforms the data from the OW node into something Pushover can use. This node also defines the priority, devices, and sounds.

Let’s break the node down. Pushover looks for several components: a message (notification body), a topic (or message title), and where to send it. Other information can be included, but in this flow I’m only interested in a title, body, and priority.

In the function node the topic is the alert type (i.e. Winter Storm Warning). As defined previously, this is msg.payload.value.alert. Our message body is the description, or msg.payload.value.alertDescr.

The priority can be set from lowest (-2) to highest (2). You can also visit Pushover to specify the sound. For my high alert notifications I use something particularly annoying.

The Alexa function node is relatively simple. The items we are interested in are the “type”, “devices”, and “text”. Generally, set the “type” to “announcement”.

Your devices can be found either in your Alexa account info or from any of the other Alexa node’s. Devices show up in the dropdown and are entered exactly as written.

Lastly, like the Pushover function node, the Alexa function node combines the alerts. Alexa looks for java scripting so spaces must be explicit. In our case, to get the text to appear correctly and the speech to be correct: msg.payload.value.alert + " " + msg.payload.value.alertDescr. Note the a space is entered in between the quotation marks.

The last part of this block is the Alexa Routine node and my Pushover subflow. The subflow only contains my Pushover node so that I don’t have to re-enter the API key every time I need to use it.

Customize your heart out

The most powerful feature of this sequence is the notification block. I don’t really care about frost or freeze warnings. I do care about tornado warnings and winter storm warnings. This sequence lets me scale those alerts. The best part? Its easy to take the notification block and apply to other sequences. Water leak? Get a high priority alert. Door left open too long? Get a low priority alert.

Limitations

There are a couple of important limitations to using this sequence that should be pointed out. First, this particular driver only shows the first alert issued. It does not order them by type or priority. On a Hubitat dashboard it simply shows “Special Weather Statement +1”. I’m still working to find a weather driver that a) can be exposed to NR and Hubitat and b) allows for splitting out the different alerts. Second, this driver only polls the API according to the frequency you set. By default this is set to 1 hour. To change, on the device page in Hubitat, go to the OpenWeather Alerts Driver, scroll down and change the API refresh. I’ve moved mine down to 5 minutes.

Third, and this should be common sense, don’t rely on one system for alerts. When the consequences of missing an alert can quite literally be deadly, always have a backup. I’ve got this sequence that blasts out alerts to the phones, to my lights, and through Alexa. I’ve also got the built-in phone alert system and a weather alert radio. While this sequence is great for those “useful to know” alerts, I do not rely on it soley for those high priority alerts (tornado warnings) since there are potentially multiple failure points.

Wrapping Up

Next step: get your own personal weather station. Personally I like the Tempest. My PWS drives several other NR sequences and my temperature automation.

Hopefully this sequence also gives you ideas on some other things you can do with NR. Feel free to drop a comment if you have any questions.

**Updated 3/21/21 (added alert driver limitations)

**Updated 4/19/21 (changed node-red-contrib-alexa-remote2 to -alexa-cakebaked)

Author: Zack

Pharmacist, tech guy, pianist, lover of beer, gamer, beach bum. Probably missed something. Just assume I'm into a little bit of everything.