What are the other use-cases? As noted in the following thread, introducing a first-class looping feature is something we are considering…
It’s generally an anti-pattern that ends up making rules run significantly more often (and thus unnecessary resource utilization as you alluded to). Other than sending a periodic refresh to a device, most of the use-cases I see are better suited as an event-driven rule design. That being said, there are some cases where a loop could be a better fit, so I’m interested in hearing more use-cases from the community!
One concern is that if a loop is available as a first-class feature, many people will end up using a loop approach rather than an event driven approach which ends up unnecessarily multiplying the resource problem.
Heck, even going back to the use-cases where a loop is warranted (eg. a refresh), most of those rules are being written because of a fundamental flaw with an upstream device (eg. a device that is not reporting data in an event driven manner like it should). In those cases, sometimes it’s just a faulty device or oftentimes its old devices that didn’t push events because of now expired patents… but sometimes it’s a matter of updating or configuring the device accordingly.
I would note that energy meters and power meters are a bit unique in that they tend to report a ton of events, so there are some cases where periodically snapshotting energy/power data rather than using an event-driven rule makes sense!