Z-wave: about to give up

fversteegen · March 5, 2021, 9:12am

I am struggling for a while with Z-wave. I have an Aeonlabs Zwave+ USB Stick, 4 Neo Coolcam doorsensors, 2 Fibaro Smoke sensors and 1 Neo Coolcam powerplug. The issue I am experiencing is that nodes not (or not correctly) reporting their status. I have already tried moving from legacy Z-wave to OZW to Zwavejs (performing a full reset of both the controller and all the nodes in between). I also tried individually removing and re-adding the nodes (which works, but afterwards the status is still incorrect).

In the Z-wave logs I cannot find anything meaningful of things going wrong. Can anybody point me in the right direction of solving this issue?

Below an dump of my Z-wave log.


                      installer icon:  0x0c06
                      user icon:       0x0c06
10:05:10.790 CNTRLR   [Node 009] BatteryCC: doing a complete interview...
10:05:10.790 CNTRLR » [Node 009] querying battery status...
10:05:10.835 CNTRLR « [Node 009] received response for battery information:
                      level:                           95
10:05:10.835 CNTRLR   [Node 009] WakeUpCC: doing a partial interview...
10:05:10.836 CNTRLR » [Node 009] retrieving wakeup interval from the device...
10:05:10.876 CNTRLR « [Node 009] received wakeup configuration:
                      wakeup interval: 43200 seconds
                      controller node: 1
10:05:10.877 CNTRLR   [Node 009] BinarySensorCC: doing a complete interview...
10:05:10.878 CNTRLR » [Node 009] querying supported sensor types...
10:05:10.920 CNTRLR « [Node 009] received supported sensor types: 
                      · Door/Window
10:05:10.921 CNTRLR » [Node 009] querying current value for Door/Window...
10:05:10.962 CNTRLR « [Node 009] received current value for Door/Window: false
10:05:10.962 CNTRLR   [Node 009] ConfigurationCC: Loading configuration parameters from device config
10:05:10.966 CNTRLR » [Node 009] querying parameter #1 value...
10:05:11.010 CNTRLR « [Node 009] parameter #1 has value: 0
10:05:11.011 CNTRLR » [Node 009] querying parameter #2 value...
10:05:11.052 CNTRLR « [Node 009] parameter #2 has value: 255
10:05:11.053 CNTRLR   [Node 009] AssociationCC: doing a complete interview...
10:05:11.053 CNTRLR » [Node 009] querying number of association groups...
10:05:11.095 CNTRLR « [Node 009] supports 4 association groups
10:05:11.096 CNTRLR » [Node 009] querying association group #1...
10:05:11.152 CNTRLR « [Node 009] received information for association group #1:
                      maximum # of nodes: 5
                      currently assigned nodes: 1
10:05:11.152 CNTRLR » [Node 009] querying association group #2...
10:05:11.194 CNTRLR « [Node 009] received information for association group #2:
                      maximum # of nodes: 5
                      currently assigned nodes: 
10:05:11.194 CNTRLR » [Node 009] querying association group #3...
10:05:11.244 CNTRLR « [Node 009] received information for association group #3:
                      maximum # of nodes: 5
                      currently assigned nodes: 
10:05:11.244 CNTRLR » [Node 009] querying association group #4...
10:05:11.285 CNTRLR « [Node 009] received information for association group #4:
                      maximum # of nodes: 5
                      currently assigned nodes: 
10:05:11.292 CNTRLR   [Node 009] AssociationGroupInfoCC: doing a complete interview...
10:05:11.293 CNTRLR » [Node 009] Association group #1: Querying name...
10:05:11.338 CNTRLR « [Node 009] Association group #1 has name "Lifeline"
10:05:11.338 CNTRLR » [Node 009] Association group #1: Querying info...
10:05:11.383 CNTRLR « [Node 009] Received info for association group #1:
                      info is dynamic: false
                      profile:         General: Lifeline
