I’ve been using Openhab for a bit more than a year now. I been using the community forum, but I’m not going any further with an issue on my Z-Wave network.
1) System Information
My network consist of 5 nodes:
1 Aeotec Z-Stick Gen5
4 Eurotronics Spirit Z-Wave plus
Openhab 2.5.2 running on a Synology NAS (DS718+ / CPU Intel Celeron).
I’ve been running this network until September 2020 without any major issues. As I restarted the heating system for this winter (beginning of October), I keep on loosing one node. It is shown as “OFFLINE - Communication error” in Paper UI.
After a while it will get back Online.
In the event.log I have following message '2020-12-12 09:43:13.914 [hingStatusInfoChangedEvent] - 'zwave:device:78787b80:node4' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller '
That device is not as far away as some other nodes from the controller.
I’ve analysed the event.log.
Yesterday it was Offline 12,5hours and changed from OFFLINE to ONLINE 51 times.
Today, without any changes, it occurred 8 times and the device was online for 22 hours.
Moreover the heating mode, is not working.
3) What I’ve done so far
I’ve look at quite some post in the forum without finding anything
delete the whole openhab directory
Exclude using the stick all single nodes
Reset the stick and all Spirit to factory settings
Change the battery of the faulty node
Include all nodes from the stick
Add all new Z-wave from the inbox of Paper-UI
Copy from my backups only the items, rules and sitemap, and persistence files.
It did not really helped.
I’ve noticed in HABmin, that
on the first days after the reinstallation. The nodes where not showing any neighbours.
yesterday, all nodes except 4 where linked to node 1 (The Stick)
Today using the network analyser, I got this
Do you have any idea where the problem could come from?
Does the device have an issue?
Is that a range problem?
Thanks for your support and advices.
I’m adding the z-wave debug log. debug.log (896.5 KB)
With 4 battery powered nodes and the controller, you have a very weak mesh. All of the device must communicate directly with the controller. Adding some mains powered devices will help. Placement of the devices can help/hurt too. Walls, floors, metal garbage cans, file cabinets, etc… lots of things can cause interference.
Possibly. Since they are battery powered, have you tried manually waking them up? Have you tried replacing the batteries?
I think @5iver was being a little optimistic With only battery devices in your system, you will have NO mesh network. As Scott said, all devices will need to communicate directly with the controller - there will not be any possibility for routing.
If a device is offline, it means that the controller has tried to communicate, and got no response. We see this with node 4 in your log. It’s worth noting that a lot of things can influence range - not just the distance between the nodes - so it’s difficult to compare just “by site”. Unfortunately there’s no easy way to look at signal strength, but the log is quite clear that at least node 4 has communication problems
However - you also need to remember that this shows neighbours - not routes. So a link in this table simply means that one device can hear another device - it doesn’t mean that it will be able to route via that device. Routes are managed by the controller, and are unknown to the binding.
In this case, all devices are battery devices, so they will not participate in routing. The fact that node 4 does not appear as a neighbour to node 1 simply confirms the point I made earlier - the link from node 1 to node 4 is poor - this is causing communication problems, and timeouts, which sets the device OFFLINE.
Any mains device will be fine - they will all work as a router.
I’m not sure what “particular device” you mean. You should have a “thing” for each node in the network.
I guess you’re missing the channel? The binding only manages channels - you then create a thing to “talk” to the device via the channel, but the binding has no knowledge of items - that’s up to you to add.
If the channel is missing, then I would assume it’s not defined in the database. I’m not familiar with the device, but I see a “thermostate_mode” channel in the database - is this what you’re after?
Well, Probably not familiar enough with the terms.
You are correct the heating_mode is missing. zwave:device:78787b80:node4:thermostat_mode to be specific.
It is working well for the other 3, but is not working on node 4.
So the issue is not that the channel, or the item ( ) is missing, but that the option is missing? You’re seeing a 1 and have a numerical entry box in this node where the others have a dropdown?
I don’t really know why that is - they should all link back to the same thing definition - you could try deleting the thing and adding it back (not excluding). This will make OH re-read the thing definition. From what I can see, the definition in the database export looks ok, so hopefully that will fix it.
I bought a Z-Wave Plug (Abus SHHA 100000 / Manufacturer 0403 / Type 003:0003).
The first day, it did improved a bit. (only 2 disconnections)
The second day (well yesterday), I had no disconnections. Let see if it keeps working stable now.
The meshing is a bit strange. The new node is node 6…But it is apparently not connected to the controller (node 1)…
I’m not sure if the neighbourhood is really representing the mesh…
Honestly that’s confusing. I Hope the network will stay stable.
I’ll keep an eye on it, and if it does stay stable, I will report this issue as solved.
It doesn’t represent the mesh - it represents neighbours that can hear each other. Note though that you have an extremely poor mesh as it looks like most of your devices are battery operated (other than node 6) - so mesh networking really will not work well.
This information is only updated periodically - normally during the heal.