We currently have a general shutdown procedure of all switches in our home. This routine works sometimes but in most cases 2 or 3 lights are not turning off. We are using the Inovelli LZW31-SW dimmers. We have 17 of them. Our mesh should work great as all switches are close to the hub as well as various other switches should act as repeaters. There should be enough coverage for communication. We initially used a group to shut them down but have now switched to RM in order to shut them down one by one and add some delay. Hope someone can help to troubleshoot why the sometimes lights stay on during the shutdown. Here are the details for our dashboard layout and topology.
Is there a way to improve on the routing? Some dimmers directly communicate with the hub which are further away then some dimmers that are routed via 4 different points. We believe that mesh optimization occurs automatically but is there a process we should complete to optimize the mesh i.e. exclude and then include again?
Thank you so much for the fast reply. Let me try what you sent and see if this makes a difference. We are trying to shut them down all at once. When we used the group feature it shut them down depending on what dimmer receives what command first. But it always left some switches/dimmers not turning off. We are unsure if this group command shutoff overloads the HE. We therefore switched to RM with the following details. This actually works quite well. However, we still have a few lights not wanting to turn off.
It will be a slight bit slower in that the point of that app is that it doesn't slam the Zwave network with commands all at once.
Then I would say you are likely back to a Zwave mesh issue. Do you have power monitoring turned on for these? Do you know if you are on the latest Inovelli firmware for these devices?
I am fairly new to HE and unsure on the power monitoring you are mentioning. Yes it appears we are on the latest and greatest firmware.
Or is this not the latest firmware?
It appears you are on the latest production release according to what I see on the Inovelli site. However there is a Beta update for "Fixed - Dimmer sending duplicate reports in certain scenarios while being controlled by certain hubs". Not sure if you are having this, or what hubs where this is seen. You might want to dig around on their forums and see if that update might help anything. Knowledge Base Redirect – Inovelli
You do appear to have some form of power monitoring turned on, it at least shows energy in your screenshot above. If you aren't using it, turn everything below off. This might not match exactly, these are a different device. Power reporting when set too low, or with too many reports can overwhelm the Zwave mesh.
Thanks for the confidence Not sure I can add much beyond what you have, except to do the same thing I use a scene, turn off optimization, and use metering. However most of my switches are Lutron so it's notr really a valid comparison. Agree on the power reporting though!
Ok turning off the power reporting did help a bit and it responds slightly better. However, I still have from time to time a few switches not turn on. I have only updated the .otz on one switch as this is a long and tedious process to get them all updated. But I will try firmware 1.61 Beta and see if this makes a difference. A few more questions:
a) Does the mesh rebuild itself as some routing goes via long routes where there should be shorter ways possible.
b) Do I need to exclude and then include the switch again to get better performance?
Here is the switch I just upgraded to 1.61. What do these numbers all mean? Seems like the communication is not working that well. This switch is very close to the HE in same fashion as others but the others have much lower values.
Only if errors occur, and if the device is Z-Wave Plus. It’s a bit of black magic, and the hub has no control over the routing algorithm. Wish it did, though. If the route seems fine, it will persist.
That’s why the advice is to build your mesh from the hub outwards.
You could exclude and then re-include, so that the route is forced to be discovered anew.
Tony Fleisher’s (@tony.fleisher’s) excellent Z-Wave Mesh Details app (installable from Hubitat Package Manager) is an excellent way to see what is going on.
I'll give this a shot though my knowledge is not as good as some... RTT average is the time it takes for HE to send a command and get a response. Yours is kinda on the long side. LWR RSSI is basically the signal strength above noise experienced along the last working route. Neighbor count is the number of other devices the device can talk to. Route changes is the number of times the route to the device has changed since the last reboot. Depending on how long ago that also seems fairly high. Security is fairly obvious, and the route is the route as the hub sees it, to the device. Each node represents a repeater used in the last working route (except for the last, which is the device itself).
So I tried the repair method of a node but that does not fix/optimize the node. By excluding and then including the node again it appears the node is now working perfectly as it should with really fast response time and an optimized path. See below now for the same mesh node details as above after exclude/include. I will do this now with all my nodes and try to report back the final results. Just testing the 2 nodes it appears very fast at first glance!!! Thank you for all your help.
I have been using Tony Fleisher’s (@tony.fleisher’s) tool and it really is awesome. I am using it to gauge how well the mesh is working. What a great community.
Not sure I can add much beyond what you have, except to do the same thing I use a scene, turn off optimization, and use metering. However most of my switches are Lutron so it's notr really a valid comparison. Agree on the power reporting though!
