Hi Mark,
i have tested org.openhab.binding.nikohomecontrol-2.3.0-SNAPSHOT.jar binding.
The result:
Unfortunately Paper UI buttons are working in reverse order:
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.
Hi Mark,
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.
Thanks.
@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.
This may be a stupid question.
But how do I define the Invert flag for niko home blinds ?
is this in the items file or somewhere else ?
Thanks a lot
The invert flag is not in the final version of the binding. Unless a bug was introduced, the mapping should respect OPENHAB and Niko up/down.
Found the issue.
it’s not the binding or openhab. it’s the homekit service in i/o
when you ask siri to close it opens and visa versa
Hi,
I have a Niko Home Control II set.
I would like to change some buttons color in Habpanel depending on rollershutters status but I can’t get the status value.
In the paperui control page, I can see command percentage but if I do something and then press stop I thaught it would update the percentage but it does not.
Did I miss something ?
Thanks for this amazing job
@Nepomuk3000 It should return the state, although it may not be immediate. The binding receives the state update from Nilo Home Control, and with rollershutters, that may be some time after the command was given.
Is the problem the state update in PaperUI? Don’t rely too much on it. PaperUI is just an admin UI, and is not always accurate on this. Check the events.log if you see the events in there.
You could swith on debug logging (or even trace logging) for the binding. I believe I have some specific trace info in the binding for rollershutters to see exactly what is happening.
What version of openHAB and the binding are you using?
Hi Mark,
The integration is working flowlessly
in openhab the percentages , up and damn completely match with NHC2 using Hobby API.
0 = Closed
100 = open
etc.
But when installing homekit on the openhab2.5.x somehow homekit revert the readings from the state and actions.
Do you perhaps know how to revert states towards homekit ?
All revert homekit topics are none NHC2 topics where you manually define things in a .things file.
Here I define the homekit things in paperui and than link the homekit manually defined items to it.
Thanks for your help
I am a bit at a loss here. Niko Home Control has the inverse convention for percentages when it comes to open close than openHAB. Therefore the binding inverts the percentages. That seems to work fine.
I believe Homekit also has the inverse convention form openHAB. I had a quick look at the Homekit code and it does seem to inverse. Therefore the combination should give the right picture. I have no idea where it goes wrong.
In absence of an idea, the only way I can imagine resolving this is with a rule and a virtual item. The virtual item should get the opposite state from the real item through the rule, and be connected to Homekit.
Mark,
For me I formost use openhab to translate everything to homekit.
what is the invers flag i need to add in things or items in order it to invers it ?
Dont really care if it’s invers in openhab as long as it’s correct in homekit
or could you help me refer to what you mean with the virtual items
(noob in openhab talking )
thanks