Multi-state point in semantic model

1

Hi,
I am setting up the semantic model and cannot find the proper way to define a “multi-command/multi-state” switch.
In sitemaps, this was achieved by Selection or mapping. What is the equivalent for semantic model points?

Why are points (and items…) so much specialized? Why don’t we just define one type of point * called genericpoint with the following characteristics:

  • type of command it can receive (text or number or combination of both, with limits for numbers and list of valid text commands)
  • type of state it can be set to (text or number)
  • if it is able to process a command (yes for wall switches, light…, no for sensors)

Then:

  • a switch is a genericpoint that only can receive ON and OFF and can be set to ON and OFF
  • a dimmer is a genericpoint that can receive ON, OFF, DIM, BRIGHT or any number between 0 and 100 and can be set to any number between 0 and 100
  • a rollershutter is a genericpoint that can receive UP, DOWN, STOP or any number between 0 and 100 and can be set to any number between 0 and 100
  • a TV channel controller is a genericpoint that can receive any text corresponding to the list of channel and be set to any value of the corresponding list
  • the audio setup of my AV system is a genericpoint that can be set to “stereo front”, “multichannel 7.1” or “stereo back”
  • a light scene in a room is a genericpoint that can receive same commands as a dimmer + custom commands such a “NIGHT”, “MAX”, “WARM”, “READER”

I think you see the idea: reducing the number of types for points and making them much more versatile to use

2

The Semantic model does not dictate what sort of UI widget the Item is presented using in the Overview Cards. If the default for that Item type doesn’t meet with your needs, just as you did with the sitemap, you need to choose a different widget.

You do this by editing the Item’s “Default List Item Widget” Item metadata. You probably want to set up a oh_list_item widget for this. That will tell MainUI how to represent that Item by default where ever it shows up in a list (e.g. in the cards generated in the Overview tabs).

This is completely separate from the semantic model.

That’s not what the semantic model is for. All the stuff you describe are features of the Item (e.g. a Switch Item can only receive ON and OFF as a command, Number Items can only be set to a number, Dimmer Items can only be set to an integer between 0 and 100, etc.).

The semantic model is to provide information about what that Item represents, not how to interact with it. Without the semantic model:

Number MyTemp

Where is MyTemp located? Is it part of a thermostat or is it measuring the CPU temp of my desktop? The computer can’t understand that “MyTemp” means temperature based on the label so how do we tell it that it’s a temperature? Is that Item a sensor or a setpoint?

That’s the sort of information that the semantic model adds. The model was original created/adopted to support HABot so you can issue commands like “turn off all the lights in the kitchen” and it can figure out which Items are lights and which of those Items are in the kitchen.

That’s already part of what makes a Switch a Switch, whether you have a semantic model or not.

The same for all the rest of your examples. That stuff that is needed whether or not you have a semantic model defined and, as has been the case since before there ever was a semantic model, that is already implied by the Item’s type.

The docs have a handy table that lists all the Item types and what sorts of states they hold and commands they receive. Items | openHAB

But, as of now, MainUI doesn’t look at the semantic model when choosing how to represent Items by default. So if the default for that Item type doesn’t meet your needs, just as is the case with sitemaps, you have to override the default and choose a different UI element/widget to represent that Item.

3

Totally agree on your point. And be sure do not confuse items and points. but they are tightly linked.
The semantic model only helps to provide an interaction method (command) with the equipment and represent its state. But considering the proxy layers I have setup (which all are set to Text item to accept text and values as well), I am realizing that the logic of genericpoint could apply to items: having one more versatile genericitem that would replace switch, number, dimmer, rollershutter, text items types.

Back to genericpoint, advantage is that they could be displayed using a single default “multibutton” / “slider” widget and replace most of the types of points defined in the semantic model. Mulltibutton would address switches (2 positions/ commands), rollershutters (3 commands, “continuous” position), dimmers and more generally any type of controllable channel (with discrete or continuous values).

