I have recently started to experience weird behaviors with my roller shutters.
I was now working at my computer sitting at home all alone, and some of my shutters closed and reopened again. No button pressed that I know. If I go to the logbook I don’t see anything strange, but I just can’t happen to figure out what triggered my roller shutters to fully close and then fully open.
I’ve had these devices installed for years and my experience has always been sound. Not even sure where to start.
I checked the add-on and it looks like it did not report anything for a few hours, but some minutes ago (it is 14:20 currently) it seems to have thrown some errors into the console.
When I configured and enabled this add-on I did not enable logging. I just did now and restarted it. Will try to analyze the logs once I have them. In the mean time if anybody has any experience with this, I would very much appreciate any insight that could be shared here.
2024-03-19T04:47:57.744Z CNTRLR » [Node 003] requesting current switch state...
2024-03-19T04:47:57.787Z CNTRLR » [Node 003] querying current sensor reading...
2024-03-19T04:47:57.829Z CNTRLR « [Node 003] received current sensor reading:
sensor type: Power
value: 0 W
2024-03-19T04:47:57.830Z CNTRLR » [Node 003] querying meter value (type = Electric, scale = kWh)...
2024-03-19T04:47:57.876Z CNTRLR » [Node 003] querying meter value (type = Electric, scale = W)...
2024-03-19T12:41:41.831Z CNTRLR « [Node 003] Received updated node info
2024-03-19T12:41:41.832Z CNTRLR [Node 003] Node does not send unsolicited updates; refreshing actuator and sen
sor values...
2024-03-19T12:41:41.834Z CNTRLR » [Node 003] querying Binary Switch state...
2024-03-19T12:41:41.872Z CNTRLR « [Node 003] received Binary Switch state:
current value: true
2024-03-19T12:41:41.872Z CNTRLR » [Node 003] requesting current switch state...
2024-03-19T12:41:41.915Z CNTRLR » [Node 003] querying current sensor reading...
2024-03-19T12:41:41.962Z CNTRLR « [Node 003] received current sensor reading:
sensor type: Power
value: 0 W
2024-03-19T12:41:41.963Z CNTRLR » [Node 003] querying meter value (type = Electric, scale = kWh)...
2024-03-19T12:41:42.009Z CNTRLR » [Node 003] querying meter value (type = Electric, scale = W)...
Ok, the issue just happened again, right after I enabled logging in the add-on.
I notice a gap in the time reported by the add-on. I wonder if the add-on uses a different time than the system?
This is the output that I see (I’m sure it is 1h in the past, as I just enabled it and the issue occurred a few minutes later, and at the time of this writing it is 14:42):
2024-03-19T13:24:41.908Z DRIVER ███████╗ ██╗ ██╗ █████╗ ██╗ ██╗ ███████╗ ██╗ ███████╗
╚══███╔╝ ██║ ██║ ██╔══██╗ ██║ ██║ ██╔════╝ ██║ ██╔════╝
███╔╝ █████╗ ██║ █╗ ██║ ███████║ ██║ ██║ █████╗ ██║ ███████╗
███╔╝ ╚════╝ ██║███╗██║ ██╔══██║ ╚██╗ ██╔╝ ██╔══╝ ██ ██║ ╚════██║
███████╗ ╚███╔███╔╝ ██║ ██║ ╚████╔╝ ███████╗ ╚█████╔╝ ███████║
╚══════╝ ╚══╝╚══╝ ╚═╝ ╚═╝ ╚═══╝ ╚══════╝ ╚════╝ ╚══════╝
2024-03-19T13:24:41.910Z DRIVER version 12.4.4
2024-03-19T13:24:41.911Z DRIVER
2024-03-19T13:24:42.934Z CONFIG version 12.4.4
2024-03-19T13:24:43.318Z CNTRLR querying Serial API capabilities...
2024-03-19T13:24:43.436Z CNTRLR received API capabilities:
firmware version: 1.0
manufacturer ID: 0x86
product type: 0x01
product ID: 0x5a
supported functions:
· GetSerialApiInitData (0x02)
· SetApplicationNodeInformation (0x03)
· ApplicationCommand (0x04)
· GetControllerCapabilities (0x05)
· SetSerialApiTimeouts (0x06)
· GetSerialApiCapabilities (0x07)
· SoftReset (0x08)
· GetProtocolVersion (0x09)
· SetRFReceiveMode (0x10)
· UNKNOWN_FUNC_SET_SLEEP_MODE (0x11)
· FUNC_ID_ZW_SEND_NODE_INFORMATION (0x12)
· SendData (0x13)
· SendDataMulticast (0x14)
· GetControllerVersion (0x15)
· SendDataAbort (0x16)
· FUNC_ID_ZW_R_F_POWER_LEVEL_SET (0x17)
· UNKNOWN_FUNC_SEND_DATA_META (0x18)
· FUNC_ID_ZW_GET_RANDOM (0x1c)
· GetControllerId (0x20)
· UNKNOWN_FUNC_MEMORY_GET_BYTE (0x21)
· UNKNOWN_FUNC_MEMORY_PUT_BYTE (0x22)
· UNKNOWN_FUNC_MEMORY_GET_BUFFER (0x23)
· UNKNOWN_FUNC_MEMORY_PUT_BUFFER (0x24)
· EnterBootloader (0x27)
· GetNVMId (0x29)
· ExtNVMReadLongBuffer (0x2a)
· ExtNVMWriteLongBuffer (0x2b)
· ExtNVMReadLongByte (0x2c)
· ExtExtWriteLongByte (0x2d)
· GetNodeProtocolInfo (0x41)
· HardReset (0x42)
· FUNC_ID_ZW_REPLICATION_COMMAND_COMPLETE (0x44)
· FUNC_ID_ZW_REPLICATION_SEND_DATA (0x45)
· AssignReturnRoute (0x46)
· DeleteReturnRoute (0x47)
· RequestNodeNeighborUpdate (0x48)
· ApplicationUpdateRequest (0x49)
· AddNodeToNetwork (0x4a)
· RemoveNodeFromNetwork (0x4b)
· FUNC_ID_ZW_CREATE_NEW_PRIMARY (0x4c)
· FUNC_ID_ZW_CONTROLLER_CHANGE (0x4d)
· FUNC_ID_ZW_SET_LEARN_MODE (0x50)
· AssignSUCReturnRoute (0x51)
· FUNC_ID_ZW_REQUEST_NETWORK_UPDATE (0x53)
· SetSUCNodeId (0x54)
· DeleteSUCReturnRoute (0x55)
· GetSUCNodeId (0x56)
· UNKNOWN_FUNC_SEND_SUC_ID (0x57)
· FUNC_ID_ZW_EXPLORE_REQUEST_INCLUSION (0x5e)
· RequestNodeInfo (0x60)
· RemoveFailedNode (0x61)
· IsFailedNode (0x62)
· ReplaceFailedNode (0x63)
· UNKNOWN_FUNC_UNKNOWN_0x66 (0x66)
· UNKNOWN_FUNC_UNKNOWN_0x67 (0x67)
· GetRoutingInfo (0x80)
· UNKNOWN_FUNC_LOCK_ROUTE_RESPONSE (0x90)
· GetPriorityRoute (0x92)
· SetPriorityRoute (0x93)
· UNKNOWN_FUNC_UNKNOWN_0x98 (0x98)
· UNKNOWN_FUNC_UNKNOWN_0xB4 (0xb4)
· UNKNOWN_FUNC_WATCH_DOG_ENABLE (0xb6)
· UNKNOWN_FUNC_WATCH_DOG_DISABLE (0xb7)
· UNKNOWN_FUNC_WATCH_DOG_KICK (0xb8)
· UNKNOWN_FUNC_UNKNOWN_0xB9 (0xb9)
· UNKNOWN_FUNC_RF_POWERLEVEL_GET (0xba)
· UNKNOWN_FUNC_GET_LIBRARY_TYPE (0xbd)
· UNKNOWN_FUNC_SEND_TEST_FRAME (0xbe)
· UNKNOWN_FUNC_GET_PROTOCOL_STATUS (0xbf)
· UNKNOWN_FUNC_UNKNOWN_0xD2 (0xd2)
· UNKNOWN_FUNC_UNKNOWN_0xD3 (0xd3)
· UNKNOWN_FUNC_UNKNOWN_0xD4 (0xd4)
· undefined (0xee)
· UNKNOWN_FUNC_UNKNOWN_0xEF (0xef)
2024-03-19T13:24:43.436Z CNTRLR querying version info...
2024-03-19T13:24:43.443Z CNTRLR received version info:
controller type: Static Controller
library version: Z-Wave 3.95
2024-03-19T13:24:43.444Z CNTRLR querying protocol version info...
2024-03-19T13:24:43.449Z CNTRLR received protocol version info:
protocol type: Z-Wave
protocol version: 3.95.0
2024-03-19T13:24:43.449Z CNTRLR querying controller IDs...
2024-03-19T13:24:43.455Z CNTRLR received controller IDs:
home ID: 0xe45ab5aa
own node ID: 1
2024-03-19T13:24:43.463Z CNTRLR Performing soft reset...
2024-03-19T13:24:43.466Z CNTRLR Waiting for the controller to reconnect...
2024-03-19T13:24:44.969Z CNTRLR Re-opening serial port...
2024-03-19T13:24:45.974Z CNTRLR Waiting for the Serial API to start...
2024-03-19T13:24:50.977Z CNTRLR Did not receive notification that Serial API has started, checking if it respo
nds...
2024-03-19T13:24:51.004Z CNTRLR Serial API responded
2024-03-19T13:24:51.024Z CNTRLR supported Z-Wave features:
2024-03-19T13:24:51.025Z CNTRLR querying controller capabilities...
2024-03-19T13:24:51.033Z CNTRLR received controller capabilities:
controller role: primary
is the SUC: true
started this network: true
SIS is present: true
was real primary: true
2024-03-19T13:24:51.033Z CNTRLR finding SUC...
2024-03-19T13:24:51.037Z CNTRLR This is the SUC
2024-03-19T13:24:51.037Z CNTRLR querying additional controller information...
2024-03-19T13:24:51.144Z CNTRLR received additional controller information:
Z-Wave API version: 5 (legacy)
Z-Wave chip type: ZW050x
node type Controller
controller role: primary
controller is the SIS: true
controller supports timers: false
nodes in the network: 1, 2, 3, 4, 5, 6, 7
2024-03-19T13:24:51.230Z CNTRLR [Node 001] Embedded device config loaded
2024-03-19T13:24:51.242Z CNTRLR [Node 002] Embedded device config loaded
2024-03-19T13:24:51.248Z CNTRLR [Node 003] Embedded device config loaded
2024-03-19T13:24:51.252Z CNTRLR [Node 004] Embedded device config loaded
2024-03-19T13:24:51.256Z CNTRLR [Node 005] Embedded device config loaded
2024-03-19T13:24:51.263Z CNTRLR [Node 006] Embedded device config loaded
2024-03-19T13:24:51.268Z CNTRLR [Node 007] Embedded device config loaded
2024-03-19T13:24:51.273Z CNTRLR setting serial API timeouts: ack = 1000 ms, byte = 150 ms
2024-03-19T13:24:51.277Z CNTRLR serial API timeouts overwritten. The old values were: ack = 1500 ms, byte = 15
0 ms
2024-03-19T13:24:51.278Z CNTRLR Interview completed
2024-03-19T13:24:51.286Z CNTRLR [Node 001] The node is alive.
2024-03-19T13:24:51.286Z CNTRLR [Node 001] The node is ready to be used
2024-03-19T13:24:51.287Z CNTRLR Interviewing nodes and/or determining their status: 4, 7, 3, 6, 2, 5
2024-03-19T13:24:51.287Z CNTRLR » [Node 004] pinging the node...
2024-03-19T13:24:51.353Z CNTRLR » [Node 007] pinging the node...
2024-03-19T13:24:51.354Z CNTRLR » [Node 003] pinging the node...
2024-03-19T13:24:51.355Z CNTRLR » [Node 006] pinging the node...
2024-03-19T13:24:51.356Z CNTRLR » [Node 002] pinging the node...
2024-03-19T13:24:51.356Z CNTRLR » [Node 005] pinging the node...
2024-03-19T13:24:51.423Z CNTRLR [Node 004] The node is alive.
2024-03-19T13:24:51.423Z CNTRLR [Node 004] The node is ready to be used
2024-03-19T13:24:51.424Z CNTRLR « [Node 004] ping successful
2024-03-19T13:24:51.473Z CNTRLR [Node 007] The node is alive.
2024-03-19T13:24:51.473Z CNTRLR [Node 007] The node is ready to be used
2024-03-19T13:24:51.475Z CNTRLR « [Node 007] ping successful
2024-03-19T13:24:51.505Z CNTRLR [Node 003] The node is alive.
2024-03-19T13:24:51.506Z CNTRLR [Node 003] The node is ready to be used
2024-03-19T13:24:51.508Z CNTRLR « [Node 003] ping successful
2024-03-19T13:24:51.539Z CNTRLR [Node 006] The node is alive.
2024-03-19T13:24:51.540Z CNTRLR [Node 006] The node is ready to be used
2024-03-19T13:24:51.542Z CNTRLR « [Node 006] ping successful
2024-03-19T13:24:51.593Z CNTRLR [Node 002] The node is alive.
2024-03-19T13:24:51.594Z CNTRLR [Node 002] The node is ready to be used
2024-03-19T13:24:51.596Z CNTRLR « [Node 002] ping successful
2024-03-19T13:24:51.662Z CNTRLR [Node 005] The node is alive.
2024-03-19T13:24:51.663Z CNTRLR [Node 005] The node is ready to be used
2024-03-19T13:24:51.664Z CNTRLR All nodes are ready to be used
2024-03-19T13:24:51.665Z CNTRLR « [Node 005] ping successful
I can’t see anything strange in the log, other than a soft reset:
Againg, the roller closed completely on its own and fully re-opened without any of us triggering any of this.
The log file won’t show any new data. This could very well mean that home assistant is not behind this behavior. However, if I go to the entity itself, this is what I see:
persiana_habitacion_3 was opened
4:33:34 PM - 31 seconds ago
persiana_habitacion_3 became unavailable
4:33:34 PM - 31 seconds ago
persiana_habitacion_3 was opened
2:25:24 PM - 2 hours ago
persiana_habitacion_3 became unavailable
2:24:08 PM - 2 hours ago
The entity becomes unavailable and right then it closes (although that is not displayed) and opens up again… and these two timestamps correlate 100% with what I see.
Any hint would be much appreciated. I came across this issue and it might correlate with my case.
It doesn’t look like ZWave JS is restarting from the logs, so I’m not sure why they would be going to unavilable, but do you have automations to control your covers where the cover itself is the trigger action?
no, I don’t. My covers are closed at night. Other than that, I don’t have any other automation with the covers in scope. I think the nodes are simply trying to calibrate themselves when they come out of the unavailable state?
Ok. I was thinking that a trigger was firing incorrectly.
Yeah, there’s something odd going on there. I wonder if unpairing them and re-pairing them again might help. Or possibly refreshing the states in ZW2js might help as well.
Repairing means I need to have physical access to the device or could I now migrate the nodes from my current network to a new one? It is quite some hassle as it is not really accessible where the device is tucked away. What do you mean with refreshing the state?
If you go to your zw2js interface (I think it’s usually listening on port 8091 by default), select the drop down for your device (far left hand side, the down arrow), then select the Advanced button on the far right:
None of those snapshots feel familiar. Are you using the add-on? The closest thing that I can find that resembles a configuration interface is this: Z-Wave - Home Assistant
Ahhhhh… no. I’m using zwave2js standalone on another server and then using the zwave integration just as a passthrough for the devices.
In the actual integration, I would try a rebuild first and then a heal after that. Depending on the number of devices you have, it might take a while and some devices might be slow to respond. BUT… let it get through the whole way. If you don’t have a lot of devices, it might take an hour or so.
