semanticHomeMenu for openHAB 4 - Discussions


Together with our brand new openHAB 4.1 Winter Release, we are proud to
give you some more stuff to play with - the semanticHome Menu - openHAB 4 version, the next evolution step of the main_widget project.

Please read the documentation provided in the marketplace posts carefully and enjoy!

If you have questions, problems or just want to ask for additions, please use this topic here, but do not post in the marketplace topics.
Issues and bugs can also be reported directly at my github repository.

Enjoy and a Merry Christmas to all of you…


The SemanticHomeMenu looks like a really amazing project. Thanks for all the work on this.

One comment: In the yaml code under Installation and usage on semanticHomeMenu Part 1 - Main [;] there is a widget reference to ‘main_widget’. This should probably be updated to ‘semanticHomeMenu’.

On a separate note, I am struggling to implement lights in the SemanticHomeMenu.

For a color light I get the following, but without the RGB color picker.

The equipment group looks like this.

The color item looks like this.

Can anyone point me in the direction of what I need to change to get it to work? Or perhaps share a screenshot of an equipment group and a color item setup that will work with the SemanticHomeMenu?

Thanks, corrected :wink:

There should be no Point tag for the equipment!
But that’s not your issue. Your colorpicker item is not following the namescheme, it should be „_color“ > lowercase, not camelcase.

Perfect, thanks. Works perfectly with lower case. Highly appreciated.

One comment though. I have created all my equipment and lights in the semantic model in OpenHAB MainUI and all of these are created with _Dimmer, _Switch and _Color based on the suggested UpperCase naming by OpenHAB when it was created.

I am not sure if maybe openHAB is suggesting different naming conventions based on location or if the standard naming convention by openHAB is UpperCase, eg. _Dimmer as it suggests to me.

If the openHAB standard naming convention is actually UpperCase, eg. _Dimmer, it could be considered also to follow such standard for the semanticHomeMenu, to make it as easy as possible to apply for new users. If the naming standard which openHAB has suggested in my case is a location based naming standard, i.e. in some countries openHAB suggests _dimmer and in other countries the suggested wording is _Dimmer, it could be considered to apply an optionality for lower or upper case in the widget config for the main widget.

Also, when creating the OneCall weather forecast items, the naming suggested by openHAB is Local_Weather_and_Forecast_One_Call_API_… whereas the naming assumed in semanticHomeMenu Weather widget is OneCallAPIweatherandforecast_…

It could be considered to align the weather widget with the standard naming when creating the OneCall items or alternatively to add optionality in the main widget config to use a different naming for the OneCallAPI items.

Once again, thanks for all the work that has been put into the semanticHomeMenu. It is a really great widget you have created.

Thanks for your feedback. Never thought of the „general“ naming scheme introduced or documented a while ago.
I will check, how we can handle both schemes without introducing breaking changes.
I will keep you posted here….

I’m fairly new in the openHAB world, and this semanticHomeMenu looks really great!

Unfortunately, I didn’t name my items according to the ‘rule set’ used in the code. I can’t remember seeing any guidelines about ‘proper configuration’ (also not here: Semantic Model | openHAB). I altered one of the widgets to the naming I used, and it works. But I noticed I wasn’t consistent everywhere, so it’s probably better to ‘change’ the item names.

  1. I suppose this ( is the complete overview on how to name items?
  2. Is there a way to change the names of my items? I created them through the mainUI. But maybe I can edit the json file?
    I assume it’s safer to just delete all items and recreate them…

The name of the things is not important, correct?

Thanks in advance for your clarification!

The naming guideline used in the widgets is not completely following the overall openHAB naming guideline. So one of the next versions might include breaking changes on that behalf.

You cannot simply rename Items, better delete and recreate them.

Yes, but every widget documentation has it’s own items section you can check.

There is no option in the UI, as this is not a simple task. It is safer to unlink and remove the items and recreate them.

Using “Create Equipment from Thing” will take the Thing name with added channel name as the Item name, so it is not absolutely unimportant.

Okido, I’ll get on it :wink:

Maybe a suggestion would be to make a complete overview, and add a link to it here (Semantic Model | openHAB) and in a future OH version also right below the ‘name’ field when adding a thing or an item.

If I had known about these conventions, I would have abided by them… :slight_smile:

Please note that our semanticHomeMenu widgets do not completely follow the naming convention and also most of the bindings don‘t.

As changing the widgets would introduce a breaking change and many bindings use their own naming, I tend to leave the widgets like they are right now.

cc @cbg

What exactly do you mean with the naming convention? I didn’t come across any until in the semanticHomeMenu documentation…?

It is in the docs

I see. I did read those, but I would call them general guidelines rather than elaborate conventions.

For example, I was consistent in my Item names in that I ended all “actual temperature” Items with
Werkelijke_Temperatuur (although WerkelijkeTemperatuur had probably been better). But the widget RadiatorControl only works if these Items end with _ambientTemp

Maybe it’s an idea to use vars in the widgets, and define them at the top of the code, so that users can edit these variables without altering the actual code beneath? Unfortunately, my understanding of YAML (or widgets) is not yet big enough to try that myself. (It’s not quite clear to me from the docs how to define variables in widgets…)

Ok, you are right, it is a guideline, not a must.

Definitely a no go.
The widgets are created to not mess around with code or configs.
If you want to change something to fit your needs, you can do so of course.
But we are not implementing config options in the released widgets.
Every widget documentation contains full examples for the naming of used items and it is a prerequisite to use this naming.

We have tried other solutions in the past (using repeaters and semantic tagging for the items) but had to abandon this due to massive performance issues, making the widgets unusable.

I didn’t think of any possible performance issues :slight_smile:

(I assume the appliances widget is still under construction?)

How can the timer be controlled, if that mode is chosen in semanticHomeMenu_RadiatorControl?

oh-repeaters in combination with filter expressions can be very time consuming, that‘s why the new cache option was introduced and used in the widgets.

Yes and no, it is more or less a placeholder atm, but I can post some examples of my personal use. As we do not know what appliances you have and want to show, we cannot prebuilt this one.

This is not fully implemented right now, will try to finish this part soon.

1 Like

I’ve got a Shelly RGBW2 in the kitchen, controlling 1 white LED stripe. The equipment doesn’t have a switch channel, only a brightness channel. I followed the instructions here (, and the light apperas.

But it only gives a switch in the widget. The switch doesn’t work, since there’s no switch channel. But there’s also no slider visible, or three dots which could let the slider appear…

Maybe it’s because the semantic class of the equipment is set to Lightbulb? It looks like lines 125, 131, 150, 217 and 225 expect another class? But the widget only appears if the class is Lightbulb (as the instructions prescribe). Not if Lightstripe is used.

Or am I missing something?

Following the docs, brightness and color channels accept ON/OFF commands, so you can link the switch item to those channels.

Indeed, semantic class Lightstripe is not supported atm, but can be added.
Just look into the semanticHomeMenu widget and find the oh-repeater for the colorLight. Duplicate that block and change Lightbulb to Lightstripe.
The main identifier for rendering the controls is the tag, you need to tag your Equipment as ColorLight.

1 Like