[homematic] Validate datapoint values before writing to config #12557
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
HM config datapoint values on some devices can be out of their valid
range in some cases, particularly if they are unused by the device
currently [1]. Since openhab-core now validates attempts to update
configuration by the thing handlers, make sure we always send a valid
configuration even for those affected datapoints.
[1] One example for such behaviour is HmIPW-DRBL4, which has multiple
datapoints which depend on each other
- POWERUP_JUMPTARGET can have values OFF, ON, OFF_DELAY, ON_DELAY
- POWERUP_ONDELAY_VALUE, POWERUP_ONDELAY_UNIT are only used if
POWERUP_JUMPTARGET has value ON_DELAY
- likewise, POWERUP_OFFDELAY_VALUE and POWERUP_OFFDELAY_UNIT are
only used if POWERUP_JUMPTARGET has value OFF_DELAY
- if e.g. the POWERUP_JUMPTARGET is OFF, e.g. POWERUP_ONDELAY_VALUE
might stay uninitialized by CCU and/or device itself, in which
case it may be reported with an invalid value
Signed-off-by: Danny Baumann <[email protected]>
maniac103
force-pushed
the
hm-config-validation
branch
from
ac8ae99 to
fa4d32b
Compare
lolodomo
requested changes
Apr 2, 2022
...atic/src/main/java/org/openhab/binding/homematic/internal/handler/HomematicThingHandler.java
Outdated
Show resolved
Hide resolved
| @@ -140,8 +140,7 @@ private void doInitializeInBackground() throws GatewayNotAvailableException, Hom | |||
| loadHomematicChannelValues(channel); | |||
| for (HmDatapoint dp : channel.getDatapoints()) { | |||
| if (dp.getParamsetType() == HmParamsetType.MASTER) { | |||
| config.put(MetadataUtils.getParameterName(dp), | |||
| dp.isEnumType() ? dp.getOptionValue() : dp.getValue()); | |||
| config.put(MetadataUtils.getParameterName(dp), getValueForConfiguration(dp)); | |||
There was a problem hiding this comment.
As getValueForConfiguration can retrun null, I am not sure whether this config entry should be set to null, or not set at all ?
I am even not sure if this is valid to set a null value for a config parameter.
There was a problem hiding this comment.
The only case under which getValueForConfiguration() returns null is if the datapoint holds a null value. In that case I'd say that writing null into the config is correct.
The places I checked that care about the keys present in the map (those that call containsKey() and keySet() seem to be able to deal with null values being present. Not sure about e.g. the UI, but given the previous code put null values in this case (value being null) as well, I guess it should be fine.
...inding.homematic/src/main/java/org/openhab/binding/homematic/internal/model/HmDatapoint.java
Outdated
Show resolved
Hide resolved
...atic/src/main/java/org/openhab/binding/homematic/internal/handler/HomematicThingHandler.java
Outdated
Show resolved
Hide resolved
...inding.homematic/src/main/java/org/openhab/binding/homematic/internal/model/HmDatapoint.java
Outdated
Show resolved
Hide resolved
...inding.homematic/src/main/java/org/openhab/binding/homematic/internal/model/HmDatapoint.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Danny Baumann <[email protected]>
NickWaterton
pushed a commit
to NickWaterton/openhab-addons
that referenced
this pull request
Apr 27, 2022
…ab#12557) * [homematic] Validate datapoint values before writing to config HM config datapoint values on some devices can be out of their valid range in some cases, particularly if they are unused by the device currently [1]. Since openhab-core now validates attempts to update configuration by the thing handlers, make sure we always send a valid configuration even for those affected datapoints. [1] One example for such behaviour is HmIPW-DRBL4, which has multiple datapoints which depend on each other - POWERUP_JUMPTARGET can have values OFF, ON, OFF_DELAY, ON_DELAY - POWERUP_ONDELAY_VALUE, POWERUP_ONDELAY_UNIT are only used if POWERUP_JUMPTARGET has value ON_DELAY - likewise, POWERUP_OFFDELAY_VALUE and POWERUP_OFFDELAY_UNIT are only used if POWERUP_JUMPTARGET has value OFF_DELAY - if e.g. the POWERUP_JUMPTARGET is OFF, e.g. POWERUP_ONDELAY_VALUE might stay uninitialized by CCU and/or device itself, in which case it may be reported with an invalid value Signed-off-by: Danny Baumann <[email protected]> Signed-off-by: Nick Waterton <[email protected]>
|
This pull request has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/openhab-3-3-milestone-discussion/132715/130 |
andan67
pushed a commit
to andan67/openhab-addons
that referenced
this pull request
Nov 6, 2022
…ab#12557) * [homematic] Validate datapoint values before writing to config HM config datapoint values on some devices can be out of their valid range in some cases, particularly if they are unused by the device currently [1]. Since openhab-core now validates attempts to update configuration by the thing handlers, make sure we always send a valid configuration even for those affected datapoints. [1] One example for such behaviour is HmIPW-DRBL4, which has multiple datapoints which depend on each other - POWERUP_JUMPTARGET can have values OFF, ON, OFF_DELAY, ON_DELAY - POWERUP_ONDELAY_VALUE, POWERUP_ONDELAY_UNIT are only used if POWERUP_JUMPTARGET has value ON_DELAY - likewise, POWERUP_OFFDELAY_VALUE and POWERUP_OFFDELAY_UNIT are only used if POWERUP_JUMPTARGET has value OFF_DELAY - if e.g. the POWERUP_JUMPTARGET is OFF, e.g. POWERUP_ONDELAY_VALUE might stay uninitialized by CCU and/or device itself, in which case it may be reported with an invalid value Signed-off-by: Danny Baumann <[email protected]>
andrasU
pushed a commit
to andrasU/openhab-addons
that referenced
this pull request
Nov 12, 2022
…ab#12557) * [homematic] Validate datapoint values before writing to config HM config datapoint values on some devices can be out of their valid range in some cases, particularly if they are unused by the device currently [1]. Since openhab-core now validates attempts to update configuration by the thing handlers, make sure we always send a valid configuration even for those affected datapoints. [1] One example for such behaviour is HmIPW-DRBL4, which has multiple datapoints which depend on each other - POWERUP_JUMPTARGET can have values OFF, ON, OFF_DELAY, ON_DELAY - POWERUP_ONDELAY_VALUE, POWERUP_ONDELAY_UNIT are only used if POWERUP_JUMPTARGET has value ON_DELAY - likewise, POWERUP_OFFDELAY_VALUE and POWERUP_OFFDELAY_UNIT are only used if POWERUP_JUMPTARGET has value OFF_DELAY - if e.g. the POWERUP_JUMPTARGET is OFF, e.g. POWERUP_ONDELAY_VALUE might stay uninitialized by CCU and/or device itself, in which case it may be reported with an invalid value Signed-off-by: Danny Baumann <[email protected]> Signed-off-by: Andras Uhrin <[email protected]>
psmedley
pushed a commit
to psmedley/openhab-addons
that referenced
this pull request
Feb 23, 2023
…ab#12557) * [homematic] Validate datapoint values before writing to config HM config datapoint values on some devices can be out of their valid range in some cases, particularly if they are unused by the device currently [1]. Since openhab-core now validates attempts to update configuration by the thing handlers, make sure we always send a valid configuration even for those affected datapoints. [1] One example for such behaviour is HmIPW-DRBL4, which has multiple datapoints which depend on each other - POWERUP_JUMPTARGET can have values OFF, ON, OFF_DELAY, ON_DELAY - POWERUP_ONDELAY_VALUE, POWERUP_ONDELAY_UNIT are only used if POWERUP_JUMPTARGET has value ON_DELAY - likewise, POWERUP_OFFDELAY_VALUE and POWERUP_OFFDELAY_UNIT are only used if POWERUP_JUMPTARGET has value OFF_DELAY - if e.g. the POWERUP_JUMPTARGET is OFF, e.g. POWERUP_ONDELAY_VALUE might stay uninitialized by CCU and/or device itself, in which case it may be reported with an invalid value Signed-off-by: Danny Baumann <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
HM config datapoint values on some devices can be out of their valid
range in some cases, particularly if they are unused by the device
currently. Since openhab-core now validates attempts to update
configuration by the thing handlers, make sure we always send a valid
configuration even for those affected datapoints.
One example for such behaviour is HmIPW-DRBL4, which has multiple datapoints which depend on each other:
Fixes the issue reported here