Add new model keys option #986
Conversation
|
Overview of all current model names and some proposed new keys. Also note weather (rain/wind) key changes in #1019, other odd key changes in #1010, and that
|
zuckschwerdt
force-pushed
the
feat-newmodelkeys
branch
from
64e5d80
to
ed1a28b
Compare
|
Curious why not "FineOffset" instead of "Fineoffset"? |
|
Any more comments on unique, short, and uniform model "keys"? Otherwise I'll get basic support in and convert keys slowly. Old keys will be supported for at least 2 more releases (a year or so) in any case. |
|
Otherwise looks good to me! |
zuckschwerdt
force-pushed
the
feat-newmodelkeys
branch
from
ed1a28b
to
40b5ff0
Compare
|
All renames are listed in the table above and commited to master. Please everybody review carefully and comment with suggestions to improve. |
|
'Schrader Electronics EG53MA4' to 'Schrader-EG53MA4'? |
|
Yes, all those TPMS need some attention too ;) |
|
Any reason why you didn't split I didn't look close enough and though the '-' was the separator, but that's not always true. |
|
Can you explain in more detail? The keys should be |
|
There are a few cases where things are missing and it's ambiguous, like For MQTT discovery it would be nice to have fields like model, manufacturer, name and type, and it's hard to extract these from the current |
|
Yes, that should rather be |
|
S.a. https://github.com/zuckschwerdt/rtl_433/blob/feat-mgmqtt/examples/rtl_433_mqtt_hass.py for a draft how Home Assistant discovery could work. |
|
Would it be possible to change what's been proposed as "Honeywell-Doorbell" to "Honeywell-ActivLink" or "Honeywell-Home" or "Honeywell-Alarm"? ActivLink more accurately describes the signal protocol Honeywell seems to use for devices that support this protocol, but they've trademarked the term "ActivLink". There are over 100 SKU's of devices that use this protocol, which also include older Friedland Response and Friedland Libra+ devices (which I believe Honeywell bought the rights to), and the newest international Honeywell Home devices. These devices not only include doorbells, but also security devices such as motion sensors and door/window sensors. Perhaps another option is to rename what's been proposed as "Honeywell-Security" to something else (I believe what is currently called the "Honeywell Door/Window Sensor" is an older, less-sophisticated protocol used by previous generation Honeywell devices), and use "Honeywell-Security" to refer to the newer, current ActivLink protocol line of devices? |
|
Sure, sounds good. -Security for the old one -ActivLink for the new one. Went in with 897f9db. |
I just installed the RTL_433, several times and I still cannot update it to the new model and when I try to run the app it does not run just pop up this message. Consider using the "-M new model" to transition to new model keys. This will become the default someday. . |
|
I should just be |
Unfortunately, it does not work. That is all I have in return for that command. see picture. |
|
I does work, you just don't have any inputs available. You should add at least RTL-SDR. |
As you say, exactly I use BME 280 on my terrace wall so I have o plenty of data coming in. A DHT22 on the other side of the wall which measures the internal temp and hum. I can add whatever sensor I want to. I also have ESP8266 based anemometer from adafruit, which is pretty good. It is under testing now, I placed right next to the existing weather station to see the accuracy. All the data transmitted via mqtt to my raspberry and my nas. Both running node-red server. My weather station has an internal unit which is sending the packet to a web based dashboard. I opened the case and there is an ESP WT8266-S1board which is connected to my wifi router. I maybe a serial connection is possible. If we could download the sketch and then modify it with an addition of mqtt publish command, then all the data can be captured. Opinion? This is the unit I use.
|
|
Dumping the binary code from the ESP is possible, but you will have to reverse engineer the functionality (source code). It could be possible to change the web dashboard URL in the firmware and re-upload. Then run your own webserver to capture the data. |
|
Hello, |
|
i saw the reponse on #1277 (comment) |
|
Yes, |
|
I'm trying to make domoticz (rtl_433 data consumer program) newmodel compliant. |
|
Thanks! I'm working on a script to extract all useful metadata from our decoders, but it will take some time to finsh that. Having something working right now is great. |
|
Maybe others keys need to be checked (found in my extraction) : |
|
Not sure if there is a unit to power_idx/power_max. |
|
i PR'ed the domoticz project to support the newmodel. Now units should be better handled, (i had several problems with those units), i think that more devices will now report nicely between rtl_433 and domoticz. |
|
Ah, so this is why everything here just stopped working. That'll teach me to track master without reading every commit message :) |
|
Well newmodel is now 1 year old now. If something broke don't hesitate to point out what is the problem if i did something wrong, i'll try to fix it. |
|
True - but there's only been one release in that time, and no release notes to alert people to the upcoming deprecation; you wouldn't be prepared unless you spot the mention in the help output ( |
|
As always, patch welcome. We are trying to get a release together and it is things like this I'd like to get listed somewhere. But it's hard to keep track of things and creating a sane api (command line/data) that doesn't break with minor changes. |
|
I'll try and compile the ChangeLog tomorrow. Likely I'll put the biggest updates on the README also. Thanks for the hint! |
|
Hello, domoticz project is now newmodel compliant (merged in developpement branch). When i red issue related to rtl_433 i've found one issue that make me feel that integration could better than now. The problem is in csv output format that type of device is not formalized, this output does not tell the type of device it is about, when there is a temperature data it is easy to deduce it is a temperature sensor (that the way domoticz actually handle data coming from rtl_433 csv output) but when it comes to a switch (with multi-state), it is not always possible to use the corresponding sensor/actuator in domoticz. So there is only a portion of device recognized by rtl_433 that can are handled in domoticz. |
|
We did try to classify devices in the past but there are quite some differences with individual outputs. The TPMS for example are tagged as a device class, but e.g. weather sensors will be quite different in capability and it's best to look at the output to infer what is transmitted. We don't have many decoders for switches, this is best solved with a flex config. Perhaps we could allow adding meta-data with flex configs, not sure. If you find keys that report the same thing but are represented differently in decoders then try to find and suggest a normalized common key, sure! |
Change the identifier of packets OSUVR128Packet as updated in rtl_433 merbanan/rtl_433#986
This PR allows a way to transition to new unique, short, and uniform model "keys" instead of the old often descriptive model "names".
For now early adopter users can opt-in to new model keys using
-M newmodel. At some point after the next release we can default to new model keys and offer a-M oldmodelfor legancy use.A few changed model keys are included as example.