Oh, I have a the medium one at our beach house and I like it. The xl is another league, but the medium one is the perfect one for cozy rooms.

I have a scene controller where I basically "commented" (aka disabled) actions because I was testing new things.

When pressing the button, every group is executed. The first is correct, the others two not. Removing them is obviously working.

newscene is a simple variable getting getEntity( "mqtt>shelly_masterbedroom_scenecontroller_2" ).attributes.button.state.

I'm not sure if this is new, but I think it's not expected.

@toggledbits is alarm() a new thing? What's the best example to understand its use? IE: A global variable named christmas_time, that will be updated every hour/day with dateparts()? Thanks.

Thanks! I managed to get the 4 buttons, a nice feature for the wife.

Unfortunately, it's not POE, but it was easy for me to pull a cable. It has a relay, but I'm not using it ATM.

In the coming weeks I'll mount the second one on the second floor. The custom firmware has both MQTT and HTTP APIs, so it's easy to synchronize them.

Here we go. This wall is still original, so height is temporary. Since it's concrete, I'll address this later and I'll move it lower.

Our house is very bright, so the photos are not good, but in person it's OK.

I don't know if you guys are into dashboards, but I am.

For a second home I tried the Shelly Wall Display 2, and while not so big, it worked well over the summer.

Since we're remodeling our house, I just swapped my old Fire Tablet (with its own problems) with two new Shelly Wall Display XL. I just removed the standard firmware, and I added mine (https://github.com/dbochicchio/ShellyElevate), forked from https://github.com/RapierXbox/ShellyElevate

I just managed to support buttons (this thing has 4 of them) and it's all auto-discovered by Home Assistant and accessible via Reactor.

