Github Boards Devices Community Docs Blog

MQTT Discovery Message - Hampton Bay Fans

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

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.

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/"
}

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)

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

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

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

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.

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