Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HS-WX300 Switch/Dimmer Parameter 3 seems to not work correctly #4047

Closed
3 of 11 tasks
pdobrien3 opened this issue Jan 5, 2022 · 17 comments · Fixed by #6868
Closed
3 of 11 tasks

HS-WX300 Switch/Dimmer Parameter 3 seems to not work correctly #4047

pdobrien3 opened this issue Jan 5, 2022 · 17 comments · Fixed by #6868
Labels
config ⚙ Configuration issues or updates

Comments

@pdobrien3
Copy link

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

Describe the bug

What causes the bug?

Unknown

What do you observe?

Parameter 3, which controls the bottom LED operation, doesn't seem to work correctly. Here is what happens on my HS-WX300 that is setup as a switch

on when load is on
load is off == LED 1 is on
load is on == All 7 LEDs are on
on when load is off
load is off == All 7 LEDs are off
load is on == All 7 LEDs are on

What did you expect to happen?

on when load is on
load is off == LED 1 is off
load is on == LED 1 is on
on when load is off
load is off == LED 1 is on
load is on == LED 1 is off

Steps to reproduce the behavior:

  1. Go to config parameter 3 and set it to desired setting, make sure config parameter 13 is disabled and all LEDs are switched to off.
  2. Click on/off the switch either manually or remotely
  3. Look at LED 1

Device information

Manufacturer: Homeseer
Model name: HS-WX300
Node ID in your network: 120

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)
  • 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:

zwavejs2mqtt: 6.2.0
zwave-js: 8.9.1

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

2022-01-05 23:13:51.445 INFO ZWAVE-SERVER: ZwaveJS server listening on port 3000

@zwave-js-bot zwave-js-bot added this to Needs triage in Triage Jan 5, 2022
@AlCalzone
Copy link
Member

Honestly, this sounds like a firmware bug in the device. The driver only sets the parameter to a value and has no control over how the device behaves.
Its not even consistent in any way that we could say the description is inverted or something.

@AlCalzone AlCalzone added the cannot fix ❌ This is something out of our control - like invalid device behavior label Jan 6, 2022
@AlCalzone AlCalzone removed this from Needs triage in Triage Jan 6, 2022
@pdobrien3
Copy link
Author

I get your point. Although it would seem like if it was a firmware issue, there would be several issues found through a google search. The only thing I can find is two posts related to HAss. All that said, I have emailed HS Support although I don’t expect any resolution. They always blame it on HAss.

@AlCalzone
Copy link
Member

AlCalzone commented Jan 6, 2022

Don't give in to their excuses then.

The configuration CC is standardized and if you set a parameter with the correct value and size as stated in the manual, it simply cannot be the application's fault. That's not how Z-Wave works.

All the application does is tell the device to change a config parameter. It cannot control the LEDs (or anything really) on the device itself. The device firmware is in charge of the hardware.

They always blame it on HAss.

There's also the option to use Silabs' PC controller to set the param. That way they cannot blame it on HA 🤣

@pdobrien3
Copy link
Author

Thank you for your last comment. I used it in my communications with HS. I seem to have gotten some traction.

From Homeseer:

It looks like this is an error in documentation as parameter 3 explicitly says both that it will control the bottom LED and that it will control all of them. I will reach out to our engineers about this so we can get the doc updated and perhaps get a feature request in that allows for both options.

@zwave-js-assistant
Copy link

This issue has not seen any recent activity and was marked as "cannot fix ❌".
Closing for housekeeping purposes... 🧹

Feel free to reopen if the issue persists.

@pdobrien3
Copy link
Author

I gave homeseer support this link to report their findings.

@rrauenza
Copy link

rrauenza commented Apr 11, 2024

I'm confused because I don't understand how the integration works at the code level, but if the docs are wrong, can the logic not be just swapped in the code?

Also, latest docs say this - https://docs.homeseer.com/products/hs-wx300-r2-user-guide

Param 3:

