Reactor-Editor / Reactor-ui-Status Errors

[toggledbits]

OK. That's normal behavior if the login/session cookie expires or is no longer valid. And it's all browser-side, so the logs aren't of any value there. And it's working for me, so we may have to dig a little. Next time you are tempted to use the Restart button, just do a plain refresh on your browser and see (report) what happens.

Also, what browser are you using? And, please upload your users.yaml file (redact any plaintext passwords)

[gwp1]

@toggledbits Using Brave browser. Redacted users.yaml on it's way.

[tunnus]

Happens to me as well (Chrome + userauth-24137-57b41335 on Docker)

[toggledbits]

If you just refresh the page instead of hitting the button, does it refresh, or go to the login page?

[tunnus]

If I refresh that Tools-page, it'll go to Status-page

[toggledbits]

userauth build 24143

• Fixes something that might, perhaps, address the Restart button issue some people are having (and I cannot reproduce at all on any broser). Also adds some debug (browser side) that we might be able to access to figure it out if it persists.
• Revamps the port determination. Some of you, particularly docker users, may find that your Reactor UI shifts to port 8554, and is actually the desired location for HTTPS service.
• Updated a lot of docs, including developer docs for building controllers.

[tunnus]

@toggledbits Restart-button still does not work. Chrome:

[toggledbits]

That's ACL restriction. You probably need to give logged-in users permission to use the API, or at least, that particular API.

[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.