Missing discovery messages for Nexa 433MHz devices

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

Hi!

I’m just getting started with OMG. I think it looks awesome and I cannot wait to (finally) ingest all the 433MHz traffic in my home!

I’ve setup my board configured with the latest dev version (07d9ed) of lilygo-rtl_433 firmware (finding out the hard way that I get stuck in a boot loop if I run the 1.7 release). With this version, I get a bunch of MQTT messages based on devices in my area. That’s fantastic!

However, I’m struggling a bit getting the auto discovery feature in Home Assistant working properly. Watching the messages on my MQTT broker, there are a bunch of devices that does not pop up for me. Notably, my Nexa devices does not seem to get discovered automatically. Or rather, I do get an rssi sensor for one of my devices, but there is also (much more interestingly) a state field indicating if “ON” or “OFF” was pressed and that does not get picked up. And the other device is missing completely:

Discovered "Nexa" devices in Home Assistant

When browsing around with MQTT Explorer, I find that there are sensor data messages getting sent on MQTT but HA does not discover them since the discovery messages are missing:

MQTT Explorer showing messages with "Nexa"
MQTT Explorer showing messages with "Nexa"1920×1080 145 KB

This is the discovery message being sent on homeassistant/sensor/Nexa-Security-3-7559323-rssi/config:

{"stat_t":"+/+/RTL_433toMQTT/Nexa-Security/3/7559323","dev_cla":"signal_strength","unit_of_meas":"dB","name":"rssi","uniq_id":"Nexa-Security-3-7559323-rssi","val_tpl":"{{ value_json.rssi | is_defined }}","state_class":"measurement","device":{"ids":["Nexa-Security-3-7559323"],"cns":[["mac","Nexa-Security-3-7559323"]],"mdl":"Nexa-Security","name":"Nexa-Security-3-7559323","via_device":"OMG_1"}}

Example of the sensor data being sent on 433MHz/OMG_1/RTL_433toMQTT/Nexa-Security/3/7559323:

{"model":"Nexa-Security","id":7559323,"channel":3,"state":"OFF","unit":1,"group":0,"protocol":"Nexa","rssi":-82,"duration":622071}

Any idea why this is so? A bug in the gateway, or just the sad reality of being on the lackluster RF433 protocol?

Cheers!

2

That is correct, there are currently no discovery implementations for the “state”, “unit” or “group” additional JSON keys of your Nexa Security devices.

Please try today’s test development build with SHA: 66d614 at

which will be available until about 02:00 UTC tonight, and let us know how the discovery entries are with it.

3

Well that just about explains it! :smiley: Thanks for the info. Where can I read about which fields are supported?

Wow, that’s a blazing fast update you made there! Thanks a bunch, I’ll make sure to try it out and see how it goes.

As long as I know that something is unsupported, I’m OK with writing manual configs for them in Home Assistant. Since these particular devices (a door bell and a remote control) only communicates button presses, I’m extra keen on getting them via auto discovery since the MQTT device trigger (which apparently is " a better option than a binary sensor for buttons, remote controls etc.") does not support manual configuration.

While not ideal, and new to me, I guess I should be able to craft my own auto discovery messages and send them on MQTT. It would be a little bit bothersome to have that configuration outside of my configuration.yaml, but I assume it could work. Does that make sense, you think?

4

In the code, config_RF.h file. This is also where I added the group, state and unit keys for the test builds.

Can you verify that these are being auto-disocvered now and correctly displayed in HA, so that we can go ahead and merge them into the development branch for future inclusion?

Sending your own discovery message would have also been a suggestion from me, but having these keys included in OMG auto-discovery, along all the other existing keys, is really the best option.

5

Sorry for the delay, I had to get home from work.

I’m now on 66d614. Unfortunately, I see no new dm being published.

Here’s the console output for when I press a button:

