Multi-System Reactor

@toggledbits

Surely in an election between all users, this is the most important "a tool to see where I'm using an entity, as trigger or condition". You have already explained before the difficulty, and that the effective use of a DB would help this crossing of information, but the cost of the DB is still high and can sacrifice a lot of the system.

One day you will find a way to #1 MSR request.

I would add one more request, that I have commented on before and I am sure you have in your notebook of improvements for the future. In the home screen, the same way you have the Recently Changed Entities board, a board that can show the history of what happens in the Set Rules, so it would be possible to follow the last actions.

And again and repeat "Thanks for the hard work @toggledbits" !

Thanks to you!
The fix is working.
Now I can truck energy consuption on Influxdb. The idea is to try to make in MSR what in HA is doing with utility_meter, Trend and Lovelace UI togheter. Maybe in future we will see a standard MSR energy plugin too.

Utility Meter

Instructions on how to integrate the Utility Meter into Home Assistant.

Trend

Instructions on how to integrate Trend binary sensors into Home Assistant.

Kinda where I figured things stood, and by all means, stay the course! About to sell my unused Ezlo Plus now, btw.

OK. In playing with this a bit more, I'm going to make suninfo.sun_angle go away (eventually; after a deprecation period), and it's replacement will be a soon-to-come suninfo.elevation. The elevation is the true angle of the sun above the horizon. Unless you live on the equator, the sun is not really at 0 degrees at solar noon, as sun_angle indicates. For example, right now for me in the Atlanta area at this time, solar noon gives me an elevation of just 33.5 degrees (summer solstice about 80 degrees). I think the true elevation will be a better metric for solar energy calculations, and in combination with azimuth, you should easily be able to compute ray angles/exposure to solar panels and good things like that.

The other things I'm fixing is that our friends in Prudhoe Bay and Tromsø are getting incorrect day lengths, etc., right now because the sun never rises at this time of year. The sunrise/sunset times are null as expected, but the day length is 24 when, IMO, it should be zero, and the sun_angle is null which is again not as useful as having a real elevation.

@toggledbits No, I guess we shouldn't spend any more time trying to understand. It works and I'm delighted. I do appreciate that you try to teach us fishing instead of handing the fish. I always try for hours before I ask for assistence. That's the way to learn and grow. Take care!

I'll get after those docs... you're not the first to be bitten.

Yep, I'm calling Vera to get the status in my system and update my internal data. MQTT is used to push the updates and it's working very well. I've noted your points and I've updated my config. I'll update the MQTTController build later tomorrow. I'm just testing all my changes in production today, to be sure everything's working.

I've also added reactor_system>* to the published controllers, and I'll use sun information later when working on my new automations based on solar.

@gwp1

I really don't know if I did something very wrong, but I consider myself an experienced person, so what I am witnessing in my Hubitat is making me extremely worried.

See the report below that I just ran, 31 nodes failing.

633ffbae-3cb8-4f34-8300-f88914027483-image.png

You comment about leaving Reactor that I'm sure was happy, and now using MSR, this opens up a huge universe of possibilities, I'm really a fan, I just hope to have a hub at the same level as MSR.

@toggledbits yeah, accounting the different kind of styles is hard, but I think this is a specific use case for advanced scenarios, so I’ll trade it for a less advanced ui.

@gwp1 said in MSR: run for two hours based on a condition, then wait 4 hours after the reset evaluating again:

@toggledbits When using pulse does it do a re-eval of the triggers to see if the reaction should be run again or will it simply rerun the reaction again?

Well, in a manner of speaking. You're thinking about it backwards, I think. It doesn't need to re-evaluate conditions at the pulse time because the condition state is always up to date, being updated when events within them occur. But I think it works as you would expect: as long as the underlying condition is true, the pulses continue; when the condition is no longer true, no more pulses.

