I've noticed this issue over a few various upgrades and it doesn't always happen with every upgrade too. I haven't been able to track down why or anything that may be the cause.

I am running MSR (latest-26284-5f780cf0) in a docker on unRAID. After an upgrade and my docker restarts, some entity attributes are missing, causing the rule (or reaction) to fail when run. A quick restart of the container resolves everything and the attribute is back.

I failed to get a screenshot of the attribute list showing the (missing?) at the right of the attrib list, or within the Entities section. I did capture my overview page showing the error from the reaction running. And below that is a small list of the attribs (after the container restart.)

Is there maybe a race condition during the initial restart and reload of the attribs after an upgrade? If there is more I can supply now, please let me know. Otherwise let me know what to collect next time I see this.

This round, the issue was with a local app on my HE for my Spa. In the past, it usually is always with an Echo device. Once or twice, the issue was with one of my Hue lights. All of which are 3rd party apps on my HE.

Thank you @toggledbits. The latest-26177-3f86f4af build resolved the issue.

I upgraded the docker to version latest-26177-be756a68. Unfortunately I am still not getting my Telegram alerts unless I put the Chat ID in the GUI. I don't know if it matters, but my chat_id starts with a "-". I think I have another chat ID that does not start/show as a negative ID. I can't test with that ID though.

In looking at my reactor log file for the Telegram issue I recently posted about, I noticed I have over 40 "hass_services-YYYY-MM-DD.json" files lingering in my /reactor/logs/ directory. These go back all the way to Sept 2025. Can these be manually deleted? Or should these be removed as part of the MSR update process? I have a feeling this is how MSR "validates" the approved hass release and that the very latest file should remain. But I wanted to check before I just blew them away.

Running MSR "latest-26174-bd90c17c" via a docker within unRAID. With this latest docker update a day or two ago, Telegram stopped working. In looking at the logs, the ultimate error is that the chat_id is missing. I verified that my chat ID is still noted within the notifications YAML, but the reactor log still shows it failing. If I manually paste the chat ID into the notification field in the GUI, MSR will send the telegram message. It appears to be ignoring the "If left blank, the profile's default_chat_id value will be used."

Error log

