Status updates for Qubino Relays/Dimmers generally do not work

Hi Chris,

I just did it with one of my not working ZMNHDD Dimmers (node 160).

https://filebin.ca/3mrPP2FWp4My

The log should show the moment from clicking ‘Reninitialise the device’ in Habmin until the end of (re)initialisation (00:06:30 to 00:06:40).

Cheers,
Martin

Thanks Martin - that’s useful. It’s showing the database change I made hasn’t had the desired effect. I’ll take a look at this tomorrow.

The dimmer you sent me already says it supports multi-channels - do you know if there’s a way to completely reset the Qubino dimmers? I’ve not found it in the docs.

I just found this section in the docs:
grafik

So pressing the button 1 5 times within 3 seconds (in the first 60 seconds after repowering the device) should do the trick.

1 Like

ok, I’ll try that. Now I understand what You mean :slight_smile: I mixed up concepts of channel and command class.
BTW. I think i broke my dimmer … now, when i turn off the light from 100%, it sends couple of reports like 80%, 50%, 20% and lastly 0%. And sometimes it does not send the 0% report and openhab thinks that the light is turned on … :frowning:

Sounds also like a parameter soft dimming.

There are parameters for that and aswell for max and min dimming values. I think you played too much there :wink:

I have set the attribute “60 – Minimum dimming value” to 10 and “61 – Maximum dimming value” to 50. Other parameters are default (I think). what parameter number are You refering as “soft dimming” ? Mayby i’ll just reset the dimmer :slight_smile:

Hi Chris,
These qubinos are driving me crazy…
After re-initilizing one of the dimmers (the first one I tried) it “dropped out”. I.e. no xml created - not working anymore.
This evening I spent two hours, trying to include it to the controller. Started at node no 55. for this dimmer, at the count of 60 (that is four failed inclusions - it did fail during any of the steps) i finally managed to get it up and running.
(The only way to get it included was to do it directly to the Aeon stick. Then checking if it was successful with Zensys tools - and after that adding it to openhab via Habmin.)

Now using the Jan 2. Binding - it actually works as expected - reporting back dimmer status on “dimmer 1” and power status as well.
So - as of now - it seems to work. Now I have four more to try to get up and running…

So I tried the latest update. I had to re-include the device for changes to happen (removal of the switch channel). It seems to work as expected, but one thing - the ON command does send SWITCH_BINARY_SET ON command but this command turns the light always to 100% - not the last value :frowning:

I’ll add the configuration for “restore last value” into this channel.

Upon further checking - the restore last value is only available for the multilevel switch - ON will always send 100%. This should be the same as before and I don’t think this can be changed.

I’m also experiencing such a lag with my qubino dimmer, but i thing this is how these devices work … If i switch on and then off locally within 1-2 seconds I do not get any updates in the OH and in the debug log I get reports only for last action. If it was the delay in OH then I would get all the updates eventually.

@chris unfortunately i still have problems with other two qubino dimmers i have. I re-included them and they do not report the dimmer status but report the power meter value. Additionally one dimmer does not react to commands.

first dimmer:
firmware v3.5, enabled endpoint i2 - this is the first i tested with new binding and it is working ok.

second dimmer:
firmware v1.1, with temperature sensor, can be controller from OH but does not report status when switched locally. In debug log i see that report message arrives but is not send to the channel like meter_watts is:

2018-01-04 20:13:52.361 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 41: Application Command Request (ALIVE:DONE)
2018-01-04 20:13:52.364 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 41: resetResendCount initComplete=true isDead=false
2018-01-04 20:13:52.367 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 41: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2018-01-04 20:13:52.371 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 41: SECURITY not supported
2018-01-04 20:13:52.374 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 41: Received COMMAND_CLASS_SWITCH_MULTILEVEL V3 SWITCH_MULTILEVEL_REPORT
2018-01-04 20:13:52.377 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 41: Switch Multi Level report, value = 99
2018-01-04 20:13:52.383 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-01-04 20:13:52.387 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 99
2018-01-04 20:13:52.391 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 41: Commands processed 1.
2018-01-04 20:13:52.394 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 41: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@189c735.
2018-01-04 20:13:53.385 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 41: Application Command Request (ALIVE:DONE)
2018-01-04 20:13:53.388 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 41: resetResendCount initComplete=true isDead=false
2018-01-04 20:13:53.391 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 41: Incoming command class COMMAND_CLASS_METER, endpoint 0
2018-01-04 20:13:53.395 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 41: SECURITY not supported
2018-01-04 20:13:53.398 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 41: Received COMMAND_CLASS_METER V3 METER_REPORT
2018-01-04 20:13:53.402 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 41: Meter: Type=Electric(1), Scale=W(2), Value=20.2
2018-01-04 20:13:53.409 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Got an event from Z-Wave network: ZWaveMeterValueEvent
2018-01-04 20:13:53.412 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_METER, value = 20.2
2018-01-04 20:13:53.416 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Updating channel state zwave:device:zstick:node41:meter_watts to 20.2 [DecimalType]
2018-01-04 20:13:53.420 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 41: Commands processed 1.
2018-01-04 20:13:53.424 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 41: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@3cf624.

third dimmer:
firmware v3.5, no additional endpoints enabled, can’t be controller from OH, debug logs give me:

2018-01-04 20:13:32.581 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Command received zwave:device:zstick:node40:switch_dimmer1 --> ON
2018-01-04 20:13:33.635 [DEBUG] [converter.ZWaveBinarySwitchConverter] - NODE 40: Command class class COMMAND_CLASS_SWITCH_BINARY for endpoint 1 not found
2018-01-04 20:13:33.637 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: No messages returned from converter