0 = Bottom LED ON if load is OFF
1 = Bottom LED OFF if load is OFF

...is this still the wrong docs? Where in the codebase does this logic live? I don't mind doing a PR ... but my searching has failed me so far.

Oh - this is in zwavejs not hass core. I'll search this repo next.

@rrauenza
Copy link

rrauenza commented Apr 11, 2024

Looks like their docs are still wrong unless the code has already been fixed:

"led_indicator_two_options": {
		"label": "LED Indicator",
		"valueSize": 1,
		"defaultValue": 1,
		"allowManualEntry": false,
		"options": [
			{
				"label": "On when load is off",
				"value": 0
			},
			{
				"label": "On when load is on",
				"value": 1
			}
		]
	},

The English is expressed a little differently, but I think the logic matches their (presumably incorrect) docs.

@pdobrien3 Do you want to ping your contacts at HS and followup if they ever actually updated their docs?

Is this project opposed to reversing the logic against what the (presumably incorrect) docs say?

@AlCalzone
Copy link
Member

@rrauenza I'm fine updating our config files to match the actual device behavior.

@rrauenza
Copy link

Thanks ... there is a subtle language issue in the existing templates:

"led_indicator_two_options": {
                "label": "LED Indicator",
                "valueSize": 1,
                "defaultValue": 1,
                "allowManualEntry": false,
                "options": [
                        {
                                "label": "On when load is off",
                                "value": 0
                        },
                        {
                                "label": "On when load is on",
                                "value": 1
                        }
                ]
        },
        "led_indicator_two_options_inverted": {
                "label": "LED Indicator",
                "valueSize": 1,
                "defaultValue": 1,
                "allowManualEntry": false,
                "options": [
                        {
                                "label": "On when load is on",
                                "value": 0
                        },
                        {
                                "label": "On when load is off",
                                "value": 1
                        }
                ]
        },

Neither of these apply. The indicator is configurable to be either on or off when the load is off. This setting doesn't affect anything about the indicator and the load being on.

0 = Bottom LED ON if load is OFF
1 = Bottom LED OFF if load is OFF

I don't know if this subtle distinction is only for this particular device ... or if the template is subtly wrong for other devices as well.

I was going to proceed by just not referring to the template and fixing it locally in the wx300 json, unless you'd rather I just point to the inverted template.

@AlCalzone
Copy link
Member

This setting doesn't affect anything about the indicator and the load being on.

I see! Usually the LED indicator either follows the load state (on when on, off when off) or inverts it (on when off, off when on).
Maybe this was the assumption when the templates were written.

I don't know if this subtle distinction is only for this particular device ... or if the template is subtly wrong for other devices as well.

Actually let me reach out to my contact at HomeSeer - the situation has changed a bit since this issue was created. They should be able to clarify.

@AlCalzone AlCalzone reopened this Apr 12, 2024
@AlCalzone AlCalzone added investigate 🔎 Not sure what's going on here - need to investigate and removed cannot fix ❌ This is something out of our control - like invalid device behavior labels Apr 12, 2024
@AlCalzone
Copy link
Member

Response from HomeSeer:

parameter 3 is designed to control the state of the bottom LED when the load is OFF and the switch is in NORMAL mode. If the load is ON and the switch is in NORMAL mode, the bottom LED will always be ON. This is how the WD200 worked as well.

Seeing that the master_template is currently referenced, this HomeSeer specific parameter should probably go into their template file and get referenced from HS-WX300 and -WD200.

@AlCalzone AlCalzone added config ⚙ Configuration issues or updates and removed investigate 🔎 Not sure what's going on here - need to investigate labels Apr 15, 2024
@pdobrien3
Copy link
Author

After re-interviewing, device information is lost:

Unknown manufacturer 0xXXXX | 0xXXXX | Unknown product 0xXXXX

@AlCalzone
Copy link
Member

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

@pdobrien3
Copy link
Author

zwavejs_2024-06-06.log

@AlCalzone
Copy link
Member

