Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Unsolved
Collapse
Discussion Forum to share and further the development of home control and automation, independent of platforms.

Global Moderators

Forum wide moderators

Private

Posts


  • Is there a way to turn this section (image in post) off?
    toggledbitsT toggledbits

    When I'm working on my laptop, this section on the right takes up about 25% of my screen width, and I never look at it or touch anything in it. Is there a way to turn it off? I've been tinkering in the settings but not finding anything effective so far.

    3720b582-eae4-4731-b0fd-8ac167b24f01-image.png

    Comments & Feedback

  • Device log?
    toggledbitsT toggledbits

    You list Hubitat and HASS as hubs, and the default logging for both of these hubs should tell you what you need to know. I've tried to keep these messages fairly consistent across the controllers, generally in this form:

    [...]2025-11-25T12:45:08.121Z <xxx:INFO> xxx#house perform power_switch.set on Switch#house>device_396 with { "state": false }
    

    Search using the canonical entity ID. There are several capabilities that can turn a light on, so searching by capability is harder. The idea is to find a perform ??? on ??? with ??? at the right time with the right entity ID.

    From there, start looking backwards for a message like either one of these:

    [...]2025-11-25T12:45:00.100Z <Engine:NOTICE> Starting reaction Parking Area Light Off (re-lk5lrx5a)
    
        or 
    
    [...]2025-11-25T12:45:08.121Z <Engine:INFO> Resuming reaction Parking Area Light Off (re-lk5lrx5a) from step 3
    

    If this line is within just a couple of lines, maybe even directly before, the perform log entry you found above, then that's the name of the Reaction that manipulated the device. If that has :S or :R at the end of its ID and the tag <SET> or <RESET> appended to the Reaction name, the Reaction is part of a Rule with that ID and name, and that is the rule that is manipulating the entity — you're done!

    If the Reaction ID doesn't have the :S or :R suffix, then the Reaction is not rule-based (e.g. it's a global reaction), and you need to find what launched it.

    If the line you've found is of the form Resuming "<reaction name>" (reaction id)" from step n, then keep looking backwards. You may find more Resuming lines for other steps of the same reaction, but your goal now is to find the line that looks like Starting "<reaction name>" (reaction id).

    Once you are on the Starting "<reaction name>" (reaction id) line, you should not have to look very far to find an Enqueuing "<reaction name>" (reaction id) line.

    Once you are on the Enqueueing line, you should not have to look very far to find another Resuming or Starting reaction line. This line may have the :S and :R on the reaction ID that you are looking for to indicate the rule that launched the reaction. If it doesn't, then the reaction was launched by another reaction, and you just repeat the above process looking for what started this reaction. This path will eventually lead to the responsible rule.

    Live example from my host this morning. The perform action we found above is for an outdoor flood light that lights a parking pad at my house. It got turned off. By what, though? Well, we already established that is was by a reaction called Parking Area Light Off because we found a Resuming line for that reaction right before the perform line for the entity. Let's keep digging to find the responsible rule. Here's are some more relevant lines from my log:

    [...]2025-11-25T12:45:00.067Z <Engine:INFO> Enqueueing "Morning Lighting Off<SET>" (rule-knjifbn1:S)
    [...]2025-11-25T12:45:00.078Z <Engine:NOTICE> Starting reaction Morning Lighting Off<SET> (rule-knjifbn1:S)
    [...]2025-11-25T12:45:00.078Z <Engine:INFO> Enqueueing "Outdoor All Off" (re-kl73syb6)
    .
    .
    [...]2025-11-25T12:45:00.088Z <Engine:NOTICE> Starting reaction Outdoor All Off (re-kl73syb6)
    [...]2025-11-25T12:45:00.089Z <Engine:INFO> Enqueueing "Parking Area Light Off" (re-lk5lrx5a)
    .
    .
    [...]2025-11-25T12:45:00.100Z <Engine:NOTICE> Starting reaction Parking Area Light Off (re-lk5lrx5a)
    .
    .
    [...]2025-11-25T12:45:00.118Z <Engine:INFO> Resuming reaction Parking Area Light Off (re-lk5lrx5a) from step 2
    [...]2025-11-25T12:45:00.119Z <Engine:NOTICE> Parking Area Light Off delaying until 1764074708119<11/25/2025, 7:45:08 AM>
    .
    .
    [...]2025-11-25T12:45:08.121Z <Engine:INFO> Resuming reaction Parking Area Light Off (re-lk5lrx5a) from step 3
    

    Working backwards from the last line, which is the Resuming line that we found earlier (reaction step 3), we find a Resuming line for the previous step (2) of that same reaction at 12:45:00.118. Notice also that reaction had a delay at that step that was logged immediately after, which accounts for the time gap between reaction steps 2 and 3.

    Keep working backwards to 12:45:00.100 and we find the Starting line for that Parking Area Light Off reaction. And continuing to look backwards for that same reaction ID, we eventually find the Enqueueing line for it (12:45:00.089). Usually these two lines are pretty close together, but it's not usual to have other things logged between.

    Now just looking backward line by line (not searching for any ID here), we soon find a Starting reaction Outdoor All Off line (12:45:00.088) very close to our Enqueueing line, indicating that Outdoor All Off launched the Parking Area Light Off reaction.

    Now we just repeat this process with Outdoor All Off — find it enqueued at 12:45:00.078 by Morning Light Off<SET> also at 12:45:00.078. The <SET> on the name and :S on the ID means it's a rule reaction, so Morning Light Off is the rule that triggered and started the sequence of two other reactions that eventually turned off the light.

    So to recap:

    1. Find the perform line (search using entity ID) that occurs at about the right time.
    2. Look backwards a short distance and you will find either a Starting <reaction> or Resuming <reaction> line. If that's a rule's SET or RESET reaction, you've found the responsible rule. Otherwise, a global reaction manipulated the entity/device, so proceed to the next step.
    3. Find what launched the current reaction. Keep looking backward until you find the Enqueueing line for it. Then very shortly preceding it, you should find a Starting <reaction> or Resuming <reaction> line for a different reaction. That's what started the current reaction. If this new reaction is a rule's SET or RESET reaction, you've found the responsible rule. Otherwise, find what launched this new (global) reaction by repeating this step.

    NOTE: Almost all actions in Reactor are asynchronous, meaning the Engine launches them in a separate process and the Engine can move on to working on a different reaction if multiple are running concurrently. Some in particular can take a lot of time (like HTTP Request). Depending on how busy your system is in that moment, all of these lines can be separated by other lines for other things going on, and you have to be careful and patient sifting through them.

    Multi-System Reactor

  • Midnight crossing not working in date/time condition (build 25325)
    toggledbitsT toggledbits

    Tested. It's working and not. It looks like if the condition is evaluated (e.g. Reactor restart or rule edited) in the period between midnight and its end time, it's getting the wrong result (should be true but reporting false). That's a regression in 25315. I've already got a fix for that based on your DM.

    What docker image are you using specifically?

    Multi-System Reactor

  • Error: Command timeout
    toggledbitsT toggledbits

    You might also try 25325 now and see if it goes away (or at least becomes less frequent -- there may be more than one similar case to one fixed in that release).

    Multi-System Reactor

  • Reactor (Multi-System/Multi-Hub) Announcements
    toggledbitsT toggledbits

    Reactor build 25325

    • Rules/Expressions: fix an additional evaluation case from @Crille
    • UI: silence an error that could occur during restarts (the shutdown process could stimulate the Set Rules status widget to fire queries at the inoperative host that eventually time out).
    • HassController: Bless HA to 2025.11.3
    Multi-System Reactor announcements

  • Error: Command timeout
    toggledbitsT toggledbits

    Got it. OK, next time it pops up, open the Developer Tools windows on your browser, and in the Console tab, you should see a similar message with the pre-roll context -- copy-paste a bunch of that here and let's see what it can be.

    Multi-System Reactor

  • Error: Command timeout
    toggledbitsT toggledbits

    Timeouts within proximity to a restart are not a concern. And when I say "proximity", I mean 30 seconds because that's the default timeout period.

    Host-side logs won't reveal anything here. If you want to look at logs, it's browser-side developer console that will have info. No screen shots, please, copy-paste text is far preferable. Also need to know browser version/details. And need to know if you are using login authentication or straight-in access.

    Also, please remember the posting guidelines. Posting the one line with an error message isn't within those guidelines. There should be 20-25 lines of context preceding, always. Looking at one line with no context has about zero chance of leading me to any conclusions.

    Multi-System Reactor

  • [Solved] Local expression in Rule does not evaluate as they used to do
    toggledbitsT toggledbits

    Try build 25323 just posted.

    Multi-System Reactor

  • Reactor (Multi-System/Multi-Hub) Announcements
    toggledbitsT toggledbits

    Reactor build 25323

    • Rule-based Variables: correct an error handling dependency evaluation of subscoped variables.
    • SystemController: prevent spurious exception that could be thrown while shutting down Reactor. It had no effect, but it's preventable and I like my logs error-free.
    Multi-System Reactor announcements

  • [Solved] Local expression in Rule does not evaluate as they used to do
    toggledbitsT toggledbits

    First question is, does the behavior change if you restart Reactor?

    If not, then put the rule into level 5 logging as shown in the numbered steps in this post, restart Reactor, get the rule to run its challenge, and then send me the entire log file and your reactor.log file. I will PM you a link for the uploads.

    Multi-System Reactor

Member List

CatmanV2C CatmanV2
therealdbT therealdb
toggledbitsT toggledbits
akbooerA akbooer
DesTD DesT
rafale77R rafale77
  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Unsolved