@Chris, still having troubles. I have channel 0 with blinds_control, channel 2 with switch_dimmer or switch_binary. I can turn the blinds (channel 2 “ON”), drive them “UP” with channel 0. Then I drive them “DOWN” with channel 0. In this situation they do not rotate back open automatically but stay closed and the next open command “ON” for channel 2 gets ignored. I have to send “OFF” to the 2nd channel first, which does just produce a very short click of the relay, before it then accepts “ON” again to turn the blinds. Is this behaviour expected ? I wouldn’t know how to handle this with rules, since there is a command delay over the network and if a 2nd command is send too quickly, it overwrites the first one (which even might get ignored then). One would need to tell the Qubino somehow that after down the blinds are closed when the motor has stopped. Any idea how to do this ?
Sorry - I don’t know how to actually use the device as I don’t have any of these, or any blinds devices. Maybe @vossivossi can comment as I think from above he has these working in OH1?
In your example, what are you trying to do exactly?
In general you’r able to ajdust the UP/DOWN blinds opening level with channel 0 or 1 (as chris said, endpoint 0 is equivalent to the root device, with endpoint 1 being a mirror of the root device in a fully multichannel context).
Now, if you wish to adjust the slat tilting level (venetian mode) you need to use channel 2.
By default, after every UP/DOWN movement of the blinds the slats are corrected to the last level they were set (this can be disabeld via parameter). This is why you’ll see slight activation of the relays after every UP/DOWN movement.
As far as needing to exclude the device after enabling venetian mode, and then having to reinclude it i’m afraid this is a Z-Wave protocol requirement. The Node Info frame MUST NOT change while a device is included into any network. The same is true when temperature sensors are connected to Qubino devices.
PS: If there’s anything, someone intimately familiar with the Qubino product line, can do to help out the openHAB folks in regards to integration, please let me know.
@Kjamsek thanks for your help ! My problem is that after the blinds were up and I give the command down, it stops when down and does not move anymore for rotating the blinds (which are closed already). The qubino seems not to understand that the blinds are closed though, but remembered apparently that they used to be open. So the next open command (channel 2 ON) is ignored. One first has to give channel 2 OFF, then wait, then channel 2 ON again, this works.
The problem is that I struggle to automated the movements with rules if the channel 2 command is ignored or depending on what happened before. Is there a way to ask the qubino what it things its status is, so that I can send commands accordingly ?
I see the problem. Thing is, you described you want to open blinds. In regards to opening/closing the blinds itself you need to use channel 0, since that controls the up/down axis.
When you send commands to channel 2 you are setting only the level of the tilting of the slats, not the actual movement up/down. Please make sure that the configuration parameter for a full slat tilt is filled out for your blinds motor (i beleive it’s called the “slats turning time” parameter). This is basically the same as when you calibrate the main shutter only that it’s done manually since there’s no limit switches at slat tilt end spots.
From what you’ve described it looks like the module’s positioning is out of calibration. Please re-calibrate the shutter (change the parameter back to 0 after it’s done) and double check that you’ve entered the correct slat tilting time. This should re-position the blinds at the same spot as the module tracks it as.
Though, do keep in mind that over time, while moving the blinds up/down, the position tracking gets changed from the calibrated state due to small milisecond variances that add up over time.
In regards to rule creation i’m afraid you will need to delay actions for the ammount of time that the blinds motor needs to traverse the blinds length. Unless you buy a motor with feedback (and of course also get a home automation module that supports it) you will need to delay these actions regardless of what brand of module you get.
EDIT:
Unfortunately i’ve only started looking into OpenHAB as an automation platform, so i’m not knowledgeable about how rule creation works exactly.
I’m not sure if OpenHAB allows you to request the value from z-wave devices, since it obfuscates specific protocol control to merge many protocols into one platform, but on a Z-Wave controller you could request the current position via Basic/Multilevel Switch Get commands, that will reply with Basic/Multilevel Switch Reports. In case the module wasn’t calibrated you’d receive the value 0xFE in the Reports, whereas a calibrated module should return a value in the interval of 0x01 to 0x63 (1-99% decimally speaking).
Note that for the tilt channel, i.e. endpoint 2 , it’s a switch_multilevel type. That is, you need to define the openHAB item to be a dimmer so it sends a percentage and not ON or OFF as it’ll do if you define it to be a switch (or UP/DOWN if you treat it as a rollershutter).
Remember you need to calibrate it first. And check out your setting of parameter #73 (see manual)
@mstormi no luck ! I recalibrated the qubino, but the behaviour did not change. If the blinds are open and up and I run them down, it stops and does not open then at the end. It neither does by giving the dimmer 99% or the switch “ON”. I agree with you this looks like a problem in the qubino not handling the end switch correctly and getting stuck there. If one gives “OFF” first and then “ON” to the switch (or “0” first and then “99”) it works, as then the qubino realises it is is down and closed and opens. Very frustrating !!! I will keep playing if I find something to work around this problem, doesn’t look obvious to me what a solution could be.
One question, in rules, is there a way to wait until the power meter changes to > 0 and a way to then wait until it changes to 0 gain. With this I could see from Openhab, what the qubino is doing…
Hi again, I think I found a workaround that does allow me to drive the blinds. I give the close blinds command (dimmer OFF) 30 sec before I open them in the morning, this then ensures that the qubino does react to the dimmer ON to open the blinds. Not ideal, but this morning it worked for all blinds. Thanks everybody for their help, much much appreciated !
Interesting workaround that you found. 
I have to admit that I did not use rules to automate my blinds so far, they are just controlled via UI or switch with the Qubino devices. This works fine so far.
It is important to set parameter 73, I tried it with 0 and 1. At the moment I am using option 0 (Slats return to previously set position only in case of UI control). This gives me (and also especially my wife) the possibility to manually control the blinds position with the hardware wall switch. But when I am controlling the device by UI (Browser, Habdroid etc.) the blinds always return automatically to the previous position after the Up/Down-Phase is finnished. I would have assumed that they should to the same when being controlled by a rule (as the device will hardly know if someone pushed a button on the UI or the command was triggered by a rule).
So basically I conclude the device always will return to the LAST KNOWN blind position after moving Up/Down. This also explains why your workaround works well as you modify the last known blind posiiton first and then fire the Up/Down-Command. So you might try to set the desired blind position FIRST and then make the Up-Down-Movement. However, my conclusion is only based on my own observed behaviour with OH1, not OH2.
I have the same settings as @vossivossi describes. With this I can have for example 2 sliders in habpanel. One for the general blind position and one for the slats tilt. Parameter 73 I have set to 1 as well. But as already noted, it is important to calibrate the slats ( not just the autocalibration of the shutter ). With parameter 72, one can set the amount of time the slats need for a full turn. The default of 150 (1.5 seconds) was way too long for my blinds. I currently set this to 90. However, it is still not 100 percent correct. If I set for example general blind position to 70% and slats to 50% ( about 45 degree ), then set general blind position to 30%, the blinds go down to 30% and when they reach the position, there is a short pause, and finally the module sets the slats again to 50%. But it is not 45 degrees anymore. rather about 60. So I guess I have to fiddle around with this calibration to get the exact timing.
I absolutely agree. The control of the blinds position (unfortunately) is ONLY based on time. But sometimes the communication time (latency) between the Z-Wave-Controller and the device varies. For this reason this is never exact science but rather a “heuristic approximation” and will never bring the result in 100% of all use cases. However, it seems that there are no better alternatives available at the moment and - at least for me - the drawbacks are acceptable.
Perhaps my workaround also helps:
I was a bit greedy and bought cheap Duwi Z-wave rollershutter controllers for some blinds. They were so bad, that until now they don’t have any parameters appearing in Habmin - so no way to configure or calibrate. As the result they had similar problem with control - when blind thinks it at the end it does not want to move again.
What I did - I played with basic command classes and endpoints until I found a command which surely brings the blinds up from any state as long as I need. Same for down command. These became two different hidden switch items in OpenHAB. To control them I used a rule which translates rollershutter commands to these switches and finally it did work fine.
@Artyom_Syomushkin , can you tell me more about those hidden switch items and how you did it ? Maybe I will look into this as well…