This looks like a device bug. Here's the relevant log snippet with comments:

2024-06-06T09:35:26.470Z CNTRLR   [Node 176] [+] [Node Naming and Location] name: "Kitchen Light"
2024-06-06T09:35:26.470Z CNTRLR   [Node 176] Beginning interview - last completed stage: None
2024-06-06T09:35:26.470Z CNTRLR   [Node 176] new node, doing a full interview...
2024-06-06T09:35:26.471Z CNTRLR » [Node 176] querying protocol info...
2024-06-06T09:35:26.472Z DRIVER   all queues busy
2024-06-06T09:35:26.475Z SERIAL » 0x0105004100b00b                                                     (7 bytes)
2024-06-06T09:35:26.476Z DRIVER » [REQ] [GetNodeProtocolInfo]
                                    payload: 0x00b0
2024-06-06T09:35:26.479Z SERIAL « [ACK]                                                                   (0x06)
2024-06-06T09:35:26.481Z SERIAL « 0x010a0141d39c0104100100ee                                          (12 bytes)
2024-06-06T09:35:26.482Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:26.482Z DRIVER « [RES] [GetNodeProtocolInfo]
                                    payload: 0xd39c0104100100
2024-06-06T09:35:26.483Z CNTRLR « [Node 176] received response for protocol info:
                                  basic device class:    Routing Slave
                                  generic device class:  Binary Switch
                                  specific device class: Binary Power Switch
                                  node type:             End Node
                                  is always listening:   true
                                  is frequent listening: false
                                  can route messages:    true
                                  supports security:     false
                                  supports beaming:      true
                                  maximum data rate:     100000 kbps
                                  protocol version:      3
2024-06-06T09:35:26.484Z CNTRLR   [Node 176] Interview stage completed: ProtocolInfo
2024-06-06T09:35:26.484Z CNTRLR » [Node 176] querying node info...
2024-06-06T09:35:26.486Z SERIAL » 0x0105006000b02a                                                     (7 bytes)
2024-06-06T09:35:26.486Z DRIVER » [Node 176] [REQ] [RequestNodeInfo]
                                    node id: 176
2024-06-06T09:35:26.489Z SERIAL « [ACK]                                                                   (0x06)
2024-06-06T09:35:26.491Z SERIAL « 0x01040160019b                                                       (6 bytes)
2024-06-06T09:35:26.491Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:26.492Z DRIVER « [RES] [RequestNodeInfo]
                                    was sent: true
2024-06-06T09:35:26.518Z SERIAL « 0x010d00498400b0060410015e559f08                                    (15 bytes)
2024-06-06T09:35:26.518Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:26.519Z DRIVER « [Node 176] [REQ] [ApplicationUpdateRequest]
                                    payload: 0x00b0060410015e559f
2024-06-06T09:35:26.519Z CNTRLR « [Node 176] node info received
                                  supported CCs:
                                  · Z-Wave Plus Info
                                  · Transport Service
                                  · Security 2
2024-06-06T09:35:26.519Z CNTRLR « [Node 176] node info received
                                  supported CCs:
                                  · Z-Wave Plus Info
                                  · Transport Service
                                  · Security 2
2024-06-06T09:35:26.520Z CNTRLR   [Node 176] Interview stage completed: NodeInfo
2024-06-06T09:35:26.521Z CNTRLR » [Node 176] Querying securely supported commands (S2_Authenticated)...
2024-06-06T09:35:26.523Z SERIAL » 0x011100a9000100b0039f0197250000000037ee                            (19 bytes)
2024-06-06T09:35:26.523Z DRIVER » [Node 176] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ callback id:      55
                                  └─[Security2CCNonceGet]
                                      sequence number: 151