and

2018-01-04 20:19:22.373 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Command received zwave:device:zstick:node40:switch_dimmer1 --> 5
2018-01-04 20:19:22.376 [DEBUG] [erter.ZWaveMultiLevelSwitchConverter] - NODE 40: Command class SWITCH_MULTILEVEL not found when processing command on endpoint 1
2018-01-04 20:19:22.379 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: No messages returned from converter

and does not report status exactly as second dimmer:

2018-01-04 20:14:55.057 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 40: Application Command Request (ALIVE:DONE)
2018-01-04 20:14:55.058 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 40: resetResendCount initComplete=true isDead=false
2018-01-04 20:14:55.060 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 40: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2018-01-04 20:14:55.061 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 40: SECURITY not supported
2018-01-04 20:14:55.062 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 40: Received COMMAND_CLASS_SWITCH_MULTILEVEL V3 SWITCH_MULTILEVEL_REPORT
2018-01-04 20:14:55.064 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 40: Switch Multi Level report, value = 0
2018-01-04 20:14:55.067 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-01-04 20:14:55.068 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 0
2018-01-04 20:14:55.070 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 40: Commands processed 1.
2018-01-04 20:14:55.072 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 40: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1ee75e1.
2018-01-04 20:14:56.081 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 40: Application Command Request (ALIVE:DONE)
2018-01-04 20:14:56.082 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 40: resetResendCount initComplete=true isDead=false
2018-01-04 20:14:56.083 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 40: Incoming command class COMMAND_CLASS_METER, endpoint 0
2018-01-04 20:14:56.084 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 40: SECURITY not supported
2018-01-04 20:14:56.086 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 40: Received COMMAND_CLASS_METER V3 METER_REPORT
2018-01-04 20:14:56.087 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 40: Meter: Type=Electric(1), Scale=W(2), Value=0E+1
2018-01-04 20:14:56.090 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Got an event from Z-Wave network: ZWaveMeterValueEvent
2018-01-04 20:14:56.091 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_METER, value = 0E+1
2018-01-04 20:14:56.094 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 40: Updating channel state zwave:device:zstick:node40:meter_watts to 0 [DecimalType]
2018-01-04 20:14:56.098 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 40: Commands processed 1.
2018-01-04 20:14:56.099 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 40: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@e5792f.

I think i fixed it, the one thing that was different between working dimmer and not working dimmers is that working one sends reports from endpoint 1 and not working dimmers from endpoint 0. I excluded with reset of the settings (5 times on i1), and after the inclusion the dimmer sends updates on endpoint 1. So it seems that to update to this dev binding the qubino device must be totally wiped from the z-wave network :slight_smile:

Those qubinos ere giving me a hard time … the last one had no additional endpoints defined and even resetting didn’t helped. So I enabled i2 endpoint and then reincluded and only then it reports correctly … I hope that this was the last time I had to reinclude qubino device …

Hi!

I have read this thread throgoughly and think that I have the same problem. I have an ZMNHAD1 H1S5P2, which I think means firmware version 5. I downloaded the latest snapshot yesterday from https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastStableBuild/org.openhab.binding%24org.openhab.binding.zwave/, however I think it was before the 2018-jan-04 22:45:20 snapshot came out. Is snapshot the same as dev branch? If not, how do I get builds from the dev branch?

After excluding the device (but not resetting all settings) and including it again with the (back then) latest snapshot, it seems to work with updates to the controller. However it doesn’t seem to work with association to another device I have (Aeon Labs Nano Switch). Could it be a related problem? The other way works. When I manually press the Nano Switch the Qubino lights up. Also it seems that when updating configuration settings the updates from the Qubino can stop working again, but another exclude/include fixes it. I have not tested it thoroughly enough to know if it is 100% repeatable.

I bought one Nano Switch and one Qubino to evaluate which one I think is best and I would very much like to use the Qubino due ti it’s faster response time when pressing the switch and the fact that there’s a 2 relay version of it.

Please let me know if I can be of any help.

No - they are different.

Thank you!

I have tried it out now. Excluded the Qubino with 5 clicks within 60 sec of power up, and then removed all Things. After that I replaced the snapshot jar (named 2.3.0) with the dev jar (named 2.2.0). Then I added the controller again and included the Qubino. Now it is working exactly as before trying the snapshot, no updates at all. It’s as if I am running the release version again. How can I verify that it actually is the new jar that is executing?

Edit: Sorry, I forgot to mention that I shut down OH before swapping the jar

in the karaf console type bundle:list. it will show all the bindings with versions.

It said:

229 | Active | 80 | 2.3.0.201801032157 | ZWave Binding
230 | Installed | 80 | 2.2.0.201801021718 | ZWave Binding

I uninstalled the 2.3.0 and restarted, excluded the Qubino again with 5 clicks, removed all Things and added them back again, included the Qubino again and now it works! It doesn’t work every time however. Sometimes it misses state changes. When that happens I get nothing in the log, even though debug output is activated. It doesn’t seem to happen when I hold the laptop in front of the switch, but it happens when the laptop is sitting on a (grounded) steel bench about 1 meter away. Maybe that is disturbing the RF signal.

The association to the Nano Switch still doesn’t work however. Only the Nano Switch can trigger the Qubino, not the other way around. Has anybody else had any luck with association and the Qubino 1 Relay?

The dev version is your bundle 230 (dated 201801021718). As both bindings are still installed the snapshot version is currently still active. So you need to unstall the old version with

bundle:uninstall 230