@napalmcsr
Actually, it never worked right until I learned about boolean. No showing off, just want to understand more about xor and wondered why it worked in this flow.
[EDIT]
BTW @napalmcsr I would've shot you a smile on that post you withdrew. I'm not good enough with node red to show off.
But, I'm not a "participation trophy" generation, so my sense of humor is a little candid. (just sayin')
Your Ultimate Boolean is copied from elsewhere and is looking for 6 topics. They all get initialized as False. So ANY True and you have a difference. 5 False, one True = XOR True
Ahh .. that makes sense, so if I want any one of these sensors to stop the timer, this rule fits that bill because then all need to be false to go past and dim the light?
What do you mean? I did copy it from the other flow. Is that bad?
Yeah, I missed the original post, I see what csteele said and agree with that and also add the possibility that there might be no physical way to make all 6 inputs true at the same time. Therefore XOR would be like an OR.
That's what I was looking for and since I worked down the list on ultimate and nothing worked, it left me with xor. And it worked. I just kept thinking "different'
But, I was like, I need to know why.
I'm surprised an OR didn't work. That means only one has to be active,
Yah, or kept stopping the timer no matter what was happening. Wouldn't run through the rest of the rule. Maybe is was something I did? But I literally only changed the boolean output each time.
[edit]
without the boolean the rule was very unpredictable.
I don't think you need the Boolean at all..
You're replacing all payload with "active" (or "on" in one case) converting that from "active" to "true" then checking for True.. why not just check for Active?
@csteele @napalmcsr
I told you I thought I was going to become a boolean junkie. My kitchen and dining rely heavily on multiple motions to keep things going in there, so just about every rule can be improved with a boolean.
"active" / "inactive" is still boolean 
I think i have the original rule hang on ... i'll get it
[EDIT]
That's how I originally had it, but I couldn't figure out how work that can light into the mix and it was really unpredictable for me like that. I must've modified the original flow instead of backing it up.
think I should change it back?
Maybe I'm missing it, but the is true will never be false so will the stop timer ever be stopped?
It's gonna take me a bit to create 6 fake devices to test this out interspersed with work... but I'll get something to show....
From what I gather when I watch it run (dogs are roaming the house) when at least one device changes to active, then the flow evaluates to false. When all of the devices are inactive/off then true. Using the term that @csteele used earlier in the thread "different' .. I think
Ok, I built out the devices and applied them to the Flow.. and discarded that stuff at the end...
What it looks like you want is for the "Cans Switch" to be off, and then ANY other motion, is going to start the 30 second timer, cancelable.
Is that close?
yes as long as they're all inactive. But I want any one device to stop the timer.
I can't tell if it's what you want.. but THIS does:
"Cans" must be OFF. "On" blocks most everything else.
I altered the "Is True" to use a Regex to watch for EITHER "active" or "on"...
Another way to do something similar is to use a Change node to make the ONE exception into the same as everything else.
I change payload.value from "on" to 'inactive and from "off" to "active" then the single "Is Active" can do it all.
What's the yes or no?
Download the Hubitat app
