@CatmanV2 my bad - I should have called you out for not following posting etiquette. I just recognized a scenario similar to one I run.

Here's an example of what I do for my garage overhead light:

Expanding the yellow outlined three dotted box....

Then my SET/RESET are

All told, what happens is "If the laundry room door out to the garage is opened, and the garage door is closed during the day OR it's night time/really dark outside turn on the light and leave it on for :90 after the laundry room door closes then turn it back off".

Doing it the way you're doing it, it's gonna turn off after that 180 second delay no matter what happens.

Doing it the way I'm doing it, if the laundry room door is left open... or is reopened... the light stays on. :90 is enough time to close that door and get oneself and doggo into the Jeep if leaving. If returning, :90 isn't too long to have the light on after one goes into the house.

This is where @toggledbits says "wow, that's over-complicated --- try this instead" because he usually does and is usually right LOL. (I tend to overthink/overcomplicate my automations....)

@CatmanV2 Off the top of my head, you'd want to set the Follow to 180 (three minutes).

I'd create an OR Group that contains both doors. Set the above at the Group level... in my mind that means " of either/any/both" doors, the last one closed starts the three minute timer. If any are reopened before it runs out, it restarts upon re-closure.

@SweetGenius Just catching up here - I've had this with Safari on iOS for ages. Just stalls loading, takes a few refreshes, etc.

In Brave Mobile browser it loads finger snap fast. I don't remember why I was doing it with Safari, to be honest.... perhaps that's the only browser that would let me save a link on my browser homepage? Dunno.

I use Brave on the Mac, also. And Windows... and... Linux...

@toggledbits this appears to have gone away, I've not seen it since updating. Will mark as solved.

@therealdb I just bought and installed the ZWA-2. You are right, the setup was easiest thing I've done in ages. Of concern was the fact that ZWJS-UI in Home Assistant shows the correct name, etc. but somehow references my old Zooz details.

Very odd.

But it seems to be performing fine - I'm slowly moving things over to it from my Hubitat C7 which seems not able to keep itself together of late. Huge delays, switches literally stuttering, etc.

@toggledbits is there a log that will show me what rule is turning on a specific device?

I've got a switch that has been kicking on at 2200 ET for several nights now and the reactor.log doesn't have a thing in it that I can see on a device level (it being more rules-based).

@toggledbits I just put it live.

The past few days I've had a situation wherein the dialogue blips past and then MSR is "greyed out" like it's in the background of a pop-up... but the pop-up isn't visible.

We'll see if this resolves that all.

Thank you, sir!