10:05:11.383 CNTRLR » [Node 009] Association group #1: Querying command list...
10:05:11.430 CNTRLR » [Node 009] Association group #2: Querying name...
10:05:11.477 CNTRLR « [Node 009] Association group #2 has name "Sensor Basic rep"
10:05:11.478 CNTRLR » [Node 009] Association group #2: Querying info...
10:05:11.522 CNTRLR « [Node 009] Received info for association group #2:
                      info is dynamic: false
                      profile:         Notification: Access Control
10:05:11.522 CNTRLR » [Node 009] Association group #2: Querying command list...
10:05:11.562 CNTRLR » [Node 009] Association group #3: Querying name...
10:05:11.605 CNTRLR « [Node 009] Association group #3 has name "Sensor notifi rep"
10:05:11.605 CNTRLR » [Node 009] Association group #3: Querying info...
10:05:11.647 CNTRLR « [Node 009] Received info for association group #3:
                      info is dynamic: false
                      profile:         Notification: Access Control
10:05:11.658 CNTRLR » [Node 009] Association group #3: Querying command list...
10:05:11.700 CNTRLR » [Node 009] Association group #4: Querying name...
10:05:11.743 CNTRLR « [Node 009] Association group #4 has name "Binary Sensor rep"
10:05:11.743 CNTRLR » [Node 009] Association group #4: Querying info...
10:05:11.785 CNTRLR « [Node 009] Received info for association group #4:
                      info is dynamic: false
                      profile:         Notification: Access Control
10:05:11.785 CNTRLR » [Node 009] Association group #4: Querying command list...
10:05:11.830 CNTRLR   [Node 009] NotificationCC: doing a complete interview...
10:05:11.831 CNTRLR » [Node 009] querying supported notification types...
10:05:11.873 CNTRLR « [Node 009] received supported notification types:
                      · Access Control
10:05:11.873 CNTRLR » [Node 009] querying supported notification events for Access Control...
10:05:11.930 CNTRLR « [Node 009] received supported notification events for Access Control: 22, 23
10:05:11.932 CNTRLR » [Node 009] enabling notifications for Access Control...
10:05:11.943 CNTRLR   Failed to execute controller command after 1/3 attempts. Scheduling next try i
                      n 100 ms.
10:05:12.076 CNTRLR   [Node 009] Interview stage completed: CommandClasses
10:05:12.076 CNTRLR   [Node 009] Interview stage completed: OverwriteConfig
10:05:12.076 CNTRLR » [Node 009] requesting node neighbors...
10:05:12.088 CNTRLR « [Node 009]   node neighbors received: 
10:05:12.088 CNTRLR   [Node 009] Interview stage completed: Neighbors
10:05:12.088 CNTRLR   [Node 009] Interview completed
10:05:12.089 CNTRLR   [Node 009] The node is ready to be used
10:05:13.095 CNTRLR » [Node 009] Sending node back to sleep...
10:05:13.103 CNTRLR   Failed to execute controller command after 1/3 attempts. Scheduling next try i
                      n 100 ms.
10:05:13.230 CNTRLR   [Node 009] The node is now asleep.
10:06:13.350 CNTRLR « [Node 009] received wakeup notification
10:06:13.350 CNTRLR   [Node 009] The node is now awake.
10:06:14.352 CNTRLR » [Node 009] Sending node back to sleep...
10:06:18.525 CNTRLR   [Node 009] The node did not respond after 1 attempts.
                      It is probably asleep, moving its messages to the wakeup queue.
10:06:18.526 CNTRLR   [Node 009] The node is now asleep.
New client
Client disconnected
Code 1000:

VikingBlod · March 5, 2021, 2:20pm

Coming from Smarthings where I had my ZWAVE and Zigbee working, I also tried getting ZWAVE working in HA. Tried multiple times going back to Smartthings and like you got frustrated. In my case I could approach this one device at a time so could figure out what would worked best. I also tried multiple options. In the end what I found worked for me;