At this time, all proxy items I defined to control equipments in a smart way (eg: usable by any non skilled person) cannot be displayed in MainUI.
For example, the living-room has 7 Zwave dimmers + 1 RGBW dimmer. When people turn the light on the living-room, they don’t want to see 8 devices in the UI but only 1 “smart” device which can be set to “READING”, “LOW”, “WARM LOW”, “DEFAULT”, “THEATER”, “STONE WALL HIGHLIGHT”, “HIGH”, “MAX” (which is already quite complicated to choose from for some…). And even a “CUSTOM” command which actually displays / hide all the sliders of the underlying real dimmers.

This could be achieved quite easily with sitemaps. No much to change to the Main UI to have the same possible behavior I think

4

No, the Item Type provides the interaction method. The UI Widget provides the interaction method. The Semantic model does not and never has played no role at all in the interaction method. Perhaps someday but probably not soon.

It sounds like you have set up openHAB in a very specific and somewhat unusual way and want to change how OH works to accommodate your specific choices in setup. And there is nothing wrong with that. But the introduction of a new Item type is a really big deal. It impacts everything which is one reason why there hasn’t been a new Item type introduced for over half a decade. And you also want to rewrite the UI so that it uses the semantic model in a wholly new way on top of that.

Why not? Like I already said, just like you’d choose a Selection element in the sitemap to represent that Item or a Switch with mappings, rather than rely on the default widget which, in this case would be Text. So you do the same thing in MainUI. You choose and configure an appropriate widget to represent the Item instead of the default by setting the Default List Item Widget Item metadata.

If you’ve got a lot of Items that need the same widget configuration, you can create a custom widget (Developer Tools → UI Widgets) and select that widget for the Item instead of using the built in widgets.

5

@rlkoshak. My point here is not to complain about not finding a way to implement what I want: I know I can build (well… if I have the skills :face_with_raised_eyebrow:) almost what I want in openHAB with a little effort and the existing.

My point is rather to propose more genericity for items types making them inherit from a parent item class that would bring more flexibility to the users and developers by covering most command/update usages. When I see how groups, semantic, and general features are develop, genericity sounded to be in the DNA of OH development.

Of course, such a core change probably requires a development effort. But I believe it is worth at the end because this would simplify how we deal with items in code (instead of having to care about what type of command the item is capable of).

Such evolution could be brought in 2 steps (1) implement the new generic item aside from existing items (2) make all current items become a specialized class from the generic item (inheritance).

6

To some extend, yes as I had to implement some features important to me that were not in the original OH1.8. Honestly, I think I miss time to stick to all new features coming with new versions of OH

But I am doing my best to model my current system using the existing OH brick (for example it has been rocky simple to setup the semantic model due to the logic of items/groups imbrication I has setup since the beginning :cowboy_hat_face:)

7

There already is a GenericItem. GenericItem (openHAB Core 4.2.0-SNAPSHOT API)

All Item types already inherit from GenericItem.

OH core already doesn’t have to know or care about the specific type of the Item except in cases where it matters (e.g. a binding needs to know what commands and updates an Item can accept to command or update the Item when interacting with the end devices).

All the ways you can interact with an Item is already incapsulated in the Item type. Nothing needs to care about that stuff unless it matters. Where it doesn’t matter they use the Item as a GenericItem. Where it does they use the Item as it needs to be used.

