Comments (8)
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!
from rtl_433-hass-addons.
I don't have that sensor to test with, so will need some info from you.
- Have you been able to configure the rtl_433 add-on to send data to MQTT? If no, please start there.
- 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.
from rtl_433-hass-addons.
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.
from rtl_433-hass-addons.
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"
}
from rtl_433-hass-addons.
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.
from rtl_433-hass-addons.
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?
from rtl_433-hass-addons.
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 liketemperature_C
ormoisture
. You can see the list of all keys here: https://github.com/pbkhrv/rtl_433-hass-addons/blob/main/rtl_433_mqtt_autodiscovery/README.mdKeys like
event
orextradata
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.
from rtl_433-hass-addons.
Thank you!
from rtl_433-hass-addons.
Related Issues (20)
- rtl_433 MQTT Auto Discovery (next) does not start HOT 12
- How can you tell which version of rtl_433 you're actively using? HOT 6
- How to install in HA Core? HOT 4
- 0.4.1 Stopped receiving HOT 66
- Is it possible to Filter devices and add fields to data to InfluxDB ? HOT 3
- Auto Discovery publishes SCMPlus time value, skips the rest such as gas meter consumption. Case sensitive? HOT 3
- Device added by Auto Discovery doesn't persist across reboots. "This entity is no longer being provided by the mqtt integration" HOT 2
- on AmbientWeather-TX8300 report Battery statur from rtl_433 MQTT Auto Discovery (next) HOT 6
- DEVICE_TOPIC_SUFFIX config problem HOT 8
- Enable devices disabled by default in config?
- New repository HOT 2
- New version 0.8.0 not working HOT 5
- rtl_433 MQTT Auto Discovery will not run after update HOT 6
- Support RTL-SDR Blog V4 Dongle HOT 3
- No MQTT topic visible HOT 2
- Latest version says rtl_433: option requires an argument: F
- Getting started HOT 4
- Config for device trigger conflicts with existing device trigger HOT 3
- rtl_433 does not start anymore HOT 4
- No MQTT topics created - No error in logs HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rtl_433-hass-addons.