(Changed) Polling period for Qubino 2 Flush (Z-wave) Relais sensors set to 30 min?

Setup, Configuration and Use Beginners
, ,
1

Hi,

I am struggling to get reliable power meter updates for Qubino 2 Flush Relais (Z-wave) units in OH2. I do get a first reading when I start openhab and the connection is made, but then the values of the power meter are not updated anymore, independently if I switch a light on manually (wall switch) or via OH2-UI.

My first reaction was the Qubino units are buggy and I went to the shop to get them checked. We wired them up and connected the units to another home automation system and they immediately reported the power changes with very little delays (seconds), so it seems the problem is in OH2 or the z-wave binding setup ?

The background of this problem is that I like to update the OH2 switch states if a wall switch was used to change the status. This works for the system start (via my rules that get triggered), but then there is no power meter reading anymore and hence the rules are not functioning. Maybe there is another way, I just down know how (beginners problem…).

Any help would be very welcome !

Best, markus

My setup: fresh version of OH2 (677) and Z-wave binding that comes with it.

2

Try setting association group 1 (or lifeline or whatever it is called in your device) to your zwave controller.

3

@sihui:

thanks for the reply. I tried this now in HABMIN, putting the controller into either only the Default Reporting Group or into all Association Groups for the channels. No change in behaviour. I need to restart the system OR hit “Refresh” on HABMIN to get a new reading reliably (or the status update for the binary switch triggered manually as it seems).

Btw, my configuration for the switch:

Switch Light_FF_LivingRoom_Sofa "Living Room: Sofa " (Lights, Lights_Random, FF_LivingRoom) { channel=“zwave:device:c1977c1d:node10:switch_binary2” }

Number Light_FF_LivingRoom_Sofa_Power “Living Room: Sofa Power [%.2f W]” (Lights_Power) { channel=“zwave:device:c1977c1d:node10:meter_watts2” }

4

Could you tell which device you have?:
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list
I cannot find it in the zwave database …

What do you get in BasicUI or ClassicUI?

5

@sihui:

The devices are sold under the name qubino flush 2 relais, the code is ZMNHBD, which in @chris table is listed under Goap ZMNHBD Flush 2 relays as it seems.

This is with Basic UI, same in HABMIN (looking at config->things->device description) where the refresh button is and as well the list of items/channels. I didn’t try Classic UI, but I can’t see it in the logging any tate change of the power sensor or the binary switch (when using the wall switch to trigger it). Only after the “refresh” command one of the two at the time (!) appear in the logging as updated and as well in Basic UI/HABMIN (takes a few seconds).

PS: other qubino devices don’t have this issue, like the qubino flush shutter (ZMNHCD), same here, it is listed under Goap. Those report the power updates almost immediately.

6

Check your settings in config parameter 40, 41, 42, 43 …

Edit: default setting are: power is only reported when the change is more than 10% and every 5 minutes.

7

yes, did that already:

40: 10 (%)
41: 15 (sec)
42: 10 (%)
43: 15 (sec)

changing the parameters did not change the behaviour for me.

PPS: the qubino flush shutter reports the power updates, but not the state updates. I can get the qubino flush 2 relays to report the state update with a “refresh” command. It seems I don’t understand the concept really how this is supposed to work. As I said before, in the shop with other home system it reported correctly, so it looks like some config issue or binding ?

8

What do you mean by that? A browser page refresh?
Actually there are no config settings to get the actual states from a device, it should work instantly … and does on my system … as long as the correct association group is set to your controller - in your case “Default Reporting Group”

9

@sihui yes, a refresh on HAPMIN clicking on Conf->things->device->Desciption “refresh items”, image attached.

Screen Shot 2017-01-03 at 21.30.51 .png761×350 40 KB

I don’t get the updates. I am really confused about how this should be set correctly, here is my config…

Screen Shot 2017-01-03 at 21.32.37 .png772×166 23.8 KB

10

Looks all fine … sorry, no more ideas.

11

I had a fibaro dimmer 2 stop reporting sensor power today. Got it working again by excluding it and then readding it.

Regards s

12

hi, hmm, that’s another idea. I’ll try that later…

cheers, markus

13

Just to report, I tried excluding/including the device, no change. Did not fix the problem. Any other ideas what could be wrong ? Or is it a binding issue for the qubino device @chris ?

14

Ok, some progress here. I overlooked that there is a “polling period” in HABMIN to configure this. By default this is set to 30 min for the Qubino devices, which makes little sense for a power sensor. Putting this to 15 (seconds) gives me the sensor updates (Yeah). I think the default for the polling time should be updated such that the sensors get read. @chris, do you think this makes sense to change it ?

15

No - generally polling is bad news as it congests the network needlessly (in most cases).

You should be able to configure the device to report without polling. Normally there should be configuration options that tell the device to send every x minutes, or when the power changes by y watts. Normally you would only configure it to send when there’s a change.

I would be very surprised if the Qubino doesn’t have this feature (the Qubino devices I have definately do).

16

Hi @chris, the Qubino device does have those options, but they seem not to have an effect in OH2. Reporting works for the flush shutters (ZMNHCD) for me, but for the 2 relays (ZMNHBD) it doesn’t. It works as well for a FGBS001 Universal Binary Sensor for me. See discussion here. The only workaround I found was to change the polling. I do see that the network is now slower, that is true.

For all my devices I put the reporting to 15 sec (regardless of the polling interval) and >10% changes, but this seems to have no effect. I tried the Qubino 2 relays device with another home automation system in the shop, it did report immediately. So it seems there is some sort of config issue in OH2/binding somewhere for the 2 relays (ZMNHBD), but I wasn’t able to debug this. Any help welcome.

17

What do you mean? The reporting is a function of the device - the device should send the same message as the poll, but without the binding having to poll.

If the configuration in the device doesn’t work, then either the device has a problem, or the configuration isn’t right. You should capture a log to see if the device is sending anything - if it is, then we need to analyse it to make sure it’s what the binding is expecting to see, and if it’s not, we’ll sort out the binding to fix this.

Adding polling is not the solution - getting the device reporting to work is…

This may be related to the way Qubino decides to send multi-channel data. Did you do all the configuration of this device within OH2 or have you need using OH1 to do the initial inclusion etc?

18

Hi @Chris, I agree with you, I will try to get some debug logs to see later today. I agree, it looks like there is some sort of config problem, either on my side or on the binding.

Concerning your question, I am including the device with the USB controller, I normally discover the device in the paper UI, the config then I do in HABMIN (OH2) (parameters,…), for the UI and for running the system etc I have items/rules/sitemap… config files.

19

Hi @Chris, here is how far I got it with looking into the logfiles. I think I have a good hint on what is going on. The Power_meter updates in the logfiles are for the Qubino Flush 2 Relays are for endpoint=0 (which is the overall power), but not for endpoints=1 and endpoints=2, which are the individual switches. I do see in the logfiles lines like this:

2017-01-08 17:04:57.605 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Application Command Request (ALIVE:DONE)
2017-01-08 17:04:57.606 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: Starting initialisation from DONE
2017-01-08 17:04:57.606 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Incoming command class METER
2017-01-08 17:04:57.606 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 2: Received METER command V3
2017-01-08 17:04:57.606 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 2: Meter: Type=Electric(1), Scale=W(2), Value=17.3
2017-01-08 17:04:57.606 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMeterValueEvent
2017-01-08 17:04:57.606 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveMeterValueEvent
2017-01-08 17:04:57.606 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = METER, value = 17.3
2017-01-08 17:04:57.607 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Updating channel state zwave:device:c1977c1d:node2:meter_watts to 17.3 [DecimalType]
2017-01-08 17:04:57.607 [DEBUG] [ternal.converter.ZWaveMeterConverter] - Not the right scale E_KWh <> E_W

which is endpoint=0 and the command class is METER (!!). It looks to me the values are for the individual endpoints though ??? There are in fact tons of endpoint=0 messages for the nodes in the lofile like this, so the Qubino is reporting as it should, but it ends up wrongly.

One possible other issue I see is a mismatch comment E_KWh<> E_W in the logilfe during init phase (nodes get initialised). This looks like a bug to me, as the message gives scale=W.

Later on I found a different pattern for a Qubino Flush 2 Relays:

2017-01-08 17:15:00.426 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 57: Application Command Request (ALIVE:DONE)
2017-01-08 17:15:00.427 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 57: Starting initialisation from DONE
2017-01-08 17:15:00.427 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@63ef849a already registered
2017-01-08 17:15:00.427 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 57: Incoming command class METER
2017-01-08 17:15:00.427 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 57: Received METER command V3
2017-01-08 17:15:00.427 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 57: Meter: Type=Electric(1), Scale=W(2), Value=30.2
2017-01-08 17:15:00.427 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMeterValueEvent

and the nothing for this node anymore. I found this only once.

Then I tried turning on/off switches (from the Basic UI) to trigger power meter updates:

2017-01-08 17:48:40.888 [ItemCommandEvent ] - Item ‘Light_FF_DiningRoom_Rear’ received command ON
2017-01-08 17:48:40.907 [ItemStateChangedEvent ] - Light_FF_DiningRoom_Rear changed from OFF to ON
2017-01-08 17:48:41.913 [ItemCommandEvent ] - Item ‘Light_FF_LivingRoom_Sofa’ received command OFF
2017-01-08 17:48:41.930 [ItemStateChangedEvent ] - Light_FF_LivingRoom_Sofa changed from ON to OFF
2017-01-08 17:48:42.755 [ItemCommandEvent ] - Item ‘Light_SF_Mezzanine_Stairs’ received command ON
2017-01-08 17:48:42.788 [ItemStateChangedEvent ] - Light_SF_Mezzanine_Stairs changed from OFF to ON
2017-01-08 17:48:44.277 [ItemCommandEvent ] - Item ‘Light_FF_LivingRoom_Rear’ received command OFF
2017-01-08 17:48:44.282 [ItemStateChangedEvent ] - Light_FF_LivingRoom_Rear changed from ON to OFF
2017-01-08 17:48:44.851 [ItemCommandEvent ] - Item ‘Light_FF_Stairs’ received command ON
2017-01-08 17:48:44.857 [ItemStateChangedEvent ] - Light_FF_Stairs changed from OFF to ON
2017-01-08 17:48:45.591 [ItemCommandEvent ] - Item ‘Light_FF_GuestBedroom_Sofa’ received command ON
2017-01-08 17:48:45.626 [ItemStateChangedEvent ] - Light_FF_GuestBedroom_Sofa changed from OFF to ON
2017-01-08 17:48:46.845 [ItemCommandEvent ] - Item ‘Light_FF_GuestBedroom_Rear’ received command OFF
2017-01-08 17:48:46.848 [ItemStateChangedEvent ] - Light_FF_GuestBedroom_Rear changed from ON to OFF

This triggered 2 change events:

2017-01-08 17:49:16.371 [ItemStateChangedEvent ] - Light_FF_LivingRoom_Rear_Power changed from 9.6 to 0
2017-01-08 17:49:17.652 [ItemStateChangedEvent ] - Light_FF_LivingRoom_Sofa_Power changed from 18.4 to 0

I first did not understand this, but after some digging there was (by change) a POLL event in between:

2017-01-08 17:49:11.165 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Polling…
2017-01-08 17:49:11.165 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Polling zwave:device:c1977c1d:node57:switch_binary
2017-01-08 17:49:11.165 [DEBUG] [converter.ZWaveBinarySwitchConverter] - NODE 57: Generating poll message for SWITCH_BINARY, endpoint 0
2017-01-08 17:49:11.165 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 57: Creating new message for application command SWITCH_BINARY_GET
…

and this leads to