[latest-26174]2026-06-26T18:04:45.814Z <Engine:INFO> Enqueueing "rule-2ajie2fd<SET>" (rule-2ajie2fd:S)
[latest-26174]2026-06-26T18:04:45.815Z <Engine:NOTICE> Starting reaction rule-2ajie2fd<SET> (rule-2ajie2fd:S)
[latest-26174]2026-06-26T18:04:45.815Z <Engine:INFO> rule-2ajie2fd<SET> all actions completed.
[latest-26174]2026-06-26T18:04:45.983Z <NotifyTelegram:ERR> NotifyTelegram failure response from endpoint: 400 Bad Request
[latest-26174]2026-06-26T18:04:45.983Z <NotifyTelegram:INFO> NotifyTelegram request URL: https://api.telegram.org/bot[[REDACTED]]:[[REDACTED]]/sendMessage
[latest-26174]2026-06-26T18:04:45.983Z <NotifyTelegram:INFO> NotifyTelegram request body: {"text":"Test message","chat_id":""}
[latest-26174]2026-06-26T18:04:45.983Z <NotifyTelegram:INFO> NotifyTelegram request headers: { "content-type": "application/json", "content-length": (undefined) }
[latest-26174]2026-06-26T18:04:45.983Z <NotifyTelegram:ERR> NotifyTelegram request to https://api.telegram.org/bot[[REDACTED]]:[[REDACTED]]/sendMessage message Test message
[latest-26174]2026-06-26T18:04:45.983Z <NotifyTelegram:CRIT> Error: NotifyTelegram request failed [-]
Error: NotifyTelegram request failed
    at NotifyTelegram.notify (/opt/reactor/server/lib/NotifyTelegram.js:300:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
    at async NotifyTelegram.sendNotification (/opt/reactor/server/lib/Notifier.js:189:137)
[latest-26174]2026-06-26T18:04:45.983Z <Engine:ERR> Engine#1 reaction rule-2ajie2fd:S step 1 notification (Telegram) failed: [Error] NotifyTelegram request failed [-]
[latest-26174]2026-06-26T18:04:45.983Z <Engine:CRIT> Error: NotifyTelegram request failed [-]
Error: NotifyTelegram request failed
    at NotifyTelegram.notify (/opt/reactor/server/lib/NotifyTelegram.js:300:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
    at async NotifyTelegram.sendNotification (/opt/reactor/server/lib/Notifier.js:189:137)
[latest-26174]2026-06-26T18:04:45.983Z <NotifyTelegram:ERR> NotifyTelegram failure response text: {"ok":false,"error_code":400,"description":"Bad Request: chat_id is empty"}

Snippet of the notification yaml with all the description text removed:

  # Telegram
  Telegram:
    profiles:
      default:
        description: Default Profile
        api_url: https://api.telegram.org
        bot_token: "[[REDACTED]]:[[REDACTED]]"
        default_chat_id: "[[REDACTED]]"

Docker image "latest-25264-2fbe9217" running on unRAID.
Running this in Chrome Version 140.0.7339.[128 or 208] with the same results in Edge.

The UI, when searching within the Rule Set, does not reset/self clear when you click outside of the rule set area.

To reproduce the issue:
Click on Rule Sets and type in something within the Search window that does not exist for a rule name. "french" in my example.

Click outside of the gray area, where my mouse is in the screen grabs, which will close the Rule Sets pop over.
Click on Rule Sets again and none of the rules will appear. The search term isn't sticky either.

The rules won't appear again until you type any character, or press the backspace, in the "Search for rule" field.

I don't know if my issue is related or not here. It seems like it should, but I also understand that local expression handling has changed within the last couple of builds. I don't know exactly when my issue started, nor what build I was on. My guess would be Sept 7th as my rule was last "SET" on that date.

I am running latest-25254-f6a45e41 in a docker on unRAID. The following rule has been in place for years and has been working pretty reliably, until recently.

The Set Reaction is just to turn on the shower exhaust fan. I collapsed it for screenshot space.
If I change the Local Expressions to: (and in this order)

MBath_HumityRise = "CurrentHumidity - MBath_prevHumidity"
MBath_prevHumidity = "CurrentHumidity"
CurrentHumidity = (some # value like 48)

And then manually change the CurrentHumidity value to 54 (something >=3), the rule triggers. The MBath_HumidityRise value changes to 6 too. Setting the CurrentHumidity to 50, changes the HumidityRise value to -4.

When I set these expressions back to pull from the device, I see the prevHumidity value change, but the HumidityRise value always stays 0. I set up global expression under different names and watched the values too. In the same order with the Rise expression above the Prev expression, I never see the Rise value change.

I will see if I have 25260 available for my docker update and test that, but for the life of me I cannot figure out why this rule stopped working.

EDIT: Updated to 25260 and I'm still not seeing the HumidityRise expression change. I kept my global expressions since they update and refresh on the page, where the local expressons don't appear to do so within the rule. Watching these two expressions, as soon as the prevHumidity sensor updates, the expression turns green. But the Rise expression didn't and still showed 0. In this screen grab, the humidity went from 46 to 45. I would have expected the top expression to show a -1.

Refined my actions to include a timeout, just in case someone comes home, but they leave without entering the door.

Actions:
Set variable 'lastLockEvent' to "pending entry"
Turn on porch light
Turn on driveway lights
Repeat While:
-- Triggers:
-- [lastLockEvent] contains "manually locked"
-- [OR]
-- [lastLockEvent] contains "pending entry" (condition sustained for 20 minutes)
-- Actions:
-- Delay 10 seconds
Delay random between 1 to 5 minutes
Turn off porch light
Turn off driveway lights

@toggledbits said in Feature Request - Wait for an event/trigger within Reaction:

hub variable should appear as an entity with the string_sensor capability, and it should have an extended action (x_hubitat_Variable.setVariable) to let you change the value.

Worked perfectly!

Thank you for the feedback and allowing me to type out my thoughts to refine this rule.

@toggledbits said in Feature Request - Wait for an event/trigger within Reaction:

As you disclose details, it's beginning to look like you've imagined a solution based on some other product, and you're trying to get Reactor to work its way, instead of doing it "the Reactor way."

That is very possible. I'm still mentally mapping this out too. And I 100% know that an image of my rule set would really help clear things up. I'm not in a position to get a screenshot at the moment. I'll try to put my thoughts in to text. (scary)

Rule set as of today:
Triggers:
After midnight AND
Before sunrise AND
Any Presence Sensor in the group changes from Not Present to Present

Actions:
Turn on the porch light
Turn on the driveway lights
Wait for a random period of time between 10-15 minutes
Turn off the porch light
Turn off the driveway lights

What I am after is within the Actions only. The Triggers are still the same.

Actions:
Turn on the porch light
Turn on the driveway lights
Wait until the HE Hub variable "lastDoorLockEvent" reports "Manually locked"
Wait for a random period of time between 10-15 minutes
Turn off the porch light
Turn off the driveway lights

The waiting until the hub variable is what's potentially causing the issue. When I go to bed, and assuming the door was open, I'll close it and lock it. So the hub variable now reports "Manually locked". If someone arrives after midnight and before sunrise, the variable will still report "Manually locked" since the lock status hasn't changed yet. So theoretically MSR won't wait since it already sees the variable as what it is looking for.

And as I type this out, I suppose I could insert a set variable into the actions. I honestly haven't looked yet, but can MSR set a variable that is local to the hub only? Not within MSR.

Actions:
Turn on the porch light
Turn on the driveway lights
Set HE Hub variable "lastDoorLockEvent" to "waiting entry"
Repeat Until the HE Hub variable "lastDoorLockEvent" reports "Manually locked"
Wait for a random period of time between 10-15 minutes
Turn off the porch light
Turn off the driveway lights

The entire concept stems from Hubitat's Rule Machine's "Wait for event" that you can define in a rule. I have a couple of these at my remote HE, where I can't run MSR easily.

Hmm.... Thanks for this, I think I can make it work, but it may take two Repeat While actions. It doesn't appear that I can wait for a change. It's only waiting for a True or False and not a change from Opened to Closed.

I believe in my rule I would need a "Repeat While the door is false" (open) to wait for someone to actually open the door. Then a "Repeat While the door is true" (closed) to wait for them to close the door and then continuing on the actions to turn off the lights.

I think this feature request could be accomplished with the use of two or more rules, but it would be great if there was a way to wait for an event or trigger to occur before continuing on in the reactions.

For example, I have a rule that will turn on some exterior lights if you arrive home after the porch lights have been turned off. Right now this rule randomly will turn off between 5-10 minutes after the person has entered the geofence. On some occasions this 5-10 minutes isn't long enough, say if you are unloading the car or something. I would like to kick off the reaction, but pause it part way through and wait for the door to close and lock, then continue it on. Hubitat Rule Machine has a "Wait for event" option, but I really want to keep all my logic within MSR.

I have an older Vera Plus controller that has been collecting dust for a little while. I know the hardware is no longer supported but I would prefer it to go to a good home vs the eWaste center. No charge, just pay for shipping and it's yours. If you are interested, let me know.

I love it when solutions come to you in your dreams. It dawned on me that my Hub Security on the hub was reset but I still had it enabled on MSR. As soon as I enabled it on my hub and restarted MSR, and literally had a kid walk through the entire house, every motion sensor was tripping back and forth from inactive to active back to inactive.

Running MSR latest-23344-ca53d088 within a Docker.

My Hubitat (HE) hub suffered almost a 4 day outage from a corrupt backup that failed to restore. During this time I had my MSR docker stopped. Well, I didn't stop it until the the hub had been down for 24 hours. Anyway, I finally got the hub back online this morning and am fixing my MSR rules for everything that was lost. Support needed to purge out the Apps section of the backup.

So my issue. So far everything I have fixed is working as expected, with the exception of my motion controllers. I can see them go "Active" within my HE, but the Entity within MSR never changes from false to true. I ran through a slew of rooms that have motion sensors and only 1 out of 6 changed to true.

I removed the sensor I'm testing with from Maker API, restarted MSR, re-added it, restarted MSR, but no difference. I then Deleted it from MSR and restarted MSR. It was re-added, but again no change. How can I go about testing this further to find out why/what is going on?

Hmm.. OK. I was re-reading the HubitatController section of the docs and realized that I removed my Hub Information device a couple of months back. Perhaps that was part of the issue? I put it back and then upgraded to 2.3.7.140. So far so good. Hopefully it was the missing Hub Information device, or perhaps my HE was just having an off day? I'll monitor things and report back if there is any issues. Thanks all.

Same here. Docker image latest-23344-ca53d088. And I am aware that he would need more details. I'm not reporting this has a bug since he hasn't blessed 2.3.7 yet. I actually upgraded earlier in the day and some rules were triggering just fine. It wasn't until the evening when a lot of my logic was SUPER slow, delayed, or not working at all. Which would make sense if MSR couldn't chat with the hub.
I don't subscribe to the remote backups, so I don't think that bug will effect me. But good to know, thanks.

If you are thinking about upgrading your Hubitat Elevation hub from 2.3.6 to 2.3.7, and you are using MSR.... wait! I was trying to resolve a different issue with the HE and didn't even think twice about how MSR would react. Well... MSR was not happy and was complaining that the events feed had become unresponsive. And my automations were not working either. I have since reverted back to 2.3.6 and will happily wait for @toggledbits to do his magic.

Hi @toggledbits,

I had an idea about my Echo speaking which windows or doors are open when an announcement is made reminding the family to close things up when it is hotter outside. Let me start off by saying I'm not great with expressions and in no way any programmer. To get started I read the How To: Expressions and what do you know, you have an example on how to do exactly what I am looking for. However I think I found a typo/correction that may be needed? Again, not a programmer here.

In the How To: Expressions with Entities section you state the new expression called open_perimeter_doors and give the example with the end of null : doorid. In the description you state you order them this way because when the door_sensor.state is true, the door is closed/secure. I have a few different brands of contact sensors and all of them are just the opposite. They are true when they are open and false when they are closed. For me, this was an easy fix. I swapped them.

What blew my mind and took a bit of thinking was a little further down in your example of joining the getEntity ID and getName.

join( each doorid in perimeter_doors: do
           e = getEntity( doorid ),
           e.attributes.door_sensor.state ? null : e.getName()
       done
    , ", " )

The "e.getName()" in the example would cause the expression to never evaluate. I needed to change this to "e.name". With e already being set as "getEntity( doorid )", only name was needing to be appended. In your example you are appending ".getName()", resulting in "getEntity( doorid).getName()"

Again, NOT a programmer, but perhaps a stale How To example from before a major update to the expression logic? Just wanted to share my results in case the manual does need an update.

I'm not in need of it. As I was moving off Lighting Director I just happened to notice they had a max number of lights. I think the OG DeusExMachina did too. I think how you have it would be more lifelike. Especially when you couple of a few specific OFF rules so the lights turn off faster than 10-20 minutes.