Homeseer 300 Dimmers Broke with JS Upgrade?

ts1234 · May 11, 2025, 4:30pm

While the "button" on the left say ON...the "Current State"

Says OFF. From what I can tell this is actually the state the system thinks it's in.

bertabcd1234 · May 11, 2025, 4:49pm

"Current States" is what really matters. I wouldn't pay much attention to the top left in your screenshot; that's just the UI trying to be helpful in making a command you're likely to want to send easier to do (and something that should be fixed if it's a consistent problem, but not unlikely to be one related to the driver or Z-Wave JS or not). I'd start by making sure that the device is actually reporting like it's supposed to, which is what I'm seeing and which I thought was the original claim.

ts1234 · May 11, 2025, 5:38pm

Part of the confusion is certainly my fault. I'm not taking the screenshots on the same devices. They are all acting up. I have all versions of HS switches. Somewhere I have some of the R1 300's...not sure if they are different ID's.

The bothersome thing here isn't related to the current problem (probably) but the device type for my 300 is identical to the oldest switch I have...see below.

Bath 300
Device Id
16438
Device Type
17479
Firmware Version
2.02
Hardware Version
2

Ceiling HS-WD-200+
Device Id
12342
Device Type
17479
Firmware Version
5.14
Hardware Version
1

HS-100+ Couch
Device Id
16438
Device Type
17479
Firmware Version
1.13
Hardware Version
1

I changed nothing originally. Not until the issues started.

ts1234 · May 12, 2025, 1:59pm

These are my 300's.

None of them update state status. Nothing I can find is configured wrong...other than the text field that often shows 300's even on the 200's since the JS update.

I'd buy you a 300 to test with...but they are out and supposedly coming out with a new model later this year. No matter how this turns out,,,thanks for writing this since Hubitat drivers don't expose everything they are capable of and those are the features that make these worth buying.

bertabcd1234 · May 12, 2025, 2:36pm

It's still not clear to me if the "status" you mean is just a possible UI glitch with that "Switch" box in commands or the actual "Current State" of the device, which is again the only thing that matters:

The "Events" tab here is really the authoritative source, but unless something in your browser is broken, "Current States" normally updates in real-time, too, so it's normally just as good if you're watching -- but it might be good to check.

If the "Current State" value (again all that matters for now) is not updating in response to digital (commands from this page) or physical (from the paddle) manipulation, enabling debug logging and providing the output of Logs when you do these things would be helpful to see. Make sure you are using my driver (it is apparent from your screenshot that some other driver was in use at at least some point, as mine does not use one of those state variables).

If you continue to have problems, please re-visit the suggestions above.

FWIW, I do have a HS WX-300. I am on firmware 1.13. I don't have an R2 model but don't think there were any significant changes between the two besides the chip upgrade. I see there is a new firmware version only for the new version, though nothing there looks like it should change anything that matters (e.g., Z-Wave command classes used) here either. But I don't know what specific hardware or firmware the problematic devices of yours are on, either.

ts1234 · May 12, 2025, 7:19pm

You helped me narrow this down...I think. I have an R1. It works perfectly as the state updates.

ANY any of my R2's weirdly turn on and off in the real world...never update state...and the weird part.

EVEN WHILE THE BULB TURNS ON AND OFF THERE ARE ZERO LOG ENTRIES.

This is an R2 Issue only. Thanks for pointing out your test switch was a R1.

bertabcd1234 · May 12, 2025, 7:46pm

I'm assuming debug logging was on when you did this? And does the stock driver show anything different?

Settings > Z-Wave Details > Z-Wave Logs would be another place you can check (if you're using Z-Wave JS, as you are; it's not very informative otherwise), ideally looking for just entries that say something about your (hex) node ID while you believe a report should be coming in. Otherwise, staff may need to turn up Z-Wave logging on your hub to see if they can figure anything out. I don't have an R2, and it looks like they're sold out everywhere (with likely no plans to replace them?), so I probably won't be much help.

