I’ve got several Sonoff SNZB-04 open/close sensors around the house.
Most of them are pretty stable in deCONZ, some of them have the habit of dropping out of the network all of a sudden.
Now that DDF is around, I have the possibility to mark them as sleeper, and generate a DDF file for that change.
It is my understanding, that this would mean there is a better chance for certain end point devices to remain in the mesh.
My questions:
Is it correct that defining it as a sleeper could prevent it from dropping from the network?
If so, is it really enough to tick the sleeper box, and save the autogenerated DDF file (as bronze, or higher)?
The bindings seem a bit incomplete to me.
No, I don’t think it will have an impact on connexion issue. Sleeper or not is more for deconz core to know if it can make or not some action on the device.
And you can’t choose yourself if a device is a slepper or not, it s a setting native from the device.
And idk if I have correclty understand but yes, it’s possible some binding are not complete on some DDF. And if you use the feature “Edit DDF” I think the binding part is totally empty.
So, I misunderstood the sleeper setting.
I thought sleeper suggested that it was an end point that doesn’t periodically provide status information.
Since the SNZB-04 only seems to provide status changes, it can go silent for some time.
The binding part is not totally empty for snzb-04, but the ias zone doesn’t include any specific attributes.
Any thoughts how to prevent the disappearance of devices from the network?
There is some end device that are not sleeper, like TRV or doorlock. Swoop have put a tip to identify them on the wiki, just try to send a request like read an attribute, if you have a timeout error > sleeper device.
Any thoughts how to prevent the disappearance of devices from the network?
For me it s hardware/firmware dependent, some brands cause issue as device or used as router for others devices, it s (almost) the same working mode for all.
Try to find better router for worst sensors.
