I would like to set the temperature of a thermostat. What do I have to do, that automatically in the location overview an input option is displayed? I have already declared the item for temperature setpoint as “Mearusement” “SetPoint”. When I click on the setpoint, I do not expect a diagram, but an input option. Where the NULL is in the screenshot, I would like to see some kind of slider or something similar.
@ysc: Do you have any idea?
Yes,
Go to the Model, find your setpoint item, then click “Add metadata” > “Default List Item Widget” and then change the widget type from “Default” to “Stepper List Item” or “Slider List Item”, whichever you prefer.
Complete the details and save.
Better heuristics to determine the best default widget is something that has will have to be improved in subsequent OH3 releases, right now little more than the type (and eventual state/command descriptions) are considered. Surely the semantic tags should be considered as well.
Thank you very much!
Is it possible to define this metatags in the items file? Or should i change this via ui for text-defined items?
With textual configuration it’s something like:
Number Item ... { listWidget="oh-stepper-item" [ min="0", max="100", ... ] }
@ysc I have the same problem when integrating the Shelly Thermostat and adding a channel for the target temperature using Settemp. The channels gets created, but the linked item is displayed as read-only. Even if the above approach (adding meta data works) I need a way to defined this on the channelTyp level in the thing xml.
This this is the only way to avoid confusing the user, because channel/item is there, but can’t be modified from Main UI. In any case I would at least expect a raw edit field (like PaperUI did it) and then the user has the option to change the control. What do you think? Is there a way on the XML level to add the default widget?
Personally I dislike bindings interfering in Item presentation business, but understand the attraction for “instant setup”.
This sounds like a use-case for read-only / write property via channel. If the channel is read-only, Item defaults to number display. If read-write (or write only), stepper display.
So the channel supplies a read-only property, but the Item infrastructure chooses the actual widget.
ok, ordered 
This is something that could perhaps benefit from an evolution of the thing type description, like “how would you like the UI to display this particular thing?”. We can imagine binding add-ons providing UI widgets tailored to their things.
This is a broad question however which has to account that there are multiple UIs and whether separation of concerns warrant this at all (bindings would not ideally being concerned with the UI).
But as I said earlier there could be some evolution in the logic of the UI to show an appropriate control when the item has a “Control” or “Setpoint” tag.