No one would stop your from filing an issue or submitting PRs (note a change like this will probably hit about 5 separate repos with their own maintainers so you’ve a lot of work just convincing all the maintainers that this is supportable and doable. As far as I understand it, this seems to be finding a new way to solve problems that have already been solved to make a very rare and specific way of configuring OH a little bit easier. But it does so through a huge amount of work and it muddies the distinction between what responsibilities go in the Items and what go in the semantic model. And this can be dangerous because:

  1. the semantic model is and will probably remain optional
  2. there will then be two places to look to figure out how to interact with an Item
  3. except in your very specific case where you have String Items proxying just about everything, it doesn’t actually save any work for the end users.
8

Thankfully OH architecture is sometimes robust (I am joking :grin:). More seriously, if all is there with class inheritance, why such a versatile item is not accessible to end users ?

Of course this has nothing critical: a Number item can model derivation of Dimmer/Rollershuttter item I expect by mapping the commands to numeric values: a bit ugly but it works.

To illustrate, I use a Number item to model light control for each room. It controls one or a combination of “real” light dimmers, color bulb or simple bulbs.
The item can be sent:

  • level commands between 1 and 100 (which set the level)
  • scene presets commands mapped to values over 100 which turn to direct light modes ,
  • Up/Down commands to change preset (mapped to values 997 and 998),
  • Bright/Dim commands to change level (mapped to values 995 and 996),
  • Detail command to show/hide underlying light items in the UI (mapped to value 999),
  • Blue, Cyan, Red… commands to switch to color modes mapped to 800-808
  • Info, Warning,… Alert commands to set temporarily the color in the room in sync with the notification sub-system (TTS, Kodi OSD), mapped to 700-709

Indeed, for simplification of UI and end-user experience (end-users being members of the family not interest at all in home automation…), “hiding” the 1080 items I have behind scene items for all functions (for light, audio video, doors, shutters, alarm, presence) is valuable so I use this logic intensively.
Maybe I miss something in OH that would help to achieve this differently but these scene items are the smartest way to create simple, robust, intelligent interaction between systems.

9

They are exposed in Rules. In fact by default that’s all you get in the rule, is the Item cast as a GenericItem.

However, a “GenericItem” is meaningless in the UIs so it’s not exposed there. A GenericItem doesn’t possess enough information to describe how it’s interacted with. GenericItem is also abstract so it doesn’t really exist on it’s own. So when the UIs query the REST API for the Items, they get the subclasses of GenericItem, which they need because it’s that which tells MainUI how to interact with that Item (e.g. a Switch Item uses a toggle). If the default widget isn’t what you want, there are ways to configure and change that interaction on an Item by Item basis.

For example, in your example I can easily see that Item having a custom Default List Item Widget which can do everything you describe. If you have more than one Item that works like this, in MainUI you can create a custom widget and apply that to each Item that needs it (i.e. define it once and reuse it).

What you’ve done is define your own custom abstraction layer between your “raw” Items and your interaction Items. And now you are looking for a way to codify that in some way in OH core. But most users don’t do it that way and there is already a way to define custom interactions with Items.

That’s why it seems very much you are solving a problem that has already been solved, you just don’t like it or are unaware of it.

10

Yes, you are totally right: I was not aware of what the Main UI brings with the widgets. I did not deploy HabPanel as I consider touchscreen interfaces as brilliant for show-off but unusable for end users reluctant to IT. I sticked to a tweaked sitemap (but I am now working to switch it to main UI since I discovered the widgets and got my semantic model in)
Probably should I dive deeper in the new features when they come but that supposes to be a real OH geek and addict, what I am not, mainly due to the lack of time to spend on it.

It would be wise to provide demo setups for main and new features when installing OH (like there was a demo.sitemap) to guide users and “advertise” the new functionalities (with dummy item).

I don’t know what public is targeted by OH, but my limited brain misses more “how to’s” in the documentation and some downloalable and usable examples or links to the main topics in the forum related to basic setups so we have an overview of what can be achieved by each layer. For example, in my case, I am trying to address my scene abstraction level at item level whereas it seems now obvious that is is partly addressed with semantic and widget levels.

That’s just a personal feedback, not a criticize on OH which remains to me the most flexible, versatile and robust (except for rules and scripting but maybe because I did not dive neither in the last features…)

11

There is https://demo.openhab.org/ which is mentioned in the docs (but probably needs to be added to the Getting Started Tutorial). There is also the Marketplace with tons of examples that can either be installed and used or looked at for examples. The Getting Started Tutorial also dedicates four pages explaining the ins and outs of MainUI to include creating custom widgets.

But with MainUI, there is no single file you can just look at to see examples that can ship with OH. That’s why we have the resources above.

This is what the Getting Started Tutorial is for. If you find it lacking we are open to suggestions for improvement. And I’m not saying this is you, but most of the time when people complain that there are not enough tutorials, they’ve not even looked at Getting Started.

Problem is what’s a “basic setup”? Everyone’s home automation is unique and bespoke. One person’s basic setup totally misses the mark for someone else. We can’t cover them all. So while the Getting Started Tutorial isn’t an end-to-end tutorial where it creates the Things, uses those same things for the Items/Model, then UI widgets for those same things and so on, each individual page is a nearly self contained tutorial unto itself and they progress from simple to complex.

12

Like, um, smartphones?

13

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.