I will attempt to reproduce this issue tomorrow and gather the logs, for the moment i have captured the room lighting screenshot from a pc as requested
That is a simple RL configuration and there should be no issues with its performance.
That points to device related issues. @jtp10181 is one of the Z-Wave experts. A single ghost can still cause issues with your network. It looks like your previous picture/pdf was done shortly after a reboot. You might want to take another picture if you haven't restarted the hub recently. You should also take a picture of the Z-Wave device topology. After your cleanup did you do a power down/unplug for a minute cycle? If not, don't do it until after you've taken updated picture of your network. Your initial cleanup was extensive, and that power cycle process may be useful.
For turn on options try adding turn on if already activated. This will re-activate the RL every trigger even if it thinks it is already active. This can help sometimes if the RL is active but the lights are off somehow. Then it will re-activate it and turn them back on. I usually add this to every RL unless it is a dimmer and you want to avoid the dimmer level being reset for every motion trigger.
I would add to the turn off restrictions, the Stays Off pending. This will prevent the contact sensor from turning it off immediately if the motion timeout is still pending.
In this rule that setting is functionally the same as using 'switches that determine all lights are off' setting. But it is useful in other scenarios.
Along with a 'stays pending' adding motion active for the sensor to the restriction may also be useful. There are some scenarios where the sensor never goes inactive, so there are no stays to be pending.
I use all these settings in lots of my rules. Room Lighting setup can be made to be very complicated that it becomes difficult/impossible to visualize all the overlaps. The issues more often pop up on the means to turn off.
@ThunderboltsRock you should also consider reviewing/posting logs for the RL instance and the 3 devices.
1 Like
Link to screen capture zwave gosts 11 03 2024 and zwave device topology
https://1drv.ms/f/s!Aoemdv993MGDgowO8phpQKyuql__MQ?e=pdQ6ca
Thanks I have added these
Below are logs screenshot for when the garage light did not activate, even after manually attempting to activate
1 Like
That condition indicates device/mesh issues.
It looks like you've got 1 ghost still, which can cause problems. You also have a few devices with few routes, which are shown in the rows/columns that are mostly red. You have some devices with 9.6k speed that indicate difficulty with reaching the hub. Your garage lights have lots of neighbors but also lots of route changes and high times.
1 Like
Any ideas on how to get this zwave network more reliable ?
Below is screen dump from zwave mesh details app
https://1drv.ms/b/s!Aoemdv993MGDgowRYIQDotiKY03exA?e=mRevUr
Looks like everything is working as expected except your Lights garage device is not responding to commands to turn on.
That device and a few others right near it in your zwave details seems to be struggling, a lot of route changes. The image/pdf is very blurry and hard to read though.
How far away are those devices?
Do you have any metal or concrete between those and the hub?
I can look at that updated layout later today. I might need a rough layout of the house or something. Thats a lot of devices to map out though.
Hub to garage light switch is about 3mtr
No concrete but the house is metal frame. I will try and adjust the aerial on the aeotec nano switch located behind the physical switch in the wall.
Below are house layout of first and second floor with aeotec multi sensors powered by POE labeled as “P..” The Hubitat hub is located under the stairs on ground floor
So steel studs in all the walls?
Also, anything in the garage, there is possibly extra material in those walls for a fire rating. Possibly just extra thick sheeting. Could be something in that causing more interference.
The Garage Switch device looks like it is more chatty than others, lots of route changes as well. That device is possibly flooding the mesh with discovery trying to re-route all the time. It also has S0 security. Is it to control the garage door or some other switch?
Also, I know a lot of the Aeotec switches and sensors can be chatty. If the switches have power reporting and you are not using it, disable it cut down on traffic.
Thanks I will try disabling power reporting, I have also managed to get rid of the Ghost 70 device. Garage may have a few more metal columns but i wouldnt think anything much more than the rest of the building
Below is link to updated zwave ghost list
https://1drv.ms/b/s!Aoemdv993MGDgowSTkSLh1NEAmmmqg?e=u33t9f
1 Like
All ghost zwave device have been removed but I still have inconsistent lighting actions. I have observed that during many of the failed lighting action in room lighting app if I Select the radial dot to turn on or off the light it usually responds instantly but when I check the logs for the action the action command was sent but the switch did not achieve the desired state, but when manually turned on/off the light switch responds immediately. Might it be possible to add into room lighting app a check on if the device (light switch) has achieved the requested state e.g on or off and if not try again for 3 attempts? This would help with networks that are not rock solid
Just a thought .. what kind of BOX is the zwave device in ? metal or plastic ?
Dev has already stated no on that with an explanation somewhere. Basically if the device is not responding and you then hammer it with multiple commands you are most likely just going to cause more mesh issues by sending multiple commands.
Plastic
Doesn’t need to hammer just retry 3 times 1 seconds apart then write error to log if failed to reach the requested state
And what if the light does turn on but the device just doesn't respond properly, then someone turns the switch off, but then the app sends another on command and turns it back on? Then more complaints that it is broken. These are the sorts of things you have to think about with automatic retries, its not as simple as it seems.
Also, he is asking about the junction box that is in your wall, metal or plastic?
If you still have tons of route changes happening on a lot of device that is probably what is bogging things down.
You could use a virtual device and then an app or rule to retry until the device responds. I feel like someone has made an add to do this before but not sure what its called.
1 Like
The physical switch off/on vs logical switch on/off is known to Hubitat (or the nano switch) if some one physically turns on/off the switch then cancel 3 x retry’s per second and write to log.
E.g I have a rule that if physical switch is turned off in powder room then wait 5sec and turn on for 1 min (for exhaust fan which is built into light). This only works if Hubitat knows physical switch other wise it would end in a continuous loop
