I have added PercentType capabilities to Niko Home Control rollershutters. This will enable Niko Home Control rollershutters to be correctly used with Homekit and other transports only supporting PercentType for rollershutters.
As I do not have rollershutters myself, I have to rely on you to do proper testing of the functionality.
During development, it came to my attention that Niko Home Control percentages did not always match correctly to openHAB UP/DOWN percentages. The standard in openHAB is 0% for UP and 100% for DOWN. It appeared that it sometimes (but not always) was the other way around in NHC.
I therefore introduced an invert flag to be able to invert the mapping. This is not best practice (see PR#3337), and I would rather take it out if everyone sees the same behaviour.
Therefore, could you test the latest version of the binding from here with a recent snapshot version of openHAB (it will not work with 2.2) and let me know how it behaves?
Please test with the invert parameter false and true:
Command UP, does it go up?
Command DOWN, does it go down?
Command 0%, does it go completely UP (or open)?
Command 100%, does it go compeletely DOWN (or closed)?
Command 30%, does it go to 30% DOWN?
If all tests come back with the same result, I will adapt the binding to only have that one behaviour and remove the invert flag.
I will try to test again but I fail to understand how the wiring is actually influencing this. I believe that Niko and openhab are using inverted values but to confirm this we would need a few people testing
@extric99 I also think it should not be influenced by wiring. I am just getting contradicting info from different people, so need multiple people to test to settle it. Also pay special attention to the UP/DOWN commands, because the invert flag inverts them as well, and I am not sure it should.
Here is the original info from @Benoit_Krings I based it on: Niko Home Control
I then adjusted based on the contradicting feedback from @fcela: Niko Home Control
I settled on 254 for up, 255 for down and 253 for stop, which seems to work fine.
On your request, I added the invert flag, but I am not sure it is needed. If only one mapping exists, I should remove it and cope with it in the code.
i have tested org.openhab.binding.nikohomecontrol-2.3.0-SNAPSHOT.jar binding.
The result:
percentage value is working as follows:
a) 0 - push rollershuter to the bottom
b) 100 - push rollershuter to the top
c) any other value is working as expected, 50 is in the middle and so on…
Unfortunately Paper UI buttons are working in reverse order:
touch UI button UP moves rollershuter down
touch UI button DOWN moves rollershuter up
I think we had this issue already before.
Thank you.
@fcela Thanks for testing.
Did you set the invert flag on the rollershutter thing?
If the flag was not there, you may have to remove and recreate the rollershutter thing.
Note that correct percentage values in openHAB are 0 for open (up) and 100 for closed (down). So all seems to be inverted in your case.
Also try with something different from 50 as that is just in the middle and will not tell you if it is correct.
Hi
i have removed and recreated the things, the switch is there now.
I have tried with 25 as percentage value and it worked (but reversed),
I will report the final result later, I am busy now.
BR
@fcela Thank you once more for testing.
Sorry to push you on this, but I want a final confirmation as soon as possible. If I can finalize the PR this week, we have a chance to get it included in the 2.3 release.
So, did it all work as expected with the ‘invert’ flag = true? (UP and DOWN correct and percentage correct for 0% = OPEN, 100% = CLOSED and 25% = 25% DOWN, 75% OPEN)?
Hi Mark,
sorry to be late, i was really busy yesterday. I am not at my home now but I put reminder so I will test it in the evening. i will let you know.
Thank you for your patience.
when switched switch to the invert position, everything worked as expected.
Some values were somehow rounded, or skipped better to say.
When I set 55%, blind moves but value changed to 56% and so on.
Do you think we could implement step mode as well? I mean microsteps for blind exact position.
This works when you push the original niko blind switch and keep it pushed. It will do micro steps to set blind to the exact position until you keep it pressed.
@fcela Thank you for testing.
I will remove the invert flag then and make that the standard behaviour.
I will not be able to do micro steps. The issue is the Niko app does not allow any of it either (just up and down as far as I understood, not even percentage values). I achieve the percentage value by calculating the time required up to that position and scheduling a stop at that time. That is also why the position sometimes is a little bit off and the final status update may be slightly different. These are the inherent rounding errors.
Thank you for your reply and for your solution as well.
The microsteps could work quite easy, just send up/down command and stop after some period defined as parameter and repeat the whole procedure until button pressed.
Thank you for your effort once more.
Regards.
@fcela@extric99 I have rebuild the binding without the invert flag (but standard ‘inverted’ behaviour). Just to make sure, if you find time to do a final test (UP, DOWN, percentage 0, percentage 100, percentage 30). If anything ends the wrong way around, let me know. It then means I missed something when removing the invert flag.
@fcela What is different between your idea of microsteps and pushing up/down followed by stop when it is in the right position? Should there be a pause between each microstep? Or should we just have an extra channel that does up/down for (let’s say) 1% (configurable) with each push? I would not need the stop then, as you would push it as many times as you need. The problem is that I cannot do a push button with openHAB easily.
I am open to look more into this and add a solution. But I suggest to do it in a separate follow-up PR.
Hi Mark,
the blinds are working correctly without invert flag now. Thank you.
My idea for microsteps is as follows:
Pushing up/down and then stop is not accurate. It is really quite short time (1 sec aprox.) for blinds to tilt from close position to open (horizontal) position.
If I want to tilt blinds to the exact position (to have light but not direct sunlight) i can not do it using percentage values either. I will try to explain:
I have door and windows at the same room with blinds. Moving all down (100%) and then lets say 98% will make blind open at different tilt for door and for windows (door is bigger/taller than window, 1% for door is not the same as 1% for window - tilt context meaning). If 1% step for windows is quite usable, 1% step for door is just too much (the blind is passing too much direct sunlight). It would be great to have microstep (with configurable time period), so i can do exactly 2 microsteps for door and for windows and tilt will be the same for both/all of them. With configurable time period it would be quite precise.
I have sunlight (Lux) detector so i could tilt blinds as expected during the summer time. I can do it manually using original Niko push buttons now.
Anyway we can postpend this functionality till the next release. I will be ready for testing anytime.
Have a nice evening.
@fcela
Thanks once more for testing. The changes have been merged already in the 2.3.0 snapshot.
OK, I understand the microsteps. I am not sure if the timing of the micro steps will be accurate enough. Niko never designed their app communication to be able to do this. openHAB is not a realtime system. And there is a quite a bit of communication and logic in the controller, openHAB and between them to make this work.
A way to test would be to try a simple openHAB rule. Something like:
// constant for tilt time in milliseconds
val tiltTime 950
rule "tilt blind"
when
Item tiltMyBlind received command
then
// tilt up or down
if (receivedCommand == UP) {
myBlind.sendCommand(UP)
} else {
myBlind.sendCommand(DOWN)
}
// schedule the stop of tilting
createTimer(now.plusMillis(tiltTime), [|
myBlind.sendCommand(STOP)
])
end
Create a virtual rollershutter item tiltMyBlind. Use UP/DOWN with these. State is not important. When you press UP or DOWN on these, it will tilt the real blind. You could put all the virtual tilt variables in a group to do the tilting for all in the group.
What is missing here is to make sure the blind is not already moving when triggering this command. To do that, you would also need to trigger the open/close from a rule and insert a delay before tilting.
to the invert position, everything worked as expected.