[RFC] Add proper support for dynamic channel creation for things #4048
Comments
spacemanspiff2007
added
the
enhancement
I don't have any opinions on this RFC except that at least for Zwave and Zigbee, the discovered channels are shown in the Code tab. If they are not shown for other bindings (Shelly), maybe that part at least is a problem with the binding implementation instead of core?
Isn't it the whole point of textually defined things to textually define everything and not do discovery? It seems very weird to me to have a textually defined Thing but not include the Channels in the textual definition. I'm totally on board with standardization of this sort of thing. |
This is what gets shown for a fully discovered Smart Color Button (Z-Wave) with multiple channels. UID: zwave:device:controller:node33
label: "Philio PSR04 (Node 33): Smart Color Button"
thingTypeUID: zwave:philio_psr04_00_000
configuration:
config_1_1: 0
config_2_1: 99
config_10_1: 12
wakeup_node: 1
wakeup_interval: 86400
group_1:
- controller
config_25_1: 0
config_26_1: 1
group_2:
- controller
node_id: 33
bridgeUID: zwave:serial_zstick:controllerFor me it does not show the channels there (OH 4.0.0). Do you see something different?
Since the docs are always lacking the idea is to just define the plain thing and still have auto discovery / automatic channel creation. Once the device channels are properly discovered one can than edit the textual thing config to include the channel definition if desired (which then would be available from the code tab). Another idea would be to have an additional thing state |
That's weird as all of my Zwave and Zigbee (and Shelly for that matter) Things have all their Channels listed in the Code tab. Here are a few but I've looked at them all. The last Thing shown above was added last week so it's not just the old Things I have hanging around. I wonder what the difference is. Maybe you are doing a mixture of .things files and looking in MainUI? I cannot find a single one of my Zwave or Zigbee Things that does not list all the Channels in the Code tab. In truth I cannot figure out how you can even have a Thing with Channels showing on the Channels tab without them showing on the Code tab. Both the Channels tab and the Code tab are rendered from the same JSON so the UI would have to go out of it's way to not show the Channels in the Code tab and I can't think of a good reason to do that. I'm on 4.1 but I don't recall ever not seeing the Channels in the code tab for any Thing that has Channels. All of my things are auto discovered where that's possible. Do you see Channels in the Channels tab? In the RAW JSON from the REST API?
Wouldn't all that become moot when the YAML config files become a thing? Then the user can discover the Thing and, if desired, export the whole lot to a text file in one step, possibly even through an export function. Is there a case where the Thing has to be manually defined but the Channels are discovered? All my experience is that either the Thing is completely discovered or the Thing is completely manually defined. |
Yes - the rest response for the thing correctly returns the channels and the gui shows them correctly in the channels tab
But we digress ...
I don't think so. If I have to add 10 rollershutters it's very quickly to do so through a textual config (e.g. set the IP, proper name, and label). But I am not sure about the channels so I want to use auto discovery in a first step and only in a second step define the channel configuration. Btw. I just looked at my things again one flood alarm and one smoke alarm is still not working after over two weeks because it's stuck in |
That seems like even more work than discovering the Thing in the first place, exporting the YAML complete with Channels, and then copy/paste/editing from there. I don't see any benefit to starting with a file defined Thing and only then going to the UI to pull the Channels and then needing to modify your already created Thing definition with the Channels. It just seems like more work. |
|
You assume that all devices are fully discoverable by auto discovery in the first place which is not always the case. Sometimes the thing discovery also does not work or only works after providing some form of data (e.g. I want to create 10 astro things which require the coordinates). Also the thing type discovery could be faulty so it's good to have an option to set the type. |
Are there cases where the Thing is manually created but the Channels are discovered? I know of places where the Things are wholly manually configured and other cases where the Things are wholly discoverable. I know of no cases where one has to manually create the Thing but the Channels are discovered. Is there a binding that works like this? Or is it s theoretical concern? I'm not talking about Bridges though, that's a different use case.
I don't see any difference in this use case. Astro does autodiscover a Thing (two Things actually, one for sun and one for moon) based on the regional settings coordinates. And this use case too seems to be more work to:
compared to
Even if for some reason the Thing cannot be discovered (assuming the theoretical case), the fact that you don't have to jump between the editor to MainUI and then back to the editor is an improvement in workflow. At least for cases where the initial configuration of the Thing is simple like with Astro.
Seems like that should be caught and fixed instead of hidden and/or worked around. Do we have lots of cases of this? I've seen some stuff around Shelly but haven't followed that closely. |
Many bindings do not support auto discovery because it's just not possible. And almost all the time when the user currently supplies the thing via text file the channels are automatically created or discovered (since from the user perspective this is the same I'm not going to differentiate between these two).
As you can see the docs provide the thing definition but never the channel definition.
For me it's like this (since I want an astro thing for a different location).
compared to
However the discussion which one is faster is futile since obviously you are faster with the gui and I am faster with text files.
The problem with these issues is that they are really hard to identify, harder to debug and even harder to reproduce. I consider myself an above average openHAB user and it took me very long to find the cause of my Shelly issues. And even with the help of the binding developer we were not able to pin the issue. Since I've found more and more bindings which do the automatic channel generation (e.g. not yet released esphome binding, too) it's necessary to address these systematic issues because all bindings which do dynamic channel discovery are affected by this. |
That includes a bunch of unnecessary steps that are only really necessary only if something went wrong.
But that's getting off topic. To summarize:
|
|
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/get-data-from-webserver-provided-by-esp8266/154112/17 |
More and more bindings dynamically create channels for an added thing.
While this makes it easy to support various variations of a device it does also lead to unexpected behaviour and really hard to track down issues. Some of these issues can be attribitued to bugs/issues in bindings but imho there should be some core changes to make things easier for both the binding developers and users.
For examples I use mostly the shelly binding because there I've observed the issues first hand:
Improvement to things
Currently the thing lifecycle does not properly represent these steps. Thus it should be extended accordingly:
INITIALIZINGstatus for things and only there should it possible to add channels to the things. Once it goesONLINEthe channels should be "frozen" and not be added/removed any moreCHANNEL_DISCOVERY. If should be used when this thing is still being discovered. When using textual thing configuration and channels are provided there theCHANNEL_DISCOVERYshould be skipped because the channels are supplied by the user. If there are no channels provided theCHANNEL_DISCOVERYshould still run.REGISTERING_OPENHAB. Some things support sending notifications to a host controller. Most of the time this has to set up in some way so this should be the status afterCHANNEL_DISCOVERY. Some device (e.g. Shelly) allow to set this persistent on the device so there should be an option to skip this is the user has done this.Currently it's possible to share the thing through the
Codetab. However without the discovered channels the same thing configuration will lead to totally different thing behavior depending on the device. Thus the discovered channels should also be shown in the Code tab.I think this already implemented but currently it does not work for textually defined things. When channels are discovered they should be saved and after an openHAB restart restored accordingly assuming the device is still running correctly.
Some bindings implemented a custom storage (e.g. the
node_xxx.xmlof the z-wave binding) which should be standardized.Some bingings also add possibilities to create thing types through parameters (ecovacs) which should also be standardized.
Sometimes devices change (e.g. firmware update) and the user forgets to re-add the thing to openhab. When the thing goes online there should be a one time check which validates everything and logs a warning/error in case of inconsistencies.
I'm aware that things more or less "work" right now but these issues are very hard to pin down even for experienced openHAB users and lead to very frustrating behavior (e.g. it works after one restart but doesn't after another),
Anything that makes
Thingsmore reproducable is worth the effort and a step in the right direction.The text was updated successfully, but these errors were encountered: