Slow zwave / errors in ha-zwaved.log

Sometimes I get weird / slow zwave behaviour on my hub. Tonight, this leads to a lack of control of my blinds.

After resetting the hub (which sometimes helps), things do not improve today. In the zwave log, I get the following messages, starting at the moment when I try to set the blind (MLSwitch).

Is there any clue in this log what’s wrong with the network? The errors and warnings are a bit vague, though they seem to point to issues with node 12, 26 and 27.

2022-11-11 19:55:59.051132 INFO : set MLSwitch: value(82)
2022-11-11 19:55:59.074341 INFO : znetNodeCmdBinarySwitch (node id: 12 channel id: 0) value: 255, target value: 0, duration: 0
2022-11-11 19:55:59.074668 INFO : Cant handle node 12, use monitoring handler instead
2022-11-11 19:56:00.431163 INFO : znetNodeCmdBinarySwitch (node id: 26 channel id: 0) value: 255, target value: 0, duration: 0
2022-11-11 19:56:00.431497 INFO : Cant handle node 26, use monitoring handler instead
2022-11-11 19:56:01.838167 INFO : znetNodeCmdBinarySwitch (node id: 27 channel id: 0) value: 255, target value: 0, duration: 0
2022-11-11 19:56:01.838506 INFO : Cant handle node 27, use monitoring handler instead
2022-11-11 19:56:04.354623 ERROR: CurrentValuesHandler, Failed cc processing. CC = 142, ch = 2, fail = 2
2022-11-11 19:56:13.684333 INFO : znetNodeCmdBinarySwitch (node id: 12 channel id: 0) value: 255, target value: 0, duration: 0
2022-11-11 19:56:13.684684 INFO : Cant handle node 12, use monitoring handler instead
2022-11-11 19:56:15.043086 INFO : znetNodeCmdBinarySwitch (node id: 26 channel id: 0) value: 255, target value: 0, duration: 0
2022-11-11 19:56:15.043491 INFO : Cant handle node 26, use monitoring handler instead
2022-11-11 19:56:16.451741 INFO : znetNodeCmdBinarySwitch (node id: 27 channel id: 0) value: 255, target value: 0, duration: 0
2022-11-11 19:56:16.451978 INFO : Cant handle node 27, use monitoring handler instead
2022-11-11 19:56:17.009830 INFO : znetNodeCmdBinarySwitch (node id: 29 channel id: 2) value: 255, target value: 254, duration: 0
2022-11-11 19:56:19.274959 INFO : znetNodeCmdMeter (node id: 29, channel id: 2, type: 1, scale: 0, value: 0)
2022-11-11 19:56:20.631822 INFO : znetNodeCmdBinarySwitch (node id: 12 channel id: 0) value: 255, target value: 0, duration: 0
2022-11-11 19:56:20.632351 INFO : Cant handle node 12, use monitoring handler instead
2022-11-11 19:56:21.989705 INFO : znetNodeCmdBinarySwitch (node id: 26 channel id: 0) value: 255, target value: 0, duration: 0
2022-11-11 19:56:21.989996 INFO : Cant handle node 26, use monitoring handler instead
2022-11-11 19:56:23.347429 INFO : znetNodeCmdBinarySwitch (node id: 27 channel id: 0) value: 255, target value: 0, duration: 0
2022-11-11 19:56:23.347798 INFO : Cant handle node 27, use monitoring handler instead
2022-11-11 19:56:23.956270 INFO : znetNodeCmdMeter (node id: 29, channel id: 2, type: 1, scale: 2, value: 0)
2022-11-11 19:56:23.956601 INFO : Cant handle node 29, use monitoring handler instead
2022-11-11 19:56:32.839581 ERROR: AssociationRequest fail (continued). Error=-7, args=[31, 0, 1]
2022-11-11 19:56:32.890502 INFO : znetAssociationResult (node id: 31, group id: 1)
2022-11-11 19:56:34.205495 INFO : znetNodeCmdBinarySwitch (node id: 12 channel id: 0) value: 255, target value: 0, duration: 0
2022-11-11 19:56:34.205865 INFO : Cant handle node 12, use monitoring handler instead

Hello @jouked

What devices (model) are nodes 12, 26 and 27? If you want, we can create a support ticket to investigate further.

They are iBlinds v3, running firmware 3.06 or 3.07. They work pretty ok, however it’s not hard to get them to upset my zwave network.

I have 5 of these blinds, and several meshbots to run certain scenes. Triggering an all close / all open scene works, however during scene execution my zwave network blocks, until all blinds are finished. This means that e.g. motion sensors now get a delay in my house.

Also, triggering the meshbots with a scene controller (aeotec wall mote quad) in quick succesion usually kills the whole zwave system, requiring a reboot of the ezlo hub.

Can you move the hub/controller close to the blinds just as a test? Say within 5-10’.

It looks like ZWave retries are occurring which could be due to marginal RF path. Shortening the distance should swamp the RF path problem and it goes away. If however, it keeps retrying it probably a logic bug in the ZWave handling.

I know this isn’t a fix but at least it gives you more color on the failure mode.