2017-01-08 17:49:16.358 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 57: Application Command Request (ALIVE:DONE)
2017-01-08 17:49:16.358 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 57: Starting initialisation from DONE
2017-01-08 17:49:16.358 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@69978b4b already registered
2017-01-08 17:49:16.358 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 57: Incoming command class MULTI_INSTANCE
2017-01-08 17:49:16.358 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 57: Received MULTI_INSTANCE command V2
2017-01-08 17:49:16.358 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 57: Requested Command Class = METER (0x32)
2017-01-08 17:49:16.358 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 57: Endpoint = 1, calling handleApplicationCommandRequest.
2017-01-08 17:49:16.358 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 57: Received METER command V3
2017-01-08 17:49:16.358 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 57: Meter: Type=Electric(1), Scale=W(2), Value=0E+1
2017-01-08 17:49:16.358 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMeterValueEvent
2017-01-08 17:49:16.358 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Got an event from Z-Wave network: ZWaveMeterValueEvent
2017-01-08 17:49:16.358 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Got a value event from Z-Wave network, endpoint = 1, command class = METER, value = 0E+1
2017-01-08 17:49:16.358 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 57: Updating channel state zwave:device:c1977c1d:node57:meter_watts1 to 0 [DecimalType]
2017-01-08 17:49:16.359 [DEBUG] [ternal.converter.ZWaveMeterConverter] - Not the right scale E_KWh <> E_W

similar for endpoint 2 afterwards. This is command is now class MULTI_INSTANCE, while the others are METER ??? It seems like this is the reason why the power_meter updates for endpoints 1 and 2 are ending up as channel updates for endpoint 0 ? Is this a mis-config of the Qubino, I don’t see where to configure this differently ? Or something else ?

Btw, there is a frequent ERROR message in the logfile, here an example for a Qubino Flush Shutter (!), the pattern is:

2017-01-08 17:05:52.394 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 29: Timeout while sending message. Requeueing - 1 attempts left!
2017-01-08 17:05:52.394 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 29: Got an error while sending data. Resending message.
2017-01-08 17:05:52.394 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 117. Queue={}
2017-01-08 17:05:52.395 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 116
2017-01-08 17:05:52.395 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 1D 03 70 05 56 25 01 FF
2017-01-08 17:05:52.395 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 29: Sending REQUEST Message = 01 0A 00 13 1D 03 70 05 56 25 01 FF
2017-01-08 17:05:52.404 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2017-01-08 17:05:52.404 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-01-08 17:05:52.404 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
2017-01-08 17:05:52.404 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
2017-01-08 17:05:52.404 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
2017-01-08 17:05:52.405 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 29: Sent Data successfully placed on stack.
2017-01-08 17:05:52.420 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 01 00 00 02 E8
2017-01-08 17:05:52.420 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-01-08 17:05:52.420 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 01 00 00 02 00 00 E6
2017-01-08 17:05:52.420 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 01 00 00 02 00 00 E6
2017-01-08 17:05:52.420 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=01 00 00 02
2017-01-08 17:05:52.420 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 29: SendData Request. CallBack ID = 1, Status = Transmission complete and ACK received(0)
2017-01-08 17:05:52.421 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Config, dest=29, callback=
1, payload=1D 03 70 05 56
2017-01-08 17:05:52.421 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0
, payload=01 00 00 02
2017-01-08 17:05:52.421 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=1, expected=ApplicationCommandHandler, cancelled=false MIS
MATCH

It does not look to me this is related to the power meter issue, but I thought this might be interesting.

20

Why do you say it is “reporting as it should” - it looks like it’s reporting to endpoint 0 - it’s VERY unlikely that the binding will report the endpoint wrong but the logging you provided doesn’t give the received message so I can’t be 100% sure.

I suspect that this is an issue with the configuration of the multi-channel-association that I’m working on elsewhere. Unless the MC association is set correctly, the device will only ever report endpoint 0.

This is fine - no problem at all. This is simply a debug message and doesn’t indicate a problem. In fact you can see in the log that the item is being updated correctly.

So, I think the issue will be with the MC association class which is needed to get the device reporting with the MC encap class. It will likely take a little time to get this working as I’m on holiday - you could try the latest binding to see if it configures the associations better, but I’m not sure it’s 100% right yet.

If possible when providing logs, please ensure that the received data packets are provided - otherwise it’s difficult to process and see what’s happening.