node-zwave-js
node-zwave-js copied to clipboard
zwave-js
ConfigurationCCBulkGet causes error when reading non-existant parameter
Discussed in https://github.com/zwave-js/node-zwave-js/discussions/6560
Originally posted by @ackjewtn December 18, 2023
Checklist
-
[X] I have read and followed the above instructions
-
[X] I have checked the troubleshooting section and my problem is not described there.
-
[X] I have read the changelog and my problem was not mentioned there or the fix did not work.
Describe the issue
What is happening? After doing a firmware upgrade of a Z-Temp2 device, it's stuck on "NodeInfo" when re-interviewing.
Upgrading from FW: v1.2.0 SDK: v7.11.1
To: FW: v1.2.1 SDK: v7.17.2
What did you expect to happen instead? The device would get fully interviewed and work as usual.
Steps to reproduce the behavior:
- Upgrade the thermostat
- Re-interview starts and gets stuck on NodeInfo
- Take a look at the logs and see the error.
Anything else we should know?
After enabling debug logs, i see that Z-wave JS tries to get a parameter (#256), which according to Thermo-floor support, isn't supported by the device.
2023-12-18T09:54:07.245Z CNTRLR [Node 091] [+] [Configuration] 15: 0 [Endpoint 0]
2023-12-18T09:54:07.252Z DRIVER « [Node 091] [REQ] [BridgeApplicationCommand]
│ RSSI: -89 dBm
└─[ConfigurationCCReport]
parameter #: 15
value size: 2
value: 0
2023-12-18T09:54:07.253Z CNTRLR » [Node 091] querying parameter #256 value...
2023-12-18T09:54:07.266Z SERIAL » 0x011300a90001005b0570080100012500000000b4f3 (21 bytes)
2023-12-18T09:54:07.267Z DRIVER » [Node 091] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 180
└─[ConfigurationCCBulkGet]
parameters: 256
2023-12-18T09:54:07.281Z SERIAL « [ACK] (0x06)
2023-12-18T09:54:07.284Z SERIAL « 0x010401a90152 (6 bytes)
2023-12-18T09:54:07.284Z SERIAL » [ACK] (0x06)
2023-12-18T09:54:07.299Z DRIVER « [RES] [SendDataBridge]
was sent: true
2023-12-18T09:54:07.312Z SERIAL « 0x011d00a9b400000100a67f7f7f7f01010300000000020100007f7f7f7f7f27 (31 bytes)
2023-12-18T09:54:07.313Z SERIAL » [ACK] (0x06)
2023-12-18T09:54:07.315Z DRIVER « [REQ] [SendDataBridge]
callback id: 180
transmit status: OK, took 10 ms
routing attempts: 1
protocol & route speed: Z-Wave, 40 kbit/s
routing scheme: LWR
ACK RSSI: -90 dBm
ACK channel no.: 1
TX channel no.: 1
2023-12-18T09:54:07.324Z SERIAL « 0x011100a8000001005b0322020000a6007f7f99 (19 bytes)
2023-12-18T09:54:07.327Z DRIVER Dropping message because it could not be deserialized: The command class Appli
cation Status is not implemented (ZW0303)
2023-12-18T09:54:07.328Z SERIAL » [ACK] (0x06)
2023-12-18T09:54:08.378Z CNTRLR [Node 091] Timed out while waiting for a response from the node (ZW0201)
2023-12-15T12:34:13.312Z CNTRLR » [Node 091] querying parameter #256 value...
2023-12-15T12:34:13.371Z DRIVER Dropping message because it could not be deserialized: The command class Application Status is not implemented (ZW0303)
2023-12-15T12:34:14.413Z CNTRLR [Node 091] Timed out while waiting for a response from the node (ZW0201)
2023-12-15 13:34:14.427 ERROR APP: Unhandled Rejection, reason: TypeError: Cannot read properties of undefined (reading 'get')
TypeError: Cannot read properties of undefined (reading 'get')
at /opt/node_modules/@zwave-js/cc/src/cc/ConfigurationCC.ts:639:23
at Array.map (<anonymous>)
at Proxy.getBulk (/opt/node_modules/@zwave-js/cc/src/cc/ConfigurationCC.ts:638:18)
at Proxy.get (/opt/node_modules/@zwave-js/cc/src/cc/ConfigurationCC.ts:513:19)
at ConfigurationCC.refreshValues (/opt/node_modules/@zwave-js/cc/src/cc/ConfigurationCC.ts:1276:6)
at ConfigurationCC.interview (/opt/node_modules/@zwave-js/cc/src/cc/ConfigurationCC.ts:1191:3)
at interviewEndpoint (/opt/node_modules/zwave-js/src/lib/node/Node.ts:2159:5)
at ZWaveNode.interviewCCs (/opt/node_modules/zwave-js/src/lib/node/Node.ts:2688:19)
at ZWaveNode.interviewInternal (/opt/node_modules/zwave-js/src/lib/node/Node.ts:1818:9)
at Driver.interviewNodeInternal (/opt/node_modules/zwave-js/src/lib/driver/Driver.ts:1664:10)
Software versions
Driver (node-zwave-js): v12.3.0
Z-Wave JS UI: v9.3.2
Home Assistant Z-Wave Integration: WS Server
Home Assistant Z-Wave JS Addon: v3.0.2
ioBroker.zwave2 Adapter: Aeotec 700 Series v7.19.2
If you are using something non-standard, tell us here: ...
Device information
Manufacturer: Heatit
Model name: Z-Temp2
Node ID: 091 and 051
Checklist
-
[X] I made sure to provide a driver log on level debug.
-
[X] The log includes a re-interview of the problematic device (if applicable).
-
[ ] The log includes the problematic interaction with the device (if applicable).
-
[X] I provided the node ID of the problematic device (if applicable).
Upload Logfile
I have an ongoing discussion about this with Thermo floor, and they have finally involved their firmware developer to look into the underlying issue. I've seen packet captures from the interview process with firmware 1.2.1, where it's pretty obvious that the thermostat itself is responding in a weird way. See the following screenshots
Maybe @AlCalzone can comment on my suspicions, but to me it looks like it asks for Parameter 0001, and the parameter itself states that it is parameter 0100 instead.
That's correct. Like I stated here, the device responds with parameter 256 (0x0100) when asked for parameter 1 (0x0001).
I contacted them 2 weeks ago and I still haven't had any information on a new firmware.
- "we are aware of it and I've reported it to the developer."
- "I don't know how long it would take, it depends on what causes it to do this."
- "If I don't remember incorrectly, a customer in another ticket said HA were also working on a fix for it."
- "If I don't remember incorrectly, a customer in another ticket said HA were also working on a fix for it."
I've told them on multiple occasions that yes, Z-Wave JS should not crash when this happens, but the root cause for this issue is in their firmware and must be fixed, even if @AlCalzone implements a fix. Otherwise the device might not work with other "hubs" etc.
In the meantime, all the devices sold are bugged and it is not possible to downgrade... I thought it would be more responsive to a major bug....
This should be straightforward to reproduce - send the command and notice the wrong parameter no. encoding in the response. If Heatit have any questions, I'm happy to help if they reach out to me.
Got an update today from the support. We're working on it, but have no fix yet. - It sounds to me that they've acknowledged this to be an error on their side and working on fixing it.
Got an update today from the support.
We're working on it, but have no fix yet.- It sounds to me that they've acknowledged this to be an error on their side and working on fixing it.
They told me this 3 weeks ago hahaha
I've reached out to the certification team at the Z-Wave Alliance about this. Let's see if that speeds things up.
I've reached out to the certification team at the Z-Wave Alliance about this. Let's see if that speeds things up.
Thank you for your attention, because I have 2 devices purchased recently and they do not work and despite my reminders to Heat-it, their response does not satisfy me.... "Yes, the problem is simple, but the solution is not necessarily so." or “Unfortunately, Z-Wave does not let you update to a lower version number.”
Hello, any ETA on this? I have two devices that don't work with jeedom / zwavejs
Fix for Z-Wave JS will be in the next release. Haven't heard anything about Heatit though.
Like, that’s not going to push me to buy from them.
Plus, winter is over, the thermostat won't be as useful to me.
@ackjewtn could you share your Zniffer traces with the issue? The ones from your screenshot above?
Apparently the Z-Wave testing house can not (no longer?) reproduce the issue, so maybe there's a fix available, even if not publicly.
Absolutely. I've attached them here. The file contains two different inclusions and i don't remember which one the screenshot is from, but i think they both contain the issue.
I have not heard anything more from Heatit/Thermo floor regarding a new version either. Can the "Testing house" confirm which version they are testing?
Just upgraded to the latest version of the zwave-js-ui addon which includes the fix, and the inclusion now works fine again.
Thanks for the fix/workaround @AlCalzone
I think i jumped to a conclusion a bit too fast.
Seems like no update operations work now. Tried to change Thermostat mode from None => Heat
2024-04-22T11:42:48.810Z SERIAL » 0x011300a9015e076c01a503400101250000000019aa (21 bytes)
2024-04-22T11:42:48.812Z DRIVER » [Node 094] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 25
└─[SupervisionCCGet]
│ session id: 37
│ request updates: true
└─[ThermostatModeCCSet]
mode: Heat
2024-04-22T11:42:48.817Z SERIAL « [ACK] (0x06)
2024-04-22T11:42:48.819Z SERIAL « 0x010401a90152 (6 bytes)
2024-04-22T11:42:48.824Z SERIAL » [ACK] (0x06)
2024-04-22T11:42:48.827Z DRIVER « [RES] [SendDataBridge]
was sent: true
2024-04-22T11:42:50.076Z SERIAL « 0x011d00a91900007b00a67f7f7f7f01010300000000420100007f7f7f7f7fb0 (31 bytes)
2024-04-22T11:42:50.083Z SERIAL » [ACK] (0x06)
2024-04-22T11:42:50.090Z DRIVER « [REQ] [SendDataBridge]
callback id: 25
transmit status: OK, took 1230 ms
routing attempts: 1
protocol & route speed: Z-Wave, 40 kbit/s
routing scheme: LWR
ACK RSSI: -90 dBm
ACK channel no.: 1
TX channel no.: 1
beam: 1000 ms
2024-04-22T11:42:50.112Z SERIAL « 0x010e00a800015e056c0225020000a6ec (16 bytes)
2024-04-22T11:42:50.115Z SERIAL » [ACK] (0x06)
2024-04-22T11:42:50.117Z DRIVER « [Node 094] [REQ] [BridgeApplicationCommand]
│ RSSI: -90 dBm
└─[SupervisionCCReport]
session id: 37
more updates follow: false
status: Fail
duration: 0s
2024-04-22T11:42:50.119Z CNTRLR [Node 094] [setValue] result of SET_VALUE API call for ThermostatModeCCAPI: (S
upervisionResult)
status: Fail
2024-04-22T11:42:50.119Z CNTRLR [Node 094] [setValue] not updating value
2024-04-22T11:42:50.125Z DRIVER all queues idle
Guess I have them on my naughty list for good reason 🙄 I'll track that issue in https://github.com/zwave-js/node-zwave-js/issues/6780