Whether the reactions run depends on the other logic involved, but if we take the simplest case with the only condition in the rule being a repeating pulsed condition, then the rule will set at the start of the pulse (and run the Set reaction), reset at the end of the pulse (and run the Reset reaction), and repeat those reactions for each pulse.

Ref: https://reactor.toggledbits.com/docs/Condition-Options/#output-control-options

@toggledbits Let me check in the plugin 😉

I didn't mean to offend you Patrick if I have, I was just trying to work out why Meshbot rules weren't working as I expected, I like to keep an eye on what they are doing and test some of their functionality. But if you don't want to answer the question that's fine, I won't ask again.

Looks good, though I swear you might be missing a closing parenthesis at the end?

Thanks for doing the footwork, being the hands and eyes! Sorry for the trouble. Onward!

The translation might not be perfect but, your efficency is really out of this world...

Thanks.

That problem is likely the process's umask being applied, and that can't be controlled from within Reactor.

@toggledbits

Well, you put me to think a lot, I'm reviewing all the logic and I think progressing. You could have a video lesson on Creating Automations > Expressions 🙂 I am looking to meet this with trial and error. I just tested this on Groups and it worked perfectly, it will help:

Now from your last comment about the MSR visualizing the HSM, I really don't know what I have to do, the Safe Monitor you commented appears, but it is all Disarmed.

c5e7919e-b0a8-4cda-ab8b-3732df49463c-image.png

But in the HSM in the hub the rules are created, activated, and even with action alert activated.

759e9d15-f591-4ec6-87dc-d5e40bbe5810-image.png

Any recommendations on what I should do?

Thanks,

I ran the install script again and nodejs is now updated to the latest version.
pi@raspberrypi:~ $ node -v
v16.13.0
I also copied the reactor.service file as advised and MSR is working fine.

Thanks for your help

@gwp1 I think I correctly understood the use case then. The issue is that your rule set doesn't start counting the 420 seconds when the initial command is sent to the Honeywell API. The 420 seconds starts counting as soon as the setpoint is <> 65 (or 68). If you ever have the thermostats set to another value (when away, or night, or when not in heat mode) then the 'sustained for' will start counting and as soon as 420 seconds have passed, that element of the rule will go to true. You'll see it is green in the detail panel if you expand the rule set.

The thing I'm not clear on, but am making some assumptions about, is what triggers the initial call to the Honeywell API that this rule is designed to monitor/verify. Making the assumption that you turn down the thermostat at night with something like "HVAC - Heating NIGHT", and that heating is still armed and the thermostat mode is still set to heat at night, then 420 seconds after you go into night mode, every element of this rule set will be true except the Hubitat house mode rule. The rule set is primed to activate if that goes true.

So at night:

In the morning when the Hubitat mode switches from "night" to "day", this rule will go true immediately as all elements are now true.

If you add the 420 second 'sustained' to the other elements, then in the morning when the Hubitat mode switches to "day", this rule will NOT go true immediately

As long as one of the other elements goes false within 7 minutes, the rule set will never activate. The expected behavior is that the "set point has been at some other value" will go false within 7 minutes. If that doesn't happen, the whole rule set will go true and the set actions will fire including re-running the other rule set and notifying you.

I still think this could be improved as I'm pretty sure this will only fire once. If the second attempt at setting the thermostat fails, this rule will remain set and there is nothing to cause it to un-set and then re-activate. That could be your desired behavior if you want to manually fix it when it fails the first time and avoid calling the rule every 7 minutes on repeated failures.

I dealt with a lot of the same issues setting up rules for my flaky Lennox thermostat. It's still in Node-Red and looks like this:

55821e35-adfb-495c-b2b3-2a6ad7ea47bd-image.png <img src="blob:chrome-untrusted://media-app/55d4404c-a480-4453-ae24-0e6410279a3b" alt="Screenshot 2021-11-29 11.34.25.png"/>

I'm not smart/experienced/brave enough to try to replicate that in MSR yet.