Are the channel-type/state/options simply there for documentation, or can they be applied? Values seem to pass-through updateState() unchanged. I need to get a better understand of what to expect.
This is what I am expecting, but this is not what Iām seeing. Where is it applied? Iāve traced the code all the way up to the OSGiEventPublisher.post() call, and I donāt see where any of it tries to do a transformation, aside from profiles in the CommunicationsManager.
be shown in PaperUI
Iām developing in v3 environment. PaperUI is gone now?
## HTTP ERROR 404
Problem accessing /paperui/index.html. Reason:
Not Found
[Powered by Jetty:// 9.4.20.v20190813](http://eclipse.org/jetty)
I have seen ways to do this in items and with profiles. However, I am developing a binding, and Iām must develop a contract for my interface. As the developer of a binding, my job is to hide the physical implementation details behind my interface and provide users with a predictable contract. It would be inappropriate to supply a binding that canāt work out-of-the-box without hundreds of UI hacks. All of the mapping needs to happen inside the binding, and the users needs to be interacting with a sane API (channels), and not have to get their hands on a device manual in order to figure out what to do with raw values.
openHAB wisely divided concerns and supplies physical, logical(virtual), presentation, etc. abstractions. Bindings from what I can see expose an interface between the physical (channel) and logical(item) abstractions. Users are free to create virtual and UI aggregation and higher level abstractions, but Iām looking to understand developing a sane binding interface that honors separation of concerns and provides the correct level of abstraction for the virtual consumer.
The options are used with sitemaps. If you show an item on a sitemap it will display the option content and if you configure it as a Selection the ui will render it as a selection box.
Its also possible to fill these options dynamically in the binding. For example for a list tv channels.
Options are also used in the new MainUi by openHAB 3.0.
As you can see in the screenshop, only mode (Betriebsart) options defined in thing-type channels are seen and selectable.
So, is it safe to say that raw values, as supplied by the binding, are carried throughout, at least with string type, and <options> provides a dictionary with which various elements in the system can get a translation?
So rather than values being translated once as they enter or exit the binding, theyāre translated by each element of the system each time theyāre needed?
Are there cases where a user might need to interact with an untranslated value, like during scripting, configuring, rule creation, etc., or will the raw value always be hidden from user view? I may translate the raw device values to at least āparser friendlyā mnemonics in that case.
That sounds about right. After all, the Item does not ābelongā to the binding, the user may do with it what they wish - including linking to other bindings etc. stateDescription may be used to offer āsuggestionsā like a menu, but should not otherwise constrain the Item.
I havenāt figured out what happens when an Item is linked to channels with competing stateDescriptions!
Your binding can of course apply any constraint it likes to channel data in/out, and can helpfully offer descriptions of the data.
Considering actual Item state, you canāt please everyone e.g. due to language. Whether itās best to use raw device supplied codes or substitute your own, youāre best placed to decide.
Interaction with the binding will always be done trough the raw values. From your example in the first post, 02 will be the raw values, needed e.g. in rules, whereas 480p is what the UI presents to the user. You can also define this as parameters, used for translation into different languages.
Furthermore, as said before, you can limit the possible values like many bindings do if it comes to special operation modes like thermostat, hvac, air conditioners, ā¦
Well, I donāt really want to translate more than necessary. So, Iām okay with
Device Binding UI
0F -> 0F -> "Out Of Range"
But, while 0F is efficient for parsing, it means nothing to a user who might need to interact with it. So, in that case Iād prefer
Device Binding UI
0F -> "outOfRange" -> "Out Of Range"
to be parse friendly you want to keep mnemonics to [A-Za-z0-9]. When you start introducing () * +, and such, often found in the full description, you end up with processing problems.
Itās my understanding that users can supply localized strings if they want to translate to different languages.