Refactor channel converter to support device configuration during discovery #617
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This refactors the converters to allow the initialisation to be performed during discovery while devices are awake. This is necessary as channel discovery at a later time (ie once the thing is created) may fail for sleepy devices if the period between discovery and the thing creation is more than a few seconds (which is highly likely!).
In itself, this works, however as OH provides no way to parse the dynamic channels from the discovery handler to the new thing, when the thing handler is created the binding will again perform the channel discovery. For devices that are sleeping, this will fail - possibly this is ok, although it will likely indicate that the initialisation fails which may increase polling. In any case, the reporting should have been configured during discovery, so this should be working fine.
Ultimately to fully resolve this, the full discovery, including the static thing definition, all needs to be performed during discovery, and then there needs to be a way to parse this information to the thing handler.
This could be done using json encoded properties. Ideally OH would provide the ability to pass channel information to the
DiscoveryResultBuilder
(but it seems unlikely that OH would want to add this!).Alternatively we could look to provide this support in the device storage - needs more thought, but this PR provides an initial intermediate step.
Adds partial support for #527.
Signed-off-by: Chris Jackson chris@cd-jackson.com