I am developing a new binding for the Sense Energy monitor. Sense uses AI to detect different devices in the home and I’ve decided in the binding, whenever a new device is detected, it creates a new Power channel which will report the power being consumed by that device. The number of devices the monitor detects will change over time (both additions and removal) - and more frequently than you’d expect.
A common use-case in openHAB would be to create a graph of the power for the devices, and for that I would need to have the channeles linked to items in a group. Given the dynamic nature of channels being created/deleted though, it will be huge pain for the user to have to go in and monitor the number of channels and have to manually create/remove items.
Is there a better structure in openHAB to implement the dynamic nature when these devices are created/deleted?
I could create a “demo” rule which does this, but from what I have read, the rule would be fairly complicated and need to use “rawThings” in openHAB to implement. This would be difficult for users to setup/test/run.
Another option, when channels are added, I could automatically create and link items dynamically in the binding. However, I am sure that doesn’t fit the intended “mold” of openHAB and haven’t seen any other bindings which support this? Not sure if this would be an acceptable solution?
I can’t really answer your questions except to confirm that bindings are not allowed to create Items.
In general OH isn’t built to handle a use case like this I think. Devices (and therefore the Channels) are expected to remain fairly static and the entire architecture is built around that. It might be the case that you can’t get there from here without changes to the OH architecture.
You could publish an ancellary rule template on the marketplace. Rules can access Things and create/delete Items
Ignoring the fact that “bindings aren’t supposed to create items”, If the items were created / deleted dynamically, who’s going to use them other than UI that dynamically displays/deletes them? It would be of a limited use it seems?
I guess the items would need to be added to a pre-defined group, and a script can loop through that group’s members. But that is yet an extra configuration for the binding to know (which group).
An idea would be to send all the list of devices and their power consumption in a json format through a fixed (string) channel?
A rule could then deal with that json data more easily, although such a rule might not be easy to implement using rulesdsl, but it would be a piece of cake using javascript or jruby to process. What the rule does is up to them. This gives the user of the binding the most freedom.
Another idea, not mutually exclusive to the json channel, is to introduce actions that allow rules to gather this data, although that’s not event driven.
Another idea is to send a custom event (derived from AbstractEvent) with a custom payload. But dealing with such events may not be trivial in some scripting languages.
I am assuming you are talking about a binding for this ? https://www.amazon.com/Sense-Energy-Monitor-Electricity-Usage/dp/B075K6PHJ9?th=1
Just as thought you might consider treating it like a bridge and have each of the devices it detects as power consumers created as things and when a event occurs where it detects a new device trigger a “discovery” in the binding and then call the appropriate OpenHab api to create the thing. i.e. such as it finds your oven as a consumer creates a thing called oven and a channel in that thing for power then when the oven bubble is detected as consuming power the thing goes “online” and the power consumed is registered as for items well obviously you can also use the API explorer to trigger discovery or add a thing or create any item or link you want programmatically.
Think about how shelly zigbee or zwave behave heck even mqtt to some extent. Also, the odds are once the AI detects a device consuming power it remains even if the app “bubble” disappears or goes grey you could even treat things that are using power as being online and things that are not as offline and then you are pretty much following the "spirit’ of Openhab
Thanks for the input @rlkoshak / @JimT - good suggestions.
I was primarily looking at an easy way for the user to see a graph of power usage for different devices over time. I thought with with oh-chart, you could select a group and it would plot all the items in that group automatically (similar to how Charts worked in sitemaps). However, I just tried this and oh-charts does not seem to support that - is that your understanding?
I will look into using some json in either a trigger or item to communicate to the rules. I was hoping there’d be some more robust/simple way to do this.
I considered creating a new Thing for each device that is discovered, however that is yet just another step the user has to go through to accept the device, then add items. Also, once a device is created, when/if the Sense device drops a device, the binding can’t remove the device (at least I don’t think it can).
Hopefully the AI algos at Sense will improve over time, but they are far from perfect - and devices are deleted or can be “merged” with other devices through the Sense UI which is like a deletion.
A user can set inbox to auto approve if they want too.
Keep in mind the flow binding to interface to a device (bridge to the energy monitor AI ) thing as power consuming devices channel to expose a function of the thing and item to provide a value
Also you can delete things/items and links from api even force a delete you can also add/change things from api
You treat the binding as an interface and allow the options for the user to auto enable certain enhance functionality (such as auto create item or link a item to a channel or what not by calling the api then they can decide what and if something should be accomplished programmatically.
If you want it to graph and retain then by having the consuming devices as things you create all the additional metadata needed to interact with the consuming device just like any other thing in openhab and you are now able to utilize all of the other features that openhab offers from graphs to persistence transformations rules and so on.
Edit If your binding exposes the events for a “merge or delete” then you can trigger an api call to delete the thing as well. All of this depends on how much of the AI 's functionality is exposed and how smart you make the binding’s bridge behavior.
any way just my 2 cents worth as a optional design approach since you are already creating a full blown binding.
@justaoldman - Thanks for the thoughts, i’m trying to fully grasp your recommendation. When you speak of api - are you referring to the rest api - or the programming interface in java? Here is what i think your recommendation is:
for each “discovered” device, have the binding create a new Thing.
That thing will have a channel for the power
the binding would notify the user through a trigger channel/event when a thing is either added or removed
the user would need to write a rule (or through the rest api), create an item and link it to the channel for the thing.
Can you confirm this is your recommendation? I think this is close to where I’m landing as well.
Yep that was pretty much what I was suggesting.
yes, rest api .
Actual programing it fully to binding and calling the java api might be crossing into the darker grey area too much.
If you want to avoid violating the policy of a binding not creating items and links you would move that function outside of the bindings default actions. now it does not mean you can not have a configurable set of variables or “template” that if the user populated certain user defined default values for item naming convention and then generated their own token for preforming rest api calls would be any issue I personal see no reason why it could not trigger the rest api request to complete the additions of items and links that is really no different than having a rule that fires when any event occurs.
