[bug] Unable to properly include Thermofloor Z-TRM2FX thermostats

[jkaberg]

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: develop (1.0.0-alpha.2)

Describe the bug
Unable to properly include Thermofloor Z-TRM2FX thermostats using the normal inclusion method.

This happends to all my Z-TRM2FX thermostats (I have 6). All these included fine on OZW. Somehow one odd Thermostat actully got included after many heals/refresh info and container restarts. Couldnt reproduce this on the following 5.

Except for node 45 in the picture below, the other thermostats where added many hours ago and should have completed thire interviews. It seems they hang on interview stage NodeInfo or ProtocolInfo.

To Reproduce
Steps to reproduce the behavior:

1. Actions -> Start inclusion [RUN]
2. Vise versa on thermostat

Expected behavior
The thermostat properly included with zwavejs2mqtt.

Additional context

Picture (taken after the logs below - notice node 45):

Logs (first excluding the thermostat, as to then include it again - alas Node 44 and 45 is that same unit):
Better logs posted below

I tried both debug and silly log levels (from the UI), but I only got info? ^

[jkaberg]

Sorry if I posted this wrong, perhaps this should go into https://github.com/zwave-js/node-zwave-js ?

[jkaberg]

@AlCalzone Heres an log dump with me including one of the Thermostat, had a quick look at the other logs over at #1128 and it seems to be the same?

debug.log

[jkaberg]

@AlCalzone I could try to fix this myself, albeit I'm unsure how. I see from the other thread that you mention adding an combat entry to the device config. Is there any documentation (I couldn't find any) that I can take a look at?

[AlCalzone]

The docs won't tell you how to implement a compat option. If you want to dive in, this PR should help you figure out how it is done:
#1278

If the new option is true, the following query should not be executed:

node-zwave-js/packages/zwave-js/src/lib/commandclass/ConfigurationCC.ts

Lines 581 to 583 in aaa0d82

	await ignoreTimeout(async () => {
	await api.getInfo(param);
	});

[jkaberg]

@AlCalzone alright! But wouldnt whatever the interview is doing at this point (collecting information?) be dropped by this? Is the information not needed?

I'll look into it during the weekend

[AlCalzone]

getInfo just returns the device-defined description of the parameter (if the device supports that), so it is not critical

[jkaberg]

@AlCalzone Ok, so I gave it a shot. Seems I end up with the same failure after adding compat?

Did restart the container inbetween editing the config file for changes to take effect (I did confirm after restart that the changes were still there before inclusion)

Attaching logs and config file
z-trm2fx_3.0.json.txt
debug2.log

Any suggestions?

[jkaberg]

And a quick question while trying to understand the logs:

06:42:47.745 SERIAL » 0x011d0013301698813512ff7d3204fac64ebc3ef34b6793ae65550f91254f8b    (31 bytes)
06:42:47.745 DRIVER » [Node 048] [REQ] [SendData]
                      │ transmit options: 0x25
                      │ callback id:      79
                      └─[SecurityCCCommandEncapsulation]
                        │ nonce id: 243
                        └─[SecurityCCCommandsSupportedGet]
06:42:47.747 SERIAL « [ACK]                                                                   (0x06)
06:42:47.754 SERIAL « 0x0104011301e8                                                       (6 bytes)
06:42:47.754 SERIAL » [ACK]                                                                   (0x06)
06:42:47.754 DRIVER « [RES] [SendData]
                        was sent: true
06:42:48.015 SERIAL « 0x010700134f00001bbf                                                 (9 bytes)
06:42:48.015 SERIAL » [ACK]                                                                   (0x06)
06:42:48.015 DRIVER « [REQ] [SendData]
                        callback id:     79
                        transmit status: OK
06:42:49.617 CNTRLR   [Node 048] did not respond after 1/3 attempts. Scheduling next try in 500 ms.

So the did not respond after 1/3... message, is it refering to the last command, eg in this case to:

                      │ transmit options: 0x25
                      │ callback id:      79
                      └─[SecurityCCCommandEncapsulation]
                        │ nonce id: 243
                        └─[SecurityCCCommandsSupportedGet]

? If thats the case, how do we drop/compat SecurityCCCommandEncapsulation and/or SecurityCCCommandsSupportedGet?

[AlCalzone]

Regarding the security stuff - that's just the driver figuring out that the device is not securely included.

It seems like your device does not have a problem with the getInfo yet, because the api.getProperties(0); to find the first parameter is also failing. Maybe the compat option should instead disable the V3 interview entirely and choose the branch if (this.version < 3) {

[jkaberg]

@AlCalzone I think you might be right, looking over the OpenZwave config file only V2 is mentioned

I guess such feature/workaround isnt implemeneted yet, atleast I didn't see anything in the docs about it (?)

[AlCalzone]

@jkaberg One thing I just found in your log:

06:42:58.254 CONFIG   Error loading device config /usr/src/app/node_modules/@zwave-js/config/config/
                      devices/0x019b/z-trm2fx_3.0.json

I'm not sure what causes this. Just keep an eye out for this when testing the PR