Catch-all lights rule
-
Background: this is a Windows MSR install I've done for our local pool/amenity center just to run some fans and lights (not my daily driver at home). Install went perfectly fine.
Scenario: I want the lights to go on when it's dark enough (even if during a storm, not just after sunset) so I'm using
solarRadiationfrom my weather station to drive thatTrigger. Easy stuff.Issue: sometimes, someone goes in the office and just starts flipping switches and the result can be lights turned on in the daytime or off at night. I'm trying to create a "catch-all" wherein if it is daytime and the lights somehow find their way ON, they will turn themselves back OFF.
I have the following
Reactionbuilt:
I also have this
Reactionfor opposite, ie the lights find themselves turned off after dark and they will turn themselves back on:
Here are my two
rules:
*NOTE that in my manual testing, ie I turn on the light switch at the incorrect time, when the solarRadiationlevel changes theLights ONrule flags and shows asSET. On the next change ofsolarRadiationit goes back toresetagain.My expectation is that
Lights OFFrule should see the lights are on, thesolarRadiationis above the set limit, and turn them off. Instead, every other run, the ON rule moves toSETand thenresetagain on the following run.Logs appear angry:
[latest-25016]2025-01-26T22:03:31.696Z <Engine:INFO> Enqueueing "Lights ON<RESET>" (rule-m6e4ajh7:R) [latest-25016]2025-01-26T22:03:31.712Z <Engine:NOTICE> Starting reaction Lights ON<RESET> (rule-m6e4ajh7:R) [latest-25016]2025-01-26T22:03:31.713Z <Engine:INFO> Lights ON<RESET> all actions completed. [latest-25016]2025-01-26T22:03:42.565Z <wsapi:INFO> client "127.0.0.1#3" closed, code=1001, reason= [latest-25016]2025-01-26T22:03:42.753Z <httpapi:INFO> [HTTPAPI]#1 API request from ::ffff:127.0.0.1: GET /api/v1/lang [latest-25016]2025-01-26T22:03:42.754Z <httpapi:INFO> [HTTPAPI]#1 request for /api/v1/lang from ::ffff:127.0.0.1 user anonymous auth none matches /api/v1/lang ACL (#7): [Object]{ "url": "/api/v1/lang", "allow": true, "index": 7 } [latest-25016]2025-01-26T22:03:42.790Z <wsapi:INFO> wsapi: connection from ::ffff:127.0.0.1 [latest-25016]2025-01-26T22:03:42.839Z <wsapi:INFO> [WSAPI]wsapi#1 client "127.0.0.1#6" authorized [latest-25016]2025-01-26T22:03:43.353Z <httpapi:INFO> [HTTPAPI]#1 API request from ::ffff:127.0.0.1: GET /api/v1/systime [latest-25016]2025-01-26T22:03:43.353Z <httpapi:INFO> [HTTPAPI]#1 request for /api/v1/systime from ::ffff:127.0.0.1 user anonymous auth none matches /api/v1/systime ACL (#5): [Object]{ "url": "/api/v1/systime", "allow": true, "index": 5 } [latest-25016]2025-01-26T22:03:48.146Z <wsapi:INFO> client "127.0.0.1#6" closed, code=1001, reason= [latest-25016]2025-01-26T22:03:48.308Z <httpapi:INFO> [HTTPAPI]#1 API request from ::ffff:127.0.0.1: GET /api/v1/lang [latest-25016]2025-01-26T22:03:48.309Z <httpapi:INFO> [HTTPAPI]#1 request for /api/v1/lang from ::ffff:127.0.0.1 user anonymous auth none matches /api/v1/lang ACL (#7): [Object]{ "url": "/api/v1/lang", "allow": true, "index": 7 } [latest-25016]2025-01-26T22:03:48.346Z <wsapi:INFO> wsapi: connection from ::ffff:127.0.0.1 [latest-25016]2025-01-26T22:03:48.390Z <wsapi:INFO> [WSAPI]wsapi#1 client "127.0.0.1#7" authorized [latest-25016]2025-01-26T22:03:49.412Z <httpapi:INFO> [HTTPAPI]#1 API request from ::ffff:127.0.0.1: GET /api/v1/systime [latest-25016]2025-01-26T22:03:49.413Z <httpapi:INFO> [HTTPAPI]#1 request for /api/v1/systime from ::ffff:127.0.0.1 user anonymous auth none matches /api/v1/systime ACL (#5): [Object]{ "url": "/api/v1/systime", "allow": true, "index": 5 } [latest-25016]2025-01-26T22:03:52.734Z <wsapi:INFO> client "127.0.0.1#7" closed, code=1001, reason= [latest-25016]2025-01-26T22:03:52.891Z <httpapi:INFO> [HTTPAPI]#1 API request from ::ffff:127.0.0.1: GET /api/v1/lang [latest-25016]2025-01-26T22:03:52.892Z <httpapi:INFO> [HTTPAPI]#1 request for /api/v1/lang from ::ffff:127.0.0.1 user anonymous auth none matches /api/v1/lang ACL (#7): [Object]{ "url": "/api/v1/lang", "allow": true, "index": 7 } [latest-25016]2025-01-26T22:03:52.925Z <wsapi:INFO> wsapi: connection from ::ffff:127.0.0.1 [latest-25016]2025-01-26T22:03:52.965Z <wsapi:INFO> [WSAPI]wsapi#1 client "127.0.0.1#8" authorized [latest-25016]2025-01-26T22:03:54.383Z <httpapi:INFO> [HTTPAPI]#1 API request from ::ffff:127.0.0.1: GET /api/v1/systime [latest-25016]2025-01-26T22:03:54.384Z <httpapi:INFO> [HTTPAPI]#1 request for /api/v1/systime from ::ffff:127.0.0.1 user anonymous auth none matches /api/v1/systime ACL (#5): [Object]{ "url": "/api/v1/systime", "allow": true, "index": 5 } [latest-25016]2025-01-26T22:04:01.590Z <wsapi:INFO> [WSAPI]wsapi#1 rpc_echo [Object]{ "comment": "UI activity" } [latest-25016]2025-01-26T22:04:39.646Z <Rule:INFO> Lights OFF (rule-m6e33ja3 in Atrium Lights) evaluated; rule state transition from RESET to SET! [latest-25016]2025-01-26T22:04:39.656Z <Rule:INFO> Lights ON (rule-m6e4ajh7 in Atrium Lights) evaluated; rule state transition from RESET to SET! [latest-25016]2025-01-26T22:04:39.663Z <Engine:INFO> Enqueueing "Lights OFF<SET>" (rule-m6e33ja3:S) [latest-25016]2025-01-26T22:04:39.665Z <Engine:INFO> Enqueueing "Lights ON<SET>" (rule-m6e4ajh7:S) [latest-25016]2025-01-26T22:04:39.668Z <Engine:NOTICE> Starting reaction Lights OFF<SET> (rule-m6e33ja3:S) [latest-25016]2025-01-26T22:04:39.669Z <Engine:NOTICE> Starting reaction Lights ON<SET> (rule-m6e4ajh7:S) [latest-25016]2025-01-26T22:04:39.669Z <Engine:INFO> Lights ON<SET> all actions completed. [latest-25016]2025-01-26T22:04:39.675Z <Rule:INFO> Lights OFF (rule-m6e33ja3 in Atrium Lights) evaluated; rule state transition from SET to RESET! [latest-25016]2025-01-26T22:04:39.680Z <Engine:NOTICE> ReactionHistory: no entry for [latest-25016]2025-01-26T22:04:39.683Z <Engine:NOTICE> [Engine]Engine#1 entry 256 reaction rule-m6e33ja3:S-1q2f1j0p: [Error] terminated [parent terminating] [latest-25016]2025-01-26T22:04:39.683Z <Engine:CRIT> Error: terminated [parent terminating] Error: terminated at Engine._process_reaction_queue (C:\Users\Jalan\msr\reactor\server\lib\Engine.js:1644:47) [latest-25016]2025-01-26T22:04:39.699Z <Engine:NOTICE> [Engine]Engine#1 entry 254 reaction rule-m6e33ja3:S: [Error] terminated [preempted by rule state change] [latest-25016]2025-01-26T22:04:39.699Z <Engine:CRIT> Error: terminated [preempted by rule state change] Error: terminated at Engine._process_reaction_queue (C:\Users\Jalan\msr\reactor\server\lib\Engine.js:1644:47) [latest-25016]2025-01-26T22:04:39.700Z <Engine:INFO> Enqueueing "Lights OFF<RESET>" (rule-m6e33ja3:R) [latest-25016]2025-01-26T22:04:39.704Z <Engine:NOTICE> Starting reaction Lights OFF<RESET> (rule-m6e33ja3:R) [latest-25016]2025-01-26T22:04:39.705Z <Engine:INFO> Lights OFF<RESET> all actions completed. [latest-25016]2025-01-26T22:05:48.822Z <Rule:INFO> Lights ON (rule-m6e4ajh7 in Atrium Lights) evaluated; rule state transition from SET to RESET! [latest-25016]2025-01-26T22:05:48.831Z <Engine:INFO> Enqueueing "Lights ON<RESET>" (rule-m6e4ajh7:R) [latest-25016]2025-01-26T22:05:48.847Z <Engine:NOTICE> Starting reaction Lights ON<RESET> (rule-m6e4ajh7:R) [latest-25016]2025-01-26T22:05:48.847Z <Engine:INFO> Lights ON<RESET> all actions completed. -
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
solarRadiationchanges, 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.
-
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
solarRadiationchanges, 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 Interesting. Once upon a time you told me to add even a random comment as a placeholder for
reset reactionif I had no actually reset action. That's what is in each of these. -
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
solarRadiationchanges, 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 Interesting. Once upon a time you told me to add even a random comment as a placeholder for
reset reactionif I had no actually reset action. That's what is in each of these.@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).
-
@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 sorry for the delay, day job has a rude habit of interfering in fun.
This solution worked perfectly for this need. It's actually quite similar to how I control the outdoor garden fountain, HVAC, and some other things. As usual, I tried to over-complicate things.
EDIT: in fact, I find I am using this EXACT method for my outdoor LIFX lights. sigh
I am still looking for that context. Will provide when I locate it.
