I am experimenting with adding a dynamically created channel to one of the thing types in a binding that I am working on.
I have been able to create and add the Channel. I can confirm this by logging iteratively over getThing().getChannels() in the handler. However I cannot get the new channel to show up in Main UI | Thing | Channels.
@laursen since you had experience of doing this successfully in HDPowerView, I wonder if you can give me any tips?
@laursen for background … the binding that I am working on is the Velux one; and in that binding I just added support for a vanePosition channel; and since only some actuators support a vanePosition I want to create that channel dynamically only when supported. … and … and … perhaps we should also consider doing the same thing for the HDPowerView secondaryPosition channel too?
That’s actually all there is to it, IIRC. In this example the channels are truly dynamic, i.e. a unique channel is created for each scene, scene group and automation. So this use case is not about hiding irrelevant channels, but being able to add as many channels as needed to the same thing.
Sure, why not. Just keep performance in mind when implementing this, and consider the position of this secondary channel, so it will appear right after position (most likely you would end up with a mix of statically defined channels and the dynamic one).
In the meantime I discovered that the added channel does exist according to the OH Developer Tools API Explorer, but it is not visible in OH Main UI | Thing | Channels. So I think it might actually be a bug in Main UI. However the mystery is why it doesn’t show up for my thing / channel whereas it does show up for yours…
I think the differences between mine and your cases may be…
The dynamic channel is added to a thing rather than a bridge, and/or
The dynamic channel is not assigned to a channel group
Last time I tried I found I could not dynamically ADD a channel, so instead I went with dynamically removing the channel instead which works. If your having an issue I would add I had a similar issue and this may be a bug.
Wled binding has example code on removing channels dynamically.
Generally speaking yes, practically - it depends. Thing definitions (thing types) are being read from XML files by default. If you add a channel at runtime then thing type and its definition remains same as earlier, what you change is instance of a specific thing. Practically a lot depends on a fact if a caller is looking for channels of a thing or channels of a thing type. UI can do both.
In my perception it is a gray area as there is no way to declare a channel as optional within XML file. All channels you put there are enabled by default and will appear for each thing of given type no matter if handler can cover it or not. I know that in ideal universe we would have a new thing type for each of these cases, but again in practice a updated firmware version can bring new functionality, hence channels.
I would say that this is one big reason why you have channel types defined separately from thing types in the xml-files. That way you can define all possible channel types, and then dynamically add them to the Thing by the thing handler.
I would use the browser’s developer tools to check what is returned from the rest API for the different channel type definitions, thing type definition and thing, and see if there’s any difference. If there is, you could probably modify the code to add whatever’s missing.
I think the issue was to do with localisation. In the first attempt I was relying on OH to get the channel label (and description) from the channel-type definition. But in the second attempt I explicitly added a localised .withLabel() (and .withDescription()) … see below