Global Moderators group | Smart Home

toggledbits

OK. On the download server, under latest, you'll find vera_data.zip... download that and put it into your config directory, then restart.

toggledbits

At best, comparing numbers within strings is considered bad style. As @tunnus says, you're better off using epoch time format in many cases, which we could say more broadly as, there are numeric forms available that will work better (and show good programming discipline/style).

Now, your particular tests can be done in epoch time, but that may not be the best approach, since epoch time is absolute from Jan 1 1970 UTC, and you are really just looking at particular daily events. Within Reactor itself, similar calculations are done in MSM form, or Minutes Since Midnight.

Looking at your "edges" (the points in time where things change), you could set them in MSM form like this:

vFrom1 = 09 * 60 + 25,
vFrom2 = 09 * 60 + 30,
vFrom3 = 09 * 60 + 41,
vTo = 10 * 60 + 55,

You can see I am multiplying the hour by 60 and then adding the minutes, which gives minutes since midnight for each event time.

To get the current time in MSM, you can:

p=dateparts(), vToDay= p.hour * 60 + p.minute,

From there, the rest of your expression should work as you wrote it, but it will now be comparing numbers (MSM):

#Get current house temperature
CurrentHouseTemp = getEntity( "hass>Thermostat2" ).attributes.temperature_sensor.value,

case
  when CurrentHouseTemp <= 19 and vToDay >= vFrom1 && vToDay <= vTo: "true1"   # From1
  when CurrentHouseTemp <= 20 and vToDay >= vFrom2 && vToDay <= vTo: "true2"     # From2
  when CurrentHouseTemp < 26  and vToDay >= vFrom3 && vToDay <= vTo: "true3"  # From3
  else "false"
end

This doesn't change the fact that this expression won't be evaluated periodically on its own. You still need to use an Interval condition to stimulate its re-evaluation.

toggledbits

@Crille yes, already found that. Unfortunately, I don't recall what platform/install method you use, you didn't put it in your post (guidelines, please), and I haven't had time to go dig it out of other posts, which is why I haven't responded until now. That will determine what I have to do to get you the fixed file.

toggledbits

Time is never a trigger for expressions. It would basically require re-evaluation every second. There's no way for the expression evaluator to determine your intent in the expressions and find an "edge" where it would know that your conditions are changing. This is unlike the Date/Time and related conditions in the triggers, where it is usually possible to determine when the next event will occur. You should probably be using Date/Time conditions rather than expressions for logic like this.

TL;DR: that's by design. Time functions don't cause frequent re-evaluations.

Tip: you can use an Interval condition to force your rule to re-evaluate on the given interval, at which time, your local expressions will also be re-evaluated (local expressions are updated before triggers are scanned when a rule evaluation takes place).

Also: it's not correct to compare a time string to another time string. Basically, everything about this expression won't work.

toggledbits

@gwp1 said in [SOLVED] reactor_inet_check script... and containers:

Most days I'm not very smart... but I'm stubborn.

It's good to know I'm in good company.

toggledbits

OK, first, please don't screen shot text, especially code, logs, and scripts. Learn to use fenced code blocks: put three back-ticks ``` on a line by itself, then follow with the text, the close with another three back-ticks ``` on a line by itself. When formatted, it will look like this:

#!/bin/bash
# Execute the script inside the container
pct exec 101 -- bash -c "cd /home/reactor/reactor;./reactor_inet_check.sh"

The path for the script is suspicious and likely wrong. The reactor_inet_check.sh script has to be run from the Reactor install directory, and doing so would give you a script run path of ./tools/reactor_inet_check.sh. The script is built to run only this way. That's in the script header's instructions.

But also, you are trying to run the script from the Proxmox host, which I guess you can do, but it's unnecessarily hard and makes the configuration dependent on the VMID. I recommend that you run it from Ubuntu. All that's required is this in your Ubuntu root crontab:

    * * * * cd /home/reactor && ./tools/reactor_inet_check.sh

The Ubuntu /var/log/syslog should have information about the success of those runs.

If you're using Reactor access control (i.e. you are configured to required login to access Reactor), you probably will also need to add an ACL to permit the script to use the API.

toggledbits

OK. Let me know if 25016 resolved it for you.

And no, you posted correctly. Text rather than screen shot is usually better for these. I'll ask for screen shots if I need them.

toggledbits

Reactor build 25016

HOME ASSISTANT NOTE: Versions of Home Assistant earlier that 2024.1.0 are no longer supported. They may continue to work, but I won't be troubleshooting any issues that come up with them. Generally speaking, HA releases are supported one year in arears from current.

NODEJS V18 EOL: If you are using nodejs version 18, it will go off maintenance on April 15, 2025, and is therefore now deprecated. Please update to a more recent version before this date. Even-numbered LTS versions are recommended. Version 20 will go EOL in April 2026, and version 22 (recommended) in 2028.

Reaction List: Fix an error thrown when creating a new Reaction.
Dashboard: improve display of ValueSensor class objects for capabilities temperature_sensor, humidity_sensor, battery_level, and volume.
HassController: Support new vacuum activity attribute and values (see HA 2025.1 release info).
HassController: Support state for lawn mowers.
HassController: Add x_hass_system.reload_configuration and x_hass_system.restart actions.
HassController: Bless Hass to 2025.1.2

toggledbits

Confirmed. Sit tight. Patch build coming.

Also, between the "Runtime Error" and the line listed, there should have been an actual error message. Please make sure you include that when posting. Mine shows:

TypeError: this.editReaction is not a function
    at HTMLButtonElement.<anonymous> (http://192.168.0.164:8111/reactor/en-US/lib/js/reactor-ui-reactions.js:446:22)

toggledbits

OpenLuup is not Vera. There are differences in the way it operates, and I don't make any representation that I will address those differences in Reactor, and in my view it's better that openLuup addresses them if needed.

The "reload detected" message is emitted when the "loadtime" value in a user_data or status API response is different from the prior value. On Vera, this indicates that Luup has reloaded (the value is the timestamp of the reload); it remains stable otherwise. If you are seeing this message on openLuup when it hasn't reloaded, that is different from Vera Luup's native behavior.

That said, the message is informational only. The only action taken is it updates a counter that drives the x_vera_sys.reloads attribute on the system entity for the VeraController instance. Unless you are using this attribute for some purpose, it has no effect on anything and can be safely ignored.

Global Moderators

Posts

Reactor build 25016

Member List