I’m developing a binding for ESPHome devices, and due to the nature of ESPHome configurations channel types and channels are created dynamically when the device has been interrogated. Whenever I restart openHAB the thing is stuck in state NOT YET READY for 2 minutes. After this everything works as expected.
... [core.thing.internal.ThingManagerImpl] - Check result is 'not ready': ThingPrerequisites{thingUID=esphome:device:mydevice, thingTypeUID=null, channelTypeUIDs=[esphome:mynewchanneltype, ...], configDescriptionUris=[]}
Is there a way to programmatically tell core that channel types are now available? Or could someone point me to a binding that creates channels on demand - and do not exhibit this problem?
However, I do remember there was some new code for dynamic things in OH 4 which was added by @J-N-K to handle situations when channel types are calculated from some results.
As far as I understand changes in 4.0, which are related to that aspect, were introduced to prevent situations when thing type contains unknown channel types.
Other question I might have - can you normalize channel definitions i.e to rely on item types instead of calculating them from received data or discovered nodes?
Note that many pieces of channel metadata don’t strictly have to be part of the channel type. You can use a state description provider for units and min/max, for example. This can be extremely important if you have a lot of devices. For example, I have WIP commit for the mqtt.homie binding that uses constant channel types, but still dynamic thing types. Otherwise the channel metadata that MainUI has to load can be several megabytes. So for example you would have channel types in the XML for button, sensor, binarysensor, etc., but only build a final dynamic thing type with all of the groups and channels from all of the contained components.
The way it is structured now is a single thing, but with one channel for each sensor/switch/etc reported. I see the following variables in play for the channel type - all based on what the device is reporting;
Item type (all kinds including QuanityTypes)
Channel label
Icon/category
Semantic tags
Read only vs read/write
State options for text channels with predefined list of accepted values
State description pattern (ie accuracy from sensor)
So the latter 3 could be put in a StateDescriptionProvider, and the first four are fairly related. But still the list of channel types are going to be long. I’ll consider refactoring this at a later stage.
