It was noted in another thread covering a specific case of this topic that it's possible, on some hubs (ahem), for a device to flap its *failed" state quickly, and perhaps is even likely due to temporary network/mesh/device issues, or a simple choice that during restart of the hub devices are marked down until known up. All of this may cause quick, although likely uninteresting, transitions between failed and not-failed.
It may therefore be advisable to use the "sustained for" option on any rule that reacts to a change in identified failed devices, to dampen the response to such potentially spurious state changes.
