prevello
commented
3 years ago I can confirm the same issue. Been working fine for ~1 week after migrating to OpenZwave but started experience same problem yesterday. Can't seem to find any updates that causes this.
Running hassio on VMware with Aeotec Z-Stick G5.
Log:
[20200930 13:02:24.477 CEST] [ozw.library] [info]: Info - Node: 26 Sending (Send) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x1a, 0x0a, 0x98, 0x80, 0x36, 0x1f, 0x97, 0x8a, 0xfa, 0x41, 0xf5, 0x51, 0x05, 0x01, 0xda: [20200930 13:02:24.494 CEST] [ozw.library] [debug]: Detail - Node: 26 Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8 [20200930 13:02:24.494 CEST] [ozw.library] [debug]: Detail - Node: 26 ZW_SEND_DATA delivered to Z-Wave stack [20200930 13:02:24.513 CEST] [ozw.library] [debug]: Detail - Node: 26 Received: 0x01, 0x07, 0x00, 0x13, 0x01, 0x00, 0x00, 0x03, 0xe9 [20200930 13:02:24.514 CEST] [ozw.library] [debug]: Detail - Node: 26 ZW_SEND_DATA Request with callback ID 0x01 received (expected 0x01) [20200930 13:02:24.514 CEST] [ozw.library] [info]: Info - Node: 26 Request RTT 231 Average Request RTT 170 [20200930 13:02:24.544 CEST] [ozw.library] [debug]: Detail - Node: 26 Received: 0x01, 0x2d, 0x00, 0x04, 0x00, 0x1a, 0x27, 0x98, 0x81, 0xca, 0x35, 0xb1, 0x95, 0x5f, 0xed, 0x87, 0x56, 0x65, 0x53, 0x05, 0x85, 0x9d, 0x3f, 0x0a, 0x7e, 0x66, 0x73, 0xdc, 0xb5, 0xa3, 0x90, 0x5c, 0x3e, 0x08, 0x81, 0x68, 0x19, 0x36, 0x63, 0x3c, 0xbb, 0x3b, 0x2b, 0xad, 0xb1, 0x0d, 0x2c [20200930 13:02:24.544 CEST] [ozw.library] [info]: Info - Node: 0 Raw: 0x98, 0x81, 0xca, 0x35, 0xb1, 0x95, 0x5f, 0xed, 0x87, 0x56, 0x65, 0x53, 0x05, 0x85, 0x9d, 0x3f, 0x0a, 0x7e, 0x66, 0x73, 0xdc, 0xb5, 0xa3, 0x90, 0x5c, 0x3e, 0x08, 0x81, 0x68, 0x19, 0x36, 0x63, 0x3c, 0xbb, 0x3b, 0x2b, 0xad, 0xb1, 0x0d, 0x2c [20200930 13:02:24.544 CEST] [ozw.library] [debug]: Detail - Node: 26 Decrypted Packet: 0x00, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x06, 0x06, 0x0a, 0x63, 0x03, 0x01, 0x01, 0x31, 0x39, 0x30, 0x31, 0x36, 0x39 [20200930 13:02:24.544 CEST] [ozw.library] [info]: Info - Node: 26 Response RTT 262 Average Response RTT 426 [20200930 13:02:24.544 CEST] [ozw.library] [info]: Info - Node: 26 Got a AlarmCmd_Report Message....
[20200930 13:02:24.544 CEST] [ozw.library] [info]: Info - Node: 26 Received Notification report (>v1): Type: Access Control (6) Event: Keypad Unlock Operation (6) Status: true, Param Length: 10 [20200930 13:02:24.544 CEST] [ozw.library] [debug]: Detail - Node: 26 Initial read of value[20200930 13:02:24.545 CEST] [ozw.daemon] [warning]: CRASH!!! - Dumping Backtrace:
[20200930 13:02:24.545 CEST] [ozw.daemon] [warning]: #1 0x00007f912b6cb27d sp=0x00007f91286b6180 sigwaitinfo + 0x8 [20200930 13:02:24.545 CEST] [ozw.daemon] [warning]: #2 0x0000000000000000 sp=0x00007f91286b6190 + 0x8
1601463744: Socket error on client qt-openzwave-1, disconnecting. In exit [cont-finish.d] executing container finish scripts... [cont-finish.d] mqtt.sh: executing... 1601463744: mosquitto version 1.6.8 terminating 1601463744: Saving in-memory database to /data/mosquitto.db. [13:02:24] INFO: Ensure upstream MQTT server has the correct OZW status [cont-finish.d] mqtt.sh: exited 0. [cont-finish.d] done. [s6-finish] waiting for services. [s6-finish] sending all processes the TERM signal. [s6-finish] sending all processes the KILL signal and exiting.
Dear developers, I really enjoy your great work, but now I hope for you assistance to solve a problem several people are struggling with. I am running the Home Assistant Supervised alone on Proxmox on a Mac Mini using a Aeotec Z-Stick gen5. and the OpenZWave addon version is 0.5.2. Danalock firmware is version 0.16.0. Danapad is version 0.5.2. All are latest firmware.
Consistently the addon is cashing when I use the Danapad (Bluetooth code keypad for the Danalock V3 Z-wave) to unlock the lock. When I use HA to unlock/lock it works find. So does manual lock/unlock with status updates. When I try to restart the addon, its crashes again without doing anything to the lock as the lock is still sending " AlarmCmd_Report" when connecting to HA. If I initiate the pairing process from the lock when addon is restarting, I am avoiding the " AlarmCmd_Report" from the lock and the addon will run until next time I unlock the lock using the Danapad.
Here is the log for when the addon is crashing when unlocking with Danapad (Node 30 is the Danalcok V3):
I have tried with fresh install, refresh the node etc. For me is seems like "Got a AlarmCmd_Report" is causing the problem. I also experienced the same when trying on a fresh HA install in RPI 3B with another Aeotec Z-stick gen5.
I, and more with me, would highly appreciate your help. If you need more info, please let me know.
br Erik