Multi-System Reactor Developer Preview AVAILABLE
-
Congrats on the release. If you want to install on a x64 machine, just edit rpi-install.sh and replace arm7 with x64. I have mine on Windows Subsystem for Linux under Windows and it's running OK.
Can't wait for guidance on apdaters/plugins to contribute with Shelly and MQTT
@therealdb said in Multi-System Reactor Developer Preview AVAILABLE:
Can't wait for guidance on apdaters/plugins to contribute with Shelly and MQTT
MQTT will be huge.
-
On my list of hubs/controllers to tackle next are Homey and OpenHAB, but I am also interested in MQTT, so I'm hearing a bump in priority coming, at least for investigation.
-
I'm enjoying this thread as it develops, but will stand by until someone wraps MSR into a Docker package that I can install/run on my Docker-enabled Synology NAS.
Like everyone else, "I'm at full candy corn" (so the Stewie Griffith saying goes) on this project and can't wait to give it a whirl!
- LS
-
On my list of hubs/controllers to tackle next are Homey and OpenHAB, but I am also interested in MQTT, so I'm hearing a bump in priority coming, at least for investigation.
Definitely a vote for MQTT here though it does require setup on both MSR and the "children" controllers, it reduces the I/O traffic dramatically compared to the polling approaches. In my personal case, since I am a bit bored like @therealdb, and don't have much to add or improve to my home automation, my interest is on improving efficiencies. I find satisfaction even when decreasing CPU utilization by decimal points.
-
The importer will automatically split out any group that has activities (from Vera) to a Rule in MSR, and leave a "rule" condition in the parent to preserve the logic. I think it's wayyyy more convenient, but I've also had a few months of working on it to get used to it.
You can also create global reactions that can be run from any other reaction.
-
I realise that but I was so into the "old" Reactor I had to re-think a little bit. I want to build my logic without importing the old mistakes from the beginning. Suggestion for improvement: To set dimming level you have yellow background and white text which is very difficult to read, at least for my eyes
Edit: Wrong I was using the app "Dark Reader" on my RPi witch confused the colours. Turning it off it is black on yellow -
FYI, the yellow indicator means it's going to let you do what you are asking, but the value you are giving is out of range. Dimming values in MSR are real numbers between 0 and 1 inclusive.
-
Release 21050 just published; use the "Download" button in the bug tracker.
-
Send me a PM with your email address and full name; I'll set up your account and the site will email you.
-
Send me a PM with your email address and full name; I'll set up your account and the site will email you.
@toggledbits Done. Thanks!
-
Definitely a vote for MQTT here though it does require setup on both MSR and the "children" controllers, it reduces the I/O traffic dramatically compared to the polling approaches. In my personal case, since I am a bit bored like @therealdb, and don't have much to add or improve to my home automation, my interest is on improving efficiencies. I find satisfaction even when decreasing CPU utilization by decimal points.
-
I had an issue with an account on the bug tracker (already?) so I locked it down. PM me your full name and email address and I'll set up your account. It will email you an access link.
-
Got my instance going with Home Assistant. I am finding it brilliant as it is connecting to it through websocket. I am seeing the potential now to have reactor act as a bridge, detecting events happening on Home Assistant and forwarding them to openLuup and vice versa, eliminating the need for configuring additional scenes on openLuup and automation on home assistant!
-
I'm getting ready to assemble today's build (21051). I think I have everything urgent covered, with some PRs left open for confirmation. There's one more I want to try to address before I roll it up and out for the day.
This build also includes:
- Fix for condition trigger repeating when a sustained-for delay applies (#30);
- Fix an error on import (#29);
- Fix an error on Hass caused by an unhandled attribute (#27);
- New units configuration value "uk" (#31), as well as more granular control over units (if imperial, metric, or uk isn't enough, you can now set units by use class; per device/attribute is planned and part of the architecture as well);
- Fix elevation computation problem in sunrise/set data (mangles angles if elev configured <> 0) (#34);
- Now with working SMTP, Prowl, Pushover and Syslog notifications;
- Notification forwarding for Hubitat (see docs for configuration details);
- many documentation fixes and upgrades.
-
And 21051 is now available.
-
I will look into that!
Edit: It looks like the
jobsobject is dropped on Vera Luup when it's empty, but is always present on openLuup. Since the comparison to see if a value changes doesn't "go deep" on objects and arrays, it sees two empty objects as different every time they are presented (using JS's comparison operator), and the scene is being presented on each update even though outwardly there don't appear to be any changes. So two small diffs between Vera Luup and openLuup contributing.I'm just going to suppress anything that isn't a primitive and leave it at that. Deep inspection of objects and arrays isn't likely to be valuable or necessary.
