hello all, very simple question: i just started migrating from oh 2 to 3, i’m creating the semantic model. Since version 2, I have already implemented a series of items which, using network binding, verify the availability of a series of devices, for example wifi access points. Now I wonder which semantic class to associate with these items? Alarm or Status or a new class called Availability?
And what semantic property? To be honest I haven’t found one, it would be nice to have one called “Network”.
Finally, I don’t think I’m the only one with this kind of items, how did you solve the problem (if it’s a problem for you and if you’ve ever asked yourself the problem ;-))?
Go back a step - what do you want to fit these Items into the location-based semantic model for? i.e. what purpose, some kind of display feature, what would that look like, etc.?
I have the same use case. There really isn’t a great combo of tags that exist right now for this. I use “Status” for the Point and “Power” for the Property.
Furthermore, I set the custom list item widget and set the visibility to only be true when the Switch is OFF so it only shows up when there’s a problem.
On the Properties tab, I customized the card for Power to read “Batteries and Services”.
They show up under “Statuses”.
Hmm, I need to go configure that Master Bedroom Sensors properly.
Also note, these Items are part of the equipment being measured. So, for example, I have a Dad’s Sensors Equipment which is made up of Items from Network binding and others.
I’ll give an example: a sonoff device connected to OH via mqtt has, for me, three points of availability to check and monitor: the mqtt broker, the access point to which it is associated and the sonoff itself. with the network binding I am able to verify that the ports of the broker of the access point and of the sonoff are reachable at the ip level;
I therefore hypothesized that the equipment that I define in OH is also made up of the information that tells me whether the port is reachable or not (available) as well as information on the temperature, humidity and switch status.
As a result I wondered how to represent this information in the model
Thanks Rich, you’re too ahead for me, that’s exactly what I would like to do too.
I agree on the “status” class but am puzzled to define “power” something that to me is “availability” or “reachability”.
I had to choose something and I wasn’t using “power” for anything else. And I think about it as the power status, i.e. is the device powered on.
There are clearly flaws regarding the semantic model but the issue to address some of those flaws went nowhere. There are two camps it would seem. One wants all the tags for all the things so, for example, we have patio, terrace, lanai, and more or door, outer door, garage door, front door, back door, hall door, kitchen door, bathroom door, interior door, and more. This camp ultimately wants to be able to define any arbitrary semantic tag.The other camp (which I belong to) is that we should follow the pattern we have to points and properties. We only have one door equipment tag but we allow modifiers so we can create “front door” in two tags.
But both approaches requires a major overhaul of the semantic model and will almost certainly result in breaking changes so for now we have status quo.
You don’t need to have a Property tag at all if it bothers you. However, without a Property tag, it won’t appear on the Properties tab on the Overview tab.
I didn’t want to unleash any controversy about it, I just wanted to know how you dealt with the fact of the lack of some classes and properties that it seemed strange to me that they weren’t present.
I think the properties are important and useful, that’s why I asked for clarification.
No controversy. Some users disable the Properties tab entirely. Lots of people don’t even use the semantic model, and that’s completely valid too.
We have lots of options, each with trade offs. You have to choose the one that best works for you.
1 Like