[core.thing.internal.ThingManagerImpl] - Check result is 'not ready'

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?


I don’t know specific issue yet.

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.

Related issue is: Binding in "NOT_YET_READY" state after recent core changes · Issue #3394 · openhab/openhab-core · GitHub

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?

Thanks @splatch, the referenced bindings show how this should be done :slight_smile:

Precomupting all channel types isn’t feasible as it would mean a combination of multiple variables.

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.

Thanks for the info @ccutrer

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.