Feature Request: Contact sensors like GS-WDS07

[ideal2545]

Hi,

I'd like to submit a feature request to support generic contact sensors and generic motion sensors like the GS-WDS07 (arguably the most popular 433 contact sensor). I'm more than happy to provide any needed information that I get from RTL_433.

Thank you,
Jon

[pbkhrv]

I don't have that sensor to test with, so will need some info from you.

1. Have you been able to configure the rtl_433 add-on to send data to MQTT? If no, please start there.
2. If you haven't done so already, please install an MQTT explorer app (like https://mqtt-explorer.com/), connect to the same MQTT broker that rtl_433 is sending the data to, and find the "rtl_433/..." topic. It would be great if you could post a screenshot or copy-paste something from the MQTT explorer that could tell me what kind of data rtl_433 is sending to mqtt and how we could autodiscover it.
   Here are couple of examples of what I get from one of my temperature sensors and a motion detection sensor:
   

something like this from your sensor would be very helpful.

[ideal2545]

So I ran down a bit of a rabbit hole for better understanding RTL_433 and GS-WDS07's. In order to properly report, the user cant rely on protocols but has to use a flex decoder like below, its a bit of a black hole but i did come up with a working 'flex decoder':

decoder n=gswds07,m=OOK_PWM,s=476,l=1364,r=15000,g=1600,bits>=24,bits<=25,invert,get=@0:{20}:id,get=@20:{4}:event:[10:open 14:closed 6:low_battery 7:tamper],unique

This will spit out something like this:

So i think in order to properly bring this in automagically we'd need to bring in a binary sensor which looks for the name gswds07 and then an event which would correspond to open, closed or low_battery(tamper is technically there, but disabled on the contact sensor). Then we'd need to bring in a battery device class binary sensor which has something like, low_battery = on, otherwise off.

The reason I suggest looking for both conditions (gswds07 & open, closed or low battery) is because I noticed that there are some random things which will partially fall under this flex decoders radio pick up (like my RM433 sonoff remote) but they wont spit out the second condition because the values dont exist for that device.

[mbaran5]

I too would love to see this feature implemented for door sensors. I am using one of the standard protcols, SimpliSafe, which also reports an open/closed event in the 'extradata'

{
    "time": "2021-07-06 19:22:22",
    "model": "SimpliSafe-Sensor",
    "id": "1INVT",
    "seq": 165,
    "state": 1,
    "extradata": "Contact Open"
}

{
    "time": "2021-07-06 19:22:23",
    "model": "SimpliSafe-Sensor",
    "id": "1INVT",
    "seq": 181,
    "state": 2,
    "extradata": "Contact Closed"
}

[pbkhrv]

Thanks for the feedback. I'm thinking about the best way to implement this.
The way the current script works is it looks for very specific unambiguous keys in the MQTT messages and interprets the values in a particular way. Keys like temperature_C or moisture. You can see the list of all keys here: https://github.com/pbkhrv/rtl_433-hass-addons/blob/main/rtl_433_mqtt_autodiscovery/README.md

Keys like event or extradata are very generic, and could mean different things in different contexts.

More thoughts to come.

[pbkhrv]

So I ran down a bit of a rabbit hole for better understanding RTL_433 and GS-WDS07's. In order to properly report, the user cant rely on protocols but has to use a flex decoder like below, its a bit of a black hole but i did come up with a working 'flex decoder':

decoder n=gswds07,m=OOK_PWM,s=476,l=1364,r=15000,g=1600,bits>=24,bits<=25,invert,get=@0:{20}:id,get=@20:{4}:event:[10:open 14:closed 6:low_battery 7:tamper],unique

This will spit out something like this:

So i think in order to properly bring this in automagically we'd need to bring in a binary sensor which looks for the name gswds07 and then an event which would correspond to open, closed or low_battery(tamper is technically there, but disabled on the contact sensor). Then we'd need to bring in a battery device class binary sensor which has something like, low_battery = on, otherwise off.

The reason I suggest looking for both conditions (gswds07 & open, closed or low battery) is because I noticed that there are some random things which will partially fall under this flex decoders radio pick up (like my RM433 sonoff remote) but they wont spit out the second condition because the values dont exist for that device.

Before we try to tackle autodiscovery for your flex decoder, let's get it running "manually". Have you been able to create MQTT binary_sensor YAML configuration for HA to integrate this sensor?

[rct]

Thanks for the feedback. I'm thinking about the best way to implement this.
The way the current script works is it looks for very specific unambiguous keys in the MQTT messages and interprets the values in a particular way. Keys like temperature_C or moisture. You can see the list of all keys here: https://github.com/pbkhrv/rtl_433-hass-addons/blob/main/rtl_433_mqtt_autodiscovery/README.md

Keys like event or extradata are very generic, and could mean different things in different contexts.

More thoughts to come.

While the current auto discovery script does a good job with just the generic keys (data items), it has a number of drawbacks. I've wound up having to do a lot of manual editing of the auto discovered output.

Handling of the key (data items) in a model specific way is necessary. I've been thinking there should be some factory method that given an rtl_433 message that creates an object or passes back the existing object that will allow model specific overrides.

Black listing and/or white listing by model is also something I find a need for. (I like to leave all decoders in rtl_433 enabled to see what is out there, but I don't want them all in Home Assistant.)

Additional data is necessary for some device types. The DSC security sensors I have need additional data to indicate whether they are for a door, window, flood, something etc. (Generic open/close sensors can be used for a lot of things.)

Finally there are a number of deeper issues with naming that need some thought. Some devices unfortunately have a volatile component to their identification data that changes when batteries are changed. I have some LaCrosse temperature and humidity sensors that only have a volatile ID and no other fixed data.

I also have Ambient sensors have have 8 fixed by dip switch channel values, but also have a volatile ID. For my use, I'd like to eliminate the ID being used as part of the naming component, using only the model + channel.

Thought needs to be given to what happens when stuff changes. In particular what are the implications if you are also storing data downstream from Home Assistant in something like InfluxDB.

I'd be interested in having a larger discussion. This issue probably isn't the right place, though I'm not sure what a better place is. I've mentioned some of this in issues against rtl_433. Don't know whether it would be better to have a thread on the Hass community forum or the rtl_433 mailing list.

[deviantintegral]

There's been good work on the bridge script upstream: https://github.com/merbanan/rtl_433/commits/master/examples/rtl_433_mqtt_hass.py

I'm closing this for now as that's probably the best place to get visibility and discussion on this. Ideally, we get this add-on to the point where it's just using the upstream bridge script directly with no changes. Thanks!

[ideal2545]

Thank you!