Perhaps I have expressed myself in correctly. I try to control my thermostat under Locations in my room. the problem is that my item for the thermostat is a number. and I can’t control them.
the item
Number sPZB001_schlaf_solltemperature "Soll Temperatur" (SZ_Thermostat) { channel="deconz:thermostat:000000000000:00158d00032f6160010201:heatsetpoint", alexa="ThermostatController.targetSetpoint" [scale="Celsius"] }
To change how an Item is shown in the automatically generated parts of the UI you need to override the default by setting a default widget in the Item’s metadata. In this case you need to tell it to use a setpoint or slider in the default list item widget.
EDIT
now i found the option, i was blind.
THANK YOU !!!
Go to the Items page under Settings -> Items. Click on “Add metadata” Choose “default list widget”. Fill out the form to define the way that Item is represented.
Your screen shot is from the Thing, not the Item. The Semantic Class and Property have nothing to do with this.
thank you it works well.
but i had another problem, perhabps you had a idea.
i want to change the label-cell color based on a status of a switch, the values are “ON” or “OFF”.
i tried this
=parseInt(items.dummyawayswitch.state.toString) == OFF? “green” :
parseInt(items.dummyawayswitch.state.toString) == ON? “orange”: “red”
but he always shows “green”.
why do you parseInt ? 
what can i else use?
i tried
=items.dummyawayswitch.state == OFF ? “green”: “red”
in the developer test console it works when i change the OFF to ON the green and red changes.
BUT the label-cell dont gets green, it changes the color to red when the status is ON but the cell changes to black or default color when the status is OFF
I assume you mean this colory thing like here: ?
Hi everybody,
With the semantic and non-semantic idea in mind, a group of people around me are setting up our homes currently as good as possible which only now happens to become very user-friendly via the new UI.
However, we have been struggling with using SEMANTIC and NON-SEMANTIC groups within the tree because some of the items (or group) “suddenly” disappeared. It took us a while to find out when it is happening, so we put this together which I try to document below. The main question then is why this is happening and whether and if why this is maybe intended.
Let me explain our usecase:
we have the following setup in a semantic way
of course we also have rollershutters in the first floor in several rooms which I didn’t document here for brevity reasons…
All of the above are semantic items and groups
Now we define non-semantic groups, so we can control the Rollershutters in a hierarchical way. Note that the intention is to reuse our semantic RS groups that we already have in our rooms to avoid recreating them.
So
And from a control standpoint this works pretty well. We can control “RS all” together or “RS second floor” at once. All good BUT there is a display issue in the tree of the UI
We basically have two roots, one semantic and the other non-semantic. The first tree is completely shown as depicted above but the second tree HIDES the semantic groups which is kind of sad. It is only showing that the following way
Note that if you click in “RS second floor” and go to the edit mode, you of course see its sub-childs or groups.
As the behaviour is actually a bit hindering managing the groups like that as you cannot use the tree to navigate and have an easy overview of the non-semantic structure, our question is:
Is there a good reason not to show the semantic groups in the non-semantic group items or would it be possible to show them?
Additionally there is a small wish: unfortunately the checkbox “non-semantic items” is not kept. Can we make it sticky?
Thanks for all you great work and we are looking forward to understand the above behaviour.
Stefan
I believe that the Model view is first and foremost intended for viewing, managing, and manipulating the model. In the model, any semantically tagged Items can only be a direct member of one other semantically tagged Group.
Given that, it does not surprise me that the UI doesn’t handle very well the case where an Item is a member of more than one Group. That’s not really allowed in the model. The UI was never intended to be used to manage the non-semantically tagged Items so that use case is not well supported.
Ultimately it comes from the fact that the Items that are semantically tagged can only appear in the model once. That seems to be a fundamental constraint in how the model UI was built. You can’t have a semantically tagged under both Groups because that would cause the Item to appear in the tree twice. That’s not allowed in the model, though it is allowed outside the model. But the model view wasn’t created to handle the Items that are outside the model.
You can and should file an issue to see what Yannick thinks. Personally I’m a little ambivalent about it. If the UI starts allowing Items to appear under multiple Groups it will result in people building “impossible” models if not very careful to preserve the limitation that an Item can only be a direct member of one semantically tagged Group.
Thanks for your thoughts, Rich.
Though I definitely understand where you are coming from and I can see that one can do unexpected things, I do think that the usecase above is very valid to allow efficient and non-refundant management of groups. It is not that what I am proposing is not already doable in the model it is just not visible in the tree.
To be honest the biggest problem I see is recursion which probably already could appear in the model (I will try that eventually what will happen in this case) which is a bit of a challenge to prevent in tree visualizations…
I thought about filing an issue but before doing I was wondering if Yannick (@ysc ) could quickly share his thoughts
Stefan
It’s true that the it’s a limitation of the semantics implementation - items need to be direct group members to establish a relationship, so you can’t e.g. organize your living room rollershutters in a non-semantic group, place it in a location group, and expect it to appear in the model.
That’s because the model treeview is not built on the basis of group membership (at least not for semantic items), rather on these relationships described in metadata that you can otherwise see in an item details page - the “isPointOf” or “hasLocation” lines under “Semantic Classification”.
The status of “show non-semantic” could be stored in the browser’s local storage and recalled, noted.
Out of curiosity, could the code that shows the tree in the model view be reused and modified to show all the Items hierarchically without the limitations of the model. That could replace the Items list, or be an alternative view one could use on that page. Then users can get the benefit of the hierarchical view of their Items even for those that are not a part of the model.
Just a thought. I haven’t spent much time considering the impacts so consider it half baked. There might be some really good reasons not to do that.
I like the idea of Tree or Flat view mode on the items page. From a programming perspective it shouldn’t be too much trouble to organize based on group membership and to just not keep track of whether an item is already displayed. The tree builder is specific, but I expect it would be simple enough to reuse the display code and provide it a different tree to display. (I have not worked on the UI, just basing this on my past programming experience)
In part, perhaps. The flat list of Items is admittedly not very useful when you’re past having a manageable amount of them, in the end its only practical purpose is to offer a search box so you can quickly get to a particular item and bring up its page.
That would be very much appreciated - it really is a bit annoying if you work a lot with non-semantic items, and you have to go in the detail- and back on the tree view a couple times.
I also agree with Michael, the idea of having the choice between a tree- and a flat view sounds pretty good to me! Just one question to what Rich wrote:
You can’t have a semantically tagged under both Groups because that would cause the Item to appear in the tree twice. That’s not allowed in the model, though it is allowed outside the model. But the model view wasn’t created to handle the Items that are outside the model.
I’m super-new to OH (in fact, thats my first post), but if it is allowed outside the model (as non-semantic item) but not handled well in the model and is not shown, it feels more like a bug. Especially if you’re new to the concepts like me. Maybe it would be more consistent to disallow it at all, or at least display a notification - just an idea.
I would like to tag my Car’s windows as window for HaBot recognizing:
“Which windows are open”
How to do that?
Do I need a Group (Window sub-equipment) in Car for each single window or could I also use ONE Window group equipment and 4 OpenState Points?
I think either would work but the only way to find out is to give it a try.
you are right (as always and I tried it:
When using one window group the subsequent windows (tagged “OpenState”) seem to work.
Unfortunately the sub-equipment group “window” disappears then from my Locations view:
Outdoor -> Car (what I don’t like).
So I probably go without the group.
However, HaBot does not know, that these are windows then 
