No - you can’t upgrade the firmware on most of these devices. Qubino said that they would replace any old devices - they said that there is some sort of bug in these devices, and to be fair, this concept with the multi-channel associations is new and they were (I think) the pioneers. So, this is one path that’s possible (I should check exactly what they said about returns if anyone is interested in this).
Now, that said, I know other gateway software does seem to work with the older firmware, so I think it should be possible to make it work - I just don’t have one of the older devices to test against, otherwise it would probably be easy (ish!) to work out.
If someone wants to donate an older device to me I can try and get this working (I might also be able to convince Qubino to replace the device).
In future, Qubino will be adding firmware updates to all their devices (currently I think there’s only 3 devices supporting firmware updates), and the really good news is they are the first company to provide open firmware updates. I’m hopeful this might prompt others like Fibaro and Aeon to follow…
if ITEM is { channel=“zwave:device:16066d9c763:node2:switch_binary” } = operate switch1 och switch2 at the same time
i get [vent.ItemStateChangedEvent] - ZWaveNode2ZMNHBDFlush2Relays_Switch changed from ON to OFF in log
YAY
but if Item is
node2:switch_binary1" }
node2:switch_binary2" }
it does not report back!
have latest OH 2.2 stable and z.wave binding
have 2 ZMNHBD Flush 2 relays firmware 1.1
have set association groups Q1 Switch Binary,Q2 Switch Binary to OpenHAB Controller, nothing else will stick in assiciation setting
@chris I’m trying to test the development branch of the zwave binding with my qubino flush dimmer. I have a ZMNHDD device with 3.5 firmware version. I switched to OH2.2 stable and installed the zwave binding from here: http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.2.0-SNAPSHOT.jar
Then I deleted all zwave things and their xml files from /var/lib/openhab2/zwave/.
But my qubino dimmer is still not sending status updates. As I understand with this development branch the status updates should work as expected.
Chris,
flush 2 relays with firmware 1.1 still does not work. However, my supplier agreed to replace them with new devices with firmware 5.0, for free. So at least for me, this is a non issue.
Does it help if you set the lifeline association group? If it’s already set, then unset it and set it again. The other thing is to check the debug logs to make sure nothing is really being received…
I’m always testing from a newly included node, so another thing that might be interesting to try is a reset of a node (if that’s possible).
Is this using the latest dev binding from a few hours ago?
setting the lifeline association group does not help. And after reloading the setting page in habmin the setting field goes blank. Don’t know how to unset this setting, I set different node and then back to controller node. I have debug logs from the reinitialisation, can I sent them to You ? meanwhile I’ll try to exclude and include the node again.
I have some troubles to exclude than reinclude the device. In habmin i got the notification that the node was excluded, but still was shown in the things. After deletion from the things and enabling the auto-discovery the excluded node was discovered. I added this node as thing but it didn’t work at all. I had to reboot my pi and after that the node was marked red. Then I could remove the node thing and it was no longer discovered. But now I have problems to include it
ok, it seems that now i get status updates for dimmer values it is much better but not for switch on/off states. maybe it is the configuration problem, don’t have time now because we expecting guests and my wife is freaking out because i’m not helping her tomorrow i will continue
Ok, thanks - I also have to do some shopping to avoid similar issues
I noted in your log that the binding is using a single association - this is because there are no endpoints being used in you device. So, reports should have worked, but only if you use the “Dimmer” channel, and not the “Dimmer 1” channel… Which one are you using?
I also have a dimmer here so will try and test that - probably tomorrow…
Thinking about this some more while out, and part of the problem we have is the Qubino devices change their endpoints. So, depending on how they are configured will depend on the number of endpoints, and what features are supported.
@rozpruwacz if I look at the log you sent for discovery of your dimmer I see the following -:
This shows that no endpoints are supports - to be precise it shows that the multi-channel-encapsulation command class is not supported. I suspect if you add the temperature sensor, this will change.
Because of this, the binding assumes there are no endpoints, and uses the root endpoint for all configuration. As I mentioned above, I would expect the device to send reports in this state if you use the Dimmer and not Dimmer 1 channel.
Unfortunately, another day, and another user, and it will be different - because the database is a static definition, we’re chasing around a little.
For the dual switch, I don’t think this is a problem - it always supports (at least) 2 endpoints for the 2 switches.
I will have a play with this when I get a chance today or tomorrow. There is one option which is to add an option to the database to force the mutli-channel use. This is normally used to add command classes that a device supports, but doesn’t report in the NIF - effectively that’s the issue here - I think if the device were to report the multi-channel class all the time, then it would be more deterministic…
This shows that the device IS reporting the multi-instance (multi-channel - same thing) command class, and in my case, it works ok - Dimmer 1 is reporting. The switch isn’t reporting, but this actually should be removed anyway so I’ll remove this from the database.
I think what I will do next is to make a change to the database so that the binding always thinks multi-channel is supported with this device. This should give some consistency!
@rozpruwacz can you confirm is the Dimmer or Dimmer 1 is working for you? I guess the Dimmer?