Friday, December 12, 2025

 Correlation



Seeing Red


If you're into events, and you've not tried Node-Red, I think you're missing something.  Node-RED is a low-code, browser-based programming tool for visually wiring together hardware devices, APIs, and online services into event-driven applications, especially popular for IoT. It uses a graphical editor where users drag and connect "nodes" (representing functions or endpoints) to create "flows" (automations), making it easy to handle data, automate tasks, and build complex systems without extensive coding, running on Node.js.


I've got an instance running on the Raspberry Pi in the RV (and one at home too).  Here's one flow that's responsible for getting the latest weather forecast based on my location.




A little explanation might help. Upper Left, purple "RV GPS" is a node that connects to the MQTT broker and subscribes to the GPS topic. Every time a message arrives on this topic, the node is activated and pushes the message to the next node.



"Once every 15 minutes" is a node that filters out the GPS messages that arrive every minute, discards them, and passes one along every 15 minutes. (The time is configurable. As is to discard or queue messages.)  I don't need an updated forecast every minute, one every 15 minutes will do.



"Create NOAA Points URL" is a node with Javascript (thanks ChatGPT) that takes my current latitude and longitude and puts it into a format that NOAA wants. Like this:





In order to get the forecast for my location, I need to call the NOAA public "Points" API first. This call returns a payload that's almost ready to pass to the NOAA Forecast API, but I set the granularity to Hourly. I'm only interested in an hour-by-hour forecast.



The call to the NOAA public Forecast API returns a ton of data. Often 24 hours (or more) of forecast information. I'm only concerned about the next four hours so another Javascript node pares the payload down:





From there, I do more paring down of the forecast data to just the things I care about. Craft a new JSON payload and pass it to a MQTT Node that will publish the data on a topic I've also created:


{

   "topic":"WEATHER/FORECAST/NOAA",

   "dateTime":"2025-10-03T18:13:18-06:00",

   "version":"1.0",

   "period":"hourly",

   "forecast":[

      {

         "hour":0,

         "startTime":"2025-10-03T18:00:00-06:00",

         "isDaytime":false,

         "temperature":79,

         "humidity":23,

         "windSpeed":7,

         "windDirection":"NNE",

         "description":"Partly Cloudy",

         "precipProbability":2

      },

      {

         "hour":1,

         "startTime":"2025-10-03T19:00:00-06:00",

         "isDaytime":false,

         "temperature":75,

         "humidity":27,

         "windSpeed":6,

         "windDirection":"N",

         "description":"Partly Cloudy",

         "precipProbability":2

      },

      {

         "hour":2,

         "startTime":"2025-10-03T20:00:00-06:00",

         "isDaytime":false,

         "temperature":70,

         "humidity":32,

         "windSpeed":6,

         "windDirection":"NW",

         "description":"Partly Cloudy",

         "precipProbability":2

      },

      {

         "hour":3,

         "startTime":"2025-10-03T21:00:00-06:00",

         "isDaytime":false,

         "temperature":65,

         "humidity":38,

         "windSpeed":7,

         "windDirection":"WNW",

         "description":"Partly Cloudy",

         "precipProbability":2

      }

   ]

}


I use Node-Red to do a lot of work. As in:

- insert MQTT events into InfluxDB, a superb time-series database (also running on the Pi)

- throttle and forward events to my home server, in real-time

- call NOAA's Alerts API to see if there are active weather warnings at my location

- process OBD2 messages from the vehicle, calculate MPG and range 

- call public Geocoding services to look for gas stations (or other POIs) around my location


And many other things.


 

It's been a while.

So. Where ya' been? What's new? Read any good books lately? It's been a while.


Indeed.




Let's pick on what's new in the RV.  It's on-line. Let's outline the major changes starting with the network.


The Raspberry Pi based access point that was providing the RV WiFi Network has been unplugged. 


A New Router

