I reviewed my Reactor configuration file. Some time ago I had duplicated one of the hubitat device sections in anticipation of making changes to my extended LAN. While one entry was marked as "enabled: false", it seems that MSR did not like the duplicate ID even though the duplicate was disabled. I added and "X" to the "id" and "name" of the duplicated entry and the error messages ceased.
Thanks for the help
R
retireditguy
@retireditguy
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.
Hello all.. been a minute! I recently rebuilt my Z wave network and migrated to a new z wave stick. In order to prevent any downtime I kept my original z wave network up and ran a docker version of Z Wave JS UI with my new controller. This way I could add device by device without having any devices down.
I finally moved all the devices over to my new stick today. The final step was to migrate everything from my Docker instance of Z Wave JS UI to the HA add-on of Z Wave JS UI. However during this migration some of the names didn't populate correctly which I later managed to import back into Z Wave JS UI. The issue was in Reactor it is stuck on the default names and the entities are not updating. I removed the controller from Reactor, restarted, hard refreshed, and added the controller back however the new entity names have not updated. Also it seems like the old entities from my previous instance of Z Wave JS UI are lingering and not being marked as dead (I believe a certain amount of time needs to lapse before they're marked as dead in Reactor).
My goal is to basically purge all the entities for the 'ZWaveJS' controller in Reactor so it can pull all the updated entity names and only the entities that exist in Z Wave JS UI. I cannot find a quick way to do this, I know entities can be deleted one by one, but with over 100 entities this would take long
I am guessing that if I added the controller with a new name in in the Reactor config it would pull the updated entities and names but I think that would break my rules since the entity IDs would change (I made sure to name all the entities the exact same as they were previously to prevent this issue).
I'm slowly migrating all my stuff to MQTT under MSR, so I have a central place to integrate everything (and, in a not-so-distant future, to remove virtual devices from my Vera and leave it running zwave only).
Anyway, here's my reactor-mqtt-contrib package:
https://github.com/dbochicchio/reactor-mqtt-contrib
Simply download yaml files (everything or just the ones you need) and you're good to go.
I have mapped my most useful devices, but I'll add others soon. Feel free to ask for specific templates, since I've worked a lot in the last weeks to understand and operate them.
The templates are supporting both init and query, so you have always up-to-date devices at startup, and the ability to poll them. Online status is supported as well, so you can get disconnected devices with a simple expression.
Many-many thanks to @toggledbits for its dedication, support, and patience with me and my requests
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
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.
Use case:
When performing home maintenance, such as air conditioning, I want all rules involving air conditioning to be disabled.
To do this, to day, I have a virtual switch that I placed within all rules involving air conditioning, meaning that if I turn it off, none of them work.
Then another situation: the water pump system and garden irrigation, another switch.
In short, I had to create several virtual switches in Hubitat to disable rules in MSR.
Unfortunately, however, I was unable to cover all scenarios, so I wondered if it would be possible for MSR to support a virtual MSR switch, which, when configured in the reactor settings, would function as a general on/off switch for MSR.
If it is configured and turned off, the entire rules and actions in MSR stops working, except for the status change reading process, specifically for this switch, which, when turned on, would restart the MSR.
Would it be possible to do something like this? Any recommendations from the experts?
Probably a really dumb question.
Currently I am using the owntracks_sensor for tracking phones being in region in MSR and it works great.
Digging around with Home Assistant and toying with some dashboards, is there any way of exposing that sensor to HA trivially? I could set MSR to trip a virtual switch in OpenLuup which can then be exposed to HA (with all my other Vera devices) but that feels a bit in-elegant if I can do it directly.
Any thoughts?
Apologies if the ask is not clear/
TIA
C
...is back....
https://arstechnica.com/google/2025/08/researchers-use-calendar-events-to-hack-gemini-control-smart-home-gadgets/?utm_source=facebook&utm_medium=social&utm_campaign=dhfacebook&utm_content=null&fbclid=IwY2xjawMBq-pleHRuA2FlbQIxMQABHlSqIalzbz1IxcJFzlw8GBE6nC3FwvxcHgR370nJhogU6JjqbmRxG-lysqgh_aem_lx9XboYFKw9tpHnedGQKUA
C
As there are statements about compatibility for home assistant versions in MSR new version announcements (e.g. "HassController: Bless Hass to 2025.7.3"), I thought it would be good idea to track other controllers as well.
As an example, I can confirm that build "latest-25208-c53e8513" works with Hubitat Elevation C-8 platform version 2.4.2.134 using Maker API.
Updates: (the latest versions first in the list)
OK: build "latest-25264-2fbe9217" with Hubitat C-8 platform v. 2.4.3.123
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here.
Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions;
Fix an error in OWMWeatherController that could cause it to stop updating;
Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later;
Improve error detail in messages for EzloController during auth phase;
Add isRuleSet() and isRuleEnabled() functions to expressions extensions;
Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases);
Fix a place in the UI where 24-hour time was not being displayed.
Posts
-
Problem after upgrading to 25067 -
Problem after upgrading to 25067MSR had been running fine, but I decided to follow the message to upgrade to 25067. Since the upgrade, I have received the message "Controller "<name>" (HubitatController hubitat2) could not be loaded at startup. Its ID is not unique." MSR throws the message on every restart. Has anyone else encountered this problem?
I am running MSR on a Raspberry Pi4 connecting to two Hubitat units over an OpenVPN tunnel. One C8 and a C8 Pro. Both are up-to-date. It appears that despite the error message that MSR may be operating properly. -
Hubitat "hubitat" is reconnecting alertI have also encountered this problem on a recurring basis. I tried many different approaches - reboot RPI, restart MSR, reboot hubs - to correct the issue, usually without success. Earlier is week I decided to try something different. I "repaired" the "Hub Information Driver" using the Hubitat Package Manager. As so I the "repair" was complete on the hub, the problem disappeared.
-
Hubitat "hubitat" is reconnecting alert -
Trying to add second Hubitat controller [Solved]Thanks for the information. After your reply, I took a chance and downed my C7 by disabling it in reactor.yaml. I restarted MSR and my C8 was suddenly up and online. I verified that I can control my single (so far) zwave outlet. I then edited reactor.yaml to re-enable my C8 and restarted MSR one more time. Now both the C7 and C8 are up and online. Not knowing the MSR code I do not know where the problem might be, but there seems to be an issue with bringing up two (different version) Hubitats at the same time. Perhaps @toggledbits can explain it. I am just glad to have them both working so that I can continue my journey away from Vera's. One down and one to go. Thanks again.
-
Trying to add second Hubitat controller [Solved]@toggledbits - Does MSR currently support the Hubitat C8 controller or was I premature in my purchase? I have reviewed my configuration multiple times, even deleting and rebuilding it and I still encounter the scenario described above.
-
Trying to add second Hubitat controller [Solved]Forgot to add that I also installed the Maker API and "published" the devices.
-
Trying to add second Hubitat controller [Solved]Converting from Vera Plus to Hubitat at two different locations. The two sites are interconnected via a router-to-router VPN. I currently have a Hubitat C7 running at Site One and a Vera Plus at Site Two. The MSR Raspberry Pi is co-located with the Vera Plus at Site Two. I "activated" a Hubitat C8 (ethernet connected) at Site Two including the installation of Hub Information Driver and its associated device. I also installed a single zwave outlet module (GE ZW4202). I restarted MSR. The C8 and its associated devices appear on both the Entities page and the MSR Dashboard, but the C8 reports as down on the MSR Status page and the GE outlet does not respond when "clicked". I am not sure where to look to try to find the source of the problem and will greatly appreciate any suggestions.
-
Reactor Ex MachinaExcept for the values defining the active time in "Active Period", our scripts are identical. Additionally we are both controlling Hubitat systems. My testing seems to indicate that REM only shuts off one light at the end of the defined period. I believe it was the last one turned on. Are you sure that REM turns off all of your lights at the end of the defined period? I suspect there may be something wrong with the execution of the statement {{ each light in REM_Lights: performAction( light, 'power_switch.off' , { } ) : 0 }} as I noted above. Another "anomaly" occurs at start-up. The 3 scripts together are sensitive to the start sequence. If "Cycler" is started before both "Active Period" and "Deactivated", "Cycler" will trigger as soon as either starts since they both change cycler_stim.
-
Reactor Ex MachinaThe Board changed ) : to an emoticon.
-
Reactor Ex Machina@toggledbits
Working on migrating off of Vera. I am also trying to use Reactor Ex Machina and wonder whether the changes you referenced above might also keep REM from shutting down properly. REM toggles the lights off and on up until the expiration of the active period. REM ends without turning all of the lights off. The construct I am wondering about is - {{ each light in REM_Lights: performAction( light, 'power_switch.off' , { }
0 }}
I assume this is supposed to turn all of the lights in the array. I modified the "code" to handle the local/global variable change by moving cycler_stim to Global , but otherwise my REM is as it was after you modified "Deactivate REM' back on May 28, 2021. Any ideas?https://smarthome.community/topic/557/solved-random-ghosting-of-lights-when-away/32?_=1677904265383
-
MSR controller status panelHard refresh solved the issue. Thanks.
-
MSR controller status panelRunning latest version of MSR in Docker on Bullseye/Raspberry Pi CM4. Every time I "restart" MSR it returns to the default set of status panels. I add "Controller Status", but it disappears on every restart. Is this the planned behavior or do I have an issue somewhere?
-
Cheapest platform on which to run MSR@toggledbits I have the CM4IO currently installed in a Waveshare CM4-IO-Board- Case-A metal case. The board is mounted to standoffs inside the case. I was able to remove enough of the front rim of the case to be able to mount the board without the cover, so depth is no longer an issue (There was already a small cutout area in the rim.) Overall the case is 6 7/8" wide x 4 1/8" deep x 1 1/8" high. It needs about another 1 1/2" in height, making the total height 2 1/2". I appreciate your offer to model a roomier case, but I don't have a 3D printer so it would be of little use to me. I guess that I will have to run it without a cover until the market catches up, assuming that the CM4 on CM4 IO is selling well.
-
Cheapest platform on which to run MSRLove your printed case, but it is not tall or deep enough to add the PCIE adapter for an m2 SSD. Have you come across any oversized cases for the CM4 IO boards that would accommodate use of the PCI slot.