ts1234 · May 12, 2025, 8:55pm

There will not be new ones until fall...the last new one I found was on eBay.

i can't believe how much time you out into this...THANKS! I have to step away now for today. The Hubitat driver logged.

I captured two files from zwave logs. I'm definitely clueless there,,,but will peek at them to see if I can "glean" something ..one with each driver. Hmmm...not sure how to upload a text file.

2025-05-12 02:42:17.972 PM|DRIVER « [Node 204] [REQ] [BridgeApplicationCommand] - │ RSSI: -86 dBm - └─[MultilevelSensorCCReport] - sensor type: Illuminance - scale: Lux - value: 1380
2025-05-12 02:42:17.970 PM|CNTRLR [Node 204] [~] [Multilevel Sensor] Illuminance: 1431 => 1380 [Endpoint 0]
2025-05-12 02:42:17.967 PM|CNTRLR [Node 204] [Multilevel Sensor] Illuminance: metadata updated [Endpoint 0]
2025-05-12 02:42:17.964 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:17.962 PM|SERIAL « 0x011400a800000100cc063105030a056400aa007f7f7e (22 bytes)
2025-05-12 02:42:13.128 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -81 dBm - └─[SupervisionCCReport] - session id: 11 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:13.126 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:13.124 PM|SERIAL « 0x011300a800000100e1056c020bff0000af007f7f94 (21 bytes)
2025-05-12 02:42:13.119 PM|DRIVER all queues idle
2025-05-12 02:42:13.113 PM|SERIAL « 0x011d00a92100000100ac7f7f7f7f01010300000000020100007f7f7f7f7fb8 (31 bytes)
2025-05-12 02:42:13.116 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -85 dBm - └─[SupervisionCCReport] - session id: 11 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:13.114 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:13.113 PM|SERIAL « 0x011300a800000100e1056c020bff0000ab007f7f90 (21 bytes)
2025-05-12 02:42:13.080 PM|DRIVER « [RES] [SendDataBridge] - was sent: true
2025-05-12 02:42:13.079 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:13.077 PM|SERIAL « 0x010401a90152 (6 bytes)
2025-05-12 02:42:13.074 PM|SERIAL « [ACK] (0x06)
2025-05-12 02:42:13.069 PM|DRIVER » [Node 225] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 33 - └─[SupervisionCCGet] - │ session id: 11 - │ request updates: true - └─[BasicCCSet] - target value: 255
2025-05-12 02:42:12.968 PM|CNTRLR Failed to execute controller command after 1/3 attempts. Scheduling next try i - n 100 ms.
2025-05-12 02:42:12.966 PM|SERIAL « [CAN] (0x18)
2025-05-12 02:42:12.964 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -83 dBm - └─[SupervisionCCReport] - session id: 10 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:12.962 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:12.960 PM|SERIAL « 0x011300a800000100e1056c020aff0000ad007f7f97 (21 bytes)
2025-05-12 02:42:12.958 PM|DRIVER » [Node 225] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 33 - └─[SupervisionCCGet] - │ session id: 11 - │ request updates: true - └─[BasicCCSet] - target value: 255
2025-05-12 02:42:12.957 PM|SERIAL » 0x011500a9000100e1076c018b032001ff2500000000219b (23 bytes)
2025-05-12 02:42:12.953 PM|DRIVER one or more queues busy
2025-05-12 02:42:12.947 PM|DRIVER all queues idle
2025-05-12 02:42:12.944 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -83 dBm - └─[SupervisionCCReport] - session id: 10 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:12.940 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:12.939 PM|SERIAL « 0x011300a800000100e1056c020aff0000ad007f7f97 (21 bytes)
2025-05-12 02:42:12.923 PM|DRIVER « [REQ] [SendDataBridge] - callback id: 32 - transmit status: OK, took 10 ms - routing attempts: 1 - protocol & route speed: Z-Wave, 40 kbit/s - routing scheme: LWR - ACK RSSI: -81 dBm - ACK channel no.: 1 - TX channel no.: 1
2025-05-12 02:42:12.921 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:12.920 PM|SERIAL « 0x011d00a92000000100af7f7f7f7f01010300000000020100007f7f7f7f7fba (31 bytes)
2025-05-12 02:42:12.909 PM|DRIVER « [RES] [SendDataBridge] - was sent: true
2025-05-12 02:42:12.907 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:12.905 PM|SERIAL « 0x010401a90152 (6 bytes)
2025-05-12 02:42:12.900 PM|DRIVER » [Node 225] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 32 - └─[SupervisionCCGet] - │ session id: 10 - │ request updates: true - └─[BasicCCSet] - target value: 255
2025-05-12 02:42:12.897 PM|SERIAL » 0x011500a9000100e1076c018a032001ff2500000000209b (23 bytes)
2025-05-12 02:42:12.893 PM|DRIVER one or more queues busy
2025-05-12 02:42:12.359 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -81 dBm - └─[SupervisionCCReport] - session id: 9 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:12.358 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:12.356 PM|SERIAL « 0x011300a800000100e1056c0209ff0000af007f7f96 (21 bytes)
2025-05-12 02:42:12.353 PM|DRIVER all queues idle
2025-05-12 02:42:12.350 PM|CNTRLR [Node 225] [~] [Basic] currentValue: 0 => 0 [Endpoint 0]
2025-05-12 02:42:12.347 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -84 dBm - └─[SupervisionCCReport] - session id: 9 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:12.345 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:12.344 PM|SERIAL « 0x011300a800000100e1056c0209ff0000ac007f7f95 (21 bytes)
2025-05-12 02:42:12.329 PM|DRIVER « [REQ] [SendDataBridge] - callback id: 31 - transmit status: OK, took 10 ms - routing attempts: 1 - protocol & route speed: Z-Wave, 40 kbit/s - routing scheme: LWR - ACK RSSI: -83 dBm - ACK channel no.: 1 - TX channel no.: 1
2025-05-12 02:42:12.327 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:12.325 PM|SERIAL « 0x011d00a91f00000100ad7f7f7f7f01010300000000020100007f7f7f7f7f87 (31 bytes)
2025-05-12 02:42:12.310 PM|DRIVER « [RES] [SendDataBridge] - was sent: true
2025-05-12 02:42:12.308 PM|SERIAL « 0x010401a90152 (6 bytes)
2025-05-12 02:42:12.305 PM|SERIAL « [ACK] (0x06)
2025-05-12 02:42:12.300 PM|DRIVER » [Node 225] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 31 - └─[SupervisionCCGet] - │ session id: 9 - │ request updates: true - └─[BasicCCSet] - target value: 0
2025-05-12 02:42:12.199 PM|CNTRLR Failed to execute controller command after 1/3 attempts. Scheduling next try i - n 100 ms.
2025-05-12 02:42:12.197 PM|SERIAL « [CAN] (0x18)
2025-05-12 02:42:12.195 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -83 dBm - └─[SupervisionCCReport] - session id: 8 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:12.194 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:12.192 PM|SERIAL « 0x011300a800000100e1056c0208ff0000ad007f7f95 (21 bytes)
2025-05-12 02:42:12.186 PM|DRIVER » [Node 225] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 31 - └─[SupervisionCCGet] - │ session id: 9 - │ request updates: true - └─[BasicCCSet] - target value: 0
2025-05-12 02:42:12.184 PM|SERIAL » 0x011500a9000100e1076c01890320010025000000001f58 (23 bytes)
2025-05-12 02:42:12.181 PM|DRIVER one or more queues busy
2025-05-12 02:42:12.175 PM|CNTRLR [Node 225] Scheduled poll canceled because expected value was received
2025-05-12 02:42:12.172 PM|CNTRLR [Node 225] [~] [Basic] currentValue: 0 => 0 [Endpoint 0]
2025-05-12 02:42:12.169 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -81 dBm - └─[SupervisionCCReport] - session id: 8 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:12.167 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:12.165 PM|SERIAL « 0x011300a800000100e1056c0208ff0000af007f7f97 (21 bytes)
2025-05-12 02:42:12.150 PM|DRIVER « [REQ] [SendDataBridge] - callback id: 30 - transmit status: OK, took 10 ms - routing attempts: 1 - protocol & route speed: Z-Wave, 40 kbit/s - routing scheme: LWR - ACK RSSI: -84 dBm - ACK channel no.: 1 - TX channel no.: 1
2025-05-12 02:42:12.147 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:12.146 PM|SERIAL « 0x011d00a91e00000100ac7f7f7f7f01010300000000020100007f7f7f7f7f87 (31 bytes)
2025-05-12 02:42:12.134 PM|DRIVER « [RES] [SendDataBridge] - was sent: true
2025-05-12 02:42:12.132 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:12.131 PM|SERIAL « 0x010401a90152 (6 bytes)
2025-05-12 02:42:12.128 PM|SERIAL « [ACK] (0x06)
2025-05-12 02:42:12.126 PM|DRIVER » [Node 225] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 30 - └─[SupervisionCCGet] - │ session id: 8 - │ request updates: true - └─[BasicCCSet] - target value: 0
2025-05-12 02:42:12.122 PM|SERIAL » 0x011500a9000100e1076c01880320010025000000001e58 (23 bytes)
2025-05-12 02:42:12.118 PM|DRIVER one or more queues busy
2025-05-12 02:42:11.711 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -84 dBm - └─[SupervisionCCReport] - session id: 7 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:11.709 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:11.708 PM|SERIAL « 0x011300a800000100e1056c0207ff0000ac007f7f9b (21 bytes)
2025-05-12 02:42:11.702 PM|DRIVER all queues idle
2025-05-12 02:42:11.698 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:11.696 PM|SERIAL « 0x011300a800000100e1056c0207ff0000ac007f7f9b (21 bytes)
2025-05-12 02:42:11.681 PM|DRIVER « [REQ] [SendDataBridge] - callback id: 29 - transmit status: OK, took 10 ms - routing attempts: 1 - protocol & route speed: Z-Wave, 40 kbit/s - routing scheme: LWR - ACK RSSI: -84 dBm - ACK channel no.: 1 - TX channel no.: 1
2025-05-12 02:42:11.678 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:11.676 PM|SERIAL « 0x011d00a91d00000100ac7f7f7f7f01010300000000020100007f7f7f7f7f84 (31 bytes)
2025-05-12 02:42:11.661 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:11.659 PM|SERIAL « 0x010401a90152 (6 bytes)
2025-05-12 02:42:11.656 PM|SERIAL « [ACK] (0x06)
2025-05-12 02:42:11.653 PM|SERIAL » 0x011500a9000100e1076c0187032001ff25000000001dab (23 bytes)
2025-05-12 02:42:11.651 PM|DRIVER » [Node 225] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 29 - └─[SupervisionCCGet] - │ session id: 7 - │ request updates: true - └─[BasicCCSet] - target value: 255
2025-05-12 02:42:11.549 PM|CNTRLR Failed to execute controller command after 1/3 attempts. Scheduling next try i - n 100 ms.
2025-05-12 02:42:11.546 PM|SERIAL « [CAN] (0x18)
2025-05-12 02:42:11.544 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -81 dBm - └─[SupervisionCCReport] - session id: 6 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:11.540 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:11.539 PM|SERIAL « 0x011300a800000100e1056c0206ff0000af007f7f99 (21 bytes)
2025-05-12 02:42:11.537 PM|DRIVER » [Node 225] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 29 - └─[SupervisionCCGet] - │ session id: 7 - │ request updates: true - └─[BasicCCSet] - target value: 255
2025-05-12 02:42:11.534 PM|SERIAL » 0x011500a9000100e1076c0187032001ff25000000001dab (23 bytes)
2025-05-12 02:42:11.531 PM|DRIVER one or more queues busy
2025-05-12 02:42:11.525 PM|DRIVER all queues idle
2025-05-12 02:42:11.523 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -83 dBm - └─[SupervisionCCReport] - session id: 6 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:11.521 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:11.519 PM|SERIAL « 0x011300a800000100e1056c0206ff0000ad007f7f9b (21 bytes)
2025-05-12 02:42:11.505 PM|DRIVER « [REQ] [SendDataBridge] - callback id: 28 - transmit status: OK, took 10 ms - routing attempts: 1 - protocol & route speed: Z-Wave, 40 kbit/s - routing scheme: LWR - ACK RSSI: -81 dBm - ACK channel no.: 1 - TX channel no.: 1
2025-05-12 02:42:11.502 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:11.499 PM|SERIAL « 0x011d00a91c00000100af7f7f7f7f01010300000000020100007f7f7f7f7f86 (31 bytes)
2025-05-12 02:42:11.496 PM|DRIVER « [RES] [SendDataBridge] - was sent: true
2025-05-12 02:42:11.485 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:11.483 PM|SERIAL « 0x010401a90152 (6 bytes)
2025-05-12 02:42:11.482 PM|SERIAL « [ACK] (0x06)
2025-05-12 02:42:11.477 PM|DRIVER » [Node 225] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 28 - └─[SupervisionCCGet] - │ session id: 6 - │ request updates: true - └─[BasicCCSet] - target value: 255
2025-05-12 02:42:11.476 PM|SERIAL » 0x011500a9000100e1076c0186032001ff25000000001cab (23 bytes)
2025-05-12 02:42:11.472 PM|DRIVER one or more queues busy
2025-05-12 02:42:10.817 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -81 dBm - └─[SupervisionCCReport] - session id: 5 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:10.816 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:10.814 PM|SERIAL « 0x011300a800000100e1056c0205ff0000af007f7f9a (21 bytes)
2025-05-12 02:42:10.810 PM|DRIVER all queues idle
2025-05-12 02:42:10.807 PM|CNTRLR [Node 225] [~] [Basic] currentValue: 0 => 0 [Endpoint 0]
2025-05-12 02:42:10.805 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -81 dBm - └─[SupervisionCCReport] - session id: 5 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:10.804 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:10.801 PM|SERIAL « 0x011300a800000100e1056c0205ff0000af007f7f9a (21 bytes)
2025-05-12 02:42:10.787 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:10.786 PM|SERIAL « 0x011d00a91b00000100af7f7f7f7f01010300000000020100007f7f7f7f7f81 (31 bytes)
2025-05-12 02:42:10.770 PM|DRIVER « [RES] [SendDataBridge] - was sent: true
2025-05-12 02:42:10.768 PM|SERIAL « 0x010401a90152 (6 bytes)
2025-05-12 02:42:10.765 PM|SERIAL « [ACK] (0x06)
2025-05-12 02:42:10.763 PM|DRIVER » [Node 225] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 27 - └─[SupervisionCCGet] - │ session id: 5 - │ request updates: true - └─[BasicCCSet] - target value: 0
2025-05-12 02:42:10.761 PM|SERIAL » 0x011500a9000100e1076c01850320010025000000001b50 (23 bytes)
2025-05-12 02:42:10.758 PM|DRIVER one or more queues busy
2025-05-12 02:42:10.752 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -85 dBm - └─[SupervisionCCReport] - session id: 4 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:10.750 PM|SERIAL « 0x011300a800000100e1056c0204ff0000ab007f7f9f (21 bytes)
2025-05-12 02:42:10.748 PM|DRIVER all queues idle
2025-05-12 02:42:10.739 PM|CNTRLR [Node 225] [~] [Basic] currentValue: 0 => 0 [Endpoint 0]
2025-05-12 02:42:10.737 PM|DRIVER « [Node 225] [REQ] [BridgeApplicationCommand] - │ RSSI: -83 dBm - └─[SupervisionCCReport] - session id: 4 - more updates follow: false - status: Success - duration: 0s
2025-05-12 02:42:10.733 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:10.730 PM|SERIAL « 0x011300a800000100e1056c0204ff0000ad007f7f99 (21 bytes)
2025-05-12 02:42:10.716 PM|DRIVER « [REQ] [SendDataBridge] - callback id: 26 - transmit status: OK, took 10 ms - routing attempts: 1 - protocol & route speed: Z-Wave, 40 kbit/s - routing scheme: LWR - ACK RSSI: -84 dBm - ACK channel no.: 1 - TX channel no.: 1
2025-05-12 02:42:10.713 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:10.712 PM|SERIAL « 0x011d00a91a00000100ac7f7f7f7f01010300000000020100007f7f7f7f7f83 (31 bytes)
2025-05-12 02:42:10.700 PM|DRIVER « [RES] [SendDataBridge] - was sent: true
2025-05-12 02:42:10.699 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:10.697 PM|SERIAL « 0x010401a90152 (6 bytes)
2025-05-12 02:42:10.694 PM|SERIAL « [ACK] (0x06)
2025-05-12 02:42:10.690 PM|DRIVER » [Node 225] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 26 - └─[SupervisionCCGet] - │ session id: 4 - │ request updates: true - └─[BasicCCSet] - target value: 0
2025-05-12 02:42:10.689 PM|SERIAL » 0x011500a9000100e1076c01840320010025000000001a50 (23 bytes)
2025-05-12 02:42:10.687 PM|DRIVER one or more queues busy
2025-05-12 02:42:09.051 PM|DRIVER all queues idle
2025-05-12 02:42:09.048 PM|DRIVER « [RES] [GetBackgroundRSSI] - channel 0: -101 dBm - channel 1: -103 dBm - channel 2: -103 dBm - channel 3: -97 dBm
2025-05-12 02:42:09.046 PM|SERIAL » [ACK] (0x06)
2025-05-12 02:42:09.044 PM|SERIAL « 0x0107013b9b99999fc6 (9 bytes)
2025-05-12 02:42:09.042 PM|SERIAL « [ACK] (0x06)
2025-05-12 02:42:09.039 PM|DRIVER » [REQ] [GetBackgroundRSSI]
2025-05-12 02:42:09.037 PM|SERIAL » 0x0103003bc7 (5 bytes)
2025-05-12 02:42:09.032 PM|DRIVER one or more queues busy

