hi @chris, let me reopen the discussion here. With release 2.1 the blinding does no longer expose the 2nd endpoint (binary_switch2) for the Qubino Flsuh shutters in venetian mode. Both Habmin and the PaperUI does only show the first endpoint (blinds movements).
After upgrading to 2.1 I deleted and re-included the items in habmin (misreading I had to do this for the security stuff). It could be this is because the binding hasn’t updated the node yet and still needs to discover it is actually in venetian mode, so I left it running over night. Still no change today. How can we force the binding to expose the 2nd endpoint. In the past this was done by default, even if the Qubino was not in venetian mode, giving one the option to address it in any case.
I was told by Qubino that my firmware is old, yes (there is a firmware bug in them for the state machine in venetian mode, needs separate fixing). It worked with release 2.0 and didn’t break when updating to a unstable 2.1 build (without deleting the items in habmin). Now after deleting it the problem appeared.
We would need to manually add the endpoints and command classes that your device uses. Unfortunately this can’t be done automatically since the database won’t add endpoints/classes if the device is already in use.
The XML file for your device should show the endpoints and command classes it uses, and then add the channels (the same as the newer device I guess).
You are right to be confused - I’m also confused! The “all” version was just added in the past couple of days. I’ve emailed the person who added it to ask them why this was done - maybe it’s just the version numbers are wrong or something - I don’t know. If I don’t get an answer in the next few days I will mark this as removed…
Anyway, this shouldn’t impact you for now since I think you have the <4.0 version?
Can you PM me your user name and I’ll activate your account tonight.
Hi @chris, my version is 1.1, see screenshot attached. What I am confused about is that it shows up as MOTOR_CONTROL_CLASS_C, while the version < 4 description is version MOTOR_CONTROL_CLASS_B ???
At the same time the “all” version as well doesn’t have the 2 endpoints. It seems there is more than one problem in the database. What shall we do with this ? If we need 2, then they both should have 2 version, “all” seems to be a copy.
Attached the XML. In the XML is says version 4, it has the 2 endpoints at it should and it is MOTOR_CONTROL_CLASS_C. I think the entry for version up to 4 is wrong, version 4 is definitely a MOTOR_CONTROL_CLASS_C and not MOTOR_CONTROL_CLASS_B.
Hi @chis, there are more issues, like the parameter 73 is incomplete w.r.t. the documentation. I don’t know who changed the DB entries, but there is a lot wrong now. Can we revert this, it was ok before ? Is there a history somewhere for recovering it ?
I have downloaded the org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar and replaced the qubino_zmnhcd_0_0.xml with what I got from the database. I loaded it on my RP and made sure the bundle works in karaf (dependency), making sure that 220.127.116.11706292327 is active. Then I was reloading the nodes (delete them, rediscover).
The net result is disappointing, I do see the new endpoints, the value option is fixed. If I try to turn the blinds, I get
2017-06-30 02:39:34.235 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 73: No command converter set for command zwave:device:29a8e9c7:node73:switch_binary2 type OnOffType
slimilarly, if I try to run them up/down, I get:
2017-06-30 02:40:20.661 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 73: No command converter set for command zwave:device:29a8e9c7:node73:blinds_control type UpDownType
This is beyond my knowledge and I don’t know how to debug this further. I need help on this, @chris.
PS: I do believe the v4.1 version of it has as well more problems, but since I can’t get this one to work, I am not sure.