ZWAVEJS2MQTT with the ZWAVEJS HA integration. You can disable the MQTT portion and only have the ZWAVEJS Server running. The MQTT version gives you a good UI to help debug issues. Being on the latest version also helped resolve some of my specific device issues. I do all my device inclusion from this UI. I do have MQTT running so I can see the actual data using MQTT Explorer.
I moved my ZWAVE and Zigbee sticks away from my WiFi Router and strategically placed a remote PI in a location that had better line of sight coverage (less walls and floors).
I bring my ZWAVE devices as close as possible to my AeoTec stick to pair and first try using Secure Inclusion. I wait for a completed node discovery before moving them to the final location. Not so easy with door locks or wired switches but I have found wired devices don’t have such an issue but I have uninstalled a door lock to pair it. I watch the debug log to see if a battery device falls asleep during discovery and wake it up if it does.
Devices that don’t report specific values I have found doing a complete reset on the device has worked for those.

Hope this helps.

fversteegen · March 5, 2021, 2:28pm

I decided to, once more, do a full reset of the network and go for the Zwavejs2MQTT plugin and have found, at least 1, issue now!

In Zwave2MQTT I do see the sensors actuating, but in the frontend/history tab the changes are not reflected. Needles to say: I did rename the sensor correctly. So there must be an issue with the ZwaveJS integration and (maybe) not in my Zwave network…

See below screenshots (in Zwave2MQTT “true” means “open”)

firstof9 · March 5, 2021, 2:41pm

Get a dump and create a github issue.

VikingBlod · March 5, 2021, 2:53pm

Frank,

I confirmed in my own setup the value does change when I open and close the contact on one of my devices. If you go to Configuration / Integration and select Devices you should get a list of all the ZWAVE devices the integration has picked up.

You should see the device in question and and there should be an entity that shows you the current state.

david_b · March 5, 2021, 3:03pm

I have just gone from OpenZwaveBeta to Zwavejs2mqtt, but turn off the mqtt bit so I can just use the web interface. I have the neocam door sensors and the pir sensors working fine but I did have issues when trying to use with security/encryption enabled so try without . I added via the zwavejs web page not via home assistant, and home assistant automatically found them after. Make sure you are on the latest version of Home Assistant 2021.3.1 as the bug fixes are coming fast.

Dave

ptdalen · March 5, 2021, 3:13pm

Just another data point. I moved from smarthings about 2 years ago. In the begining I also had some issues with zwave in general. I was able to get a solid working zwave solution with the legacy zwave, OWZ, and now Z-Wave JS. What I’ve seen in the community over the years, is that often a good zwave mesh makes all the difference in the world. I believe that the zwave controller used by smartthings has as strong signal and is better than many USB controllers. That’s just my opinion based on how many people (myself included) have poor success when they first migrate. To me as I added more powered devices my network quickly become more stable. The battery door lock that used to occasionally fall offline in HA, never falls offline anymore. Even when I was using legacy zwave in HA, my zwave was solid. So my point is, that if you have a mostly battery zwave devices, and just one or two powered devices, you are much more likely to have issues. Again, I dont think it’s HA as much as it is the USB controllers out there. Again, this is not always the case, just an observation from reading these forums over the years.

RickKramer · March 5, 2021, 11:02pm

So you have 1 controller, 1 powerline device and the rest are battery operated devices? What are the ranges? As that doesn’t seem like a stable base/mesh unless you live in a small apartment I guess.

fversteegen · March 10, 2021, 5:07am

That’s correct; 6 battery operated devices and 1 powered one. The sensor that is the furthest away is 5.4 metres and has got a 7cm wall in between (wall is 2x16mm gypsum board with hay in between).

I just moved everything to zwave2mqtt and strangely enough it looks like everything is working again as expected (sensor values coming in)…