Global Moderators
Forum wide moderators
Posts
-
Is there a way to turn this section (image in post) off? -
Device log?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 3If this line is within just a couple of lines, maybe even directly before, the
performlog entry you found above, then that's the name of the Reaction that manipulated the device. If that has:Sor:Rat 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
:Sor:Rsuffix, 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 moreResuminglines for other steps of the same reaction, but your goal now is to find the line that looks likeStarting "<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 anEnqueuing "<reaction name>" (reaction id)line.Once you are on the
Enqueueingline, you should not have to look very far to find anotherResumingorStartingreaction line. This line may have the:Sand:Ron 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
performaction 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 aResumingline for that reaction right before theperformline 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 3Working backwards from the last line, which is the
Resumingline that we found earlier (reaction step 3), we find aResumingline for the previous step (2) of that same reaction at 12:45:00.118. Notice also that reaction had adelayat 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
Startingline for that Parking Area Light Off reaction. And continuing to look backwards for that same reaction ID, we eventually find theEnqueueingline 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 Offline (12:45:00.088) very close to ourEnqueueingline, 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:Son 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:
- Find the
performline (search using entity ID) that occurs at about the right time. - Look backwards a short distance and you will find either a
Starting <reaction>orResuming <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. - Find what launched the current reaction. Keep looking backward until you find the
Enqueueingline for it. Then very shortly preceding it, you should find aStarting <reaction>orResuming <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.
- Find the
-
Midnight crossing not working in date/time condition (build 25325)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?
-
Error: Command timeoutYou 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).
-
Reactor (Multi-System/Multi-Hub) AnnouncementsReactor 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
-
Error: Command timeoutGot 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.
-
Error: Command timeoutTimeouts 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.
-
[Solved] Local expression in Rule does not evaluate as they used to doTry build 25323 just posted.
-
Reactor (Multi-System/Multi-Hub) AnnouncementsReactor 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.
-
[Solved] Local expression in Rule does not evaluate as they used to doFirst 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.logfile. I will PM you a link for the uploads.
