I have an Homey pro 2016-2019 with approx 60 fibaro walli devices (roller, dimmer & switches) paired.
For some reason, randomly, without sudden power supply issue, some devices are losing their route and appear unreachable in the developper tool.
so I need to unplug them from the wall, the “remove” fuction doesn’t work so I need to force it, then re-pair and modify all flows usingthis device. painful.
on a regular basis, in the devolopper tool, I see some device unreachable, but I can test them and re-heal them. but sometimes, it’s too late.
I dont’ think there is way, from the device, to force to searh for neighbours. does anyone knows if Fibaro walli devices have a heal function from their own menu ?
So the solution is probably in homey.
I didn’t see any “test” or “heal” function from the scripting capabilities of Homey but I must say that I’m totally unskilled in scripting.
Does anyone of you have developed a solution, or a script to regularly test & heal the Z-Wave devices ?
Ideally, since almost all my scripts have an error management which notify me when a step of a flow didn’t suceed, I could call the “heal” script to make sure that the flow didn’t fail because the device is lost in action.
1/ When devices appear unreachable in the developper tool. then :
sometimes I can test a heal them from the devoloper tool, then it returns to a normal state.
sometimes, I would say it’s too late, the device is also unreachable IRL nor thru scripts.
2/All my devices are within 15/20 meters and none are more than 2m from the closest powered one
the walls of my house are made of wood with wood isolation inside. no concrete with iron.
I don’t think it’s a problem of range or radio.
the instance of the problem I had this week, the walli roller shutter was 1m from the homey itself.
3/ cannot be certain but it was the power supply, I would lose more device, no ?
1 - check
2 - I see no problems there
3 - there can be a bad connection in a junction box for instance, but as you say at ‘4/’, about these issues occurring from the start, with random devices, it almost can’t be a power issue.
4 - see 3.
Oh, I just found this post about a ´brutal’ way to heal the complete mesh in one go:
.
One of the possible causes I’ve read about, can be one or more ‘chatty’ devices, which can ruin (parts of) your zwave mesh.
For every device, try to set the update time of sensors as long as you find reasonable, keep away from ‘check this or that every second’ stuff.
Probably interesting topic about chatty devices:
Hi Peter,
I didn’t know that the whole Z-Wave network was rebuilt after such hard reboot.
I was thinking that by default each devices will try to recontact the path it had in memory.
This means that after the 10 mn of disconnection, all the devices will refresh their closest neighbors ?
So I guess this starts from the X devices in direct connection with the hub, then the ones connected to devices in the 1st range, and so on ?
I must say that I’m sometimes surprised how somes devices are reaching the hub. knowing the tipology of the house, it’s clearly not the closest/ fastest path.
homey support already warned me about devices sending to many refresh parameters command. I have 5 aerotec sensor 6 and I hope I’ve tune them to not bother the network.
Yeah, that’s why it’s not recommended to PTP Homey to often, if needed at all
It can take hours for the mesh to rebuild.
No clue on how the mesh is getting built.
Yup, just as with zigbee mesh networks, it’s often not about the shortest possible routes. I’ve had one zigbee unit 2 meters away from Homey, and it connected through a light upstairs.
one last question : Many of my scripts are batch modification of configuration : open all stores of the house, close them all together, switch on/off all lights of a level or outside,…
Do you think that those scripts sending many commands at a time are saturating the Zwave network leading to devices losing their path ?
Yeah, somehow it’s pretty hard for Homey Pro 201x to control more than 2 or 3 devices, which use the same antenna like zwave, at once.
This flaw doesn’t seem to be very improved with the 2023 model, but I might be wrong here.
Workarounds / alternatives
Add, say, 50 millisecs Wait in your array. Then test a bit with less or more millisecs to get the optimal wait time before each command to the related devices
When you add the lights to a group, by using an advanced virtual device, or by using a < group > device, the commands for every group member, are executed in sequence; you can start these devices’ flowcards from Homeyscript (check the example scripts in HS)
Not HS related, but anyways: In advanced flow, one can daisy-chain the action cards, allowing for the lights to turn on/off in sequence with slight delays, instead of all at once.
