MQTT Discovery Message - Hampton Bay Fans

Theengs OpenMQTTGateway Radio frequencies gateways 315mhz, 433mhz, 868mhz
1

I thought I would share a concept I’m working thru in regards to controlling my Hampton Bay fans via HomeKit/Homebridge. In my setup I already have a lot of Tasmota Devices so have a pretty robust MQTT Setup, and am using the homebridge-tasmota plugin which uses Home Assistant MQTT Discovery messages to create devices in HomeKit. And I also use node-red for a little bit of everything. And for a OpenMQTTGateway Device, I’m using an ESP32 based device with a CC1101 RF Transceiver connected.

My concept is to use Home Assistant MQTT Discovery message to create the FAN/Light accessory in HomeKit. So far this is working pretty good with my homebridge setup, but am thinking it should also work with a real Home Assistant setup ( with changes for your setup )

To create the FAN controller I’m injecting this Mqtt message via a node-red inject node ( Code 1000 )

{
    "avty_t": "~LWT",
    "name": "Test Fan 1",
    "uniq_id": "3C71BF9E0770_F1_1",
    "payload_high_speed": "{\"value\": 1119,\"protocol\": 6,\"length\": 12,\"delay\": 437,\"mhz\": 303.732}",
    "payload_medium_speed": "{\"value\": 1135,\"protocol\": 6,\"length\": 12,\"delay\": 437,\"mhz\": 303.732}",
    "payload_low_speed": "{\"value\": 1143,\"protocol\": 6,\"length\": 12,\"delay\": 437,\"mhz\": 303.732}",
    "pl_off": "{\"value\": 1149,\"protocol\": 6,\"length\": 12,\"delay\": 437,\"mhz\": 303.732}",
    "pl_avail": "online",
    "pl_not_avail": "offline",
    "speeds": [
        "off",
        "low",
        "medium",
        "high"
    ],
    "cmd_t": "~commands/MQTTto433",
    "device": {
        "name": "cc1101-9e0770",
        "model": "[\"BME280\",\"BH1750\",\"RF\",\"Pilight\",\"rtl_433\"]",
        "manufacturer": "OMG_community",
        "sw_version": "esp32dev_rtl_433",
        "identifiers": [
            "3C71BF9E0770-1"
        ]
    },
    "~": "home/cc1101-bbbbbb/"
}

On the topic homeassistant/fan/9e0770_F1_1/config

And for the light I’m injecting this message

{
    "avty_t": "~LWT",
    "name": "Test Ceiling 1",
    "uniq_id": "3C71BF9E0770_LI_1",
    "pl_on": "{\"value\": 1150,\"protocol\": 6,\"length\": 12,\"delay\": 437,\"mhz\": 303.732}",
    "pl_off": "{\"value\": 1150,\"protocol\": 6,\"length\": 12,\"delay\": 437,\"mhz\": 303.732}",
    "pl_avail": "online",
    "pl_not_avail": "offline",
    "cmd_t": "~commands/MQTTto433",
    "device": {
        "name": "cc1101-9e0770",
        "model": "[\"BME280\",\"BH1750\",\"RF\",\"Pilight\",\"rtl_433\"]",
        "manufacturer": "OMG_community",
        "sw_version": "esp32dev_rtl_433",
        "identifiers": [
            "3C71BF9E0770-1"
        ]
    },
    "~": "home/cc1101-9e0770/"
}

On this topic homeassistant/light/9e0770_LI_1/config

In the files ‘9e0770’ is my OMG device

2

Indeed it should be interesting to make the RTL_433 devices detected “auto discovered” into HASS.
We could add the devices definition into ZgatewayRTL_433 with the same principle as ZgatewayBT autodiscovery of BLE devices.
Checking the messages that you’ve added as an example I think we should be careful regarding the JSON buffer and the MQTT max packet size.
The other challenge could be also the size of the program.

3

I have been thinking about this further and the challenge will be constructing a discovery message with the current topic structure

For example, this is a message from my acurite refrigerator thermometer

{"model":"Acurite-986",
  "id":54381,
  "channel":"1R",
  "battery":"OK",
  "temperature_C":2.22222,
  "status":0,"mic":"CRC",
  "protocol":"Acurite 986 Refrigerator / Freezer Thermometer",
  "rssi":-80,
  "duration":138235}

And this is a MQTT discovery message I have been hand crafting

{
    "stat_t": "~RTL_433toMQTT",
    "name": "Test Fridge Temperature",
    "uniq_id": "240AC4EC20DCtemprtl",
    "dev_cla": "temperature",
    "val_tpl": "{% if value_json is defined and value_json.id == 54381 %} {{ value_json.temperature_C | is_defined }} {% endif %}",
    "unit_of_meas": "°C",
    "device": {
        "name": "cc1101-ec20dc",
        "model": "[\"BME280\",\"RLT_433\",\"BT\"]",
        "manufacturer": "OMG_community",
        "sw_version": "development-rtl_433",
        "identifiers": [
            "240AC4EC20DC"
        ]
    },
    "~": "home/cc1101-ec20dc/"
}

