Making Habpanel widgets quicker and easier to setup

I have been diving into creating Habpanel widgets and 1 part really bugs me, that is the need to create an item before I can use a channel of a thing in Habpanel. I am probably wrong (please tell me this and that it is possible and easy) but it feels like items are a hangover for sitemaps that pose a HURDLE for easy Habpanel widgets in certain cases…

Perhaps an example would make my point clearer.

Say I have a KODI binding (or a camera or any device) that presents Openhab with 50 different channels that are all predictable (not possible to change) channel names and I wish to create a fancy remote widget that has all 50 controls on it. Currently it seems that the user of an advanced widget has to create 50 items and then get the user to select those 50 items in the widgets setup page, or get them to hack the JSON.

It should be as simple as select the UNIQUE ID of the KODI (or camera or whatever it is) thing and instantly the widget knows all the channels and can speak directly to these channels with no setup for the user past the need to enter 1 variable.

I know this is possible as I do it inside bindings, so some of the code needed will already be done.

Example that works inside a binding…

postCommand(new ChannelUID("ipcamera:ONVIF:UniqueID:ChannelName"), OnOffType.valueOf("ON"));

Can we get the following to work directly with no item linked, or does the Openhab framework refuse to update Channels when there is no item linked to the channel? Does the event bus require the item?

Example of hopefully the same can be done in Habpanel:

ng-click="sendCmd('ipcamera:ONVIF:{{config.uniqueID}}:enableMotion', 'ON') "
ng-click="sendCmd('kodi:kodi:{{config.uniqueID}}:play', 'ON') "

If this is possible, it means a complex widget can be dragged and dropped in, 1 variable changed and instantly it fully works as intended.

Items are the core units of openHAB. The whole idea is that a Switch Item is like any other Switch Item; it doesn’t matter to rules or UI or users whether it works by modbus, zwave, pony express,- those differences are all the business of Things and channels.

I’ve noticed a lot of people try desperately hard with convoluted methods to avoid Items. That obviously tells us something, but I don’t know what.

1 Like

I notice that @tmrobert8 came to similar conclusions with his widget that needed large amounts of channels to be setup. He used from what I can gather an interesting and complex way to scrape some info off 1 item and then to rely on the Simple Mode Linking to create the items in a predictable way that could be then used in the widget without the user needing to do as much work.

@ysc Is there a better and easy way to do this either that currently exists or one that could be proposed for Openhab 3?

Link to widget…

It tells us that they did not get the point… :wink:

Items are part of the openHAB Bus, Channels aren‘t. You want to control a Channel via openHAB? Create an Item. You don‘t need a Channel? Don‘t create an Item.

1 Like

There have been discussions at OH3 planning stage about “custom” Items. Build a complex Item using existing simple parts.

You can simulate this sort of relational thing using Groups and your own defined naming convention.
Example, Group “fred thermostat” can comprise members “fred room temp”, “fred setpoint”, “fred mode”.
Rules can handle “fred” and “mary” as single objects. So can bindings or widgets, if the rules are agreed in advance.

I’m not familiar with backend of HABPanel so maybe this isn’t possible, but if there is a way to run some code when the unique ID is changed you could generate all the items and links via the REST API. I am doing similar things in rules to save time creating many similar items for stats from my Espurna devices among other uses.

You would have to find a prefix for the items that would be unlikely to be used by the user like habpanel_kodi_{UUID}_{CHANNEL}, though the convention on these forums is camelCase. That would give you habpanelKodi{UUID}{Channel} which I think would not look as nice.

As others have explained the separation of the “physical” (aka. things - “this is a motion sensor which also reports the temperature and the humidity” - not all openHAB Things are actually physical, mind you, but you get my point) and the “functional” (aka. items - “this represents a measurement of the temperature in the living room”) layers is a fundamental principle in openHAB that is unlikely to be revisited in the near future. Links are the “glue” enabling the communication between these layers.

Now that could be cumbersome to have to build all these links, if you don’t see the value of having a well-designed functional model separate from the actual devices & services - and sometimes it can be really overkill; so in the new UI we tried to emphasize the value of having a good semantic model of locations, at least, and add your things (or parts of) as-is with the “add thing as equipment” feature (equipment is roughly the equivalent of a thing in the functional model). Adding a thing as an equipment in your model can be done in a few clicks, and you’re pretty much assured the default names for the resulting items will be predictable - you choose a prefix for the equipment group then all items will be named prefix_Channel so you can derive items names from that.

This is all explained here: [wiki] Getting Started with OH3: rewriting the tutorial - 6. Model your home with Items & link Channels

That is not what I am asking for anyone to do, despite others assuming that is my intent which I assure you it is not. Re-reading my original post again I can see how I have badly worded it and by putting forward a suggestion on a concrete way that was the only way for it to be taken.

Excellent, then if I can leverage that without making a widget overly complex then I am happy. My goal is that a widget that whilst advanced can still be very simple to SETUP for a user with very limited knowledge. If a widget has to get turned into a massive application to parse 50+ REST calls or other work arounds, then I feel that something is lacking. Having a structured system that is consistent and predictable makes life easier, so I look forward to checking out the changes in V3.

Yes I was and am aware as I have contributed in a tiny way to that exact wiki and some of the others weeks ago. Some of it I will need some time to play and have hands on time with to appreciate the changes.

The UIs by design interface with the “Items” layer of openHAB. Design choice for reasons already given - deliberately to hide device-specific details.

That does not of itself prohibit a fundamental new approach of exposing channels to UIs. The “business end” of a channel that links to Items is after all standardised and not device specific.

But it would be pretty pointless for a UI - channels are stateless. If you weren’t listening when something happened, the event is gone. When you first view your panel, it would be empty and maybe populate over a day or two as stuff updated.

The workaround to that problem would seem to be to re-invent a wheel (Items) to capture updates, allow for restore on boot, etc.

I think you may need to consider non-HABpanel users, too.

Perhaps you should split your requirement - automate creation of the internal model of your device in openHAB to some standard.
Then you can supply HABpanel widgets or sitemap templates to suit it.

Thank you that has helped me understand it 100% clearly as to why a channel directly is not the solution. The goal I would like is poorly explained it in my first post, but it is to find the items in an easy to program way in the widget without needing to present 50 configs to a user that they need to find and select 50 items from a massive list.

No need to reinvent the wheel, often there are multiple ways forward if one is willing to look. Perhaps a way inside Habpanel to say ‘find the first item that uses X channel and use it here’.

Another approach could be a filter that a Habpanel designer can apply to the item lists inside a widget setup page that only shows the ones that link to X binding or another filter criteria that makes sense. I don’t like this as it still does not address what happens if you have 50 items that need to be used in a single widget.

Many ways to extend functionality in a logical way without reinventing the wheel. If they make sense is another story as I have not delved deeply into the core systems of Openhab yet.

I agree I did start this thread on the topic a while ago. I would like to see a way that an addon can be dragged and dropped and the result just works right away.

Sounds like what YSC has said is coming in Openhab 3 and I agree that would be great if the item structure is 100% predictable when a user makes a few clicks to “add thing as equipment”. It would then solve my wish that this thread was about.