Status updates for Qubino Relays/Dimmers generally do not work

Sure, thank you very much for all the great work so far! I am living without that feature for more than a year now, so no problem as long as you won’t steal me the functioning endpoint 0 :wink:

I don’t know - I don’t have the source for other software. This is how it works - devices are required by the standard to report their command classes.

There are a number of ways that this could be implemented in other software - the end result is still the same in that the multi-channel command class needs to be used. For OH, the design choice was to configure the device specific issues in a database rather than filling the code with device specific hacks. If at some stage the recommendation from Sigma is that mutli-channel should be assumed to be supported under certain circumstances, or we just find that it’s better as devices stop reporting support for this in the NIF, then I will change this, but for now I believe that devices should report their support, and therefore device specific workarounds need to be configured in the database.

Please allow me some time to look at this - I will do so tomorrow.

I don’t think this will help. I recall some discussion about this in the ZWave community - in the past, Qubino always sent a REPORT message after a SET message to confirm that the state changed. The statement from Sigma was that this was not necessary and must be removed. A controller should assume that the configuration changed as a result of the SET message so the REPORT was not needed.

I don’t believe that this stops reports being sent when the device is manually changed.

Note that the removal of the swtich channel is not related to problems with associations - I didn’t just remove it to make things easier for me :wink: . The reason to remove this is that under ESH concepts, it is not required, and not recommended, since a dimmer provides the same functionality due to the inheritance.

Just one more thought on this: Would it be possible just to bring back the endpoint 0 channel switch_dimmer and leave the rest as it is now? People without activated multiple endpoints then could link their items to the 0-endpoints. When they change the configuration to multple endpoints they need to do a new item linking anyhow (as this requires reinclusion) and so they could then bind the items to the endpoint 1/2/3 channels.
From the logs the dimmer is reporting on the 0-endpoints if no further endpoints are activated and aon the 1/2/3-endpoints as soon as the additional endpoints are activated. So only the 0-channel is missing in the database now. Or am I missing something that it isn’t easy like that?

I don’t see why this is needed. The dimmer1 channel does exactly the same thing doesn’t it?

As I’ve said a few times, I intend to use the multi-channel command class with the device so it will not show 0 endpoints after that. The goal here is to make things simple - why do we need to have multiple channels where you need to use one channel if the configuration is set one way, and another channel if the configuration is set another way? I believe that this is a large part of the problem here - the device does things in different ways depending on how the user configured it, and this results in confusion.

Does that make sense?

Ok, so I’ve played around with this some more and it seems the Qubino doesn’t allow me to do what I wanted. It reports that it supports multi-channel-association, but then doesn’t actually support multi-channel!

Unfortunately then I’ll have to add the dimmer channel back in and we’ll have to live with the confusion that generates for now :frowning: .

You mean switch ? :slight_smile:

I meant switch_dimmer. This is for the ZMNHDD I was referring to, so it’s a dimmer…

it seems that I don’t understand the problem here … For me there are two problems.
First is that the ZMNHDD exposes different number of endpoints during inclusion depending on the parameter settings. This was the cause for OH not receiving status updates. Is that true ?
The second problem is that it is not possible to handle the dimmer with only one switch_dimmer channel because the device reports values other than 0 when the dimmer is OFF. So there must be separate channel switch_binary to know the state of the device. is that true ?

It’s linked at least. The problem (I think!) is that depending on the configuration of the switch, there are different commands required to configure associations. I think there was (is?) a combination of problems in the binding with it not sending the correct command depending on the state/configuration of the device wrt endpoints and users using the wrong channel for the configuration, such that even if the device sent the status, the channel that was being used didn’t update.

Really? The device is reporting it’s on even when it’s off?

No - not necessarily. By ESH ‘rules’ it’s not really allowed. Ideally, the binding would account for this, however the way the binding is written is that converters are linked to command classes so it’s not feasible to do this at the moment.

Ideally, I’d prefer to change the converters so that they are linked to channels - this is how I’ve written the ZigBee binding. This means a converter can use the appropriate command class for the command it gets. This is partly done in the binding at the moment in that the handler will send the command to the MultiLevelSwitch converter if it’s a dimmer command, and it will send it to the BinarySwitch converter if it’s an OnOff command.

However, if the device is reporting that the dimmer is on when it’s not, then I’m not really sure how to handle this! Qubino really made things difficult with these devices!

Yes :slight_smile: check my post that starts with “GOD DAMN IT !!!”.

The problem is that qubino dimmer behaves differently when sending SWITCH_MULTILEVEL_SET with value 255 and SWITCH_BINARY_SET with value 255. The first one makes dimmer to restore last value, and uses dimming time from parameter 66. The second one turns the dimmer always to 100% and uses dimming time from parameter 65. In OH Dimmer type uses OnOff, IncreaseDecrease and Percent and Switch uses OnOff. So when sending command type OnOff there is no way to distinguish between SWITCH_MULTILEVE and SWITCH_BINARY. I think this makes it impossible to handle this dimmer with only one switch_dimmer channel. If there would be two channels, I could at least handle this in a rule and in UI have only one item.

I missed that bit, but now agree with you :wink:

This is normal - not just Qubino - it’s part of the standard. If the converters were done differently, then we can handle this with a setting in the converter to either use the last value or not. I know this doesn’t give the user the option to change this on the fly, but we also need to try and maintain the standard ESH concepts.

