@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=36Again, 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_speedI 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
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.
@toggledbits whoops... guess this is one time having the system auto-update containers with new images is bad....
So I'm on the test version. Found this:
This is a Dynamic Group I'd created forever ago:
My ruleset:
I added the snippet as noted into my logging.yaml file:
When it didn't work I checked my yaml and found a spacing issue. That's been corrected, I now have a proper logger* log. Will upload to our pre-x Dropbox in folder 25248 logs along with the rule JSON file.
@toggledbits I'm watching all of this play out for now. "Leading edge vs bleeding edge" atm.
I'm very encouraged to see this doing as well in testing as it is. Anything to get me able to move off of non-privacy/non-cloud Echo devices is def getting my attention.
@toggledbits appreciate the quick turnaround on this. It def caught me off-guard.
@toggledbits Yahtzee! That did it.
So I... wasn't... crazy?
@toggledbits missed this last night - will do so this afternoon and advise.