ts1234 · May 13, 2025, 3:34pm

i assume this normal...any idea?

bertabcd1234 · May 13, 2025, 3:53pm

I don't think that's a problem, or at least I see it all the time in mine and assume it's normal.

Not sure about your other logs. They are fairly hard to read. Do any entries note one of the problematic node IDs? (In decimal; I remembered this wrong above...) Search in your browser may be helpful. Ideally, you'd see something here for that device when you don't in debug logs (keep in mind they may need to be re-enabled for the device) when you do one of the problematic actions and can have logs from just that short time.

ts1234 · May 15, 2025, 3:02pm

I converted back to the old non-JS zwave.

They all work again. It's definitely a JS issue. Thanks for the help. I REALLY hope you continue this support when the next version comes out, THANKS!!!

bertabcd1234 · May 15, 2025, 3:19pm

@bcopeland has a few devices he's looking at where this is happening -- tagging him here to add to "the list." Weird that the older model doesn't do it, though, since they didn't document any other changes...

If you haven't tried the other ideas, like the re-interview (harmless and easy) or re-inclusion (a bit harder but not that difficult -- I think the easiest thing for Z-Wave would be creating a temporary virtual device, using Settings > Swap Device to swap it out, doing an exclusion, including again, swapping the virtual device out, and then removing the virtual device now that the "real" device will again be back in place), then I'd also see if those help to confirm this as a Z-Wave JS issue and not some other oddity.