Anyway, that’s a discussion for another day. Due to the reporting issue (aka the GOD DAMN IT ISSUE) there’s probably no solution other than to reinstate the switch channel in the dimmer…

I think it is still an acceptable workaround (at least for me) and allows to make things work.

Is that an issue only with the older Qubino firmware versions? Or are the newer ones also affected?

It’s not a long term solution though and that’s what I would have preferred. It still doesn’t make for a particularly satisfactory user experience and doesn’t meet with the ESH concepts :frowning: .

I expect it’s all, but I’ve not personally tested this.

Following this thread about Qubinos a while …
I understand that in general old firmware versions (not upgradable) are affected?
Is a workaround foreseeable?

and specific for the DIN DIMMER ZMNHSD… is it affected? (dont know if there are different revisions from that one)…

thanks!

Yes - as mentioned above this is now working on all versions (pending some database updates).

1 Like

oh cool. sorry I wasnt sure even reading the above because somebody always answered its not working for them ;)))
but thats perfect … so I dont have to worry about installing those DIN DIMMERS :slight_smile:

thx chris!

Hi,

I spent the last 5h reading and applying your useful hints. But finally I get meter reports when manually using the switch but I can’t control the dimmer via openhab anymore ;-(

So here is my setup:

  • Qubino: ZMNHDD Flushdimmer Plus Firmware 3.5
  • Openhab 2.2 stable release
  • latest Zwave Binding (hopefully): 227 │ Active │ 80 │ 2.2.0.201801021718 │ ZWave Binding
  • Zwave XML for qubino node 15 network_c9b22654__node_15.xml (21.6 KB)

I included, excluded the device several times and also set it to default values.

Currently I cannot control the the brightness via the “dimmer 1” channel

Dimmer EG_WZ_KR1_Helligkeit "Helligkeit [%2.0f]"  { channel="zwave:device:15ff39b3682:node15:switch_dimmer1"}

The logfile shows the following error messages

16:00:27.036 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'EG_WZ_KR1_Helligkeit' received command ON
16:00:27.053 [INFO ] [smarthome.event.ItemStateChangedEvent] - EG_WZ_KR1_Helligkeit changed from NULL to 100
16:00:27.116 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 15: Command received zwave:device:15ff39b3682:node15:switch_dimmer1 --> ON
16:00:27.120 [DEBUG] [.converter.ZWaveBinarySwitchConverter] - NODE 15: Command class class COMMAND_CLASS_SWITCH_BINARY for endpoint 1 not found
16:00:27.122 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 15: No messages returned from converter
16:00:35.991 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'EG_WZ_KR1_Helligkeit' received command 27
16:00:36.001 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 15: Command received zwave:device:15ff39b3682:node15:switch_dimmer1 --> 27
16:00:36.005 [DEBUG] [verter.ZWaveMultiLevelSwitchConverter] - NODE 15: Command class SWITCH_MULTILEVEL not found when processing command on endpoint 1

It complains about missing switch multilevel and switch binary classes also the zwave xml file attached above describes this features.

<nodeInformationFrame>
  <commandClass>COMMAND_CLASS_ZWAVEPLUS_INFO</commandClass>
  <commandClass>COMMAND_CLASS_VERSION</commandClass>
  <commandClass>COMMAND_CLASS_DEVICE_RESET_LOCALLY</commandClass>
  <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
  <commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
  <commandClass>COMMAND_CLASS_SWITCH_ALL</commandClass>
  <commandClass>COMMAND_CLASS_SWITCH_BINARY</commandClass>
  <commandClass>COMMAND_CLASS_SWITCH_MULTILEVEL</commandClass>
  <commandClass>COMMAND_CLASS_METER</commandClass>
  <commandClass>COMMAND_CLASS_ALARM</commandClass>
  <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
  <commandClass>COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION</commandClass>
  <commandClass>COMMAND_CLASS_ASSOCIATION_GRP_INFO</commandClass>
  <commandClass>COMMAND_CLASS_CONFIGURATION</commandClass>
</nodeInformationFrame>

I need some guidance what to to try next or which information to collect.

Please find below the log while reinitilizing the device

openhab log part 1.xml (956.8 KB)
openhab log part 2.xml (842.0 KB)

Any hints and help is highly appreciated.

best,

Guido

you are still missing COMMAND_CLASS_MULTI_CHANNEL in your nodeInformationFrame. You need to have configured at least one additional endpoint in the dimmer for this binding version to work properly. add a temperature sensor before inclusion or enable i2/i3 endpoint.

Hi Marek,

I already tried that with no success. To me it is unclear with detailed steps I have to take to make a proper exclusion / re-inclusion. This is what I tried with no success several times:

  1. Enable addtional endpoint e.g. I2 with value 9
  2. Habmin -> “Remove Device from Controller”
  3. Habmin -> delete Thing
  4. Shutdown openhab
  5. Delete zwave XML File
  6. Start openhab
  7. Habmin -> Scan for new Devices
  8. Habmin -> add new Device from Inbox

Do I have to start the module inclusion with triple click I1? Do I have to exclude on the module itself? Resetting module to default values (5 click I1) would overwrite addtional endpoint activation.

best,

Guido