@toggledbits that log line is from the pop-up with the big red bar across the top I received in the UI.

    at _ClientAPI._commandTimeout (http://192.168.1.100:8111/client/ClientAPI.js:807:179

Seeing this randomly when returning to open browser tab after being away awhile. Once, maybe twice a day.

"What did you do to trigger it?" Literally nothing, just walked away and returned and there it was.

Actions taken in reasonably close proximity to this particular instance of it popping up: I'd restarted the MSR container in Portainer.

I'll try to grab some logs here shortly.

@tamorgen it would appear my backups were overwritten already. I had it set for a high number, seems an update somewhere dropped it back to the defaults.

@Crille 11.2 has some... issues... I rolled back to 11.1, tbh. ZWJSUI and my iblinds weren't playing nice at all.

@toggledbits would this be latest-25310-dc2bb580?

@toggledbits I've uploaded the two log files to folder HASS 11.0 for you.

@toggledbits I was able to grab this between meetings lol

dimming.maximum=1
dimming.minimum=0
dimming.step=0.03
light_effect.current=null
light_effect.speed=null
power_switch.state=false
x_hass.domain="light"
x_hass.entity_id="light.master_br_lamp_lamp_2"
x_hass.services=["light","lifx"]
x_hass.source="lifx"
x_hass.state="off"
x_hass_attr.brightness=null
x_hass_attr.color_mode=null
x_hass_attr.effect=null
x_hass_attr.effect_list=["effect_pulse","effect_stop"]
x_hass_attr.friendly_name="Master BR Lamp"
x_hass_attr.supported_color_modes=["brightness"]
x_hass_attr.supported_features=36

Again, haven't had time to parse the logs (silly day job) but posting these for @Pmccraw to compare/contrast as they build their case notes:

This is the rule that was working:

My other LIFX outdoor floods still work fine! I also noted that @Pmccraw is having this with another brand. My guess is that HA changed something because it started immediately after deployment of 11.0 (and I seem to recall some notes around dimming or some such but I just haven't been able to track it back).

Here's a quick grab from the log file, best I can do atm.

[latest-25308]2025-11-06T19:25:34.668Z <Engine:NOTICE> Starting reaction MBR Lamp ON (Mornings - fade-in) (re-mc83qh6e)
[latest-25308]2025-11-06T19:25:34.669Z <Engine:CRIT> Engine#1 reaction re-mc83qh6e handling while Repeat Conditions (re-mc83qh6e-1vwdp9fw) constraints result state true
[latest-25308]2025-11-06T19:25:34.680Z <Engine:NOTICE> Starting reaction MBR Lamp ON (Mornings - fade-in)/Repeat Conditions (re-mc83qh6e-1vwdp9fw)
[latest-25308]2025-11-06T19:25:34.681Z <HassController:INFO> HassController#hass perform dimming.up on Light#hass>light_master_br_lamp_lamp_2 with {  }
[latest-25308]2025-11-06T19:25:34.681Z <HassController:INFO> HassController#hass perform dimming.set on Light#hass>light_master_br_lamp_lamp_2 with { "level": 0.03 }
[latest-25308]2025-11-06T19:25:34.682Z <HassController:INFO> HassController#hass no entity/target for homeassistant.turn_on in { "fields": {  }, "target": {  } }
[latest-25308]2025-11-06T19:25:34.682Z <HassController:INFO> HassController#hass: sending payload for dimming.set on Light#hass>light_master_br_lamp_lamp_2 action: { "type": "call_service", "service_data": { "brightness": 8 }, "domain": "homeassistant", "service": "turn_on" }
[latest-25308]2025-11-06T19:25:34.685Z <HassController:INFO> HassController#hass action dimming.set({ "level": 0.03 }) on Light#hass>light_master_br_lamp_lamp_2 succeeded
[latest-25308]2025-11-06T19:25:34.686Z <Engine:INFO> Resuming reaction MBR Lamp ON (Mornings - fade-in)/Repeat Conditions (re-mc83qh6e-1vwdp9fw) from step 1
[latest-25308]2025-11-06T19:25:34.686Z <Engine:NOTICE> MBR Lamp ON (Mornings - fade-in)/Repeat Conditions delaying until 1762457254686<11/6/2025, 2:27:34 PM>
[latest-25308]2025-11-06T19:25:35.221Z <Rule:INFO> It's Too Windy (Ambient Cloud API) (rule-m34m60yh in Shared Rules) starting rule state evaluation; because entity-changed ValueSensor#hass>sensor_st_00136549_wind_speed
[latest-25308]2025-11-06T19:25:35.222Z <Rule:INFO> It's Too Windy (Fan use only) TEMPEST (rule-m77rbco8 in Shared Rules) starting rule state evaluation; because entity-changed ValueSensor#hass>sensor_st_00136549_wind_speed
[latest-25308]2025-11-06T19:25:35.222Z <Rule:INFO> It's Too Windy (Local APIs) (rule-m34nlj3i in Shared Rules) starting rule state evaluation; because entity-changed ValueSensor#hass>sensor_st_00136549_wind_speed

I actually have run into this with a LIFX white bulb as well. My temporary workaround is to create an automation in HA that controls the light and then trigger it from MSR.

@Pmccraw here are the guidelines https://smarthome.community/topic/768/category-topic-guide-read-before-posting

I pulled down the log from MSR but haven't had time to go thru it yet @toggledbits

@toggledbits

cover.state=true
position.step=0.1
position.value=1
x_hass.domain="cover"
x_hass.entity_id="cover.living_room_right_blind"
x_hass.services=["cover","switchbot_cloud"]
x_hass.source="switchbot_cloud"
x_hass.state="open"
x_hass_attr.current_position=100
x_hass_attr.current_tilt_position=100
x_hass_attr.device_class="blind"
x_hass_attr.friendly_name="Living Room Right Blind"
x_hass_attr.supported_features=176

And there's absolutely no rush on this specific item. The blind is opening and closing, just opposite of what I want it to and I'm fighting with learning HA templates to try and achieve this. Switchbot approaches tilting in a unique way.

@Fanan Ok, I'm gonna jump in here now. I just added a Switchbot Tilt Blind to my system and it is giving me the same

[object Object]

response when I go to Entities > Perform to test position.set.

Wasn't gonna say anything as @toggledbits is focused on the above items and it seemed a distraction.

I am on HA 2025.9.4 but installed the Switchbot just in the last 48 hours so didn't draw the line between them connecting the dots.

@toggledbits now I'm feeling hypocritical as I'm the guy at work chastising the Support folks for giving me screenshots for the exact reasons you noted.

Change deployed.

Got this upon restart of MSR:

    at _ClientAPI._commandTimeout (http://192.168.1.100:8111/client/ClientAPI.js:594:125)

Cleared it and refreshed the tab and all seems fine. Removing logging snippet.

Thank you, sir!

@toggledbits kicker is: this has been working for a long while. Dead iblind nodes (far too common, btw) get caught and pinged and I get the alerts on my phone.

I don't see a Global Expression called dead and, yes, I believe when I wrote this I was looking for either a status of 3 or status_text of dead.