I know that this is a topic that was discussed frequently the last years. With the release of OH3 coming closer, I would like to bring up this topic again and understand how this is planned for the next major version of OH.
My current level of knowledge is, that there wasnt enough interest / real-life use-cases to make the properties (including online-state) and configs of things accessible in OH2-sitemaps as there were (at least partly) configurable through PaperUI.
So for cases like “disabling a hue-motion sensor” you have to use a workaround (POST to hue REST API via http-binding) to making informations avaialable - same for online status of things and many other infos.
As I´m currently fiddling around with the build #1945 of OH3 there still seems to be no way to access these values, while there are so much interessting informations coming as a property or config-parameter.
Is there anything planned to access these values in OH3 or maybe it is already possible and Im just searching at the wrong place?
If there is no such feature planned right now, everyone is invited to call out their interest for this in a feature request I would create then.
If this isnt the right place for my concern, please tell me and I will move this question.
In OH there is a distinction between Items and Things. Sitemaps are only concerned with Items, by design. If there is information from a Thing that you want to interact with and display on the sitemap, the proper approach is to have the binding developer create a Channel for that piece of information/actuator and then link an Item to it.
I agree that your overall use case is valid (i.e. to disable the Hue motion sensor) but it should be implemented as a Channel on the Thing and a Switch Item, just like every other way to control devices in OH.
Why would there be a use case to disable a motion sensor?
Normaly you have a rule trigered by an motion event, so why not disable or enable the rule with a virtual switch item.
That‘s how I do it.
There is a direct connection between the motion sensor and the lightbulb configured in the hue app - which works very reliable and faster then a rule in openhab - at least in my experience.
…disables the link between the light and the sensor and the light remains dark as it would if deactived over the hue app. But you seems right - this trigger seems to do nothing at all?
With this request against the hue REST API, I´m able to disable the motion sensor and overwriting the link I set in the app, which was the behavior Ive expected from the switch.
