Improve support for non-listening Portable Remote Controllers

[esszopo]

Hi, I have a Duwi Portable Remote Controller which I have registered to my main zwave controller as a slave. All that is fine the only problem is that ZwaveJS keeps expecting the device to communicate its ID and manufacturing ID so it can compute what the configuration settings are it can use to query the controller with. That will not ever happen the remote controller doesn't communicate with the main controller it's only registered so it's part of the network. If you need anything like logging please let me know. I did a re-include once and than ZwaveJS did a hiccup and used all the setting of the next entry in the configuration.

[robertsLando]

zwave-js doesn't support secondary controllers

[esszopo]

The only support I need is that zwave-js ignores slave/secondary controllers

[robertsLando]

Please make a driver log of a re-interview, loglevel debug and attach it here as a file (drag & drop into the text field).

[bluemantwo]

I also have a slave secondary controller. It is a PE953 remote control for the Intermatic PE653 pool controller. But that causes no issues or problems. The zw-js controller never communicates with it after that, which is just fine. It does result is a useless node being on my list of devices, but again no problems or issues with that.

What problems are created by zwave-js in this scenario?

[esszopo]

It's not directly a problem it's more of aesthetic problem in the online menu of zwavejs where all the devices are listed the entry with my slave controller keeps having this red balloon indicating it waiting for further communication with the device. It just irritates me it would be nice if it did it the openzwave way and lists it as "Portable Remote Controller" and no further queries. Further I think there something should be done about the hiccup.

[AlCalzone]

Please make a driver log of a re-interview, loglevel debug and attach it here as a file (drag & drop into the text field).

👆🏻👆🏻

[esszopo]

I've uploaded the logging, unfortunately the hiccup didn't occur, probably because the duwi remote was the last in the listing. I did try to exclude and include a device but it got the same NodeId so that didn't help. Next week I should get some new devices from China if you want I could do it again when they arrive.

trace.zip

[AlCalzone]

The "hiccup" you reference sounds like a purely UI issue, so please open an issue in https://github.com/zwave-js/zwave-js-ui if it happens again.

The inclusion part is handled here, and I might have to add some special handling for these kinds of controllers. The main issue is that the device joins the network, but immediately stops responding to any kinds of queries, including the return route assignment:

2023-02-13T10:06:25.209Z CNTRLR   finished adding node 34:
                                    basic device class:    Controller
                                    generic device class:  Remote Controller
                                    specific device class: Portable Remote Controller
                                    supported CCs: 
                                    · Manufacturer Specific (0x72)
                                    controlled CCs: 
                                    · Basic (0x20)
2023-02-13T10:06:25.212Z CNTRLR » [Node 034] Assigning SUC return route...
2023-02-13T10:06:25.248Z SERIAL » 0x01050051221099                                                     (7 bytes)
2023-02-13T10:06:25.250Z DRIVER » [Node 034] [REQ] [AssignSUCReturnRoute]
                                    payload: 0x2210
2023-02-13T10:06:25.283Z SERIAL « [ACK]                                                                   (0x06)
2023-02-13T10:06:25.291Z SERIAL « 0x0104015100ab                                                       (6 bytes)
2023-02-13T10:06:25.303Z SERIAL » [ACK]                                                                   (0x06)
2023-02-13T10:06:25.323Z DRIVER « [RES] [AssignSUCReturnRoute]
                                    was executed: false

The driver then tries to get more information about the node, which also fails:

2023-02-13T10:06:26.808Z DRIVER » [Node 034] [REQ] [RequestNodeInfo]
                                    payload: 0x22
2023-02-13T10:06:26.811Z CNTRLR » [Node 034] Assigning SUC return route...
2023-02-13T10:06:26.873Z SERIAL « [ACK]                                                                   (0x06)
2023-02-13T10:06:26.881Z SERIAL « 0x01040160019b                                                       (6 bytes)
2023-02-13T10:06:26.885Z SERIAL » [ACK]                                                                   (0x06)
2023-02-13T10:06:26.889Z DRIVER « [RES] [RequestNodeInfo]
                                    payload: 0x01
2023-02-13T10:06:26.954Z SERIAL « 0x0106004981000031                                                   (8 bytes)
2023-02-13T10:06:26.959Z SERIAL » [ACK]                                                                   (0x06)
2023-02-13T10:06:26.962Z DRIVER « [REQ] [ApplicationUpdateRequest]
                                    payload: 0x0000

because the node is assumed to be awake but actually isn't.

In theory, we should be able to query the supported Manufacturer Specific CC to be able to identify the device, but I'm not sure how that's supposed to work.

[esszopo]

This is what openzwave makes of my remote. How it computes the generic type I've no idea, next week when I get my new devices and zwavejs does a hiccup I'll open a ticket at the ui site.

[AlCalzone]

the generic type is known from the info shared during inclusion. It does look like OZW also doesn't finish interviewing the remote though: