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.

Ask me how I know

I'm on my 4th major breakdown in 12 years of home automation. Coming from this and from an enterprise job, I know how to over-engineer
I got more RAM from my Syno, and I'm completely on docker. Even my own small script are now docker-ized.

I have a NUC that's running Reactor, Home Assistant, ZwaveJS, a couple of other obscure things, and the storage of those container is backupped every hour, day, week and month. I have the same containers on my Syno and it's just a matter of adding the NUC's IP address, update them and start them. It usually takes no more than 15 minutes. I have switched to Ubiquiti for my network and I have backup devices for that as well.

I have two new villas on the beach (3 hours drive one-way) and I'm now exploring the options. One will be a rental, one for us. I'm tempted to replicate something similar to our main house, but I want to be extra sure that everything is working without my intervention. I don't know, but I feel your pain.

@toggledbits time for a custom mqtt template

all that said, many echo devices have line in and it’s always sending out the sound. This could certainly be another low-fi option.

I have a portable ikea outdoor speaker for the pool, paired via bt with an echo and sending out line in coming from the tv. I’ll probably do something similar in the new beach house.

@CatmanV2 nope, always connected

@CatmanV2 back in the old days of no reliable internet at our new house, I had a raspberry connected via Bluetooth to the Alexa in the main room. I just played pre-recorded audio files and it worked very good.
Low tech solutions are the best

Also, some echo devices have the line in. If you have something plugged in, they will play what's sent.

As you can see from

reactor-mqtt-contrib/shelly_gen1.yaml at a05d77b468d0a09fab72d2a23bee683ba2e47c82 · dbochicchio/reactor-mqtt-contrib

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

this should be:

  capabilities:
    x_sonos_announcement:
      actions:

and the way you nest and indent is very important.

yep, it was removed from 22305.

• UI/Rules/Reactions: the changes operator should not be available in constraints (changes is an event, and constraints are static, not event-driven).