I've seen many of you using Dynamic Group Controller. I'm using it myself for monitoring device battery levels. I've read and re-read the Dynamic Group Controller docs and still cannot come to an answer for my question so let me paint my scenario:
I've migrated from EchoSpeaks in Hubitat ('cause borked and seemingly unmaintained) to Alexa Devices in Home Assistant ('cause not borked in 2026.11.0) to be able to send TTS to my Echo devices.
In EchoSpeaks I could create groups. Sweet.
In Alexa Devices I don't seem to be able to do so. As such, my thought was "wait - isn't there a way in MSR?"
Is this an effective scenario that Dynamic Group Controller can be used for?
I'm trying to allow anonymous access from a local network to /api/v1/log, but the problem now with the reverse proxy configuration is that this access is open via proxy to the internet. At least I wasn't able to configure ACL so that only an access from a local network would be permitted.
reactor.yaml:
baseurl: "http://192.168.1.12:8111"
proxy_baseurl: "https://external.com:30000"
trusted_proxy: "192.168.1.12"
Local traffic would originate from 192.168.1.0/24 network. Synology is acting as a reverse proxy and hosting MSR as a docker container (which has its own network and IP 172.18.0.5). MSR build is latest-26298-fbb75fb8
users.yaml:
- url: "/api/v1/log"
method: "GET"
source_ip: 172.18.0.0/24
allow: true
Using the above ACL works, but it enables access via proxy also. If I use source_ip: 192.168.1.0/24, then it doesn't work either locally or remotely. So I'm kinda lost what should I use as source_ip in this case?
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.
I'm trying to use MSR via reserve proxy in Synology DSM, but MSR page does not load
https://<public ip>:30000/reactor/en-US/
At the same time logging page loads normally
https://<public ip>:30000/api/v1/log
I thought maybe authentication was messing it up, but there was no deny entries in the log, and also disabling authentication did not make any difference. For this use case VPN is not an option (that works, but as said not an option for this particular use case).
Any ideas what could cause this? MSR build latest-26242-28d69aa8, Chrome browser
Nothing more to add. I see we have hvac_blower, but, anyway, maybe a native fan on the same assumptions of the fan from HASS could be reasonable.
I have a couple of them. ie, this is from ESPHome via HASS.
x_hass.domain="fan"
x_hass.entity_id="fan.kitchen_seashell_hood_ventilation_fan"
x_hass.floor_id=null
x_hass.services=["fan","esphome"]
x_hass.source="esphome"
x_hass.state="off"
x_hass_attr.friendly_name="Seashell Hood Ventilation Fan"
x_hass_attr.percentage=50
x_hass_attr.percentage_step=25
x_hass_attr.preset_mode=""
x_hass_attr.preset_modes=[]
x_hass_attr.supported_features=49
Thanks.
Build: latest-26221-b25bb3e3, Docker on Synology.
Hi, I have a Rule whose Trigger/Constraints reference other Rules via Rule State ... is TRUE. At some point it stops firing.
Expanding the rule's condition tree in the UI shows every Trigger and Constraint condition green/TRUE — confirmed live by walking into the room and watching Motion go true in real time. Rule History shows no new SET, just old reset entries.
Tried, on the same rule, same evening: recreating the trigger conditions with fresh IDs, recreating the constraint conditions with fresh IDs (flat and wrapped in a new Group — wrapping in a Group produced one SET, but it didn't reproduce on repeat attempts with the same structure), and finally a full container restart with a verified-correct saved rule. Still no SET, even with a fresh live motion event right after the restart.
Separately, I found that this rule (and its 10 per-room clones) share identical internal condition/group IDs with each other — leftover from a batch clone done months ago, never regenerated. Not sure if that's related, since fixing the IDs didn't reliably fix the symptom either.
Has anyone seen a Rule State condition show TRUE in the UI without the Rule ever producing a SET, surviving a clean restart?
Thanks in advance
Hey @toggledbits I'm back to trying to optimize a couple of things based on dynamic group.
First of all, I think I found a typo in the doc:
primary_attribute: "binary_sensor.state"
primary_attribute_value: |
d = false;
each id in members: d = getEntity(id)?.attributes?.power_switch?.state or d,
d
I think the correct code snippet is d = false,
All that said, my use case for dynamic groups is to group 3 different climate devices, so I could easily command them at the same time. Commands are good, but sometimes I want to check if any of the devices are on, and that's easily done with a similar snippet as the one you have in the docs. But this is limited to the primary attribute, while I want to have any of the attributes in the group to be driven by a similar logic (while all are null in the group). ie, access hvac_control.mode and see if any of the unit is set to cool, or heat. Is that possible, without re-defining an expression in each of my rules? Thanks!
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
Edit: Solved in latest-26221.
Bare-metal latest-26193
I have this group:
"OKforLarm":
name: OK för Larm
select:
- include_controller: vera
- include_capability: door_sensor
filter_expression: entity.attributes.door_sensor.state
It contains the entities I expect but behaves a bit odd. When I open vera>device_10097 the entity attribute door_sensor.state changes to true but it won't show up as member in the group, when I also open vera>device_10095 they both shows as members and when I close vera>device_10095 it disappear from the group but when I close vera>device_10097 it lingers in the group until I restart Reactor.
[RESOLVED] Phantom device, “INFO” appears
Multi-System Reactor
2
Posts
2
Posters
318
Views
2
Watching
-
Hi
I'm seeing multiple warnings "INFO" like the one below in the Reactor log file.
[latest-26177]2026-06-28T23:19:39.784Z <Engine:INFO> Resuming reaction HOME UPDATE 30/30<SET> (rule-me9cq25r:S) from step 5 [latest-26177]2026-06-28T23:19:39.784Z <Engine:INFO> HOME UPDATE 30/30<SET> all actions completed. [latest-26177]2026-06-28T23:19:39.791Z <Engine:INFO> Engine#1 task 114 (rule-me9cq25r:S) has completed after restart [latest-26177]2026-06-28T23:19:40.211Z <HubitatController:INFO> HubitatController#hubitat ignoring DEVICE event for device 225 (Ping VM Reactor); device not enumerated by Maker API [latest-26177]2026-06-28T23:19:40.214Z <HubitatController:INFO> HubitatController#hubitat ignoring DEVICE event for device 225 (Ping VM Reactor); device not enumerated by Maker API [latest-26177]2026-06-28T23:19:40.312Z <HubitatController:INFO> HubitatController#hubitat ignoring DEVICE event for device 225 (Ping VM Reactor); device not enumerated by Maker API [latest-26177]2026-06-28T23:19:40.314Z <HubitatController:INFO> HubitatController#hubitat ignoring DEVICE event for device 225 (Ping VM Reactor); device not enumerated by Maker API [latest-26177]2026-06-28T23:19:40.413Z <HubitatController:INFO> HubitatController#hubitat ignoring DEVICE event for device 225 (Ping VM Reactor); device not enumerated by Maker API [latest-26177]2026-06-28T23:19:40.414Z <HubitatController:INFO> HubitatController#hubitat ignoring DEVICE event for device 225 (Ping VM Reactor); device not enumerated by Maker API [latest-26177]2026-06-28T23:19:40.513Z <HubitatController:INFO> HubitatController#hubitat ignoring DEVICE event for device 225 (Ping VM Reactor); device not enumerated by Maker API [latest-26177]2026-06-28T23:19:40.515Z <HubitatController:INFO> HubitatController#hubitat ignoring DEVICE event for device 225 (Ping VM Reactor); device not enumerated by Maker API [latest-26177]2026-06-28T23:19:40.615Z <HubitatController:INFO> HubitatController#hubitat ignoring DEVICE event for device 225 (Ping VM Reactor); device not enumerated by Maker API [latest-26177]2026-06-28T23:19:40.616Z <HubitatController:INFO> HubitatController#hubitat ignoring DEVICE event for device 225 (Ping VM Reactor); device not enumerated by Maker API [latest-26177]2026-06-28T23:19:40.716Z <HubitatController:INFO> HubitatController#hubitat ignoring DEVICE event for device 225 (Ping VM Reactor); device not enumerated by Maker API [latest-26177]2026-06-28T23:19:41.453Z <Rule:INFO> Panel Tripped (rule-mfdbsyrp in SharpTools) starting rule state evaluation; because predicate-state-changed Predicate#rule-mfdbsyrp/trig [latest-26177]2026-06-28T23:19:41.454Z <Rule:INFO> Panel Tripped (rule-mfdbsyrp in SharpTools) evaluated; rule state transition from SET to 'RESET'And that's correct; this device hasn't been exported from Hubitat to MSR.
I ran a query to see if it was in any of the reactor's files, and the only thing I found was the information in the log.
root@reactor:/home/wilson/reactor# grep -rl "hubitat>225" . root@reactor:/home/wilson/reactor# grep -rl "device 225" . ./logs/reactor.log.1 ./logs/reactor.log.2 ./logs/reactor.log.3 ./logs/reactor.log root@reactor:/home/wilson/reactor#I looked in the entity directory, and this device isn't there either.
root@reactor:/home/wilson/reactor# cd storage/ root@reactor:/home/wilson/reactor/storage# ls access_token.hex default.dval default.json.corrupted expressions.dval hostkey.key reactions reactor.pid rulesets baseurl.sh default.json entities expressions.json hostkey.pub reactor_inet_check.dat rules states root@reactor:/home/wilson/reactor/storage# cd entities/ root@reactor:/home/wilson/reactor/storage/entities# cd hubitat/ root@reactor:/home/wilson/reactor/storage/entities/hubitat# ls 109.dval 138.json 147.dval 15.json 170.dval 211.json 24.dval 261.json 29.dval 48.json 62.dval 656.json 668.dval 679.json 76.dval 87.json 109.json 139.dval 147.json 163.dval 170.json 219.dval 24.json 262.dval 29.json 49.dval 62.json 657.dval 668.json 67.dval 76.json 98.dval 112.dval 139.json 148.dval 163.json 182.dval 219.json 253.dval 262.json 2.dval 49.json 63.dval 657.json 669.dval 67.json 7.dval 98.json 112.json 13.dval 148.json 165.dval 182.json 21.dval 253.json 263.dval 2.json 51.dval 63.json 658.dval 669.json 681.dval 7.json 99.dval 118.dval 13.json 149.dval 165.json 190.dval 21.json 254.dval 263.json 32.dval 51.json 64.dval 658.json 66.dval 681.json 83.dval 99.json 118.json 142.dval 149.json 166.dval 190.json 220.dval 254.json 264.dval 32.json 57.dval 64.json 659.dval 66.json 68.dval 83.json controller_all.dval 11.dval 142.json 14.dval 166.json 19.dval 220.json 257.dval 264.json 3.dval 57.json 653.dval 659.json 676.dval 68.json 84.dval controller_all.json 11.json 143.dval 14.json 167.dval 19.json 224.dval 257.json 265.dval 3.json 58.dval 653.json 65.dval 676.json 69.dval 84.json sys_hsm.dval 123.dval 143.json 150.dval 167.json 201.dval 224.json 259.dval 265.json 46.dval 58.json 654.dval 65.json 677.dval 69.json 85.dval sys_hsm.json 123.json 144.dval 150.json 168.dval 201.json 22.dval 259.json 27.dval 46.json 60.dval 654.json 666.dval 677.json 70.dval 85.json sys_mode.dval 12.dval 144.json 151.dval 168.json 20.dval 22.json 260.dval 27.json 47.dval 60.json 655.dval 666.json 678.dval 70.json 86.dval sys_mode.json 12.json 146.dval 151.json 169.dval 20.json 23.dval 260.json 28.dval 47.json 61.dval 655.json 667.dval 678.json 74.dval 86.json system.dval 138.dval 146.json 15.dval 169.json 211.dval 23.json 261.dval 28.json 48.dval 61.json 656.dval 667.json 679.dval 74.json 87.dval system.json root@reactor:/home/wilson/reactor/storage/entities/hubitat#Obviously, I can't find anything when I search in the Reactor GUI either.
Where else should I look to try to resolve this situation?
Thanks.
-
That's a bug in Maker API... it's sending updates for a device that isn't enumerated for export. You can safely ignore those messages.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
