I’ve only looked into the code to see how it was being done, and again when playing with JSR223 to add some Things/Channels that I could link Items to for custom lists of streaming radio stations. I’m definitely not much use for creating support documentation for binding development. But I would if I could!
Even experienced developers will have a major hurdle getting into OH development without proper documentation. Now is a good time to get this built up too, since there is a large chunk of openhab-core documentation that should be migrated over from the ESH documentation. I’m fully immersed in trying to figure out how to use ConfigOptionProviders (without documentation ). I have been thinking of starting up a topic about the need for development documentation when I come up for air, but that may be a while. Although, if someone would want to get that ball rolling, I’d surely chime in!
I created and linked items to the corresponding channels and as I already stated, I´m using the kodi binding as a reference, but after one week of trial and error still zero progress. I still have now idea what to do that getStateDescription will be called on my channels. Every channel of every thing is being logged when i use logger.info() in my description provider but the ones that I need.
Do you already have some code to link to? If so I can have a look into it. What do you exactly want to do? Which part of the StateDescription do you plan to change during runtime?
The DynamicStateDescriptionProvider of your binding will be an OSGI service which needs a consumer to get activated. Linking items to channels will not be sufficient. You have to add those items e.g. to a sitemap or inspect them in Paper UI. On the one hand the DynamicStateDescriptionProvider provides the information via the getStateDescription method to the consumer, on the other hand the bridge / thing handler - in other words you - are responsible for collecting the information and pass it towards the provider. Therefore the Kodi binding uses a polling job which frequently retrieves information about e.g. the users favorites or PVR / IPTV channels from the Kodi interface and stores them temporarily in a HashMap.
Just last night in bed I was wondering how I could phrase asking this exact same question, so I’ll be following this one with interest!
I’m currently writing a new Binding, which will need to dynamically modify aspects of some Channels (source names etc) - but I’ll also want to change the available options for a channel based on the value of a Property of the Thing - is that the same thing, or something different?
Sounds similar. You can change every property of the StateDescription, which are
* the minimum value of the state
* the maximum value of the state
* the step size
* the pattern to render the state
* the readOnly property - if the state can be changed by the system
* the options - a predefined list of `StateOption`s
If you like to change the label, the description, or similar, you have to implement it in a different way by re-creating the channel.
@Zodiarc Thanks for the link, I will have a look later.
I’ve got a Property of the Zone thing type (selectableInputs), which is currently a comma-separated string. It’s this list that I’d like to then have as a drop-down in the Source channel. It would also then be nice to get the proper names of these from the units.
@Zodiarc, thanks for pointing in the direction of your WIP code - I’ve managed to utilise it as a basis and have my Source selection drop-downs in the Control section of PaperUI working absolutely perfectly. Each Zone Thing has a completely customised list, using a subset of the full list (the full list is maintained at the Bridge level).
Next I’ll look into replacing my comma-separated list with a drop-down list when configuring the Properties of my Zone Thing.
My latest code is up on my github repository if anyone else is interested.
It might be that when you’re calling updateOptions your Channel isn’t yet Linked as it’s too soon in the initialization process.
I’m calling setStateOptions from both initializeThingHandler (which actually only takes affect for me if the Thing is modified after it’s already fully Online) and most importantly from the channelLinked event - it’s this latter one which seemed to be the trick.
I still have defined a default set of Options in the config, but I’m then overwriting it once I’ve got the information I need. Not sure if this is required, or whether it’s OK to leave the config without any default Options…
Setting of the state options is not a problem. I used logger.info() to output the options in the provider and it was populated correctly. The framework simply somehow refuses to call getStateDescription on my (linked) channel. I’ve put another logger.info() into getStateDescription which outputs the channel UID when it’s called and I see every channel with a string type in my setup except the one I actually want.
I walked through your code and the implementation looks good. I could not find a reason why it is not working. Two minor things to mention:
The originalStateDescription paremeter of the getStateDescription could be null which should be handled in your code before accessing it’s methods.
The <state readOnly="false"></state> tag on your ac-mode channel type definition id superfluous because readOnly="false" is default.
We maybe have to look at a different place for your issue. Just to make sure everything is correct might I ask you to post your configuration (item, etc.) for it?
Currently I have an idea how to improve the implementation for dynamic state descriptions. As nearly 90% of the existing implementations are similar we could think about an abstract BaseDynamicStateDescriptionProvider class in for the framework which bindings are able to inherit. One problem I am aware of could be solved by this approach: translating the dynamic state options. For me it is not working right now.
The only difference I can really see between yours and mine is that I’ve got some default <options> set against my channel in thing-types.xml, and I’m then overwriting them with the dynamic stuff.
I do not think that is the reason. I have not set default options for the channel types in Kodi binding and it is working.
I can remember there is an open issue in Paper UI if you manually create Things which are related to a Bridge. The resulting UID is different than in textual configuration. Unfortunately I cannot find the source where I read it.
Did you try to put your item in a Sitemap for a different UI? Maybe Basic UI?
@Confused I looked into your code too. The implementation for the dynamic states looks good. Same comment:
The originalStateDescription paremeter of the getStateDescription could be null which should be handled in your code before accessing it’s methods.
Your binding is a new one? Do you think about providing it to the community and contribute it to the official openHAB 2 Add-ons repository? Would be very much appreciated.
I did all my thing and item setups through PaperUI. I also tried to set the item to enforce auto update (since the ones that are called have this option enabled too) but still no progress…
UPDATE: So I had time to work on it again and instead of trying to solve the mystery I added 2 more channels to the dynamic descriptor. I don´t know why and how but one of them actually worked (and I did nothing different). The code in my repository was updated. The channel that actually works is the swing mode.
Another thing I noticed: I added default options for those channels that are not working with the dynamic descriptior in the thing-types.xml. Those options also don´t appear. Any ideas?
Alright I´m already thinking this system is trying to mock me or something… I removed everything as a test and recreated it. Now the one channel that was working also stopped to work… Even state options defined in thing-types.xml are ignored… This bevaviour is so random that I´m starting to thing that there´s something wrong with the actual framework.
). I have been thinking of starting up a topic about the need for development documentation when I come up for air, but that may be a while. Although, if someone would want to get that ball rolling, I’d surely chime in!