Values get mixed across devices

[bostjane]

I use Zwave JS UI in Domoticz via mqqt mosquitto broker. I'm getting strange behaviour that I got new "devices" in Domoticz that doesn't even exists. For example, device for Aeotec Multisensor 6 is created for electric A, V and W values, which is obviously wrong. Similary I get new devices For Fibaro Wall plug for Air temperature which is also obviously wrong.

I guess Zwave JS UI sends out those "devices" as Domoticz probably doesn't simply make them up. It doesn't happen a lot, but from time to time, so it's not quite easy to log.

What is going on?

[robertsLando]

@bostjane Firstly, do you see those values in UI? I mean go to control panel, click (expand) the node row and check if it reports support for those command classes. Some nodes report support for command classes they should not and that's a possible reason of this issue

[bostjane]

I have already checked that in the beginning and forgot to mention it in my first post.

If device sends a specific value, does it stay in GUI forever (with exception to re-interview)? I checked Multisensor 5 and Fibaro Wall Plug and they do not have this invalid values in GUI, but they do appear in Domoticz. Maybe there is a problem when values are pushed to the mqqt broker?

[kpine]

Usually this is because of https://zwave-js.github.io/node-zwave-js/#/troubleshooting/nonsensical-values.

[bostjane]

Usually this is because of https://zwave-js.github.io/node-zwave-js/#/troubleshooting/nonsensical-values.

@kpine I read the supplied link, thanks. I wasn't aware that ZWave was so poorly designed at the beginning as far as error detection is considered.

I would like to focus on my explicit case to figure it out if at least in my case Zwave JS could/should detect the wrong data and discard it. Multisensor 6 node did not report it supports electric V, A and W values (at least I don't see them in GUI) and further it supports "Multilevel Sensor v5" - isn't this new enough that according to documentation Zwave JS should be able to query which meters/sensors the device supports and discard data?

[kpine]

I would like to focus on my explicit case to figure it out if at least in my case Zwave JS could/should detect the wrong data and discard it.

If that's what is happening, then:

https://zwave-js.github.io/node-zwave-js/#/troubleshooting/index?id=rule-1-use-the-driver-log-luke

https://zwave-js.github.io/zwave-js-ui/#/troubleshooting/generating-logs?id=driver-logs

[robertsLando]

Even a re-interview of the device may help

[bostjane]

I'll send log as soon as next such event occurs...

In my previous post I wondered if anything can be determined theoretically, without log. In particular documentation says "The sending node supports an older version of the Meter or Multilevel Sensor CC that do not support querying which meters/sensors the device supports." as case when it can't be done anything to prevent wrong data to be accepted. Is "Multilevel Sensor v5" old enough for such statement? Or is it new and device could be queried and wrong values discarded as a result.

[robertsLando]

without a log it's difficult to say

[bostjane]

Here are logs and screenshot of wrong devices in Domoticz. The most probable time when the wrong devices appeared is the "Last seen" time in Domoticz.
zwavejs_2023-08-09.log.gz
zwavejs_2023-08-10.log.gz
zwavejs_2023-08-11.log.gz
zwavejs_2023-08-12.log.gz
zwavejs_2023-08-13.zip

[robertsLando]

@AlCalzone do you think this is related to: https://zwave-js.github.io/node-zwave-js/#/troubleshooting/nonsensical-values ?

[AlCalzone]

Yeah it is. The W report at the bottom is received 3 times with the same content. So if it is not from node 28, the node ID was likely corrupted somewhere along the route and a repeater repeated the same corrupted command multiple times.

In general, this mesh is not healthy. Tons of repeated messages, much too much reporting going on. Essentially the mesh flooded to its limits just from the meter/sensor reports.

I suggest following these steps:

1. If you haven't already, https://zwave-js.github.io/node-zwave-js/#/troubleshooting/connectivity-issues?id=general-troubleshooting
2. https://zwave-js.github.io/node-zwave-js/#/troubleshooting/network-health?id=optimizing-the-reporting-configuration
3. https://zwave-js.github.io/node-zwave-js/#/troubleshooting/network-health?id=testing-the-connection-strength

[bostjane]

Yes, the world tends not to be ideal and neither is my mesh :) I'll follow recommendations above as much as I can, but of course I can not move my washing machine and motion sensor just to have better reception :)

Just for seconds let us leave the fact of flooded mesh, bad transmissions, etc and focus on corrupted message that Zwave JS got - it could be the only message in an day and still be something that needs to be addressed. So, could ZWave JS somehow detect this corrupted message and discard it, that's something that might be done and improve the overall reliability, not just in my case but for all?

My thinking... corrupted message must have originated from nodes where Aeon Labs Smart Switch 6/7 are connected. Only those nodes can send electric V, A and W values in "Meter v3". As Node 28 does not have "Meter v3", shouldn't/couldn't Zwave JS simply ignore such data? If not unconditionally, I suggest new feature that Zwave JS accepts them in first inclusion or Re-Interview (as now), but not later anymore. Or maybe to introduce check option in GUI per-device or globally that would prevent receiving values that device doesn't have.

I think such upgrade would be very useful.

[AlCalzone]

As Node 28 does not have "Meter v3", shouldn't/couldn't Zwave JS simply ignore such data?

Indeed, this is on the todo list: zwave-js/node-zwave-js#5510

That said, improving the mesh health and reducing the traffic goes a long way in preventing such issues altogether.

[AlCalzone]

Indeed, this is on the todo list: zwave-js/node-zwave-js#5510

I have scheduled this for the next release, FYI.

[robertsLando]

The https://github.com/zwave-js/zwave-js-server/blob/master/src/lib/server.ts#L509 PR has been merged many months ago and this should be fixed now