2024-06-06T09:35:26.528Z SERIAL « [ACK]                                                                   (0x06)
2024-06-06T09:35:26.530Z SERIAL « 0x010401a90152                                                       (6 bytes)
2024-06-06T09:35:26.530Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:26.530Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2024-06-06T09:35:26.547Z SERIAL « 0x011d00a93700000100ab7f7f7f7f00000300000000030100007f7f7f7f7fa8    (31 bytes)
2024-06-06T09:35:26.547Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:26.547Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            55
                                    transmit status:        OK, took 10 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 100 kbit/s
                                    routing scheme:         LWR
                                    ACK RSSI:               -85 dBm
                                    ACK channel no.:        0
                                    TX channel no.:         0
2024-06-06T09:35:26.562Z SERIAL « 0x012200a800000100b0149f024d01160cbe78b04d5d430270f5bd809dd30900ab0 (36 bytes)
                                  07f7f68
2024-06-06T09:35:26.562Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:26.563Z DRIVER « [Node 176] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -85 dBm
                                  └─[Security2CCNonceReport]
                                      sequence number:  77
                                      SOS:              true
                                      MOS:              false
                                      receiver entropy: 0x160cbe78b04d5d430270f5bd809dd309
2024-06-06T09:35:26.564Z SERIAL » 0x012e00a9000100b0209f0398011241d6764de87d5dc196ef028f14aac8c36fbe4 (48 bytes)
                                  1162c2ade545485832500000000385f
2024-06-06T09:35:26.565Z DRIVER » [Node 176] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ callback id:      56
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 152
                                    │ extensions:
                                    │ · type: SPAN
                                    │   sender EI: 0xd6764de87d5dc196ef028f14aac8c36f
                                    │ security class:  S2_Authenticated
                                    └─[Security2CCCommandsSupportedGet]
2024-06-06T09:35:26.572Z SERIAL « [ACK]                                                                   (0x06)
2024-06-06T09:35:26.574Z SERIAL « 0x010401a90152                                                       (6 bytes)
2024-06-06T09:35:26.574Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:26.574Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2024-06-06T09:35:26.594Z SERIAL « 0x011d00a93800000100ab7f7f7f7f00000300000000030100007f7f7f7f7fa7    (31 bytes)
2024-06-06T09:35:26.594Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:26.594Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            56
                                    transmit status:        OK, took 10 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 100 kbit/s
                                    routing scheme:         LWR
                                    ACK RSSI:               -85 dBm
                                    ACK channel no.:        0
                                    TX channel no.:         0
2024-06-06T09:35:26.632Z SERIAL « 0x012a00a800000100b01c9f034e0035b86a2c5686bba79723fe41a44cb5e61472d (44 bytes)
                                  dfb9a05d28800ab007f7f9b
2024-06-06T09:35:26.633Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:26.634Z DRIVER « [Node 176] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -85 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 78
                                    │ security class:  S2_Authenticated
                                    └─[Security2CCCommandsSupportedReport]
                                        supported CCs:
                                        · Version
                                        · Binary Switch
                                        · All Switch
                                        · Association
                                        · Association Group Information
                                        · Manufacturer Specific
                                        · Device Reset Locally
                                        · Powerlevel
                                        · Configuration
                                        · Central Scene
                                        · Scene Actuator Configuration
                                        · Scene Activation
                                        · Supervision
                                        · Firmware Update Meta Data
2024-06-06T09:35:26.634Z CNTRLR « [Node 176] received secure commands (S2_Authenticated)
                                  supported CCs:
                                  · Version
                                  · Binary Switch
                                  · All Switch
                                  · Association
                                  · Association Group Information
                                  · Manufacturer Specific
                                  · Device Reset Locally
                                  · Powerlevel
                                  · Configuration
                                  · Central Scene
                                  · Scene Actuator Configuration
                                  · Scene Activation
                                  · Supervision
                                  · Firmware Update Meta Data
2024-06-06T09:35:26.634Z CNTRLR   [Node 176] [+] [Security 2] interviewComplete: true    [Endpoint 0] [internal]

# The highest security class has been detected along with the supported commands, which includes Manufacturer Specific CC.
# The query for manufacturer ID etc. times out:

2024-06-06T09:35:26.635Z CNTRLR   [Node 176] Interviewing Manufacturer Specific...
2024-06-06T09:35:26.635Z CNTRLR » [Node 176] querying manufacturer information...
2024-06-06T09:35:26.637Z SERIAL » 0x011c00a9000100b00e9f039900ae378b74c82901503cb7250000000039b1      (30 bytes)
2024-06-06T09:35:26.637Z DRIVER » [Node 176] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ callback id:      57
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 153
                                    │ security class:  S2_Authenticated
                                    └─[ManufacturerSpecificCCGet]
2024-06-06T09:35:26.643Z SERIAL « [ACK]                                                                   (0x06)
2024-06-06T09:35:26.645Z SERIAL « 0x010401a90152                                                       (6 bytes)
2024-06-06T09:35:26.645Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:26.645Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2024-06-06T09:35:26.662Z SERIAL « 0x011d00a93900000100ab7f7f7f7f00000300000000030100007f7f7f7f7fa6    (31 bytes)
2024-06-06T09:35:26.662Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:26.662Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            57
                                    transmit status:        OK, took 10 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 100 kbit/s
                                    routing scheme:         LWR
                                    ACK RSSI:               -85 dBm
                                    ACK channel no.:        0
                                    TX channel no.:         0
2024-06-06T09:35:27.689Z CNTRLR   [Node 176] Timed out while waiting for a response from the node (ZW0201)
2024-06-06T09:35:27.690Z CNTRLR   [Node 176] [+] [Manufacturer Specific] interviewComple [Endpoint 0] [internal]
                                  te: true

# but the next command is answered without S2 synchronization, which means the device understood the previous query and never answered. There's also no other timeout, so the communication is stable.

2024-06-06T09:35:27.691Z CNTRLR   [Node 176] Interviewing Version...
2024-06-06T09:35:27.691Z CNTRLR » [Node 176]   querying the CC version for Version...
2024-06-06T09:35:27.693Z SERIAL » 0x011d00a9000100b00f9f039a00e6f7dcb4db6a5badfa765e25000000003a00    (31 bytes)
2024-06-06T09:35:27.694Z DRIVER » [Node 176] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ callback id:      58
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 154
                                    │ security class:  S2_Authenticated
                                    └─[VersionCCCommandClassGet]
                                        CC: Version
2024-06-06T09:35:27.699Z SERIAL « [ACK]                                                                   (0x06)
2024-06-06T09:35:27.701Z SERIAL « 0x010401a90152                                                       (6 bytes)
2024-06-06T09:35:27.701Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:27.702Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2024-06-06T09:35:27.734Z SERIAL « 0x011d00a93a00000300aa7f7f7f7f00000300000000030100007f7f7f7f7fa6    (31 bytes)
2024-06-06T09:35:27.734Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:27.734Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            58
                                    transmit status:        OK, took 30 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 100 kbit/s
                                    routing scheme:         LWR
                                    ACK RSSI:               -86 dBm
                                    ACK channel no.:        0
                                    TX channel no.:         0
2024-06-06T09:35:27.744Z SERIAL « 0x011e00a800000100b0109f034f00d3c02dd33f50a0c4936615a400ab007f7f32  (32 bytes)
2024-06-06T09:35:27.745Z SERIAL » [ACK]                                                                   (0x06)
2024-06-06T09:35:27.746Z DRIVER « [Node 176] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -85 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 79
                                    │ security class:  S2_Authenticated
                                    └─[VersionCCCommandClassReport]
                                        CC:      Version
                                        version: 2
2024-06-06T09:35:27.746Z CNTRLR   [Node 176]   supports CC Version (0x86) in version 2

You can try excluding, factory resetting and including the device again to see if that fixes it. If not, this is a case for HomeSeer's support - they may want to see that log snippet.

@pdobrien3
Copy link
Author

exclusion, factory reset, and inclusion fixed the issue. Thanks !!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
config ⚙ Configuration issues or updates
Projects
None yet
3 participants