execBinding on UI config for OpenHAB 3.4.2 does not give a switch

Setup, Configuration and Use Beginners
,
1

I am in pain trying to recreate my OpenHAB 2.5 text config in the new 3.4.2 UI after an upgrade.

The problem is execBinding, that seems to not produce a switch when linking the Point with the Running channel, although I suspect it should. I do remember that 2.5 used only this channel.

I have checked that the scripts run with ‘sudo -u openhab’. They have no parameters, but I have tried filling the exec.whitelist with %2$s at its end and without, no difference. But I do not even really get to running the script …

I first remove everything related from Items and Things, and restart openhab. Then:

  • add the script Thing, with default settings,
  • select the location group in the Model tab, click on ‘create equipment from Thing’,
  • select the Thing and its running channel, and leave everything on default.

The Equipment and the Point is now created, but the problem is that the Point does not have a switch, just a NULL title. The script therefore cannot run.

Strangely, in some trials it seems to work, but only if the channel links of the Point contain an ‘? (unknown) Invalid Link’ entry, with an execBinding reference that does not exist. For such an item everything works as expected, but if I remove this invalid Link, again the NULL appears instead of the switch. This only works for one Point, and I cannot control when does this happen, so this is less than satisfactory.

I have trialled a zillion combination of Point and Equipment classes, but nothing seems to work so far.

/var/log/openhab/openhab.log does not seem to contain anything related.

I have also noticed that when pressing “add link” on the Point and selecting the list of Things, the very first Thing seems to be empty, but selectable. This maybe points to some database corruption that may explain that mysterious unknown link, but how should I recover from this without nuking everything?

2

As far as I’m aware, nothing has changed on the exec binding between OH 2 and OH 3. What ever config you used to user should still work largely unchanged.

But, you are changing things. Though what you are changing is irrelevant to the functioning of the Exec binding. The semantic model does not change how Items, Links, Channels and Things work. The semantic model is strictly a way to model the physical layout of your home automation for building the Overview tabs in MainUI. That’s it. The semantic model is completely independent from the operation on the Exec binding. There is nothing you can do in the semantic model to break it but to make it work

Still this is something different. It’s similar to trying to use the Default or Group element on a sitemaps. As with sitemaps, if the default widget isn’t what you want, you have a way to specify your own custom widget through the default widget Item metadata.

There are some limited things you can do to influence the default through the Semantic tags. I believe if the Item type is Switch and the semantic point tag is Switch or Control it will default to a toggle widget, but only if the state description metadata doesn’t set it to read only.

If you just leave it with the Point tag, MainUI will prevent default to a label widget.

3

That was it, thanks!

So far, I had completely ignored the widget settings. Force-setting each of them to toggle, the scripts now work as expected.

It is still a pain to configure all three widgets (list, cell, standalone) for each item and setting the ON/OFF field, but at least I have a way out now. May I remark that it is quite confusing that items, that are clearly used as a switch, default to a label widget without a warning.

Thank you very much for the help!

4

One thing that old timers migrating to OH 3 fail to do which causes lots of needles work and frustration is skipping the Getting Started Tutorial.

I’m this case, you’d find a discussion about custom widgets you can define once and reuse across multiple Items.

You’d also learn that the Card widget is almost never used so you probably don’t have to worry about that one.

It’s clear to you but not so clear to MainUI. For one thing, the Exec binding labels this channel as a status channel. one does not typically command a status channel. Network binding users Switches to retirement whether a host responds to a ping. Using a toggle widget in this case doesn’t even make sense.

And based on my experience with other bindings, using Switch or Control for the Point tag usually results in a toggle widget by default.