(#44) It's all about the weather this time

Let's make this one short. 

We're still pumping data from legacy sensors into Home Assistant. This time it's data from the two weather stations here.  The long-employed LaCrosse WS2308. Jeez this thing has to be over ten years old by now.  And a newer Acurite 5n1 station.

Both systems use the 433MHz spectrum to send data from their outside sensors to their base stations. Both 433MHz protocols are recognized and decoded by the "rtl_433" open source software.

Rtl_433 can output the intercepted data as JSON payloads which, in turn, can be pumped right into our MQTT (mosquitto) broker.

Those JSON payloads aren't immediately edible by Home Assistant. 

Or, if they are, they require an expertise in programming Home Assistant, that I don't have. So, I've stuck something in the middle.

Something easy. 

Something that subscribes to the RTL JSON payloads and republishes out new JSON payloads in the MQTT Device Discovery Format that Home Assistant understands.

A lesson learned from the previous success was to treat each sensor separately. The Acurite 5n1 sends over: temperature, humidity, wind speed, wind direction and rain totals.  

That's five separate sensors, five different MQTT Device Discovery Configuration Messages.

MQTT Data Payloads

The Acurite 5n1 sends this sensor data across two different JSON payloads via rtl_433. We break out the data to five sensors. It's similar for the WS2308 station (which is labeled as WS2310 by rtl_433). The sensor data for four sensors are scattered across three MQTT messages.

Here's the rtl_433 output for the WS2308 (aka WS2310) station:

{"time" : "2022-10-18T13:47:05", "protocol" : 34, "model" : "LaCrosse-WS2310", "id" : 28, "humidity" : 35, "mod" : "ASK", "freq" : 434.020, "rssi" : -6.215, "snr" : 31.158, "noise" : -37.373}

{"time" : "2022-10-18T13:47:05", "protocol" : 34, "model" : "LaCrosse-WS2310", "id" : 28, "wind_avg_m_s" : 0.000, "wind_dir_deg" : 22.500, "mod" : "ASK", "freq" : 434.019, "rssi" : -6.265, "snr" : 31.108, "noise" : -37.373}

{"time" : "2022-10-18T13:47:06", "protocol" : 34, "model" : "LaCrosse-WS2310", "id" : 28, "temperature_F" : 65.480, "mod" : "ASK", "freq" : 434.020, "rssi" : -6.238, "snr" : 29.886, "noise" : -36.124}

MQTT Device Discovery Configuration Messages

And here's a code snippet to create the configuration MQTT topic and message.

For each station, create the configuration messages for each sensor in that station.

Forward Station Data to Home Assistant

With the configuration messages created and sent to Home Assistant, now just forward the data packets from the weather stations to the new topics specificed in the configuration messages:

Topic: 

home/LaCrosse-WS2310-28/temperature 

Payload:

{"time" : "2022-10-18T14:53:17", "protocol" : 34, "model" : "LaCrosse-WS2310", "id" : 28, "temperature_F" : 66.200, "mod" : "ASK", "freq" : 434.020, "rssi" : -6.537, "snr" : 29.587, "noise" : -36.124}

And don't forget the state message.

Topic:

home/LaCrosse-WS2310-28/state 

Payload: 

{"state":"online"}

The sensors now all show up in Home Assistant!

(#43) Home Assistant Legacy Sensors - Part 3

It's working. Mostly.

With success from hooking the Tuya Air Quality Monitor (non-Zigbee) WiFi up to Home Assistant using the MQTT Device Discovery Protocol, it was not a lot of work to get the Eaton Home Heartbeat (HHB) sensors added.

As mentioned before, the HHB sensors are Zigbee based but I'm unable to quickly see how to unpair them from the Eaton base station and see if they'll re-pair to my Sonoff Zigbee dongle.

So, since the code that reads the HHB sensor data by polling the base station has been up and running for eight years, I made the decision to just add in the MQTT packets to support MQTT Device Discovery. And see if the sensors will appear in Home Assistant.

For the impatient, yes it works. The HHB sensors are now showing up in Home Assistant. The HHB Open/Close sensors, the Tilt Sensor, the Power Sensor, the Wet/Dry Sensor and the Motion sensors all are reporting their status in Home Assistant.

The only downside that I've discovered so far is the lag between a change in a sensor's status and when Home Assistant reflects the state change. That's because the old HHB code polls the gateway for sensor status changes.  So there's a couple of seconds of delay between a state change and the UI reflecting the state change.

No biggie. I can live with that.

Implementation - Summarized

The details are irrelevant; they're specific to my original code from 2013. And you can't buy these sensors anymore.

Nonetheless, for the curious, here's a brief summary:

- original code 'discovered' all of the HHB sensors at startup, by polling the gateway

- new Home Assistant (HA) code, added a call to "HA_CreateConfigurationMessage( HHB_Device )" as each sensor was discovered

Configuration messages were type "binary sensor". Here's the one for the HHB Open/Close Sensor:

 const   char *configTemplate_OpenCloseSensor = 
        "{\"availability\":[{\"topic\":\"%s\",\"value_template\":\"{{ value_json.state }}\"}],"       
        "\"device\":{\"identifiers\": [ \"%s\"],"                                                     
        "\"manufacturer\":\"Eaton\",\"model\":\"HHB OpenClose\",\"name\":\"%s\",\"via_device\": \"HHB\" },"  
        "\"device_class\":\"door\",\"enabled_by_default\":true,\"expire_after\" : 3600,\"force_update\" : true," 
        "\"name\":\"%s [%s] OpenClose\","               
        "\"state_topic\":\"HHB/%s\","                   
        "\"unique_id\":\"%s_OpenClose\","           
        "\"payload_on\":\"OPEN\", \"payload_off\":\"CLOSED\","   
        "\"value_template\":\"{{ value_json.state }}\"}";

The "%s" string substitutions were the MAC address for each sensor.

And then published to an MQTT Topic like:

homeassistant/binary_sensor/%s/config

Again, where the subsitution was the device MAC address.

Most of the sensors (all but the Power Sensor) also had a battery configuration message sent.
// The Eaton HHB battery levels are binary - either OK or not
    const   char *configTemplate_Battery = 
        "{\"availability\":[{\"topic\":\"%s\",\"value_template\":\"{{ value_json.state }}\"}],"       
        "\"device\":{\"identifiers\": [ \"%s\"],"                                                     
        "\"manufacturer\":\"Eaton\",\"model\":\"HHB OpenClose\",\"name\":\"%s\",\"via_device\": \"HHB\" },"  
        "\"device_class\":\"battery\",\"enabled_by_default\":true,\"expire_after\" : 3600,\"force_update\" : true," 
        "\"name\":\"%s [%s] Battery\","               
        "\"state_topic\":\"HHB/%s\","                   
        "\"unique_id\":\"%s_Battery\","           
        "\"payload_on\":\"LOW BATTERY\", \"payload_off\":\"BATTERY OK\","   
        "\"value_template\":\"{{ value_json.battery }}\"}";

To a topic of:

homeassistant/binary_sensor/%s/battery/config

That took care of telling Home Assistant to expect new sensors. Then it was a small addition to publish the unchanged data payload to a new MQTT topic.

Data Payloads still look like:

{"topic" : "HHB/STATUS",  "dateTime" : "2022-10-04T13:37:31-0600" , "deviceType" : 23 , "type" : "MOTION SENSOR" , "name" : "Dining Room Motion" , "state" : "MOTION" , "duration" : 60 , "setAlarmAction" : "ALARM ON MOTION" , "unsetAlarmAction" : "NO ALARM ON NO MOTION" , "setCallAction" : "DO NOT CALL ON MOTION" , "unsetCallAction" : "CALL ON NO MOTION" , "online" : "ONLINE" , "battery" : "BATTERY OK" , "triggered" : "TRIGGERED" , "MACAddress" : "0000093BF5" }

And published to a topic like:

HHB/0000093BF5 

There's a new payload to indicate sensor state. I think I could have told HA to parse state from the existing payload, but since this approach worked for the Tuya sensor, I just added it here.

{"state":"online"}

HHB/0000093BF5/STATE 

And that's about it. Like I said - the original code is from 2013 and updated a personal web page. So that's unique to me. And you can't buy these HHB sensors any more.  There's no sense going into more detail.

It's working.

I salvaged the existing sensors and have them integrated with Home Assistant. 

That's good enough for me, for today.