T: isAdupl?
N: Send on /RTL_433toMQTT/Nexa-Security/3/7559323 msg {"model":"Nexa-Security","id":7559323,"channel":3,"state":"ON","unit":2,"group":0,"protocol":"Nexa","rssi":-41,"duration":611000}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: 433MHz/OMG_1/RTL_433toMQTT/Nexa-Security/3/7559323 msg: {"model":"Nexa-Security","id":7559323,"channel":3,"state":"ON","unit":2,"group":0,"protocol":"Nexa","rssi":-41,"duration":611000} 
T: Min ind: 8
T: store code : 7559323 / 649079
T: Col: val/timestamp
T: mem code : 7559323 / 138129
T: mem code : 7559323 / 218345
T: mem code : 7559323 / 253690
T: mem code : 7559323 / 349372
T: mem code : 7559323 / 355256
T: mem code : 7559323 / 442390
T: mem code : 7559323 / 483090
T: mem code : 7559323 / 541975
T: mem code : 7559323 / 649079
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: isAdupl?
T: no pub. dupl
T: isAdupl?
T: no pub. dupl
T: isAdupl?
T: no pub. dupl
T: isAdupl?
T: no pub. dupl
T: isAdupl?
T: no pub. dupl
T: isAdupl?
T: no pub. dupl
T: isAdupl?
T: no pub. dupl
T: isAdupl?
T: no pub. dupl
T: isAdupl?
T: no pub. dupl
T: isAdupl?
T: no pub. dupl
T: isAdupl?
T: no pub. dupl
T: isAdupl?
T: no pub. dupl
T: isAdupl?
T: no pub. dupl

Fitering on nexa in MQTT Explorer, I see pretty much the same as before:

MQTT Explorer
MQTT Explorer1920×636 68.1 KB

6

Can you make sure that discovery is still/again active, as it turns itself off after 30 minutes of starting up, or stays off if it has been switched off within these 30 minutes.

You can see its state in the SYStoMQTT message of your RTL_433 gateway, after it has been updated after 2 minutes of monitoring with MQTT Explorer.

… "disc":true …

and then it requires a restart after discovery has been turned on again. All also accessible through the HA gateway UI interface.

7

I verified that in Home Assistant. Can/should I check somewhere in the web console too?

I’ll try an extra restart just to be sure. Give me a minute.

8

The HA gateway UI should be fine, but this is also visible and taken from SYStoMQTT for the UI. SYStoMQTT* being visible under your gateway MQTT section in MQTT Explorer, when not filtering for Nexa.

9

And there we go! :tada:

image
image684×508 33.8 KB

Screenshot from 2024-05-28 18-11-40
Screenshot from 2024-05-28 18-11-401920×858 107 KB

At first nothing happened, but then I noticed that the restart seems to have reset the MQTT credentials. So I configured them again and then it worked! So restart + reconfigure MQTT credentials made version 66d614 work!

10

The MQTT credentials requirement shouldn’t really have been happening, but glad it is working now with the discovery messages as intended :slight_smile:

The only thing I’m still seeing as a possible issue is the Unknown entry for the State. Does this update eventually and it was only because of a missing property messages not being received yet with State, or might there be an issue with it being a string?

11

The state seems to continue being “Unknown” even after the other fields are updated when I press the buttons.

Also, it seems that group is really a bool indicating if the “group” button was pressed or not. Should the approach be that we keep it as an int and let Home Assistant treat it as a bool? Or should we convert it to bool?

12

I have just started another test build, which should be available in about 50 minutes, which should make the State a binary-sensor. It will have the SHA: 4249f9. If you could try that one when it’s ready, to see if it correctly gets the new State discovery message and shows values now.

Both Group and Unit are actually defined as Integers in RTL_433, so possibly this might indicate a boolean 1/0, on/off, open/closed or whatever for the different decoders, but being defined as an int I would leave it like that and make any desired casts in HA.

13

I thought so. Just wanted to check so you made that decision intentionally, not by mistake. :upside_down_face:

