@bravenel Hey Bruce, this is off topic. Is there any thing wrong with turning off 20 or more lights at once with a rule? I have had a rule that did that at night or whenever mode changed to away. Then I installed your all off in it's place thinking less stress. Problem now is that device activity check reports several of them. Last activity was when my rule turned them off.
What is the problem in this case, then? I'd leave Device Activity Check out of the picture for a second, as if you're using the default "Last Activity At" method, then it's just pulling the same information you'd seed for this value on the device detail page. If that's when you last caused some event to be generated on the device (say, by turning it off -- sending an "Off" command that was successful and resulted in an event), then what you've described is exactly the value I'd expect to see.
Going back to the original question, I'm not Bruce, but how you send the "Off" command wouldn't really matter -- one app, another app, or even manually yourself from the device detail page. Whatever difference you've noticed here would be either coincidental timing (you've never turned them on or ff since then, maybe?) or because your rule was doing more (and perhaps at additional times?) compared to your new app.
1 Like
The only problem is device activity check warnings. What I see is Bruce's app only sends off commands to them if they are on and so many of my lights don't get turned on. The screenshot I posted shows last activity from the rule I was using before that sent off commands to all my lights before switching to the all off app. Now they dont get an event unless they were on at that time. Any how do you think it is OK to send 20+ offs to multiple lights at once.
I'd back up a bit: what problem are you trying to solve? And along those lines, are you sure your Device Activity Check interval isn't too aggressive? Do you have problems with lights just falling off your network? If so, I'd look into that problem first. If not, consider that Device Activity Check can be used for a broad array of use cases, many of which I never imagined, but finds perhaps protypical use for telling when battery devices may have actually died without needing to rely on questionable battery reporting. Mains powered devices are an unusual fit, not that you can't do it -- but you'll have to know how your devices report, and apparently, periodically on their own (without some command) isn't it, and your interval will need to greater than that to avoid false positives.
That being said, from the additional information, it seems your devices generate some event (perhaps another "switch: off" event) in response to an off() command, regardless of their current state. That's also a bit unusual but seems like the most likely explanation and is again testable from the device detail page (and probably even visible retrospectively in "Events").
If you weren't having problems before, that could give you an answer for your network. 
General statements will depend on the protocol, specific devices, and unique characteristics of your network. I would probably not do this myself (or at least space things out a bit) with Z-Wave, but Zigbee with group broadcasting would probably be fine (and you could avoid checking anything first since it wouldn't really apply), to name two possibilities. But ultimately, you'll have to see what works for you.
4 Likes
Thanks for the reply, has given me lots of good info to think about and a better understanding.
Nothing at the moment, just network and battery checks from DAC and normally do not get any notifications. I have intervals set for 36 hrs.
I used to have zigbee sengled E1D-G73 contact sensors drop off when I switched to a C8 but eventually put those back on my C7 along with some mains for repeaters. DAC kept me informed they were dropping off. C8 has zigbee and zwave. All works really well, zwave has been rock solid.
I guess that is what I have learned. I have some lights that may not get turned on for days.
