Conflicting Set Reaction Groups Appear to Fire Simultaneously in Single Rule Evaluation

[therealdb]

Before I'll open a feature request, I want a reality check, because this is maybe achievable in other ways.

Long story short: I want to react to a device in quasi-real time, but 15 or 30 secs are enough (and will prevent the rule from throttling). Right now, I've moved to 1 min, but it's obviously too late to catch all the variations. 15 secs or 30 are OK, so my first reaction to circumvent this limitation was to host the timer myself and send it via MQTT, but it's obviously a not welcome complication.

So, @toggledbits, is there any reason the minimum interval is 1 min and/or do you have any suggestion for my use case? Thanks Patrick!

[toggledbits]

The interval timing in VirtualEntityController is much more flexible and tolerant. Would you be able to use that? You could make a virtual binary switch or sensor that just toggles every 15 seconds and react to that in your rule.

[therealdb]

I know I asked it many weeks ago, but I'm back at it.

I've tried this:

          capabilities:
            binary_sensor:
              attributes:
                state:
                  expr: |
                    s = dateparts().second,
                    s == 0 || s == 15 || s == 30 || s == 45

with no luck. it seems to expr is not evaluated.

I've added

          http_request:
            url: http://localhost:8111/
            interval: 1

just to fake a request in the meantime, but it's that elegant and I want to avoid fake HTTP requests anyway. Thanks for the pointers!

[toggledbits]

I plan to make the interval available outside the context of a request; that was just a convenient "cheat" to get it done with existing functionality.

You do know that your posted config is showing a 1ms interval, right? Maybe a little small?

[therealdb]

ouch. thanks for letting me know!

[therealdb]

@toggledbits I did a test, setting 10, 2 and 5, and it seems to me it’s in seconds indeed. Btw, It’s not indicated in the docs.

But I’m trying to prevent rules from flapping since the attribute will change regardless (even if the value is staying the same). I’ll probably just code a small controller with a single entity just to pulse every 15 secs, or something similar.

[toggledbits]

Agh... you are right... even comments in my code say ms... I must have changed my mind at some point. I will update the docs and code comments to be consistent with the actual code. Oy.

In 22308, I upped the thresholds for throttling to 120 updates per minute, and 60 changes per second. Reactor can easily handle that even on a Pi 3B+. You should not run into them unless something is truly worth looking at more closely.

Edit: turns out docs do say it's in seconds, but I'll add emphasis.

[therealdb]

yep, it's working as you suggested and I've found the mention of seconds (and of 120 updates per minute in a flapping rule).

I'm just pinging /api/v1/alive, and I hope you'll add a more granular timer natively. I need to update some aggregate home energy data every 15 secs, because the relative sensors are updating very frequently (via MQTT, as I've already reported) and I cannot watch for sensors, it will flap too easily. For now, case closed, I guess. Thanks!