semanticHomeMenu for openHAB 4 - Discussions

Thanks again for reporting, I corrected both typos.

This makes it even more complicated. Don’t have a solution right now, but let me think about it.
Created an issue for to not forget about it:
RGBW lightstripes do not always have color/colorTemperature channels and create WARN entries in the log · Issue #1 · hmerk/semanticHomeMenu (github.com)

1 Like

I found another typo in the documents.

The main widget documentation instructs us to create an item gBatteryLow, but the widget itself searches for item gBatteryLowTotal (lines 1100 and 1105).

(Or is this also something better reported on github?)

When my Shelly RGBW 2 is ON, the slider is filled up to the correct percentage of brightness (in the below case, 49 %), but the slider “ball” is still at 0 %.

Also, if I try to adjust the brightness on the slider, it triggers an error: Communication failure.

Thirdly (but for me less importantly), since the equipmentType is not ColorLight, I don’t understand why the Ambiance slider is visible.

And finally (also not a real ‘problem’), I suppose the label RGB colors is visible because there’s no parameter visible in the Label component (only in the oh-slider component)?

Image:

Settings of my _brightness item:

label: Ledlampjes keuken - helderheid
type: Dimmer
category: slider
groupNames:
  - Ledlampjes_keuken
  - Shelly_verlichtingen
tags:
  - Control

Did I do something wrong in the configuration, or is this a bug?

No, please check the Energy Widget post, first item in the examples is

gBatteryLowTotal

Where did you find the wrong Item in the docs?

Both seem to be issues with the oh-slider component.
@florian-h05 could you have a look please.

To be honest, I have no clue, as the visibility has the same logic as brightness or color.

Fixed.

Fixed the wrong example for batteryLow.

I removed the light widget and re-installed it. I checked the code, and indeed, lines 258 and 266 read:

visible: "=props.equipmentType === 'ColorLight' ? 'true' : 'false'"

But still:
image

Strange! :slight_smile:

Can you please poste the config code for the equipment Ledlampjes keuken.
BTW, you need to completely reload the app after changes, otherwise it will be rendered from cache.

What exactly do you mean with “the app”?

label: Ledlampjes keuken
type: Group
category: lightbulb
groupNames:
  - Keuken
tags:
  - LightStripe
groupType: None
function: None

(I still need to add the meta-data, but haven’t got around to it yet…)

MainUI

About&Help → Scroll down to reload and press reload.
Did not find anything wrong with your config.

Done. No change…

I will do some tests later on…

Hi, @hmerk

I haven’t implemented the widgets but they look nice and may help a lot of users implement their UI faster. Congratulations to everyone who worked on them!

I have a set of questions and suggestions.

  1. What’s the use of having independent “Armed Home” and “Disarmed” buttons? I hope people don’t have their motion sensors triggering notifications at 02:00 when the cat moves, because that’s what “Armed” implies.

  2. Is the “Armed Away” a sort of “long period” armed status? I have for example a Vacation Away mode which has different rules for a prolonged period. Is that what the “Armed Away” represents?

  3. Instead of having them as widgets, can’t they be provided by default by the MainUI and users just select the ones they want to enable?

  4. It could be useful to support state-full scenes.

  5. Isn’t it easier to use a color picker than the RGB counterpart in the lights widget? How does someone know what to combine to get an orange tone?

  6. A difficult one. The Radiators widget could have set points based on the state (maybe a standard state machine would be required). I think just 2 or 3 (active, sleep, away) are important.

  7. Can they be added to the demo on openhab.org?

I believe this set of widgets bring openHAB a step closer to a standard smart home UI, such as the Home app.

What is the point of the equipment namespace in the uiSemantics metadata? Doesn’t the label of the item do the trick?

Thanks, great you like the project.

As those tree buttons just change a String Item, you can have different rules react on change of that Item.
Users can define different levels of security, a lower leven when they are at home during the night or when they have left their home. E.g. when not at home, also send a message (mail) to somebody else.

Yes, it is a different level of security. Many professional systems implement such different modes.

This is quite not as easy, as they would need to be rewritten as Vue widgets like the standard widgets coming with MainUI. I do not have the Vue skills t do this. Furthermore, this would in some kind break the concept of using the semantic model, if we let the users decide which one to use.
But you can use the widgets as your standard standalone od list widgets.

This has already been asked. If I get a good described feature request at my repository, I could think about it. But keep in mind, that there has been a long discussion whether as scene is statefull or stateless. Conclusion was, a scene is stateless, cause changing only one Item included in the scene will make the scene invalid.
But it would be quite simple to add another widget to enable/disble defined rules, whoch one would use as statefull scenes.

Anything within the qidgets can be changed, but I am not going to publish a version with colorpicker.
If you check the really long main-widget discussion topic, it was a long way to have such a design for the widgets, giving all a nearly identical look and feel. using the colorpicker would brak this.

As said before, everything is possible. The widgets can easily be extended if one needs such a funtionality. But as it will not be the usecase for everone, it will not go into the basic widgets.

Yes, they could, but that would give users a wrong impression. If you follow all posts, you will note that implementing this project needs a bit of work, which easily overwhelmes new users and they get a bad first experience when it is not working as expected.

It could, but this might be a long long was to go.

1 Like

Yes and no :wink:
In some places, when no uiSemantics are set, we use the labels. But using it, you can label your Equipment Items different than what you see in the widgets.
E.g, using a standard group popup, you will see the label of the equipment. As I have labeld all my ligts really simple within the floor/room structure, you could only see x-times “CeilingLight” in a group list.
Not really easy to find out which is the right one. Therefore Items can be labeled as e.g. “Ceiling Light Kitchen”, which will identify it correctly. But that would look nast in our widgets, as we have the rooms in a second row.

Gotcha.

And when is the location namespace needed/useful?