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.

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.

Yep, I confirm I had to update a couple of rules where I had similar variables as @tunnus
I used script action because it’s multi line and definitely better in terms of readability.

Ok, I was probably lucky in the past, I don't know. I could send you the rule's JSON if you want to take a look. Anyway, I'll try to move some logic into set variables for the time being. Thanks.

I'm 100% sure it used to work before. I did a restart and nothing changed.
I have "Force re-evaluation of expressions and conditions" in the rule and I was under the impression that was forcing updates. Now back to change a couple of rules that have the same problem. I'll move them to Script Action to set the values, but as I said I'm 100% sure it used to work OK before.
Thanks.

After updating to latest-25201-2aa18550, I found that an old rule (probably 2-3 years old) has started experiencing a weird behavior.
As you can see from this screenshot:

It seems that while rain variable is false and wind is true, debugmessage (and other similar variables) are not updated correctly. If I press on the Play Icon on the variable inside the rule, it is then updated. It was working OK previously, so maybe it's the new version.

As you can see from this screenshot, the first one is updated manually, but the second one is still showing the old value:

The rule has just some action in the SET part doing notifications and calling MQTT endpoints for logging.

Anyone with the same problem? /cc @toggledbits

Also, for me a virtual device instead of checking for rule states seems to be less prone to errors. So I have one for home status, guests, party etc and the rules are much easier to write.

I use script action a lot with arrays of devices defined in a variable. Very handy for when you want to do it without messing with config files.

Version 25154 on GitHub:

GitHub - dbochicchio/reactor-opensprinkler: OpenSprinkler controller for Reactor - Multi-Hub Automation

OpenSprinkler controller for Reactor - Multi-Hub Automation - dbochicchio/reactor-opensprinkler

No release, just download the code.

Fix for station status and support for MQTT capabilities in OS 2.2.1. Still based on both HTTP/MQTT because the underline fw is still not 100% MQTT-ready.

Just copy storage and config from your bare metal install, point the container paths to the disk and you're good to go. Very easy*.

• this excludes external controllers, but the relative installation is well documented.

I still run my primary network on UZB, but I've just bought an Aeotec ZStick 7 for a new house. I'll switch to that for my primary house before end of the year, mainly because I want to use ZWave LR for a couple of devices and I need a 700/800 series router.

All that said, I'm running inside ZWaveJS and it's working as expected. My system with Reactor is pretty solid. I think ZWave is still the tech to go. My experience with ZigBee is quite similar (I run everything: Zwave, Zigbee, MQTT, Matter).

I prefer a structure where I organize them by features. The name reflects the rule set they're in (ie Lights-Outdoor-Gate is in Lights-Outdoor) to simplify discoverability, until a global search is added

the clock problem is a know bug. update to latest.

Please be 100% extra sure to copy everything under storage. this includes any file/directory under the path. do it while bot reactors are stopped for better accuracy.

I haven't moved this particular piece into MSR yet, but my logic is:

• watch for idle: if watts<5 for at least 15 secs, that's done. If previous status is running, mark as completed. Otherwise, stays idle.
• watch for watts. if idle and watts > 50 for at least 15 secs, that's running.

I think the best way to achieve this is by having two different rules. I'll probably design it with a virtual device with a string_sensor, containing the current state. I've never moved this part of my system to MSR, because I want to write a controller doing exactly this, but the logic is not complex.

So, an empty string is 200ish, otherwise error/timeout is null? That works, thank you!

I have a very strange situation, where if InfluxDB restarts, other containers may fail when restarting at the same time (under not easy to understand circumstances), and InfluxDB remains unreachable (and these containers crashes). I need to reboot these containers in an exact order, after rebooting InfluxDB.

While I understand what's going on, I need a way to reliable determine that InfluxDB is not reachable and these containers are not reachable, in order to identify this situation and manually check what's going on - and, maybe, in the future, automatically restart them if needed.

So, I was looking at HTTP Request action, but I need to capture the HTTP response code, instead of the response (becase if ping is OK, InfluxDB will reply with a 204), and, potentially, a way to programmatically detect that it's failing to get the response.

While I could write a custom HTTP controller for this or a custom HTTP virtual device, I was wondering if this is somewhat on you roadmap @toggledbits

Thanks!

@Pabla said in Advice on Storing and Backing Up Bind Mounts - Docker:

Perfect thats exactly what I was thinking of doing! Since I am using Portainer their equivalent of Docker Compose is Stacks and Portainer has a handy built in GUI back up feature which backs all that up. Just need to figure out how to automate it and store it off the host for easy future retrieval.

Portainer is just a nice GUI - I'm using it too to do basic stuff like restarting a container or see the logs, especially when I'm remote. But at the end of the day, it's just some GUI over docker/docker-compose CLI commands:

cd /home/casa/containers/zwavejs/ && sudo docker compose pull && sudo docker compose up -d

and you're good to go. Easier to run 5-6 times per container than clicking on some random web page, but I know it's personal. The only thing that matters is a disaster/recovery strategy that you'll be able to quickly follow.

Yeah, containers are a game changer for manageability.

I just have a /home/casa/containers (where casa is the user) where I have my configs/storage. Easy to backup/mirror. In case of disaster recovery, just copy everything and I'm ready. For consistency, I save my docker-compose file in the same dir. Restoring a container is very easy.

I added standard RAM as well, from a laptop.
Yep, the zwave network is on the stick. That's why you have to regularly backup it.
You may consider something using serial-to-IP:

tubeszb

Z-Wave PoE Kit

@CatmanV2 yep. My syno is the backup plan. The only prod containers on the syno are mosquitto and influxdb. This way, in case of failure, the mqtt server is still running and retained messages are picked up from the queue. With this configuration, I avoid the slower cpu of the syno. The nuc one is definitely faster.