Posts made by toggledbits | Smart Home

toggledbits

OK. That's enough info to determine it's a NUT problem (or driver problem), at least.

You may want to look at this. You should be troubleshooting at the Network UPS Tools level, looking at your (operating) system log files. Restarting the service isn't going to fix it.

toggledbits

@wmarcolin said in Throttled problem:

remembering that every 10 minutes I stop and restart the service to mitigate the problem.

OK. So basically, the log is showing exactly that. It's showing that every 10 minutes, the NUT service is closing the connection, and the service takes 60 seconds, almost exactly, to restart before NUTController can connect to it.

Try turning off the 10 minute restart and see what it does.

toggledbits

@wmarcolin pull the 25026 release of NUTController. I made some changes to the recovery discipline and added more info messages. Let's see if it helps us get to the bottom of this.

toggledbits

@gwp1 said in Catch-all lights rule:

Once upon a time you told me to add even a random comment as a placeholder for reset reaction if I had no actually reset action. That's what is in each of these.

I'm pretty sure there was more context to that advice. Go find it. Let's have a look.

@gwp1 said in Catch-all lights rule:

This may be another case of me making things more complicated than they need to be...

Yeah, not what I would chose.

Why not something like this:

Make a rule that detects if any of the controlled lights is on (i.e. an OR group when there are multiple devices). I'll call it "Any Light On"
Your "Lights ON" rule is (AND group, with sustained for 300 seconds option):
- solarRadiation < 14
- Rule "Any Light On" is FALSE
Your "Lights OFF" rule is (AND group, with sustained for 300 seconds option):
- solarRadiation >= 14
- Rule "Any Light On" is TRUE

The SET reactions for each should be obvious (run your ON or OFF reaction). The RESET reactions should be (completely) empty.

The "sustained for 300 seconds" will provide 5 minutes of hysteresis:

Once it gets dark enough and has been that way for 5 minutes with no lights on, it will turn the lights on;
Once it gets light enough and has been that way for 5 minutes with lights on, it will turn them off;
If it's dark and the lights are turned off, they will turn back on in 5 minutes. If you want that faster, reduce the sustain period on "Lights ON"
If it's light and the lights are turned on, they will stay on for 5 minutes, then get turned off. Adjust "Lights OFF" sustain to suit.

This is pretty much exactly how my kitchen undercabinet strips are controlled (motion sensing and house mode are also part of it, but not applicable here).

toggledbits

You're not showing your RESET reactions for either rule.

Edit: by the way, neither rule is looking at the lights, so when you say things like "the lights find themselves turned off after dark and they will turn themselves back on" and "wherein if it is daytime and the lights somehow find their way ON, they will turn themselves back OFF", you're not showing anything that literally does that. It would only happen by accident if/when solarRadiation changes, because that's the only thing you are looking at.

Logs aren't angry at all. One message is missing a piece of data, but other than that, this looks as expected. Are you forgetting that the changes operator with no terminal values is just a pulse? So the rule(s) would be expected to set and reset very quickly, which it appears they are doing. It also appears that at least the "Lights OFF" rule has something in the reset reaction, so when the rule resets, the running set reaction will be stopped before it finishes (or maybe even before it starts), and the reset will be run. That's documented behavior. If you don't want your set reaction to be pre-empted, your reset reaction has to be completely empty, not even a comment.

toggledbits

Somewhere between...

[latest-25016]2025-01-25T02:06:47.511Z <NUTController:INFO> NUTController#nut client ready

and

[latest-25016]2025-01-25T02:10:03.774Z <NUTController:NOTICE> NUTController#nut starting NUT client with "192.168.50.8":3493; waiting for ready...

is another message I need to see. NUTController will log the reason for a disconnect prior to reconnecting.

Using a time series is a band-aid that may mask the symptom but won't fix the problem. I don't recommend it, because it really doesn't reduce the system load -- it still needs to handle the change notifications, it's just doing it in a different subsystem.

toggledbits

when I have a UPS problem the NUT is sending dozens of reports per second

What's the UPS problem? Maybe that could be addressed in NUTController if its some odd failure mode of NUT that I can detect?

What you likely don't want to do is allow the issue to place an even larger load on the system by increasing the throttling limit.

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.

toggledbits

Also see the edit I just made regarding your test. Apologies for brevity. I'm on the run today.

toggledbits

@gwp1 said in Migrating MSR to Docker on Proxmox:

Shamefully going to ask when that was added.

Check the release notes.

@gwp1 said in Migrating MSR to Docker on Proxmox:

I even did a test Rule Set > Rule create/del and all is well.

Make sure you restart Reactor after doing a create, and make sure the rule still exists, and then delete it, restart, and make sure it stays gone after the restart. If not, your storage permissions don't have sufficient write privileges. The reason for this particular sequence is that Reactor caches writes to reduce load on flash memories (like the MicroSD cards typical of Pi's), so it may be several minutes before stuff in memory is written to disk. Restarting Reactor forces the write during shudown.

toggledbits

@gwp1 said in Migrating MSR to Docker on Proxmox:

The log shows this,

Look at the startup messages. Reactor loads the global expressions at startup. That's where the useful messages will be.

@gwp1 said in Migrating MSR to Docker on Proxmox:

What file do Global Expressions live in?

They live in storage/expressions.json, but recent similar experience suggests that if one file has broken permissions, many do, so whatever you learn from that one file will likely need to be applied to many. Log in to your virtual machine, do ls -la from inside the storage subdirectory, and post the entire output. Also fetch http://reactor-ip-address:port/api/v1/system and post that output.

By the way, it's also plausible that you haven't mapped your docker container to the right directory. Can you describe how you are launching the docker container, and post any commands you may have executed doing that?

toggledbits

Lights switches for warehouse

Catch-all lights rule

Throttled problem

Dynamic Alert Based on Tripped Expression

latest-25016 toggle.toggle on VeraController Lock entity not working

[Solved] Local expression evaluation

Hello and first network question

[SOLVED] reactor_inet_check script... and containers

Apple Home Automation Issue

Migration Vera to HA > how to send sensor data from Vera to HA?

[Solved] Migrating MSR to Docker on Proxmox

Runtime error latest-24366 when Create New Reaction

Reactor (Multi-System/Multi-Hub) Announcements

'Random' lights turning on

Vera reload detected where there does not appear to be one.

Has something changed with the "Changes" operator in Constraint groups ?

Reactor-Editor / Reactor-ui-Status Errors

[Solved] Error dialog running reaction in build 24302

every X days field uneditable

[Reactor] Use VirtualEntityController actions to drive a Reolink spotlight

Posts

Reactor build 25016