You could also try plugging in a wall switch (like a DZPA1-2BW) between the hub and the blinds to be a possible hop path (repeater). Again more of an experiment than a fix but might help you characterize problem more.

As I have written elsewhere I have seen confused ZWave devices that don’t respond and it is usually when I run a scene with multiple back to back device state changes and I suspect it is compounded when a marginal (or collisions if the channel access control is confused) ZWave path starts requiring retries on the RF link.

I tried but there’s no difference, even with the hub at 6 feet from my iBlind (device number 26). So there must be something else going on.

In fact, there is a difference, even 15 minutes after bootup, I cannot control any of my blinds with the hub in this location.

2022-11-13 15:05:59.077791 INFO : znetNodeCmdMeter (node id: 28, channel id: 0, type: 1, scale: 2, value: 0)
2022-11-13 15:05:59.078224 INFO : Cant handle node 28, use monitoring handler instead
2022-11-13 15:06:20.098086 ERROR: CurrentValuesHandler, Failed cc processing. CC = 142, ch = 0, fail = 2
2022-11-13 15:06:41.098828 ERROR: CurrentValuesHandler, Failed cc processing. CC = 113, ch = 0, fail = 2
2022-11-13 15:07:02.099464 ERROR: CurrentValuesHandler, Failed cc processing. CC = 37, ch = 0, fail = 2
2022-11-13 15:07:23.100153 ERROR: CurrentValuesHandler, Failed cc processing. CC = 50, ch = 0, fail = 2

2022-11-13 15:07:44.121007 ERROR: CurrentValuesHandler, Failed cc processing. CC = 142, ch = 1, fail = 2
2022-11-13 15:07:51.252818 INFO : set MLSwitch Multi: value(50)
2022-11-13 15:07:51.253310 INFO : set MLSwitch: value(50)
2022-11-13 15:07:51.273016 INFO : set MLSwitch Multi: value(99)
2022-11-13 15:07:51.273537 INFO : set MLSwitch: value(99)
2022-11-13 15:08:05.121675 ERROR: CurrentValuesHandler, Failed cc processing. CC = 37, ch = 1, fail = 2
2022-11-13 15:08:06.253488 ERROR: { “code”: -15, “data”: “hub.gateway.zwave.err.report.expired” }
2022-11-13 15:08:06.253865 INFO : set MLSwitch: value(50)
2022-11-13 15:08:06.273700 ERROR: { “code”: -15, “data”: “hub.gateway.zwave.err.report.expired” }
2022-11-13 15:08:06.274013 INFO : set MLSwitch: value(99)
2022-11-13 15:08:21.254041 ERROR: { “code”: -15, “data”: “hub.gateway.zwave.err.report.expired” }
2022-11-13 15:08:21.254372 INFO : set MLSwitch: value(50)
2022-11-13 15:08:21.274124 ERROR: { “code”: -15, “data”: “hub.gateway.zwave.err.report.expired” }
2022-11-13 15:08:26.122282 ERROR: CurrentValuesHandler, Failed cc processing. CC = 50, ch = 1, fail = 2
2022-11-13 15:08:36.254570 ERROR: { “code”: -15, “data”: “hub.gateway.zwave.err.report.expired” }

2022-11-13 15:08:47.143167 ERROR: CurrentValuesHandler, Failed cc processing. CC = 142, ch = 2, fail = 2
2022-11-13 15:09:08.143841 ERROR: CurrentValuesHandler, Failed cc processing. CC = 37, ch = 2, fail = 2
2022-11-13 15:09:29.144561 ERROR: CurrentValuesHandler, Failed cc processing. CC = 50, ch = 2, fail = 2

Hello @jouked

Was this always the behavior with the blinds or did it start at some point? (perhaps after a change in the z-wave network).

If you’re not sure what could have changed, the simplest way to work this issue out would be to unpair/re-pair the blinds, and re-write the scenes.

I don’t think there was any trigger, performance has been like this since the start. And the blinds were one of the first devices on my ezlo hub.

@jouked, I have 10 iBlinds on 2 difference Ezlo Plus hubs running firmware version 2.0.33.211.6.2. Mine are working pretty well but this is after having made some adjustments.

At the recommendation of the CEO of iBlinds, I added an AeoTec Range Extender 7 - this helps with battery-operated actuators.

First, I use a 2 second delay between each blind when opening and/or closing. When closing, I set the dimmer value to 0 and the switch to false. When opening, I simply set the dimmer value.

Perhaps these adjustments will help in your case. These shouldn’t be necessary but I spent countless hours working with Ezlo and iBlinds to wring out the kinks but in the end, resorted to finding work-arounds even though I really wanted simultaneous opening/closing :wink:

Quick update, right now the iBlinds are working pretty well! Currently it takes only 8 seconds after triggering a scene to move all blinds into the correct position. Over the past few weeks I’ve added a Aeotec repeater, re-included a single blind (the smart start inclusion did not fully work) and recreated the meshbots controlling the blinds. Not sure which change caused the biggest improvement, but the result is satisfying.

1 Like