-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[miio] dynamically generate channelTypes #9158
Conversation
jenkins build error unrelated to this PR |
Simplify the json database creation for new models and less chance for errors Related to openhab#7276 Signed-off-by: Marcel Verpaalen <[email protected]>
Signed-off-by: Marcel Verpaalen <[email protected]>
864ddd4
to
c801f69
Compare
Signed-off-by: Marcel Verpaalen <[email protected]>
Signed-off-by: Marcel Verpaalen <[email protected]>
Signed-off-by: Marcel Verpaalen <[email protected]>
....binding.miio/src/main/java/org/openhab/binding/miio/internal/basic/OptionsValueListDTO.java
Outdated
Show resolved
Hide resolved
....binding.miio/src/main/java/org/openhab/binding/miio/internal/basic/OptionsValueListDTO.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Connor Petty <[email protected]> Signed-off-by: Marcel Verpaalen <[email protected]>
Thanks for the improvements suggested in the feedback. Implemented. |
Signed-off-by: Marcel Verpaalen <[email protected]>
return null; | ||
} | ||
|
||
public void addChannelType(MiIoBasicChannel miChannel, String model) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed in my own bindings that my channels would not show up in the UI if the channel types weren't available in the ChannelTypeProvider before the thing handler was started. Is there something special about your setup here or did you find some kind of workaround to prevent that issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not experienced that. I'll do some specific testing on that.
It very well can be the case, but as the basicHandler changes the type from generic to basic after it did the identification it would have satisfied that requirement. But... I would need to check the code if it still does that when the type has already changed, I guess than indeed it may be an issue.
I wonder how other bindings are doing this, as in many cases the channel definition is based on something that is loaded of the device.
How did you solve it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up encoding all of the relevant channel information into the channel type name itself. And then reconstructed the channel type by decoding the information in the name on demand. Wish I didn't have to do that and that there was some way around it so that's why I was asking if you are experiencing the same issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strange. I don't see the behavior. If I change the model info on an existing thing, the new channels appear in the mainUI almost instant. No reloading of the page (I go from the code page to the channel page and the new channels are there)
No specific actions I take to handle the reloading the handler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well if it works for you then that is good enough to me. I'll sort out my own setup some other time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cpmeister could you point out the code you've used so we can have a look (cc @markus7017)
We're having the same issue with a binding where the channels show up in the console but not in the UI on OH3, and it appears to be related to channel ChannelType. All works well in OH2.5
Thx!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I mentioned before, I had to implement the ChannelTypeProvider such that the ChannelType information could be derived from the ChannelTypeUID without having a handler inject ChannelType definitions into the provider ahead of time.
@fastlorenzo What binding are you having trouble with?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the quick reply!
I ended up fixing it by checking in the ChannelTypeRegistry if the ChannelType exists before dynamically creating the channels.
This is the Carnet binding (interface with Audi/VW API), so all channels are taken from the car info, and are different even with the same car model (depending on options for example)
https://github.com/markus7017/openhab-addons/pull/14/files
* [miio] dynamically generate channelTypes Simplify the json database creation for new models and less chance for errors Related to openhab#7276 Signed-off-by: Marcel Verpaalen <[email protected]> Co-authored-by: Connor Petty <[email protected]>
* [miio] dynamically generate channelTypes Simplify the json database creation for new models and less chance for errors Related to openhab#7276 Signed-off-by: Marcel Verpaalen <[email protected]> Co-authored-by: Connor Petty <[email protected]>
Related to [miio] Binding enhancements #7276