Issue of the topic:
I have been adding and linking items for my things using both PaperUI and HABmin; over time, I have added a number of things that are of the same type, but I notice that the item values don’t display consistently. In PaperUI’s Control section, the values display but some lack units. In some other UIs like the BasicUI or in the OpenHAB app, the values can be missing altogether (even though they display in PaperUI and HABmin.
I am creating/linking my items through PaperUI and HABmin using the default settings and as far as I can see in the web interface, the configuration is the same.
What might I be missing in setting this up correctly?
As an example, these are two things that are the exact same type (Z-Wave motion/temperature/light sensors):
Invisible to you in these UI’s, every Item can have default state options properties. Can’t remember what they are called exactly. If you use the REST API to examine these two Items in JSON form, you will spot the difference.
Invisible or not, the UIs can use those to do default formatting of the state display and widget options (like populating a selection box, or displaying ALARM/OK instead of ON/OFF)).
Where does that come from? The binding can pass it along through the channell to the Item. That kind of data is derived from discovery or the binding otherwise “knowing” detail about the target device.
In the case of zwave, I’d guess that involves the device database thingy.
Remember, this is all about defaults. If you don’t like the default formatting then set your own formatting.
Apart from the administrator UIs, which are toolboxes and not expected to give you fancy formatting,
Ah I see, thank you for that info. I didn’t realize there was some behind-the-scenes default data from the binding that could vary. It seems that the items which by default showed values in a specific format without me configuring the format had some extra “stateDescription” data in the JSON returned from the REST API.
I was confused when the defaults themselves started to differ for what I otherwise thought should be exactly the same and there wasn’t any clear representation of why in the administrator UIs.
That’s the magic words, thankyou!
Most of the existing bindings don’t implement this stuff.
zwave can because it (sometimes) has detailed knowledge e.g. that channel name on this model device is a smoke alarm.
