[Solved] alarm() in global expression throws error in log.

[Pmccraw]

Hello,
I currently have an office light (connected via a Leviton Zwave Dimmer switch) controlled from a Gen5 Aeotech Zwave switch installed on my Synology 720+ NAS. I run HA(2025.11.10) in a virtual machine from my NAS and Reactor on the container manager of the same NAS. Prior to updating to 25304 the rule I had set to turn the light on to a specific dimming value worked correctly. Now the rule appears to follow the decision tree, however the reaction does not trigger setting the dimming or turning on the office light?

Strangely I can still turn the light on and off as well as dim it directly from HASS..? I have tried using the ''try this action'' button in the rules reaction setting and it will not control the light and does not throw an error flagÉ

Please help,

P.S
Reactor has been rock steady for me over the last few years and I'm a big fan of this solution.

[toggledbits]

Please read the posting guidelines and update your original post with the information that specifies.

[Pmccraw]

sorry about this but can you provide a link to the posting guidelines.

[gwp1]

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

[Pmccraw]

thanks much for the prompt reply!

[tamorgen]

I'm running into this as well. It appears that using haas>whatever-switch and power_switch.on or power_switch.off isn't working since the 25310 update and Haas 2025.11.0. I had a few stragglers in my rule sets that stopped working. I switched to using zwavejs>whatever-switch, and it works fine.

I also tried from Entities --> whatever-switch --> Perform --> power_switch.on and there is no action performed

[gwp1]

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

[toggledbits]

I need to see device attributes for those devices (from the Entities list -- use Copy Attributes and paste as fenced code block, no screenshots please). Also would be helpful to see the hass_states.json and hass_services.json from the logs directory, but these are larger. If any of you are willing to upload them, let me know and I will provide you a link.

Edit: it looks like HA 2025.11.0 breaks the homeassistant domain commands (turn_on, turn_off). I'm digging more into that, to see if it's a change to their required parameter structure, or just brokeness, but HA does not reply with an error when those services are attempted, and that's usually what happens when parameters/service definition changes.

Edit 2: ...and a little more info. The service data published by the API in 2025.11.0 now omits the target data detail. That's odd. Maybe they are assuming that when target data is empty, just supply an entity? I need to dig through the release notes. But, easy to work around.

[gwp1]

@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

[toggledbits]

OK. I'm on this. See my previous post above yours. HA changes the way the definition of some services is published -- there's now no data/detail where there used to be data/detail. I'm not sure if that's an error they'll correct later, or if that's a new way of saying "just use the default behavior" (which in this case is pretty easy to guess). I will have a workaround update published shortly.

FWIW, specifically, from 2025.10.4:

        "homeassistant": {
            "save_persistent_states": {
                "name": "Save persistent states",
                "description": "Saves the persistent states immediately. Maintains the normal periodic saving interval.",
                "fields": {}
            },
            "turn_off": {
                "name": "Generic turn off",
                "description": "Generic action to turn devices off under any domain.",
                "fields": {},
                "target": {
                    "entity": [
                        {}
                    ]
                }
            },
            "turn_on": {
                "name": "Generic turn on",
                "description": "Generic action to turn devices on under any domain.",
                "fields": {},
                "target": {
                    "entity": [
                        {}
                    ]
                }
            },
            "toggle": {
                "name": "Generic toggle",
                "description": "Generic action to toggle devices on/off under any domain.",
                "fields": {},
                "target": {
                    "entity": [
                        {}
                    ]
                }
            },

Compare this to 2025.11.0:

        "homeassistant": {
            "save_persistent_states": {
                "fields": {}
            },
            "turn_off": {
                "fields": {},
                "target": {}    # <--- where did the detail go???
            },
            "turn_on": {
                "fields": {},
                "target": {}    # <--- where did the detail go???
            },
            "toggle": {
                "fields": {},
                "target": {}    # <--- where did the detail go???
            },

[gwp1]

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

[toggledbits]

OK... I found the PR in HA's code and the reasoning behind it. They are trying to make their data/responses more compact (performance reasons). I will have an updated build shortly for this change.

[Pmccraw]

thanks all for the quick action on this issue!

[toggledbits]

OK. Please pull 25310 (aka latest) again. I've patched HassController for this change.