Yes indeed, this seems to be something recently introduced, not specific related to the binding.
opened 06:03PM - 08 May 23 UTC
enhancement
Some bindings implementing dynamic thing types, channel types or channel group t… ypes are now initialized with a delay of 2 minutes. The thing status is UNINITIALIZED/NOT_YET_READY during this delay. After this delay, you got these warning in logs and the thing finally goes ONLINE:
```
20:25:31.807 [INFO ] [org.openhab.core.Activator ] - Starting openHAB 4.0.0 (build Build #3453)
20:25:47.197 [INFO ] [re.automation.internal.RuleEngineImpl] - Rule engine started.
20:27:44.279 [WARN ] [.core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'remoteopenhab:server:prod' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
20:27:44.290 [WARN ] [.core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'remoteopenhab:server:prod': {thing/channel=Type description remoteopenhab:itemString1 for remoteopenhab:server:prod:SonosSalonRadio not found, although we checked the presence before.}
20:27:44.313 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'remoteopenhab:server:prod' changed from UNINITIALIZED (NOT_YET_READY) to INITIALIZING
20:27:44.319 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'remoteopenhab:server:prod' changed from INITIALIZING to UNKNOWN
20:27:45.598 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'remoteopenhab:server:prod' changed from UNKNOWN to ONLINE
```
See issue openhab/openhab-core#3394
PR openhab/openhab-core#3407 introduces `AbstractStorageBasedTypeProvider` to reduce this problem.
It has now to be used in the bindings with dynamic type providers showing this delay at startup.
Bindings implementing ThingTypeProvider:
- [ ] digitalstrom
- [ ] homematic
- [ ] mqtt.generic
- [x] netatmo => no change required
- [x] systeminfo => PR #14501
Bindings implementing ChannelTypeProvider:
- [ ] bluetooth.generic
- [ ] digitalstrom
- [x] guntamatic => change required => PR #17901
- [x] harmonyhub => PR #14507
- [ ] homematic
- [ ] km200
- [ ] miio
- [ ] mqtt.generic
- [x] netatmo => no change required
- [ ] networkupstools
- [x] remoteopenhab => PR #14956
- [x] resol => no change required
- [ ] sensibo : change required
- [x] smartmeter : PR #19146
- [ ] solarwatt
- [ ] tacmi
- [x] tr064 => no change required
- [ ] wundergroundupdatereceiver
- [ ] yamahareceiver : change required
Bindings implementing ChannelGroupTypeProvider:
- [ ] evcc : requires dynamic channel groups per `loadpoint` and `vehicle`. not yet implemented
- [x] harmonyhub => PR #14507
- [ ] homematic
- [ ] km200
- [ ] mqtt.generic
- [ ] sensibo : to be removed as the binding does not use channel groups
It is unclear how (from the binding side) I could do anything to prevent this. The dynamic creation of channels is rather fundamental to be able to support the over 350 different miio devices
I have not seen it with my devices yet, but will keep eye on it