In its place is a Netgear N750 (WNDR4300) router running OpenWRT v24.10 and the Travelmate package to provide an access point. Having a dedicated router has made things easier, more capable and more reliable. 


Running OpenWRT means the router can send status and health messages over MQTT. As in:


{

   "dateTime":"2025-10-03T17:58:00",

   "router_hostname":"OpenWrt",

   "wifi_interfaces":[

      {

         "interface":"phy0-ap0",

         "essid":"C*****",

         "access_point":"28:***",

         "mode":"Master",

         "channel":1,

         "frequency_ghz":2.412,

         "hardware":"embedded [Atheros AR9340]",

...

         "phy_name":"yes"

      },

      {

         "interface":"phy1-ap0",

         "essid":"C*****",

         "access_point":"28:****",

         "mode":"Master",

         "channel":149,

         "frequency_ghz":5.745,

         "hardware":"168C:0033 168C:A120 [Atheros AR9580]",

         "phy_name":"yes"

      },

      {

         "interface":"phy1-sta0",

         "essid":"SG",

         "access_point":"2F",

         "mode":"Client",

         "channel":149,

         "frequency_ghz":5.745,

         "hardware":"168C:0033 168C:A120 [Atheros AR9580]",

         "phy_name":"yes"

      }

   ],

   "connected_clients":{

      "count":3,

      "clients":[

         {

            "mac":"a",

            "hostname":"foo",

            "ip":""

         },

         {

            "mac":"b",

            "hostname":"bar",

            "ip":""

         },

         {

            "mac":"c",

            "hostname":"too",

            "ip":""

         }

      ]

   }

}


[ Thank you ChatGPT, or Claude, for writing the 'ash' shell script that pulled the data from the router, crafted the JSON packet and sent it out. ]


At a glance I can tell how the router is working and if the expected clients are connected.


Travelmate provides an Access Point and uplink capability. Right now, I have the 2.4GHz radio in the router configured as the AP. The 5GHz radio in the router is the internet uplink. When the RV is parked, an old Samsung smartphone with a Tello data plan provides Internet access.  A 2GB/month, $6 plan is sufficient to support the data consumption.  So far, I seem to be using about 30-40MB per day.




When I'm in the RV, or camped and want to do system updates or other data intensive tasks, I can fire up Starlink or the hotspot on my phone (a 20G Mint Mobile plan).  





A great feature of Travelmate is that it will monitor all configured available uplinks/hotspots and connect to a higher priority one.  This means that all I have to do when I'm in the RV is enable the hotspot on my phone.  After a minute or so, the router switches from the 2GB Tello phone to my 20G Mint Mobile device. And I can do large data updates without consuming all of my Tello data. 



Power!

I had been hesitant to use a dedicated router because of my guess-timated power
consumption. But now that the RV has 200Ah of LiFePO4 battery there's sufficient power to run the systems for several days. 


I measured the current consumption of the router to be about 2.5A.  And it's powered by 12V DC. A simple buck converter was installed to ensure the 13-14V of battery power is pulled down to a consistent 12V DC. The router and Raspberry Pi can stay on all of the time without concerns about depleting the batteries.


The router, the Pi, the ESP32 and the phone are all connected to the Load Output on the EPEver MPPT controller. I can monitor the current.  When things are idling, the power consumption is very small.





Weather Now

The second big change is the 433MHz RF devices in the RV.  I found another Acurite 5-in-1 weather station on sale for $50.  It stays in the RV and gets pulled out and put up when we stop.  This station transmits all data on 433MHz. 


There are four other temperature and humidity sensors around the RV that also send on 433MHz.






433Mhz Reception


A dedicated ESP32 microcontroller with a 433MHz receiver running OpenMQTTGateway and a port of the RTL433 software provides protocol decoding.  

The binary data from the devices are intercepted, converted to JSON and sent over MQTT:


{"model":"Nexus-TH", "id":22, "channel":2, "battery_ok":0, "temperature_C":34.6, "humidity":22, "protocol":"Nexus, FreeTec NC-7345, NX-3980, Solight TE82S, TFA 30.3209 temperature/humidity sensor", "rssi":-50, "duration":731000}


{"topic":"WEATHER/CURRENT/ACURITE", "dateTime":"2025-10-03T18:13:21-06:00", "version":"1.0", "station":"2796", "channel":"A", "temperature":81, "humidity":46, "windSpeed":0, "windDirection":135, "rain":1.3}


One disappointment is that this setup is not able to receive and decode the transmissions from the TPMS sensors on all six RV wheels. I've made a number of attempts to decode and have not been successful. I've tried contacting the TPMS vendor, asking if they'd publicize their protocol details and they've refused.


Next up - It's Brian's Fault

Sunday, March 10, 2024

Staying out of the Ditch (Part II)

 

Staying Out of the Ditch

About four years ago, now, we had a helluva scare in Wyoming. A sudden gust of wind pushed us into the ditch. Emmy was driving; we had slowed down to about 45mph, thankfully.  

I'd like to try to avoid that again, if possible.

See Part I of this post where I cover off how I get the forecasted weather conditions for my current location.

A quick recap:

  • there's a GPS receiver on top of the RV that tells me my current location, as a latitude/longitude pair every minute
  • I'm calling the NOAA's weather API to get the weather forecast for my current location
  • I'm also calling the NOAA's Alerts API to pull any severe weather conditions that are around me.


"The World Needs More Lerts."

Just like I take my current latitude and longitude and get the hourly weather forecast for "here", I pass those coordinates into the NOAA Alerts API. The NOAA call returns a JSON packet with no alerts, or the ones issued for my area.



NOAA returns a ton of information. And, as before in the forecast return data, I only clip out the information I think is necessary to display.  That's

  • The Event (eg. Wind, Snow, Rain, Flood...)
  • Urgency (Immediate, Expected, Future, Past)
  • Certainty (Observed, Likely, Possible, Unlikely)
  • Severity (Extreme, Severe, Moderate, Minor)
  • SAME Code
  • Details

You can read the NOAA documentation for more information about the return values.   The first four are self-explanatory. The SAME code is a number that you can enter into a Weather Radio that supports such codes. Punch the SAME code into the weather radio, and it will watch for alerts in this area. A SAME code designates a geographic area (more or less).

The last column, details, is simply a constructed hyperlink to the details on this alert. Click it and it will retrieve the full alert data.

Here's an example:



We'll "start to end" Part II here.

Part III, when I get around to it, will go into the implementation details.  But before I end Part II, some thoughts on the "Why?"

Why Bother?

Isn't this "re-inventing the wheel"? Isn't this information -- and more -- already available from a number of apps on any phone in 2024?

Sure.

So why?

A couple of reasons, some selfish, some pragmatic:

  • The apps on a phone are "pull" in nature. I have to take action to get the information. I have to stop watching the road, and press buttons on my phone to request the data.  Pulling data in 2024 is insanely stupid, IMO. The computer(s) have all of the capability to push data to me.
  • The apps on a phone have a user-experience that appeals to their developers. That may or may not be the way I want to consume the data.
  • The apps on the phone have a UI that changes whenever the developer feels like it. That sometimes aggravates me. I just get the muscle-memory set to use the app with minimal thought, and the developer decides to change things.

I can continue to refine the experience to tailor the output to my needs.  Some of the things I've thought about for V2 are:

  • tailor the wind warnings for heightened alert if the direction will be broadside
  • play the Star Trek Red Alert sound when some urgent alert comes in
  • pull up alerts and forecasts for where I'm heading, instead of just where I am
  • add a NOAA radar screen so I can see a current radar

And so on. I'm sure I'll come up with some new ideas for the next revision. Even more so after I use this one in the RV for a while.