Am thinking the complexity would be to define the value_template and including the appropriate id

One other thought I had was to follow the rtl_433 approach and publish a unique topic for each unique device, ie RTL_433toMQTT//<sensor_id>/channel

It would simplify the value_template immensely but add more topics to manage

{
    "stat_t": "~RTL_433toMQTT/Acurite-986/54381/1R",
    "name": "Test Fridge Temperature",
    "uniq_id": "240AC4EC20DCtemp54381",
    "dev_cla": "temperature",
    "val_tpl": "{{ value_json.temperature_C }}",
    "unit_of_meas": "°C",
    "device": {
        "name": "cc1101-ec20dc",
        "model": "[\"BME280\",\"RLT_433\",\"BT\"]",
        "manufacturer": "OMG_community",
        "sw_version": "development-rtl_433",
        "identifiers": [
            "240AC4EC20DC"
        ]
    },
    "~": "home/cc1101-ec20dc/"
}
4

It makes sense and will be closer to what we do with BLE. The mac address is the ID in this case.

What is the channel for, in your example ?

Also I’m not sure we need the model into the topic structure.

We could have :

~RTL_433toMQTT/54381/(1R)
5

What is the channel for, in your example ?

My acurite device includes channel to indicate that it is physical unit #1, the unit has a second sensor that is channel 2F. The ID number changes everytime the battery is changed with this unit ( which is pretty typical )

What do you use for your main system, home assistant ? Would it make sense to make the solution compatible with this Home Assistant Add-on: rtl_433 with MQTT auto discovery - Home Assistant OS - Home Assistant Community

It would also need to include support for whitelisting and/or blacklisting

6

Digoo temperature sensor are also doing this : -(

I have home assistant, I run also one instance of openhab for other purposes.

Well, that’s a good architecture question, does mqtt autodiscovery code is more relevant into an addon rather than the gateway itself ? I don’t have the answer yet. The only drawback that I see if we put the discovery code into an hass addon, is that Openhab that uses hass auto discovery mechanism will be excluded unless we develop a binding for it.

There is a wip for RF gateway below

7

Just for reference in this conversation, this is the MQTT Topic defaults from rtl_433

Publishing MQTT data to 192.168.1.12 port 1883
Publishing device info to MQTT topic "rtl_433/HOSTNAME/devices[/type][/model][/subtype][/channel][/id]".
Publishing events info to MQTT topic "rtl_433/HOSTNAME/events".
Publishing states info to MQTT topic "rtl_433/HOSTNAME/states".

And this is what it looks like in MQTT Explorer

image
image605×768 46.8 KB

8

Note that after thinking about it, I think we could keep the principle of managing MQTT discovery into OMG and not via an add on.

Some pros :

  • no separate add on to manage
  • auto discovery mechanism already in place in the code
  • keep the compatibility with openhab
    Some cons :
  • mqtt discovery messages will be big but as rtl433 gateway is only compatible with esp32 I dont see difficulties to handle them. Especialy we could improve the json buffer allocation.
9

I was also thinking about having it as a common component for multiple gateways, then space may not get too excessive but at the risk of added complexity. May need to play with it as a concept first though to ensure that the approach would work.

I’m currently working thru enabling the FSK device decoders, then will switch to this. I have a user looking for support of his WH51 devices.

1 Like
10

I think there is room for a separate library that handles discovery by MQTT following a device model, I will think about it. It could be used by different gateways and manage different discovery conventions.

11

I had just noticed the definition ‘valueAsASubject’ and am thinking this should be a required definition as part of the MQTT Discovery process as it would greatly simplify the creation of discovery messages. I’m going to use this as a requirement as I look further into adding MQTT Discovery Support for rtf_433_ESP.

12

ok, note also that this way we are consistent with the behavior of ZgatewayBT. With this gateway the MAC address of the discovered sensor is also integrated at the end of the topic.

13

Going back to my original topic here, Hampton Bay Fans, I had a friend give me a Sonoff IFAN03 and am currently trying it out instead of my original Hampton RF Module. I have flashed it with Tasmota and also changed the motor speed Capacitors for North American usage ( I used the capacitors out of a Hampton Bay unit ). And so far am very impressed with how well it works versus the RF approach where the lights would occasionally get out of sync, and having device state feedback from the unit is another plus. If someone uses the remote my home bridge setup would show the change in device status.

For folks watching, my homebridge-tasmota config homebridge-tasmota/DEVICES.md at master · NorthernMan54/homebridge-tasmota · GitHub