@toggledbits thanks, using an independent reaction works nicely!

@toggledbits thanks for the analysis, but I'm having a different experience. If/when I manually re-run the reaction, it does not stop the already running reaction (the one that set the delay). Also, counter (g_oscFlag) is not increasing past 1.

I fixed that script action (but that didn't make any difference):

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

"Also the variable name used in the first group isn't shown in any of the expressions"

If you mean osc_timer_armed, that is the only local expression I currently have in this rule, and that was also shown in the first screenshot in my previous post.

Did you try to reproduce this by creating an identical reaction? As it is important to have that group with delay-action. Without that (delay) variables update/increase fine, but that's the essence: delay-action is needed to create this "window" during which pulses are counted.

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 here are the lines:

{
                            "id": "cond267i1qkw",
                            "type": "entity",
                            "data": {
                                "entity": "mqtt>faikin_states",
                                "attribute": "x_mqtt_daikin.comp",
                                "op": "change",
                                "value": [
                                    "",
                                    ""
                                ]
                            },
                            "options": {
                                "holdtime": 900
                            }
                        },
                        {
                            "id": "cond267hhvhi",
                            "type": "entity",
                            "data": {
                                "entity": "mqtt>faikin_states",
                                "attribute": "x_mqtt_daikin.consumption",
                                "op": "change",
                                "value": [
                                    "",
                                    ""
                                ]
                            },
                            "options": {
                                "holdtime": 900
                            }
                        },

There's actually a working condition with a change operator in the same rule, and I just realized the issue: the value field includes quotation marks, while the working condition does not.

{
                            "id": "cond267i2ucd",
                            "type": "entity",
                            "data": {
                                "entity": "mqtt>faikin_states",
                                "attribute": "x_mqtt_daikin.fanfreq",
                                "op": "change",
                                "value": []
                            },
                            "options": {
                                "holdtime": 900
                            }
                        },

I've had similar problems before, but now this issue has resurfaced. Using build 26011 on Docker.

As I copied one old rule as a "template" for a similar new rule, where I have multiple conditions using changes operator (from any to any, and with delay reset of 900), these conditions do not detect change in attributes. Even if I manually reset the rule, reset delay timers do not restart.

If I do a new rule from scratch, and do not copy/import anything old, the same conditions work properly. Also, if I modify copied rule's conditions (put a random number to "from" & "to" fields), then save, and after that remove those modifications, rule begins to function normally. Just editing e.g. delay reset value does not do any good in this context.

@toggledbits, I can DM logs & related rule files to you, if you just send me instructions.

Using build 25328 and having the following users.yaml configuration:

users:
  # This section defines your valid users. 
  admin: *******

groups:
  # This section defines your user groups. Optionally, it defines application
  # and API access restrictions (ACLs) for the group. Users may belong to
  # more than one group. Again, no required or special groups here.
  admin_group:
    users:
      - admin
    applications: true  # special form allows access to ALL applications
    
  guests:
    users: "*"
    applications:
      - dashboard

api_acls:
  # This ACL allows users in the "admin" group to access the API
  - url: "/api"
    group: admin_group
    allow: true
    log: true
  # This ACL allows anyone/thing to access the /api/v1/alive API endpoint
  - url: "/api/v1/alive"
    allow: true
    
session:
  timeout: 7200  # (seconds)
  rolling: true  # activity extends timeout when true

# If log_acls is true, the selected ACL for every API access is logged.
log_acls: true
# If debug_acls is true, even more information about ACL selection is logged.
debug_acls: true

My goal is to allow anonymous user to dashboard, but MSR is still asking for a password when trying to access that. Nothing in the logs related to dashboard access. Probably an error in the configuration, but help needed to find that. Tried to put url: "/dashboard" under api_acls, but that was a long shot and didn't work.

Bumping this up, although a very minor issue…

With build 25328, if you copy a global reaction, a new reaction does not appear in the UI unless you do a refresh. I recall this used to work without needing this page refresh? Anyway, only a minor nuisance.

@gwp1 this is also my experience, so maybe the enhancement here could be that MSR would check reactions for missing entities even before they are run. That way you could spot those faulty reactions earlier (catching also rarely run reactions).

@toggledbits adding depth did the trick, thanks again!

@toggledbits ok, when I get back home I’ll try that. But wasn’t depth optional, i.e. defaults to 2 if not specified?

@toggledbits those were already in my previous post, or was something missing?

@toggledbits this configuration has been running for hours (retention being 60 min), and still "null"

@toggledbits I cannot get "accel" (acceleration) method to work. It used to work at some point, but at least with the latest builds (now using 25328) I'm getting "null" as a value. Entity values below:

value_sensor.units=null
value_sensor.value=null
x_virtualentity.last_request_time=null
x_virtualentity.request_failures=null
x_virtualentity.template=null
x_virtualentity.timeseries_aggregate="accel"
x_virtualentity.timeseries_debug=[{"time":1766248080000,"value":694},{"time":1766248380000,"value":694},{"time":1766248680000,"value":694},{"time":1766248980000,"value":701},{"time":1766249280000,"value":701},{"time":1766249580000,"value":691},{"time":1766249880000,"value":691},{"time":1766250180000,"value":691},{"time":1766250480000,"value":696},{"time":1766250780000,"value":696},{"time":1766251080000,"value":696},{"time":1766251380000,"value":707},{"time":1766251680000,"value":707}]
x_virtualentity.timeseries_depth=null
x_virtualentity.timeseries_interval=5
x_virtualentity.timeseries_length=13
x_virtualentity.timeseries_nextsample=1766251980000
x_virtualentity.timeseries_retention=60

And configuration from reactor.yaml:

 id: virtual9
          name: "Netatmo CO2 change rate"
          capabilities:
            value_sensor:
              attributes:
                value:
                  model: time series
                  entity: "hass>sensor_carbon_dioxide"
                  attribute: "value_sensor.value"
                  interval: 5
                  aggregate: accel
                  retention: 60 
                  precision: 2
          primary_attribute: value_sensor.value
          type: ValueSensor

When I tried to drop "retention" and used "depth" instead, got the following error:

Unable to configure time series "value_sensor.value" on "virtual9": missing required configuration 'retention'
Controller: VirtualEntityController#virtual
Last 15:56:17

Looking at the entity values, there's "x_virtualentity.timeseries_depth=null", and if depth is needed in the calculation, that could be the culprit?

Is the current manual (incl. examples) up to date with how retention value is handled in time series configuration? Referring to this post

@therealdb I guess only C-8 pro supports z-wave JS

@gwp1 I have C-8, but now considering to buy ZWA-2. I think it could speed up the migration if ZWA-2 is added as a secondary controller to Hubitat and then promoted to primary? And after that ZWA-2 is plugged into Home Assistant

Ok, I'm aware of "after" operator, and in this case didn't want to use "between 13:00 and 13:05"

Consider the following example:

This is always true, which is not always evident (e.g. when used within Reactions or there are a lot of other conditions and you miss this one being "green").

Manual says there's no "at" operator, but I was thinking could this behaviour be changed so that when date/time is specified like in my example, it would behave like "at" instead of being always true?