Variables not updating properly

[tunnus]

In my use case I'm trying to setup a rule which would detect certain fan oscillation event. When this event happens, fan frequency oscillates between 0 and 5.8 Hz.

So I have the following rule:

One local variable called osc_timer_armed and two global variables (g_oscCount, g_oscFlag), these are all expressionless. Originally all of these were local, but that didn't work so now trying with globals as well.

The logic is that if there are at least 6 "pulses" (0 or 5.8 Hz) within a 30 minute time window, rule would then execute desired action (e.g. a notification).

Set reaction is:

The problem is that I'm never getting to the action part (group called "Action"), as g_oscCount is not updating past 1 (and therefore g_oscFlag is not set either). First "instance" of this rule is running for 30 minutes, but g_oscCount does not increase in subsequent runs.

If I'm manually running the set reaction during this waiting (delay) time, I get the following runtime error on UI:

Error: Command timeout (1398 start_reaction)
    at _ClientAPI._commandTimeout (http://192.*.*.*:8111/client/ClientAPI.js:546:201)

My hypothesis is that the first instance of the rule (running reaction) is locking these variables and other instances cannot modify them? Although could this even happen with global variables?

Build is 26011 on Docker. Didn't find any meaningful in the logs (could increase the logging level if needed).

p.s. Script action below to speed up reproducing this issue (no need for triggers, manually running set reaction is enough - the latter part of the reaction, group "Action" is not needed either)

g_oscCount = (g_oscCount ?? 0) + 1,
g_oscFlag  = ((g_oscCount ?? 0) >= 6) ? 1 : (g_oscFlag ?? 0)

[toggledbits]

@tunnus said in Variables not updating properly:

My hypothesis is that the first instance of the rule (running reaction) is locking these variables and other instances cannot modify them? Although could this even happen with global variables?

No, it doesn't work that way. When you try to re-run the reaction, it stops the running reaction and restarts a new thread. The timeout is simply because of the long delay. That's on the UI side. The UI is waiting for a "finished" response and the reaction is taking longer than the wait time. That's harmless. It has no effect on the variables.

Every test case I've tried doing this is working fine for both local and global. I assume you've restarted Reactor as part of the testing? The only issue I see is that some variable value display updates are not happening correctly while editing the rule (i.e. in the rule editor, so don't rely on those at the moment), but they are correct if you expand the rule detail in the Rules list, and the global variables are updating correctly in the Expressions list.

Your computation of g_oscFlag is... puzzling. First of all, there's no need for using g_oscCount ?? 0 in that second expression, because the first expression assures that a value is set on g_oscCount (so the ?? 0 will never be used). But more to focus on is (g_oscFlag ?? 0) as the false side expression of the ternary operator (cond ? true : false). Here, g_oscFlag will be zero until g_oscCount is >= 6, when it will become 1, but then, it will be 1 forever more, because if g_oscCount is reset to zero, for example, then the false condition will simply set g_oscFlag to itself, which is 1, not 0. Not really sure this is what you intended, and could explain why you're not getting your desired behavior. Also the variable name used in the first group isn't shown in any of the expressions, but I assume that's just a left-over of much editing/trials. Still, check that as well.

Also, in this case, you may want to use the ?# operator instead of ??. That ensures that the left side operands can be evaluated to a numeric value. If not, the expression result is the right side operator. That will handle any non-numeric values in g_oscCount (not just null).