Global Moderators group | Smart Home

toggledbits

It's probably moot at this point... I've just spent the last two weeks completely revamping the evaluation of Rule-based variables, to make them perform more like global variables, respect dependencies between them better, etc. The last week has just been a deep dive through the logs watching the performance of my own house on the updated approach.

I'll shortly be releasing a blind build with these changes, just for you (@tunnus) and @therealdb to try. I expect this to be disruptive, because any approaches in the logic that rely on specific behaviors and side-effects of the old approach will now work differently, maybe fail, and adapting to the new approach will be necessary. But, I think the new approach will produce a result that is much more in keeping with how you would expect it to work. So, sit tight... I'll be ready to build later today or early tomorrow.

therealdb

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

therealdb

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.

toggledbits

This looks like a job for a finite state machine.

An alternate way to tackle this may be to have a state local variable that's just a number/counter that increments when the scene controller button is pushed... Set Variable state = ${{ ( ( state ?#0 } + 1 ) % 3 }}. This will make state cycle through the values 0, 1, 2, 0, 1, 2...

Then the reaction has these groups:

When state == 0: turn both fans off
When state == 1: turn 1 on, 2 off
When state == 2: turn 1 off, 2 on

It's easy to add a fourth state if you want the option of having both fans on at the same time. I'll leave the changes as an exercise for readers. DM if you need a hint.

toggledbits

This is not something i'm going to entertain at the moment. It seems like a very specialized, one-off request, and the implementation has a lot of consequences throughout the system. I recommend starting and stopping using the currently available method (i.e. stopping the process itself). It's also relatively easy to enable and disable rules in the UI, so when working on isolated systems (like a heating/AC unit), you can temporarily disable just those rules. You can also force them to a set or reset state to keep them at bay, and put them back in auto later.

therealdb

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.

therealdb

I’ve added a couple of Shelly Wave i4 as scene controllers and I’m planning to add more, since I can just use standard buttons instead of battery-powered scene controllers, which also looks better aesthetically.

That said, I’m struggling to figure out how to write a simple rule that cycles between states every time I press a button.
Example: Light 1 ON → OFF, then Light 2 ON → OFF.

The part I can’t get right is handling the case where Light 1 or Light 2 might already be ON independently of the rule.

Maybe it’s just too much sun and relaxation clouding my brain, but any hint would be appreciated.

toggledbits

It works as I would predict.

CatmanV2

You are both gents!

C

toggledbits

@CatmanV2 said in Expose MSR entities:

@toggledbits this is precisely what it is, yes

Whew. OK. Then yes, this is the way to go.

Global Moderators

Posts

Cycle Logic (pseudo-blocks)

Notes

Member List