[mqtt.generic] Send ON/OFF for dimmer channels when so configured #15929
Conversation
ccutrer
force-pushed
the
mqtt-generic-dimmer-on-off
branch
from
0ece641 to
d740042
Compare
|
As a general question: Wouldn't it make sense to use the converters introduced in openhab/openhab-core#3355? |
|
I was not aware of their existence. Yes, it probably would make sense to use those, but I would prefer to get this PR in as is, and then do a separate (much larger!) PR converting to those. It will need to consider how all the "downstream" MQTT bindings rely on their conversions, and possibly add more capabilities to core. In particular, some of the recent Home Assistant components I've added rely on non-round-trippable conversions. I.e. Cover/Rollershutter you send |
|
Note that this conflicts with #15925. I'd rather that one merge first. Once that's done, I'll rebase this one. |
...ding.mqtt.generic/src/main/java/org/openhab/binding/mqtt/generic/values/PercentageValue.java
Outdated
Show resolved
Hide resolved
ccutrer
force-pushed
the
mqtt-generic-dimmer-on-off
branch
from
d740042 to
1fc3ff7
Compare
|
I just tested this, and it's ready for review |
|
Please rebase. |
|
ping @ccutrer |
Similar to how UP/DOWN are processed for rollershutters. Signed-off-by: Cody Cutrer <cody@cutrer.us>
ccutrer
force-pushed
the
mqtt-generic-dimmer-on-off
branch
from
c426d36 to
e679080
Compare
|
rebased, conflicts resolved, which then required some changes to tests, and squashed it all together |
There was a problem hiding this comment.
LGTM.
One remaining question. The current documentation in readme.md does not show the posiblity of assigning a number to the on or off parameters. But the parameters itself do. As that functionality has been removed by this PR and now strictly needs a specific string as on or off, i wonder if this 1. is considered a breaking change and/or 2. needs a notice in the openhab update procedure, @ccutrer wdyt?
|
Looking through this again, there's nothing that prevents you from still entering a number for the special ON/OFF values. They'll just be treated as a string --- exactly as before. The only difference is that on/off no longer have a default (of 1/0). Which isn't actually a difference, because ON/OFF (on sending a command) will first be translated to PercentType.HUNDRED/PercentType.ZERO, and then scaled to the min/max, ending up at 100/0 or 1/0 as appropriate. On return back from MQTT with a current state, this commit will actually fix a bug if your min/max is 0-100, but you leave the on string as the default of "1", "1" would inadvertently get treated as 100%, not 1%. |
…enhab#15929) Similar to how UP/DOWN are processed for rollershutters. Signed-off-by: Cody Cutrer <cody@cutrer.us>
…enhab#15929) Similar to how UP/DOWN are processed for rollershutters. Signed-off-by: Cody Cutrer <cody@cutrer.us> Signed-off-by: Patrik Gfeller <patrik.gfeller@proton.me>
…enhab#15929) Similar to how UP/DOWN are processed for rollershutters. Signed-off-by: Cody Cutrer <cody@cutrer.us>
…enhab#15929) Similar to how UP/DOWN are processed for rollershutters. Signed-off-by: Cody Cutrer <cody@cutrer.us>
Similar to how UP/DOWN are processed for rollershutters.
Fixes #7991