[SOLVED] 'not in' being ignored latest-22240-3b3254d6
-
Updated to
latest-22240-3b3254d6tonight before leaving the house. Upon arrival at my friends a half mile away I see that the house is in bothDayandAwaymodes (which is causing havoc lol).Connected via VPN and examined some rules. It seems like the
not infield is being ignored in these rulesets:
Obviously I'm home now writing this so the
Awaywill show asfalsebut rest assured it was correctly showingtrueand this rule incidatedSETjust as theDayrule did.
Eveningdid the same thing at sunset - ignored that I was actually away and took over.
Thoughts?
-
I'm going to make myself look stupid, but 'Evening' is not in 'Away, Night, Vacation or Guest' so I'd expect it to be true.
What am I missing?
C
@catmanv2 I should clarify: these rules are untouched since before the release and have been working for a very long time.
As I said in the original post, these screenshots were taken when I was at home again in the evening. So the status, if you will, is showing
Eveningastruebecause it is.It wasn't true, however, when I was not home... yet it triggered at sunset completely disregarding the fact that I was away.
-
There was no work done in that area for this build, and hasn't been for quite a long run of builds now. It's even far longer for those specific operators (in/not in). Not sure what else to offer here. Everything looks as it should... am I missing something? The XOR on the parent group is an interesting choice, but shouldn't matter. If you can show it failing, that may be more helpful. I'll do some focused testing on it later today, but it passes my unit tests, so...
-
There was no work done in that area for this build, and hasn't been for quite a long run of builds now. It's even far longer for those specific operators (in/not in). Not sure what else to offer here. Everything looks as it should... am I missing something? The XOR on the parent group is an interesting choice, but shouldn't matter. If you can show it failing, that may be more helpful. I'll do some focused testing on it later today, but it passes my unit tests, so...
@toggledbits I won't be leaving the house until later this evening. I've done a cursory restart of MSR. Will advise upon my return tonight and capture some logs.
-
There was no work done in that area for this build, and hasn't been for quite a long run of builds now. It's even far longer for those specific operators (in/not in). Not sure what else to offer here. Everything looks as it should... am I missing something? The XOR on the parent group is an interesting choice, but shouldn't matter. If you can show it failing, that may be more helpful. I'll do some focused testing on it later today, but it passes my unit tests, so...
@toggledbits re the
XOR... that's leftover from removal of other criteria. I've cleaned that up to the defaultAND, not that it should play any role as it's been like that for quite a while. -
Just a curious onlooker here... why aren't you just letting the Hubitat set these statuses? Is it just a desire to keep all the logic in Reactor? I have Hubitat Mode Manager configured to set Day at sunrise and Night at sunset +30 except when the mode is Away. It sets Away when all users leave, sets Day when any user returns between sunrise and sunset +30, and it sets Night when any user returns between sunset +30 and sunrise. I'm using the Hubitat app for presence sensing, and it looks like you're using HASS, so maybe that makes keeping the log in Reactor a better way to go.
I have rules in Reactor that depend on the status (like switching modes in Blue Iris or changing modes on IP cameras), but the basic status determination comes from my Hubitat and it works flawlessly. Now that I said that, it's going to fail tonight
-
Just a curious onlooker here... why aren't you just letting the Hubitat set these statuses? Is it just a desire to keep all the logic in Reactor? I have Hubitat Mode Manager configured to set Day at sunrise and Night at sunset +30 except when the mode is Away. It sets Away when all users leave, sets Day when any user returns between sunrise and sunset +30, and it sets Night when any user returns between sunset +30 and sunrise. I'm using the Hubitat app for presence sensing, and it looks like you're using HASS, so maybe that makes keeping the log in Reactor a better way to go.
I have rules in Reactor that depend on the status (like switching modes in Blue Iris or changing modes on IP cameras), but the basic status determination comes from my Hubitat and it works flawlessly. Now that I said that, it's going to fail tonight
-
@alan_f I’ve centralized all my rules in MSR. How are you reliably determining presence?
Btw, @toggledbits , I’m Away and it flipped back to ‘Day’.
I’ll see what the logs look like when I get home.
-
I've pulled logs and screenshots and will upload what I can once laptop is finished syncing files.
*Hubitat C-7 2.4.1.177
*Proxmox VE v8, Beelink MiniPC 12GBs, SSD*HASS 2025.6.0
w/ ZST10-700 fw 7.18.3*Prod MSR in docker/portainer
MSR: latest-25139-fbd67abc
MQTTController: 25139
ZWave Controller: 25139 -
I've pulled logs and screenshots and will upload what I can once laptop is finished syncing files.
@gwp1 Also I will need all of your storage folder, and a complete description of the problem with enough specifics ("it changed" -- what is "it"? And how did it change and why is that not right? And the time of the event to correlate to the logs) and how each of the rules and reactions involved is intended to work. Full logs. No snips. Screenshots as well.
I will PM an upload link here for you shortly.
-
@gwp1 Also I will need all of your storage folder, and a complete description of the problem with enough specifics ("it changed" -- what is "it"? And how did it change and why is that not right? And the time of the event to correlate to the logs) and how each of the rules and reactions involved is intended to work. Full logs. No snips. Screenshots as well.
I will PM an upload link here for you shortly.
@toggledbits Uploaded.
"It" refers to
Mode.The ruleset for
AWAYis based on presence.DayandEveninghave their rulesets which govern their use and both include the exception ofAwaywhich was not being honored since I deployed 22240 (but had been previously as these rulesets are older.)I've begun looking at them in earnest to see if there's fat that could be trimmed as they are very restrictive in my attempt to avoid false triggering of presence which opens the garage door.
Dayshould be from sunrise and/or alarm clock time to sunset.
Eveningshould be from sunset until 0130 ET,Nightmode enablement (manual) or, ifAway, 2330 ET.
Awayshould be any time presence is not detected by Home Assistant plugin iCloud3. -
Got your files. I need timestamps for what you want me to look at.
-
I went on a quick fishing expedition to see if I could bulk search out anything obvious.
Unfortunately, your storage doesn't completely sync with your logs. There are IDs for rules logged that don't exist in storage. If you've been editing/restructuring rules trying to solve this since the last time you caught the problem, that could cause this. So my comment below may reflect what I'm seeing before those edits, but nonetheless...
Preliminary review of the logs shows that your "Away" logic triggers your "Day" logic and causes a house mode change. At 23:16:30.474Z the system received notification from Hubitat of a house mode change to Away. This appears to be stimulated by a global reaction called "Mode:
Away" a few milliseconds earlier. This causes the evaluation of large number of rules. It is about two seconds before that reaction completes, having set a global variable as its last step at 23:16:32.162. Among the activities in that span of time is that a rule called "Day (from Away if before sunset)" (which I don't have in your storage, so I can't examine it) goes set, and its Set reaction starts the global reaction called "Mode: Day", which then sets the Hubitat mode to Day (and that event makes a round trip back to Reactor at 23:16:32.514 causing other changes). That's a bit suspicious. Shouldn't it stay in Away? It seems like Away would be an overriding mode?Anyway, at the moment, I'm saying that "not in" works fine, and you have a logic error/unexpected interaction. There appear to be a lot of complex interactions between several reactions that are run by the rules, and I suspect you have things stomping on each other. You may also be able to see this in the Rule History and Reaction History widgets in the status view. And of course, you can always confirm the current mode Reactor thinks the system is in by looking at the Mode entity, and comparing that value to the "current value" in the status for various rules.
-
I went on a quick fishing expedition to see if I could bulk search out anything obvious.
Unfortunately, your storage doesn't completely sync with your logs. There are IDs for rules logged that don't exist in storage. If you've been editing/restructuring rules trying to solve this since the last time you caught the problem, that could cause this. So my comment below may reflect what I'm seeing before those edits, but nonetheless...
Preliminary review of the logs shows that your "Away" logic triggers your "Day" logic and causes a house mode change. At 23:16:30.474Z the system received notification from Hubitat of a house mode change to Away. This appears to be stimulated by a global reaction called "Mode:
Away" a few milliseconds earlier. This causes the evaluation of large number of rules. It is about two seconds before that reaction completes, having set a global variable as its last step at 23:16:32.162. Among the activities in that span of time is that a rule called "Day (from Away if before sunset)" (which I don't have in your storage, so I can't examine it) goes set, and its Set reaction starts the global reaction called "Mode: Day", which then sets the Hubitat mode to Day (and that event makes a round trip back to Reactor at 23:16:32.514 causing other changes). That's a bit suspicious. Shouldn't it stay in Away? It seems like Away would be an overriding mode?Anyway, at the moment, I'm saying that "not in" works fine, and you have a logic error/unexpected interaction. There appear to be a lot of complex interactions between several reactions that are run by the rules, and I suspect you have things stomping on each other. You may also be able to see this in the Rule History and Reaction History widgets in the status view. And of course, you can always confirm the current mode Reactor thinks the system is in by looking at the Mode entity, and comparing that value to the "current value" in the status for various rules.
@toggledbits What you described is exactly what I was experiencing - I'm reviewing some rulesets now. I think, over time, I've overcomplicated things due to false positives in presence detection. I miss Lobo lol
What still doesn't make sense is how this was working fine until 22240 dropped in. Unless something way downstream of this was impacted by 22240 and that ran itself back upstream resulting in my experience.
Thanks for looking at this - I'm going to begin a top>down review.
*Hubitat C-7 2.4.1.177
*Proxmox VE v8, Beelink MiniPC 12GBs, SSD*HASS 2025.6.0
w/ ZST10-700 fw 7.18.3*Prod MSR in docker/portainer
MSR: latest-25139-fbd67abc
MQTTController: 25139
ZWave Controller: 25139 -
@toggledbits What you described is exactly what I was experiencing - I'm reviewing some rulesets now. I think, over time, I've overcomplicated things due to false positives in presence detection. I miss Lobo lol
What still doesn't make sense is how this was working fine until 22240 dropped in. Unless something way downstream of this was impacted by 22240 and that ran itself back upstream resulting in my experience.
Thanks for looking at this - I'm going to begin a top>down review.
@gwp1 Changes in 22240 were really limited, and not related to Engine work at all. I think it's more likely you had a race condition between conflicting rules, and the upgrade changed the timing of the race. That can be complicated by the performance of the hub (i.e. variances in how fast it responds to requests), etc. Keep in mind that when you have a reaction start another reaction, they both run at the same time; the starter doesn't wait for the started to finish. And further, there's no guaranteed order to which resumes if both delay to the same instant in time. Unlike Reactor for Vera, which was pretty single-threaded because of the way the Lua API worked there, MSR is very asynchronous and concurrent.
One structure that can help concentrate logic into more viewable/manageable blocks is something like this:
Here, the only rule condition is that the Mode changes. The set reaction has groups with constraints for each possible mode, and the actions in that group only run if the current mode matches the constraint. But it keeps everything in one place. I don't think a lot of people are using reaction groups with constraints yet, and I'm not saying it's the right answer for you, but it's something to keep in mind.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
@gwp1 Changes in 22240 were really limited, and not related to Engine work at all. I think it's more likely you had a race condition between conflicting rules, and the upgrade changed the timing of the race. That can be complicated by the performance of the hub (i.e. variances in how fast it responds to requests), etc. Keep in mind that when you have a reaction start another reaction, they both run at the same time; the starter doesn't wait for the started to finish. And further, there's no guaranteed order to which resumes if both delay to the same instant in time. Unlike Reactor for Vera, which was pretty single-threaded because of the way the Lua API worked there, MSR is very asynchronous and concurrent.
One structure that can help concentrate logic into more viewable/manageable blocks is something like this:
Here, the only rule condition is that the Mode changes. The set reaction has groups with constraints for each possible mode, and the actions in that group only run if the current mode matches the constraint. But it keeps everything in one place. I don't think a lot of people are using reaction groups with constraints yet, and I'm not saying it's the right answer for you, but it's something to keep in mind.
@toggledbits This is very intriguing. I admit to having a ginormous amount of rules and conditions (ie, TV on closes the Living Room curtain upon Evening mode - but what if the TV was already on prior to Evening mode, we don't want the curtain closed during the daytime hours, and what if I ran out to the store and the house switched to Away mode and then back again etc.)
-
@gwp1 Changes in 22240 were really limited, and not related to Engine work at all. I think it's more likely you had a race condition between conflicting rules, and the upgrade changed the timing of the race. That can be complicated by the performance of the hub (i.e. variances in how fast it responds to requests), etc. Keep in mind that when you have a reaction start another reaction, they both run at the same time; the starter doesn't wait for the started to finish. And further, there's no guaranteed order to which resumes if both delay to the same instant in time. Unlike Reactor for Vera, which was pretty single-threaded because of the way the Lua API worked there, MSR is very asynchronous and concurrent.
One structure that can help concentrate logic into more viewable/manageable blocks is something like this:
Here, the only rule condition is that the Mode changes. The set reaction has groups with constraints for each possible mode, and the actions in that group only run if the current mode matches the constraint. But it keeps everything in one place. I don't think a lot of people are using reaction groups with constraints yet, and I'm not saying it's the right answer for you, but it's something to keep in mind.
@toggledbits So how does this approach account for the breaking out of lighting, HVAC, blinds, etc.? Is it recommended to link out to other rulesets or drive the actions right from here? That could/would result in quite a list of things happening under each of these groups, no?
-
@gwp1 Changes in 22240 were really limited, and not related to Engine work at all. I think it's more likely you had a race condition between conflicting rules, and the upgrade changed the timing of the race. That can be complicated by the performance of the hub (i.e. variances in how fast it responds to requests), etc. Keep in mind that when you have a reaction start another reaction, they both run at the same time; the starter doesn't wait for the started to finish. And further, there's no guaranteed order to which resumes if both delay to the same instant in time. Unlike Reactor for Vera, which was pretty single-threaded because of the way the Lua API worked there, MSR is very asynchronous and concurrent.
One structure that can help concentrate logic into more viewable/manageable blocks is something like this:
Here, the only rule condition is that the Mode changes. The set reaction has groups with constraints for each possible mode, and the actions in that group only run if the current mode matches the constraint. But it keeps everything in one place. I don't think a lot of people are using reaction groups with constraints yet, and I'm not saying it's the right answer for you, but it's something to keep in mind.
@toggledbits said in 'not in' being ignored latest-22240-3b3254d6:
I don't think a lot of people are using reaction groups with constraints yet
I am and I like it a lot, since you’ll end up with less rule sets and it’s definitely easier to thinker. I’m also using groups with constraints in global reactions.
--
On a mission to automate everything. -
@toggledbits said in 'not in' being ignored latest-22240-3b3254d6:
I don't think a lot of people are using reaction groups with constraints yet
I am and I like it a lot, since you’ll end up with less rule sets and it’s definitely easier to thinker. I’m also using groups with constraints in global reactions.
@therealdb I'd like to better understand the grouping you're using with this. Lights vs blinds vs presence vs HVAC, etc.
