Need help reducing false positive notifications

[tunnus]

@toggledbits here's my users.yaml: (how should I change that?)

users:
  # This section defines your valid users. The format is:
  # username: password (one per line).

  admin: xxxxxxxx
  
groups:
  admin:
    users:
      - admin
    applications: true  # special form allows access to ALL applications
    api:
      default: allow

session:
  timeout: 43200  
  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: false

[toggledbits]

That's not up to date with current usage/structure. Refer to the users.yaml file that came in the dist-config directory, and the documentation for Access Control.

[tunnus]

@toggledbits ok, using that new file as a reference, now Restart-button is working

[toggledbits]

userauth build 24145

• Fix issue with VirtualEntityController weighted average computation (remove workarounds if you added them per earlier post).
• Make login page react to ENTER key.
• Remove dependency on user-supplied ACL for certain functions in the UI, like the Restart Reactor button on the Tools tab. These functions are now performed through the websocket interface.

If there are no further issues, this build will likely be the last on this branch, and I will be merging all the changes into latest and releasing that over the weekend or sometime next week.

[tunnus]

@toggledbits minor thing still in the docs related to time series, there's one example using "wma" name

[toggledbits]

I actually made wma a synonym for wa, so it should work either way. But, I will make the doc consistent.

[tunnus]

@toggledbits ok, thanks!

One bug might be lurking in, as I have now three virtual entities all using time series with "wa", and from time to time I'm seeing "null" value at least in one of them (sources should be stable). Still, this situation seems to be hard to reproduce, so just have to keep an eye on it. But letting you know if you'd know better what to look for.

temperature_sensor.units=null
temperature_sensor.value=null
x_virtualentity.last_request_time=null
x_virtualentity.request_failures=null
x_virtualentity.template=null
x_virtualentity.timeseries_debug=[{"time":1716579660000,"value":19.6}]
x_virtualentity.timeseries_interval=1
x_virtualentity.timeseries_retention=3

config:

...
model: time series
entity: "hass>sensor_outdoor_temperature"
attribute: "temperature_sensor.value"
interval: 5  # minutes
retention: 20  # minutes
aggregate: wa
depth: 4
precision: 1
weight:
   - 0.50  
   - 0.35  
   - 0.10  
   - 0.05  

[toggledbits]

OK. I'll do some more experiments here. Let me know if anything turns up on your end.

[tunnus]

@toggledbits this particular time series has now been stable, at least I haven't seen null values recently, but as I'm testing an other kind of series ("accel"), I'm only getting null (see below).

First, my config:

        ...
          name: "Netatmo CO2 change rate"
          capabilities:
            value_sensor:
              attributes:
                value:
                  model: time series
                  entity: "hubitat>88"
                  attribute: "x_hubitat_CarbonDioxideMeasurement.carbonDioxide"
                  interval: 5  # minutes
                  retention: 30  # minutes
                  aggregate: accel
                  depth: 5
                  precision: 2
          primary_attribute: value_sensor.value
          type: ValueSensor

and from Entities view:

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_debug=[{"time":1716813840000,"value":774},{"time":1716814140000,"value":775},{"time":1716814440000,"value":775},{"time":1716814740000,"value":760},{"time":1716815040000,"value":760},{"time":1716815340000,"value":752},{"time":1716815640000,"value":752}]
x_virtualentity.timeseries_interval=5
x_virtualentity.timeseries_retention=30

Could be a trivial configuration mistake, but I followed an example in the docs.

[toggledbits]

Acceleration is change in velocity (rate). In order to determine the change in rate, two rates have to be calculated.

The depth is used to determine the depth of the rate computation, so a depth of three would mean the rate is computed across a span of 3 samples. The first rate would therefore be computed from samples 1 and 3 (span 1-3, rate between t and t-10), and the second would be computed from samples 3 and 5 (span 3-5, rate between t-10 and t-20). The change in the two rates is computed to get the acceleration.

That means the number of samples required for the computation is 2 * depth - 1.

You have 7 samples in your time series, from t to t-30 in 5 minute increments: t, t-5, t-10, t-15, t-20, t-25, and t-30. Let's number these from 1 to 7, with 1 at t (newest) and 7 at t-30 (oldest). You've specified 5 for the depth, but that would require 9 samples, and you only have 7, so the result is null because the acceleration cannot be computed.

Reduce your span to 3 or 4, or increase your sampling period to 40 minutes if you want depth of 5 (meaning rate would be computed over the two most recent 20 minute periods).

[tunnus]

@toggledbits thanks (again)! Decreased depth to 4, and now it's working

[toggledbits]

@tunnus said in Need Testers:

now it's working

Cool. All that's explained in the docs, by the way.

[tunnus]

@toggledbits yes it's in the docs, but for accel(eration) directive, I'd prefer your explanation given here in this thread (e.g. "number of samples required for the computation is 2 * depth - 1")

[toggledbits]

The userauth branch has now been merged into the main line release path (latest), and released in build 24152. This topic is now closed. Open new topics for any new issues.

Thanks to all of you for your work in testing these changes.