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.
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 [4.0.0.0;4.9.9.9] 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.
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?
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.
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 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.
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ā¦
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ā¦)
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.
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.
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.
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.