Just one more thing: I’m honestly pretty unfamiliar with the MQTT device trigger, all I know is that they write that it is " a better option than a binary sensor for buttons, remote controls etc.". Since my devices are buttons, should we consider that type? Or maybe it does not make sense for a technical reason that I do not know about.

14

Being not that well versed with HA’s ins and outs, I honestly don’t know about the MQTT device trigger, but as other RTL_433 decoders are also using these properties, possibly some in a slightly different way, it’s best to leave the property discoveries as general as possible.

1 Like
15

@lindhe

The test build SHA: 4249f9 is now available.

Please let us know how the State property is being discovered and behaving now.

16

Thanks. I’m on 4249f9 now. Unfortunately no luck with the state. I’ve even reflashed and restarted again twice just to be sure.

Here’s the last retained dm for state:

{"stat_t":"+/+/RTL_433toMQTT/Nexa-Security/3/7559323","name":"State","uniq_id":"Nexa-Security-3-7559323-state","val_tpl":"{{ value_json.state | is_defined }}","state_class":"measurement","device":{"ids":["Nexa-Security-3-7559323"],"cns":[["mac","Nexa-Security-3-7559323"]],"mdl":"Nexa-Security","name":"Nexa-Security-3-7559323","via_device":"OMG_1"}}

BTW: same thing still with the MQTT dropping my credentials after first reboot.

N: ZwebUI setup done
N: RF Config not found using default
N: Enable RTL_433 Receiver: 433.92Mhz
N: ZgatewayRTL_433 setup done 
N: OpenMQTTGateway modules: ["LilyGo_SSD1306","WebUI","rtl_433"]
N: ************** Setup OpenMQTTGateway end **************
W: MQTT connection...
W: failure_number_mqtt: 1
W: failed, rc=-2
W: MQTT connection...
W: failure_number_mqtt: 2
W: failed, rc=-2
W: MQTT connection...
W: failure_number_mqtt: 3
W: failed, rc=-2
W: MQTT connection...
W: failure_number_mqtt: 4
W: failed, rc=-2

May not be related, but I’ve also noticed that the “console” like info screen in the web console looks different after first reboot:

First boot after flash After first reboot After second reboot
First boot
First boot499×593 24.9 KB
First reboot
First reboot499×593 19.4 KB
second rebooot
second rebooot499×593 24.7 KB
17

Oh! I thought that nothing had change, but something has! Before we had state unknown. Now we have that twice!

image

This made me realize I posted the wrong dm payload before. I watched the old topic. Here’s the new one:

{"stat_t":"+/+/RTL_433toMQTT/Nexa-Security/3/7559323","name":"State","uniq_id":"Nexa-Security-3-7559323-state","val_tpl":"{{ value_json.state | is_defined }}","pl_on":"1","pl_off":"0","device":{"ids":["Nexa-Security-3-7559323"],"cns":[["mac","Nexa-Security-3-7559323"]],"mdl":"Nexa-Security","name":"Nexa-Security-3-7559323","via_device":"OMG_1"}}
18

Some debug info from HA:

image
image568×828 26.1 KB

19

Think I’ve spotted the issue!

The discovery message says payload_on: '1', payload_off: '0' in HA ("pl_on": "1", "pl_off": "0" in MQTT), but the published message has "ON" for on and "OFF" for off.

20

Yes, I was already treading that this might happen, when turning the State into a binary-Sensor, but hoped that there would be a boolean binary state auto-conversion. Also looking at the other occurrences of State in RTL_433 I found that it could also be “open”/“closed” and for some decoders even an integer, probably allowing for more that just two states.

The final solution, which would be applicable to all of these different State type, is to change this discovery into a sensor, but allowing for the actual string to be displayed,regardless from which decoders it is coming from.

Let me have a proper look at this tomorrow, when I’ll also then issue another test build for you to try out.

With your credentials being lost, did you untick Flash Erase when uploading the new test builds, and could that have caused it?

And with the new test build tomorrow, you best delete the two current discovery messages for State, so that only the new, and hopefully then correct, one will be present.

1 Like