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?

latest-amd64

We already had a brief discussion about this via DM, but here goes again. I'm using build 25325 on Docker and noticed that a date/time condition is not working properly when a time interval crosses midnight (e.g. "from 23:00 until 01:00").

@toggledbits now this other case "triggered", so I'll send you rules as JSON and logs with some explanations

@toggledbits understood. The other case I still have is two rules having partly the same logic, but those identical bits are not behaving in the same way. Just started logging those rules and the next time they behave differently I’ll send you logs along with description what was expected to happen.

@toggledbits just sent that rule as a JSON, and updated to 25292 which did not address this issue of scrolling a long rule