Posts

• ---

  Arming Envisalink panel from MSR
  T toggledbits

  OK. EnvisalinkController won't be of much help there, since Honeywell is all I have to test with (and therefore all it currently supports). If at some point you think you may want to try it, let me know.

  Multi-System Reactor

• ---

  Arming Envisalink panel from MSR
  T toggledbits

  Gotta love AI... this thread sent me digging on the unsolved problem, and I just decided to ask Grok why I'm getting arming CIDs but not disarms... on my panel, opening reports are off by default. Thirty seconds in programming mode to enable opening reports and there they are! So now, I have parity... correct user IDs when arming and disarming (using EnvisalinkController).

  Maybe check your panel configuration and ensure both arming (closing) and disarming (opening) reports are enabled?

  Multi-System Reactor

• ---

  Arming Envisalink panel from MSR
  T toggledbits

  I've written an EnvisalinkController for Reactor that I use, rather than HA's integration, but result is somewhat consistent in that it's unexpected/inconsistent (I'm on an Ademco/Honeywell panel). For me, arming produces the right user ID in a partition CID event and email from EyezOn. But alas, state isn't consistent with EVL3/4, and there does not seem to be a corresponding disarm CID event, and the overall keypad message/status event (which must be used to detect disarming) doesn't seem to report the user slot that disarmed the alarm (nor do I get an email from EyezOn that the alarm was disarmed, which given no CID event, makes sense). A bit different from your results, but frustrating nonetheless.

  Multi-System Reactor

• ---

  [SOLVED] Conflicting Set Reaction Groups Appear to Fire Simultaneously in Single Rule Evaluation
  T toggledbits

  It's all good! Many, many, many has been the time where an extra pair of eyes helped me. That's why I'm thrilled to have my son working on this project with me now. I'm glad it was something easy (no patch and build needed). Onward!!!

  Multi-System Reactor

• ---

  [SOLVED] Conflicting Set Reaction Groups Appear to Fire Simultaneously in Single Rule Evaluation
  T toggledbits

  @gwp1 OK, so just to be clear on what I think I see, when the lights are ON as the log shows (so that the rule Master Bath Lights is SET aka true in Rule State conditions), and based on the other rule states as shown in the groups you posted above...

  This reaction group is true:

  

  And this reaction group is also true at the same time:

  

  That seems like your problem. Shouldn't that circled OR be an AND? Because in that interior group, any one of those conditions being true (the Primary Defer Controller condition specifically) will make the interior group true, and therefore the parent OR group true.

  Multi-System Reactor

• ---

  [SOLVED] Conflicting Set Reaction Groups Appear to Fire Simultaneously in Single Rule Evaluation
  T toggledbits

  In Default/Open - No Deferral, did you mean to have an "OR" in the second interior group? That looks a bit suspicious.

  Multi-System Reactor

• ---

  [SOLVED] Question regarding "in" vs "contains" vs contents of the string
  T toggledbits

  Reactor tries to be conservative about state when you edit a rule. That's to avoid whipping devices around every time you hit "Save". If you've been editing a rule and it stops behaving consistent with its intent, try the Reset Rule button first... it will wipe the entire state of the rule and force a full re-evaluation. Faster and less dramatic than restarting Reactor entirely.

  Multi-System Reactor

• ---

  [SOLVED] Conflicting Set Reaction Groups Appear to Fire Simultaneously in Single Rule Evaluation
  T toggledbits

  The first thing to do here is to look for a conflict, and when I look at your log entries, what stands out is 00:06:15 where something before the start of the snippet is causing the lights to be turned on. As you've shown the state of the reaction groups, that would make the Privacy Close and Privacy tilt groups both true at the same time.

  Reactions are run asynchronously from the rule evaluation. The rule evaluation does not capture and "lock in" all of the states of things involved in the reactions. The reactions can change the state of things as they run, and those changes may affect how later conditional reaction groups are interpreted — the evaluation of reaction group conditions happens at the moment they are encountered in execution. If it's your view that everything is frozen in time at the moment the Rule evaluation starts, that's incorrect.

  Multi-System Reactor

• ---

  [SOLVED] Question regarding "in" vs "contains" vs contents of the string
  T toggledbits

  in matches the listed (comma-separated) words exactly. partlycloudy should not match cloudy by itself. My testing bears this out. You are not showing the actual condition state, which would be preferable here (i.e. open the Rule's detail view in the Rules list). If you've been editing the rule, you may need to reset it to flush old state.

  

  Multi-System Reactor

• ---

  Reactor (Multi-System/Multi-Hub) Announcements
  T toggledbits

  Reactor build 26214

  ALL USERS: This build is strictly to address a problem for bare-metal installs only running on nodejs v22.0 through v22.11. Use node -v to show your version, or look at the startup messages in reactor.log. If your nodejs is v22.12.0 or higher, or you are running a docker image, you do not need to update to this build.

  • Workaround for module load problem in nodejs versions from 22.0 through 22.11.

  Only a bare-metal package is distributed for this build. The latest docker images are still build 26193.

  Multi-System Reactor announcements