I also have a new build in the works with support for buttons inside HA.
I added a bonus Javascript interface sending events (screen/screensaver status, buttons, motion) to automatically drive the dashboard (all doing in HTML+Javascript and monitoring Reactor's variable).

This specifical thing excluded, go get one of them, the device has a decent CPU for HA dashboards and blends wonderfully in the decor.

I don't know if there's a UI option, but when I migrated things, I just stopped reactor, opened the files and removed everything from reactor/storage/entities/zwavejs (after a backup). And start again, of course. It's brutal for sure, but it worked.

@toggledbits said in Strange behavior for MQTT templates using payload and attributes:

See the problem now?

You have control over the order in which the attributes are processed for the topic/event.

I see it! Thanks! (Never code in a hurry while doing 100 other things).

25272: Fixes for shelly_scenecontroller to better handle multiple pushes of the same button.

No joy from the logs. I added parens but no joy. The only thing that worked was a delete of the entity/restart of Reactor.

[latest-25272]2025-09-30T14:49:47.414Z <MQTTController:5:MQTTController.js:599> MQTTController#mqtt topic shellies/shelly-gatebutton/input_event/0 associated with Array(1)[ "shelly_gatebutton" ]
[latest-25272]2025-09-30T14:49:47.414Z <MQTTController:5:MQTTController.js:601> MQTTController#mqtt dispatching shellies/shelly-gatebutton/input_event/0 to shelly_gatebutton
[latest-25272]2025-09-30T14:49:47.414Z <MQTTController:5:MQTTController.js:1152> MQTTController#mqtt handling shellies/shelly-gatebutton/input_event/0 (event shellies/shelly-gatebutton/input_event/0) for shelly_gatebutton: {"event":"","event_cnt":2}
[latest-25272]2025-09-30T14:49:47.415Z <MQTTController:5:MQTTController.js:1168> MQTTController#mqtt topic shellies/shelly-gatebutton/input_event/0 affects entity shelly_gatebutton attributes value_sensor.value, button.since, scene_activation.since, button.state, scene_activation.scene_id, x_mqtt_device.online
[latest-25272]2025-09-30T14:49:47.415Z <MQTTController:5:MQTTController.js:1274> MQTTController#mqtt topic shellies/shelly-gatebutton/input_event/0 setting shelly_gatebutton value_sensor.value=2
[latest-25272]2025-09-30T14:49:47.415Z <MQTTController:5:MQTTController.js:1274> MQTTController#mqtt topic shellies/shelly-gatebutton/input_event/0 setting shelly_gatebutton button.since={"event":"","event_cnt":0}
[latest-25272]2025-09-30T14:49:47.416Z <MQTTController:5:MQTTController.js:1274> MQTTController#mqtt topic shellies/shelly-gatebutton/input_event/0 setting shelly_gatebutton scene_activation.since={"event":"","event_cnt":0}
[latest-25272]2025-09-30T14:49:47.416Z <MQTTController:5:MQTTController.js:1274> MQTTController#mqtt topic shellies/shelly-gatebutton/input_event/0 setting shelly_gatebutton button.state=unknown
[latest-25272]2025-09-30T14:49:47.416Z <MQTTController:5:MQTTController.js:1274> MQTTController#mqtt topic shellies/shelly-gatebutton/input_event/0 setting shelly_gatebutton scene_activation.scene_id=
[latest-25272]2025-09-30T14:49:47.417Z <MQTTController:5:MQTTController.js:1274> MQTTController#mqtt topic shellies/shelly-gatebutton/input_event/0 setting shelly_gatebutton x_mqtt_device.online=true
[latest-25272]2025-09-30T14:49:47.417Z <MQTTController:5:MQTTController.js:1905> MQTTController#mqtt _handle_ext_event() shellies/shelly-gatebutton/input_event/0 matches 0 subscriptions

Maybe it's something that when it's corrupted with json, doesn't work as expected. I'm reporting as an edge case, but it's very hard to reproduce. Thanks anyway. New build for my MQTT-contrib incoming.

I'm re-writing my shelly_scenecontroller mqtt template because I added a new pushbutton and I had strange results. Basically, in the last couple of days, it fired itself, because of the way the logic works. Everytime I'm pushing a button, an "S" is sent as the event, so the button.state never changes. I'm looking for button.since to determine if the button is pressed again.
That's good, but everytime a poll is done, the button.since attribute is updated, because it is tied to time().

reactor-mqtt-contrib/shelly_gen1.yaml at 8bf5022f6b8ee80feed3d881befc119a1f58fcdc · dbochicchio/reactor-mqtt-contrib

Contrib MQTT templates for Reactor. Contribute to dbochicchio/reactor-mqtt-contrib development by creating an account on GitHub.

So, I introduced the use of event_cnt from the payload, comparing the value to the stored one, in order to understand if it has been pushed again, or, in general, the number of times the button is pushed.
Updated template:

    events:
      "shellies/%topic%/input_event/%channel%":
        - attribute: "value_sensor.value"
          json_payload: true
          expr: "float(payload?.event_cnt)"
        - attribute: "button.since"
          json_payload: true
          expr: >
            entity.attributes?.button?.since == null || 
            float(payload?.event_cnt) != entity.attributes?.value_sensor?.value
              ? time() : entity.attributes.button.since
        - attribute: "scene_activation.since" # just copy button.since
          expr: "entity?.attributes?.button?.since"
        - attribute: "button.state"
          json_payload: true
          expr: >
            payload?.event == "S" ? "single" :
            payload?.event == "SS" ? "double" :
            payload?.event == "SSS" ? "triple" :
            payload?.event == "L" ? "long" :
            "unknown"
        - attribute: "scene_activation.scene_id"
          json_payload: true
          expr: "payload?.event"
        - attribute: "x_mqtt_device.online"
          expr: true

This should work, but instead I have this value:

and that's beyond strange and I can't honestly figure it out. @toggledbits any hint is appreciated. Thanks.

@toggledbits I have a couple of routines (previously working OK) that are checking for various things based on the hour we're in.

The variable code is like this one:

d = dateparts(),
(d.hour >= 20 && d.hour <= 23)

I remember we've been told that this would not work in previous builds (but it did), but it's not really working now. It was false at 20 (the rule is triggered every 30 minutes when dark), and after I pressed play it went to true. I changed it with a script action and it's working now. But I'm reporting as an edge case, because I'm not sure it is supposed to work with the new behavior. Nothing else to report ATM. Thanks for the effort!

So far, so good. Everything seems to be OK atm. I'll report in case of problems.

@toggledbits said in [Reactor] Variables not updating correctly in latest-25201-2aa18550:

Just a tip, a more efficient way to write this:

OMG, very old rules, isn't it? Thanks, I fixed it.

yep, it seems to be related (in general) to variables not being evaluated at startup. Here's a screenshot from a daily rule that it's setting a couple of things, including a virtual binary sensor for Christmas from a local variable:

After re-setting the rule, the expression got re-evaluated and the error went away. @toggledbits

EDIT. a similar one + logs

This one, instead, every time is evaluated gives the error.

[latest-25248]2025-09-11T07:19:37.602Z <Rule:ERR> Lights-Christmas-Off (rule-kwv6wdpw in Lights-Outdoor): error evaluating expression specialdays: [Error] Object does not exist [-]
[latest-25248]2025-09-11T07:19:37.603Z <Rule:ERR> Full expression: t = time(), m = dateparts(t).month, d = dateparts(t).day,
(m == 12 && d == 24) ||
(m == 12 && d == 25) ||
(m == 12 && d == 31) ||
(m == 1 && d == 1) ||
(m == 1 && d == 5) ||
(m == 1 && d == 6)
[latest-25248]2025-09-11T07:19:37.604Z <Rule:CRIT> Error: Object does not exist [-]
Error: Object does not exist
    at GlobalExpression.getInstance (/opt/reactor/server/lib/GlobalExpression.js:160:27)
    at _0x1ec9e7._func.<computed> [as _ref] (/opt/reactor/server/lib/Rule.js:848:69)
    at _resolve (/opt/reactor/common/lexp.js:1385:27)
    at _run (/opt/reactor/common/lexp.js:1429:31)
    at /opt/reactor/common/lexp.js:1697:33
    at Array.forEach (<anonymous>)
    at _run (/opt/reactor/common/lexp.js:1696:28)
    at _run (/opt/reactor/common/lexp.js:1604:33)
    at _run (/opt/reactor/common/lexp.js:1438:34)
    at /opt/reactor/common/lexp.js:1425:29
[latest-25248]2025-09-11T07:19:37.627Z <Rule:INFO> Lights-Christmas-Off (rule-kwv6wdpw in Lights-Outdoor) evaluated; rule state transition from NULL to RESET!
[latest-25248]2025-09-11T07:19:37.638Z <Rule:INFO> Lights-Christmas-Off (rule-kwv6wdpw in Lights-Outdoor) started

Ok, I got a bunch of errors at restart because of failed references in almost all variables - now it seems to be OK and variables are updated. I'm observing a couple of rules I haven't migrate yet - and, at this point, I'll not migrate - where I used to old trick that @gwp1 surfaced (and that I used without making it a rule). always seems to be OK.

@toggledbits I've updated my main system. I'll observe and report back. Thanks

I don't know if I'm the only one, but managing more than one Reactor installs, the need to have some sort of copy&paste for rules has grown on me.

While I understand the technical challenges, I'm wondering if a "god mode" where I could copy the raw JSON rule and paste it into another rule could be an advanced, flag only feature that could benefit power users.

I know I can copy the JSON file and proceed, but I must stop Reactor and when doing maintenance, it's more clicks to do.

Just an idea

Version 25244: https://github.com/dbochicchio/reactor-mqtt-contrib/releases/tag/25244

Add new Shelly Gen3 templates for dimmer and energy meter, modify version in manifest.yaml to 25244, enhance sensor expressions for accuracy, and improve event handling and actions. General refactoring and cleanup across YAML files for consistency and quality.

So, my solution, based on the logic, is this the following.

Cycle Logic (pseudo-blocks)

Trigger: Button press (scene controller state changes)

Variables:

• fan1 = getEntity("zwavejs>13-1").attributes.power_switch.state
• fan2 = getEntity("zwavejs>13-2").attributes.power_switch.state
• skip (default = false)
• lastTurnedOff (text)

Group 1 – Both OFF → Fan1 ON
Condition: skip == false AND fan1 == OFF AND fan2 == OFF AND lastTurnedOff <> "fan1"
Action:

• Turn Fan1 ON
• Set skip = true

Group 2 – Fan1 ON → Fan1 OFF
Condition: skip == false AND fan1 == ON
Action:

• Turn Fan1 OFF
• Set lastTurnedOff = "fan1"
• Set skip = true

Group 3 – Fan1 just OFF → Fan2 ON
Condition: skip == false AND fan2 == OFF AND lastTurnedOff == "fan1"
Action:

• Turn Fan2 ON
• Set skip = true

Group 4 – Fan2 ON → Fan2 OFF
Condition: skip == false AND fan2 == ON
Action:

• Turn Fan2 OFF
• Set lastTurnedOff = "fan2"
• Set skip = true

Notes

• The skip variable ensures only one group runs per button press.
• lastTurnedOff lets Reactor know which fan was just turned off by this rule (so it can toggle the other fan on next).

I'll make some other tests and see if it's working as expected. I used Chat GPT 5 giving the Reactor Docs as context and deep reasoning and it helped me a lot. I just had to explain my logic, provide a couple of screenshots and ask for logic blocks instead of script action. YMMV.