[openthermgateway] Remove 'reserved' channels (with invalid channelUIDs) #15355
Conversation
Signed-off-by: Arjen Korevaar <a.korevaar@mephix.com>
|
This pull request has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/opentherm-gateway-binding/39160/336 |
|
@ArjenKorevaar - thanks for the fix! Is it correct that these channels are highly unlikely to be linked to any items because they are only reserved for future use? |
...nthermgateway/src/main/java/org/openhab/binding/openthermgateway/internal/DataItemGroup.java
Outdated
Show resolved
Hide resolved
That is correct. Allthough, the fact that this user reports this issue indicates that his particular device does in fact sends messages using one of these id's. I can't link them to either 2.1 or 3.0 specifications of OpenTherm, so they are probably some OEM or irrelevant messages. But yes, they are highly unlikely to be linked to any items. I'm fine with it either way: I'll leave them in for reference and completeness compared to the OpenTherm specification, or remove them as they probably won't be linked to items in the current implementation. |
I was mostly asking to assess if update instructions are needed. But since they have invalid id's, probably it would be a problem providing instructions for removing those channels. Since they are probably not used, this doesn't seem worth any more considerations. I will leave it to you and @andrewfg to decide if they should be kept. Are they marked as advanced, or will they show in the UI always? And is it possible to actually use them to get access to undocumented data, or are they completely useless? If they are completely useless, I would suggest to remove them. If they can be used by advanced users knowing what they are doing, I would at least mark them as advanced (because they are - and also to be hidden by default). |
|
The question whether or not these message id's are completely useless is a bit difficult to answer, since the OpenTherm specifications (although using the term 'open') are not publicly available. As you stated correctly, these channels are highly unlikely to be used since they are for all the documation that I have been able to aquire reserved for future use. But it's not impossible for particular devices to use them anyways. My suggestion at this point: remove them from the binding. I expect the chances that a user uses any of these channels is close to zero (even the user that reported this issue doesn't use any of these channels). And if someone turns out to actually use them, I'm sure they would be able to reach out and allow us to properly name and support them. |
Signed-off-by: Arjen Korevaar <a.korevaar@mephix.com>
|
FWIW the OpenTherm specification is here; which shows some hints about the possible uses of some reserved fields. |
jlaur
left a comment
There was a problem hiding this comment.
Thanks! I'll cherry-pick this to be included in 4.0.2.
…Ds) (#15355) * Removed invalid characters from channel UIDs * Removed unused message ids Signed-off-by: Arjen Korevaar <a.korevaar@mephix.com>
…Ds) (openhab#15355) * Removed invalid characters from channel UIDs * Removed unused message ids Signed-off-by: Arjen Korevaar <a.korevaar@mephix.com> Signed-off-by: Jørgen Austvik <jaustvik@acm.org>
Fixes #15346
I would still like to keep the entire set of possible message id's from the OpenTherm specification, even though some message id's or some of their bits are not yet in use. This makes it easier to compare the bindings implementation to the OpenTherm specification documentation and implement future versions.