Closed HALLO01 closed 4 years ago
I have implemented the hint from @ppieczul and want to ask him or someone else with experience to review.
I am an absolute newbie, so I do not know if it is okay what I did, but it fixes the bug :-) I have edited the file openhab-2-5-x\git\openhab-addons\bundles\org.openhab.binding.loxone\src\main\java\org\openhab\binding\loxone\internal\controls\LxControlJalousie.java
I have added to private void handleOperateCommands(Command command) following lines:
if (command instanceof PercentType) {
if (((PercentType) command).doubleValue() == 0) { //fix
sendAction(CMD_FULL_UP); //fix
} else if (((PercentType) command).doubleValue() == 100) { //fix
sendAction(CMD_FULL_DOWN); //fix
} else {
moveToPosition(((PercentType) command).doubleValue() / 100);
}
} else if .....
A compiled jar file is available here: https://community.openhab.org/t/loxone-anyone/15712/84?u=hallo01
@HALLO01 Thanks a lot for your fix! You can compare PercentType value. This will avoid the problem of comparing floating point numbers (see for example here: https://howtodoinjava.com/java/basics/correctly-compare-float-double/) For example, you should be able to do: ((PercentType) command).compareTo(PercentType.ZERO)
Thanks for your feedback, I have updated the source code accordingly:
if (((PercentType) command).compareTo(PercentType.ZERO) == 0) {
sendAction(CMD_FULL_UP);
} else if (((PercentType) command).compareTo(PercentType.HUNDRED) == 0) {
sendAction(CMD_FULL_DOWN);
} else {
Is this ok now? If yes, can you give me a hint how to get this fix into official release?
Looks ok, if you check it works fine, first please correct a unit test to include the new behavior. I assume you have a git clone of the repo on the right branch (it looks like it is still 2.5.x branch for main development). Your changes should be on a new branch that you create.
In file https://github.com/openhab/openhab-addons/blob/2.5.x/bundles/org.openhab.binding.loxone/src/test/java/org/openhab/binding/loxone/internal/controls/LxControlJalousieTest.java In method testMovingToPosition(), there are two last cases when sending ZERO and HUNDRED positions. I think they now should not produce any commands after FullUp/Down. Just check for null instead of Stop after simulating edge position.
When you have the test fixed, try to build it from the command line (last year it was to execute "mvn install" in the binding directory. This command will also run unit tests. If everything passes, push the repo clone to your account. Then you can submit a PR from github pointing to your repo and the new branch.
If you need more details on what commands do what, I can help in a few hours.
Good luck! Pawel
pon., 27 lip 2020 o 16:14 HALLO01 notifications@github.com napisał(a):
Thanks for your feedback, I have updated the source code accordingly:
if (((PercentType) command).compareTo(PercentType.ZERO) == 0) { sendAction(CMD_FULL_UP); } else if (((PercentType) command).compareTo(PercentType.HUNDRED) == 0) { sendAction(CMD_FULL_DOWN); } else {
Is this ok now? If yes, can you give me a hint how to get this fix into official release?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhab/openhab-addons/issues/8157#issuecomment-664422181, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOHS7SEN3EZLQQMBSSGW23R5WDVBANCNFSM4PB5LGFQ .
Hi, thanks for your howto, hopefully I did everything right :-) Please check the PR
I close this issue, follow up see PR
I tell alexa to close the rollershutter, Alexa closes the rollershutter. Then I press the hardware open button or open via loxone app the rollershutter. BUG: rollershutter stops at about 95%, although it must open fully. Loxone binding sends a stop signal. All setup and log info can be found here:
The owner of the binding @ppieczul is currently not able to fix this, his recommendation is: The problem is that Alexa opens or closes shutters by sending numerical position of 0 or 1. Loxone never achieves full 0 or 1 position when operating shutters. The fix can be to check if the numerical position is 0 or 1 and send full up or down command instead of engaging position based move.
My question is, is someone able and willing to fix this?
Thank you, Thomas