HS-FLS100-G2 v1.0 not identified

[HoboPapa]

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?

NO, my problem is NOT within Home Assistant or the ZWave JS integration

Is your problem within ZWaveJS2MQTT?

NO, my problem is NOT within ZWaveJS2MQTT

Checklist

• [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.

Describe the bug

What causes the bug? Include v1.0 unit using the DSK QR code

What do you observe? I have two units: one is a v1.1 and the other is v1.0. The v1.1 unit is included properly and appears in the control panel with the proper deviceID: 0x000c-0x0201-0x000c. The v1.0 unit shows up in the control panel with an unknown device ID: "hexId": "0xXXXX-0xXXXX-0xXXXX",

What did you expect to happen? The v1.0 unit recognized with the proper device ID

Steps to reproduce the behavior:

1. settings->z-wavejs-> add device
2. enter q=QR coded scanned from the device
3. Restart HA
4. Both appear in the provisioned entity list
5. The v1.1 unit appears in the control panel with the correct deviceID
6. The v1.0 unit appears in the control panel as unknown
7. The switches and sensors work as expected for the v1.1 unit
8. The switches and sensors do not appear for the v1.0 unit

Device information

Manufacturer: HomeSeer Model name: HS-FLS100-G2 Node ID in your network: 93

How are you using node-zwave-js?

• [ ] zwavejs2mqtt Docker image (latest)
• [ ] zwavejs2mqtt Docker image (dev)
• [ ] zwavejs2mqtt Docker manually built (please specify branches)
• [ ] ioBroker.zwave2 adapter (please specify version)
• [X] HomeAssistant zwave_js integration (please specify version)
• [ ] pkg
• [ ] node-red-contrib-zwave-js (please specify version, double click node to find out)
• [ ] Manually built from GitHub (please specify branch)
• [ ] Other (please describe)

Which branches or versions?

version: node-zwave-js branch: zwavejs2mqtt branch: github haos_rpi4-64-8.5.img.xz running on an RPI4. My z-wave radio is the Aeotec Z-Stick Gen5+ Z-Wave JS 10.0.3

Did you change anything?

no

If yes, what did you change?

No response

Did this work before?

No, it never worked anywhere

If yes, where did it work?

No response

Attach Driver Logfile

zwave_js(2).log

[zwave-js-bot]

👋 Hey @HoboPapa!

It looks like you attached a logfile, but its filename doesn't look like it a driver log that came from Z-Wave JS. Please make sure you upload the correct one.

[HoboPapa]

zwavejs_2022-09-03.log

[AlCalzone]

Issue resolved or why did you close?

[HoboPapa]

Thank you for the prompt! I'm new to the git hub bug tracker. In my haste to add the proper log file I pushed the wrong send button! The issue is still open. :) I'm concerned that this last log will not be helpful because it shows a re-interview operation that completed successfully. The log shows some route failures during route discovery, but I did not see a sequence that reads the deviceID in this re-interview log. I fear that I may need to first exclude the device then capture the log through the include sequence. The exclude procedure requires that I have physical access to the node to press a button. There are three V1.0 units installed already and with all of the construction around the house they are difficult to get a ladder to. Of course, the v1.1 units have not been installed yet! They are working perfectly on my bench right now. Please have a look at the re-interview log to see it it is helpful. I may need to arrange to take one of the v1.0 units off the house and put it on the bench for easier access.

[AlCalzone]

Unfortunately the interview log is truncated. You need to keep the log window open at all times while performing the re-interview. Please try again (I only need the non-working one).

[AlCalzone]

Please re-test with v10.0.4. This version is included in: zwave_js addon: 0.1.70 or zwavejs2mqtt: 7.1.0

[HoboPapa]

v10.0.4 is installed and has been there since the first test on 9/3.

A major change has occurred to node 93 since I last reported. The control panel shows node 93 with the correct device ID and the switches and sensors how show up for it in the control panel and appear to function properly. Node 93 does not show up in the z-wave device list. settings->Devices & Services->Z-wave JS devices Not sure what happened to stimulate this result. There were lots of probes and actions but it was not recognized before I gave up on 9/3.

This unit is acting strangely since it was recognized. The flood light turns on and off momentarily in the evening. It is annoying so right now it is turned off with the control panel.

Nodes 94 and 88 are not recognized and are the same device type and version number. The behavior of these is the same as previously reported for node 93. No controls appear in the node display in control panel and switches for them in the device list are inoperative (grey). A single switch appears for Nodes 94 and 88 in the overview dashboard but these are grey too. (Node 93 does not appear in the dashboard)

The logs have been running since 9/3 and the entire set is in the attached zip file. I'm hoping that the recognition sequence for node 93 is present in the logs. The last action in the log for 9/8 is a re-interview sequence for node 94.

You may see in the logs that the Nodes 93, 94 & 88 are dead during the day. All three are attached to a z-wave wall switch with an automation to turn them on after dark. For the last test, I manually turned on the switch first and verified the device with a successful ping.

zwavejs2mqtt-store.zip

[AlCalzone]

There's no interview at all in any of these logs. Did you have filters configured for the logging? If so, remove them.

[HoboPapa]

I have not configured filters intentionally. How to I tell if any are active? I can see the interview progress in the debug window.

[AlCalzone]

How to I tell if any are active?

Check this: https://zwave-js.github.io/zwavejs2mqtt/#/troubleshooting/generating-logs?id=driver-logs There is a field "Log Nodes", this should ideally be empty.

The last action in the log for 9/8 is a re-interview sequence for node 94. I can see the interview progress in the debug window.

I didn't find the word "interview" in the log for 9/8 when I opened the log and searched for it. 🤷🏻

[HoboPapa]

Thank you for the information and patience. I've finally sorted out the logs and have captured the interview sequence in the log. zwavejs2mqtt_2022-09-17.log (My settings->general screen looks different than the user document link. It is now a devices value configuration list ... I think it changed after the last upgrade.) The log is confirming what we already know: 2022-09-17 15:48:26.945 INFO ZWAVE: Node 94 ready: Unknown manufacturer 0xXXXX - Unknown product 0xXXXX (0xXXXX)

I'm wondering if this is an equipment failure? However this thought is muted somewhat because Node 93 has magically started to work on its own. (Node 94 & 88 are the other v1.0 firmware devices and are both reporting unknown manufacturer.) Are the strings presented in the log "0xXXXX" what the equipment is returning or is it a log replacement pattern for unknown values?

I'm wondering if I should take this question to HomeSeer support but with the values that are returned from the equipment.

[AlCalzone]

You're looking at the wrong logfile. Note how my link goes to "Driver logs" not "Application logs".

[HoboPapa]

I'm now just getting back to home base and can work on this issue. I think I have the driver log. zwavejs_2022-09-28.log The log should capture the interview for node 94

[AlCalzone]

The driver thinks the node was included using S2 unauthenticated:

2022-09-29T01:56:23.419Z CNTRLR » [Node 094] Querying securely supported commands (S2_Unauthenticated)...

but the node responds with an empty list of commands

2022-09-29T01:56:30.276Z DRIVER « [Node 094] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 206
                                    └─[Security2CCCommandsSupportedReport]
                                        supportedCCs:

which means it was included with S2_Authenticated or S2_AccessControl.

Make sure you have those keys configured and if you do, re-interview the node again, this time enable the checkbox "reset security classes" in the re-interview dialog. This will cause the driver to query all S2 keys instead of just one.

If that also doesn't help, then exclude, factory reset to delete all keys on the device, then include again.

[zwave-js-assistant[bot]]

This issue has not seen any recent activity and was marked as "stale 💤". Closing for housekeeping purposes... 🧹

Feel free to reopen if the issue persists.

[HoboPapa]

I re-interviewed the faulty nodes and reset the security classes. Once complete the nodes are now recognized. Thank you for your help.

[HoboPapa]

Thank you again for your support on this issue. :) Considering the following comment in more detail:

The driver thinks the node was included using S2 unauthenticated

Is there a deeper trouble to investigate when a new device is added using a QR code?

All of the HS-FLS100-G2 devices were added using: settings->devices & services->z-wave js devices->+add device In each case, the QR code scanned from the device was entered. No other information was requested or entered. The script just added the device with the S2 unauthenticated result. Other than the "unrecognized manufacturer response" there was no indication that an invalid security class was automatically chosen.

Recovery required "reset security classes" from the control panel device interview advanced setting. The second pass appears to have selected the proper security class and the device is now properly recognized and operating normally.

Is there a problem with the initial add device function that somehow did not apply the correct security class as the device was added in the first place?

Additional information about the initial device add:

• Two devices with v1.1 firmware were properly recognized with their QR code on the first try and operate properly
• Three devices with v1.0 all failed with similar results described above requiring a reset security class action to recover.
• All devices now have a green check in the control panel security column. I did not record this status indication when the invalid S2 status was standing.

[AlCalzone]

Is there a problem with the initial add device function that somehow did not apply the correct security class as the device was added in the first place?

Can't tell without driver logs of the inclusion process.