I’m experiencing intermittent problems with my Z-wave network and from time to time some of my lights doesn’t turn on or off as expected. When looking into the log (attached) I can see that the two devices with most problems (#46 and #47) have very long response time - up to 6 sec in the attached log and also time-out and thing-state going offline and then online again. When checking the network status in HABMin, it looks fine - the two devices are communicating with the controller (#1) via a range extender (#49) and also see a few other devices as their neighbors.
Any ideas on what I can do to improve the reliability?
- Platform information:
- Hardware: Raspberry Pi3 B 1.2 with Aeotec Z-stick gen5.
- OS: Raspbian GNU/Linux 10 (buster), Linux 5.4.72-v7+
- Java Runtime Environment: openjdk version “1.8.0_252”,
OpenJDK Runtime Environment (Zulu 220.127.116.11-CA-linux_aarch32hf) (build 1.8.0_252-b225),
OpenJDK Client VM (Zulu 18.104.22.168-CA-linux_aarch32hf) (build 25.252-b225, mixed mode, Evaluation)
- openHAB version: openHABian 2.5.10-1 (Release Build)
- Issue of the topic: please be detailed explaining your issue
- Please post configurations (if applicable):
- Items configuration related to the issue
- Sitemap configuration related to the issue
- Rules code related to the issue
- Services configuration related to the issue
- If logs where generated please post these here using code fences:
Providing a longer log covering network heal and also an updated z-wave map after the nightly heal. I’m not really sure what to do about this and the timeout problems - all ideas are appreciated!
Are those 2 devices perhaps at the edge if the network coverage, with marginal signal?
Not really the edge, but some distance from the controller. I have three buildings with devices. The main building with the controller and lots of devices and then two separate buildings (35 and 50 m from the main building) with a cluster of devices in each of them. The device furthest away from the controller is device 51, my electric meter, but it seems to work just fine, providing data about consumption.
I also added three range extenders (one per building) to try to ensure more reliable communication, but I cannot say it really made that much of improvement.
Also, I know that dead nodes can be a problem but I recently used the zensys tool to remove any junk from the usb dongle.
Today’s status after nightly heal. Happens from time to time that the network is presented as just a line. Not really sure why…
Another thing that came to my mind when checking all my devices. I have a large number of Fibaro Wall Plugs. I thought they all were the same, bu some of them seem to be the older model FGWP101 which don’t seem to be Z-wave+. I understand that they should be compatible, but can they slow down the entire network or even reduce range? Should I replace them all with the newer FGWP102?
@chris does mixing z-wave and z-wave plus devices on a network affect speed or range of the network?
Yes, but I think in reality it won’t matter in most cases. It will mean that there are bottlenecks - eg the link will effectively slow down to the slowest device in the path. Probably this doesn’t really matter though. What can make a difference if there are old devices in the network is some features relating to routing may not be available (eg explorer frames that are used fo discover routes) and this can mean that links must use the source routing that is configured from the controller via the heal.
Range will be impacted if you have a device with poor performance, but to be honest, my personal view is that the chip performance is really just the thin end of the wedge when it comes to RF link - there are a lot of other factors that come to play and a couple of dB in performance probably doesn’t matter in practice. Now, if there are some very old devices in the network, then that might be a different story. Note though that this won’t impact general performance - just in the event that such nodes are used in the route.
I don’t really think it will make a lot of difference. However, the API used in those devices (from looking at the database) doesn’t include the explorer frames, so it does rely on the source routing.