Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Unsolved
Collapse
Discussion Forum to share and further the development of home control and automation, independent of platforms.
T

tamorgen

@tamorgen
Error: Command timeout
G
at _ClientAPI._commandTimeout (http://192.168.1.100:8111/client/ClientAPI.js:807:179 Seeing this randomly when returning to open browser tab after being away awhile. Once, maybe twice a day. "What did you do to trigger it?" Literally nothing, just walked away and returned and there it was. Actions taken in reasonably close proximity to this particular instance of it popping up: I'd restarted the MSR container in Portainer. I'll try to grab some logs here shortly.
Multi-System Reactor
Reactor (Multi-System/Multi-Hub) Announcements
toggledbitsT
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.
Multi-System Reactor
[Solved] Local expression in Rule does not evaluate as they used to do
CrilleC
Topic thumbnail image
Multi-System Reactor
Home Assistant 2025.11.2 and latest-25315
CrilleC
Topic thumbnail image
Multi-System Reactor
Notice to Docker + ARM Users (RPi 3/4/5 and others)
toggledbitsT
This post does not apply to users of Intel/AMD-based systems. If you are using a Reactor image tagged latest-amd64 or stable-amd64, then this post does not apply to you. It also does not apply to bare-metal installs; it's for users of docker images on ARM-based systems only (principally Raspberry Pi hosts, but could be others). After January 15, 2026, I will no longer produce the aarch64-tagged docker image for Reactor. The ARM images will be arm64 for 64-bit operating systems, and armv7l for 32-bit operating systems. For those of you running a container from the aarch64 image today, this will be a relatively simple change: you just need to switch the image used for your docker container to a differently-tagged image. If you are using docker-compose, then this is a relatively simple matter of changing the image line in your docker-compose.yaml file and then stopping (docker-compose down) and restarting (docker-compose up -d) your Reactor daemon. But there's a catch... not all of you can safely just switch from the aarch64 image to the arm64 image. And, you can't just trust the output of uname -m, for example, because this exposes the CPU architecture, but not the word size of the OS running on that CPU. For Raspberry Pi systems, the transition to 64-bit operating systems was long (starting in 2016) and not always obvious — although there was a first "official" 64-bit OS for RPis in 2020, it did not become a default recommendation in the Raspberry Pi Imager until 2021, and then that was only the default for Pi 3/4 systems with >4GB RAM; it was 2022 before it was universally recommended for all 64-bit CPUs regardless of RAM size. Depending on when you first imaged your RPi system and what default you may have been offered/chosen, you could today easily have a 64-bit CPU Raspberry Pi running a 32-bit version of the operating system. Upgrades along the way would not change this; changing it to fully 64-bit requires a full reimage of the system. To establish if your OS is 64- or 32-bit, log in to your Pi and run: sudo dpkg-architecture -q DEB_HOST_ARCH. If the response is arm64 or aarch64, then you are running a 64-bit OS and you should use the arm64-tagged image. If it's anything else, you are running a 32-bit OS, and you should use the armv7l-tagged image. pi@rpi4-1:~ $ sudo dpkg-architecture -q DEB_HOST_ARCH armhf pi@rpi4-1:~ $ uname -m aarch64 pi@rpi4-1:~ $ In the example above, the uname command reports that the CPU is 64-bit architecture (aarch64), which is true for the host on which I ran these commands, but the DEB_HOST_ARCH value is armhf, indicating a 32-bit operating system. This system has to use the armv7l-tagged image. Other systems will have their own ways of determining the word size of the running OS. Since the majority of Reactor users running ARM systems are on Raspberry Pis, I am able to supply the above instructions, but if you happen to have a different ARM system, you'll need to do some web searching to figure out how to expose that information. Or, you can just try the arm64 image, and if it doesn't start up, try the armv7l image. Remember to always back up your system before making any changes. For everyone, please make this change as soon as possible, and if you have any trouble finding a working image, please (1) go back to the current aarch64 image; and (2) let me know in this thread along with as much detail about your host system as you can offer (including the output of the dpkg-architecture command mentioned above).
Multi-System Reactor
Requesting a proper ARM64/aarch64 Docker image (Pi 5 support)
M
Hi, I'm in the process of migrating from a Raspberry Pi 4 (ARMv7) to a Raspberry Pi 5 (ARMv8/aarch64), but I’ve run into an issue: there is no proper ARMv8/aarch64 image available. None of the existing images run on the Pi 5 - they all exit immediately with code 139 (segmentation fault), which typically indicates that the binaries inside the image are not compatible with the ARM64/aarch64 architecture used by the Pi 5. Would it be possible to publish a correct ARMv8/aarch64 (linux/arm64) image? Building one should be relatively straightforward using docker buildx with multi-arch support. For example, my own Node.js images are built this way: docker buildx build --push \ -t <localrepo>/<project>:<tag> \ --platform=linux/arm64,linux/amd64 \ --file ./apps/<project>/Dockerfile . This produces both the AMD64 and ARM64/v8 variants automatically. Also, as a side note, it may be best to avoid using Alpine as the base image for the ARM64 build, since musl-based builds often cause compatibility issues and unnecessary headaches. A glibc-based base image (e.g., Debian or Ubuntu) tends to work far more reliably on ARM64, especially for Node.js applications. @toggledbits - tagging you in case you missed this. Thanks, mgvra
Multi-System Reactor
Script action and custom timers
therealdbT
Sorry to write here without trying, but I’m flying today. Am I correct if i say that script action with alarm() makes it possible to execute a reaction in a given interval, lets say 15 seconds or 3.5 minutes? That sounds amazing, since I’ve used weird tricks, including a custom controller, just to do this.
Multi-System Reactor
Help resolve change in behaviour post update
CatmanV2C
Topic thumbnail image
Multi-System Reactor
There is an alternative to homebridge-mqttthing
CrilleC
Just throwing out a general hint to the people running Homebridge and MQTT. Homebridge MQTT-Thing hasn't been updated in almost 2 years and it falls behind on compatibility with the development of Homebridge. I was looking for a replacement and found Homebridge Easy MQTT and I think it's a good replacement for MQTT-Thing. I particularly find Easy MQTT Value tranformers easier to to understand and use compared to MQTT-Thing Apply function. It took a while to migrate everything but I'm pleased and can recommend.
Software
Reactor w/HA 2025.11 error on set_datetime service call setting only time
CrilleC
@toggledbits Do you know if this is related to that PR or is it a change they made in 2025.11.1? [latest-25310]2025-11-11T13:16:24.319Z <HassController:INFO> HassController#hass perform x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_dag with { "time": "10:45" } [latest-25310]2025-11-11T13:16:24.320Z <HassController:INFO> HassController#hass: sending payload for x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_dag action: { "type": "call_service", "service_data": { "date": (null), "time": "10:45", "datetime": (null), "timestamp": (null) }, "domain": "input_datetime", "service": "set_datetime", "target": { "entity_id": "input_datetime.vvb_dag" } } [latest-25310]2025-11-11T13:16:24.321Z <HassController:ERR> HassController#hass request 1762866984320<2025-11-11 14:16:24> (call_service) failed: [Error] Not a parseable type for dictionary value @ data['date'] [-] [latest-25310]2025-11-11T13:16:24.321Z <HassController:WARN> HassController#hass action x_hass_input_datetime.set_datetime({ "time": "10:45" }) on Entity#hass>input_datetime_vvb_dag failed! [latest-25310]2025-11-11T13:16:24.321Z <HassController:INFO> Service call payload: {"type":"call_service","service_data":{"date":null,"time":"10:45","datetime":null,"timestamp":null},"domain":"input_datetime","service":"set_datetime","target":{"entity_id":"input_datetime.vvb_dag"},"id":1762866984320} [latest-25310]2025-11-11T13:16:24.322Z <HassController:INFO> Service data: {"fields":{"date":{"example":"\"2019-04-20\"","selector":{"text":{"multiline":false,"multiple":false}}},"time":{"example":"\"05:04:20\"","selector":{"time":{}}},"datetime":{"example":"\"2019-04-20 05:04:20\"","selector":{"text":{"multiline":false,"multiple":false}}},"timestamp":{"selector":{"number":{"min":0,"max":9223372036854776000,"mode":"box","step":1}}}},"target":{"entity":[{"domain":["input_datetime"]}]}} [latest-25310]2025-11-11T13:16:24.322Z <Engine:ERR> Engine#1 reaction rule-mgb8pfhs:S step 0 perform x_hass_input_datetime.set_datetime failed: [Error] Not a parseable type for dictionary value @ data['date'] [-] [latest-25310]2025-11-11T13:16:24.322Z <Engine:INFO> Engine#1 action args: { "time": "10:45" } [latest-25310]2025-11-11T13:16:24.322Z <Engine:INFO> Resuming reaction Sätt Schema VVB i Home Assistant<AKTIV> (rule-mgb8pfhs:S) from step 1 [latest-25310]2025-11-11T13:16:24.323Z <HassController:INFO> HassController#hass perform x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_natt with { "time": "03:00", "timestamp": 0 } [latest-25310]2025-11-11T13:16:24.323Z <HassController:INFO> HassController#hass: sending payload for x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_natt action: { "type": "call_service", "service_data": { "date": (null), "time": "03:00", "datetime": (null), "timestamp": 0 }, "domain": "input_datetime", "service": "set_datetime", "target": { "entity_id": "input_datetime.vvb_natt" } } [latest-25310]2025-11-11T13:16:24.324Z <HassController:ERR> HassController#hass request 1762866984323<2025-11-11 14:16:24> (call_service) failed: [Error] Not a parseable type for dictionary value @ data['date'] [-] [latest-25310]2025-11-11T13:16:24.324Z <HassController:WARN> HassController#hass action x_hass_input_datetime.set_datetime({ "time": "03:00", "timestamp": 0 }) on Entity#hass>input_datetime_vvb_natt failed! [latest-25310]2025-11-11T13:16:24.324Z <HassController:INFO> Service call payload: {"type":"call_service","service_data":{"date":null,"time":"03:00","datetime":null,"timestamp":0},"domain":"input_datetime","service":"set_datetime","target":{"entity_id":"input_datetime.vvb_natt"},"id":1762866984323} [latest-25310]2025-11-11T13:16:24.324Z <HassController:INFO> Service data: {"fields":{"date":{"example":"\"2019-04-20\"","selector":{"text":{"multiline":false,"multiple":false}}},"time":{"example":"\"05:04:20\"","selector":{"time":{}}},"datetime":{"example":"\"2019-04-20 05:04:20\"","selector":{"text":{"multiline":false,"multiple":false}}},"timestamp":{"selector":{"number":{"min":0,"max":9223372036854776000,"mode":"box","step":1}}}},"target":{"entity":[{"domain":["input_datetime"]}]}} [latest-25310]2025-11-11T13:16:24.324Z <Engine:ERR> Engine#1 reaction rule-mgb8pfhs:S step 1 perform x_hass_input_datetime.set_datetime failed: [Error] Not a parseable type for dictionary value @ data['date'] [-] [latest-25310]2025-11-11T13:16:24.324Z <Engine:INFO> Engine#1 action args: { "time": "03:00", "timestamp": 0 } [latest-25310]2025-11-11T13:16:24.325Z <Engine:INFO> Resuming reaction Sätt Schema VVB i Home Assistant<AKTIV> (rule-mgb8pfhs:S) from step 2 [latest-25310]2025-11-11T13:16:24.325Z <Engine:INFO> Sätt Schema VVB i Home Assistant<AKTIV> all actions completed.
Multi-System Reactor
Reactor Version 25310 : Office Light control via rule in reactor no longer working since last update.
P
Hello, I currently have an office light (connected via a Leviton Zwave Dimmer switch) controlled from a Gen5 Aeotech Zwave switch installed on my Synology 720+ NAS. I run HA(2025.11.10) in a virtual machine from my NAS and Reactor on the container manager of the same NAS. Prior to updating to 25304 the rule I had set to turn the light on to a specific dimming value worked correctly. Now the rule appears to follow the decision tree, however the reaction does not trigger setting the dimming or turning on the office light? Strangely I can still turn the light on and off as well as dim it directly from HASS..? I have tried using the ''try this action'' button in the rules reaction setting and it will not control the light and does not throw an error flagÉ Please help, P.S Reactor has been rock steady for me over the last few years and I'm a big fan of this solution.
Multi-System Reactor
Shelly Wall Display XL
therealdbT
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.
Hardware
[Solved] alarm() in global expression throws error in log.
CrilleC
Topic thumbnail image
Multi-System Reactor
[Solved] Define function issue in latest-25304
CrilleC
Topic thumbnail image
Multi-System Reactor
No Upgrade Notification for Build 25308?
CatmanV2C
FWIW I'm no longer getting a notification from MSR that there's an update. Just thought I'd mention it C
Multi-System Reactor
Strange behavior in MSR latest-25304 with disabled groups in Reaction
therealdbT
Topic thumbnail image
Multi-System Reactor
Do you Matter?
akbooerA
Is anyone using the Matter protocol to connect devices?
General Discussion
[Reactor] Variables not updating correctly in latest-25201-2aa18550
therealdbT
Topic thumbnail image
Multi-System Reactor
The reaction stopped working (Google Nest max playing a video)
F
Topic thumbnail image
Multi-System Reactor
Caution: zwave-js-ui docker 11.4.0 is broken
toggledbitsT
About 20 hours ago, the author of zwave-js-ui posted build 11.4.0 of that product, and it contains an error and won't start (at all) under docker. The author is aware and working on a fix. In the meanwhile, stick with 11.3.1 or earlier. Ref: Issue 4401
Software
About
Posts
201
Topics
40
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • Home Assistant 2025.11.2 and latest-25315
    T tamorgen

    @gwp1, stay at zwave-js-ui: 11.3.1, zwave-js: 15.14.0 (5.2.1) They broke iBlinds after that. It's' been reported and it's being worked, the last I saw. HAAS 2025.11.2 is working fine without upgrade ZwaveJs-UI.

    Multi-System Reactor

  • Reactor Version 25310 : Office Light control via rule in reactor no longer working since last update.
    T tamorgen

    I'm running into this as well. It appears that using haas>whatever-switch and power_switch.on or power_switch.off isn't working since the 25310 update and Haas 2025.11.0. I had a few stragglers in my rule sets that stopped working. I switched to using zwavejs>whatever-switch, and it works fine.

    I also tried from Entities --> whatever-switch --> Perform --> power_switch.on and there is no action performed

    Multi-System Reactor

  • Way to search for rules (rule state) in other rules
    T tamorgen

    That's fair. Thanks for answering with a workaround at least 🙂

    Multi-System Reactor

  • Way to search for rules (rule state) in other rules
    T tamorgen

    @toggledbits, not sure if this is a feature request or I'm using the search tool wrong. You have a "Search for rule" in the Rules Set tab in MSR. It works nicely to find a rule and bring up said rule, but can it/could it be used for as a "where used?" global search? For instance, I have a fairly large set of rules, divided up into 10 different rulesets. There's easily a hundred individual rules, and many of the rules have Rule State triggers, which of course refer to other rules. Amongst my troubleshooting today, I came across what may have been a duplicate or troubleshooting attempt, but I can't tell if it's actually used as a Rule State in another rule without opening each rule that I suspect it may be a part of.

    Thanks.

    Multi-System Reactor

  • Need help figuring out how to delay a reset on reaction
    T tamorgen

    said in Need help figuring out how to delay a reset on reaction:

    @gwp1 said in Need help figuring out how to delay a reset on reaction:

    Essentially, don't try to do things with "one big beautiful ruleset"

    Seriously. It can't be done in one, but sometimes I swear I've paired it down into so many individual functions, I forget how it all works together. When I'm troubleshooting, I have to go back and look at the rules, and think "what was I trying to do here again?"

    Multi-System Reactor

  • Need help figuring out how to delay a reset on reaction
    T tamorgen

    @gwp1 said in Need help figuring out how to delay a reset on reaction:

    Essentially, don't try to do things with "one big beautiful ruleset"

    Seriously. It can't be done, but sometimes I swear I've paired it down into so many individual functions, I forget how it all works together. When I'm troubleshooting, I have to go back and look at the rules, and think "what was I trying to do here again?"

    Multi-System Reactor

  • Need help figuring out how to delay a reset on reaction
    T tamorgen

    @gwp1, no only away. The Home mode is only 15 seconds.

    287d259d-cdc8-40e8-a723-e754ebfcb5f4-image.png

    However, since the "Phones Home" rule is a geofence rule (based upon the HA companion app), it detects the phone being there before I'm actually in the house. The Home mode does not disarm the alarm system, that is still manually done at the keypad. The only delay would be lights automatically turning on, or blinds opening during the day.

    Multi-System Reactor

  • Need help figuring out how to delay a reset on reaction
    T tamorgen

    Test appears to be successful. I was able to use one of the guest users PINs for the alarm panel, and the system went into and stayed in Guest mode. Thanks to @gwp1 for reminding me to keep it simple and get rid of the reset.

    Multi-System Reactor

  • Need help figuring out how to delay a reset on reaction
    T tamorgen

    Okay, this actually seems to be working. I needed to disarm my home alarm first, then put it in Guest mode. It appears be holding now.

    Next test, is I need to disarm the system with one of the guest users to see if it stays disabled.

    Multi-System Reactor

  • Need help figuring out how to delay a reset on reaction
    T tamorgen

    @gwp1 said in Need help figuring out how to delay a reset on reaction:

    @tamorgen You're falling into the same pitfalls I did. Notice my Mode SETs don't have resets. No need. The next appropriate rule SETs so there's no reason to reset. Any resets (like from GUEST back to AWAY or VACA) are done via their own SET rulesets.

    Okay, I think I've made progress thanks to your suggestion.

    I took the thought of creating a new rule for "Go to Away Mode", and removed the reset from "Phones Home".

    In the new "Go to Away Mode" rule, I added a condition that the mode needs to "Phones Home" rule needs to be sustained for 60 seconds.
    688c0605-c4f5-4903-8b70-e1571c6f29f1-image.png This at least makes it specific, as to what my rules do.

    Next I tried to toggle the house mode in Home Assistant, and well, it immediately changed to "Home", which is different than what I expected.

    So now, the "Go To Home Mode" rule is being tripped. I added a very short 15 second "must be sustained" condition for the "Phones Home" rule state in that rule, and now it lets me change the drop down to Guest Mode. Unfortunately, 15 seconds later, i changes to Home mode, then it changes to Away mode. I feel like this is progress, but I need to figure out why it's not staying in Guest mode

    Multi-System Reactor

  • Need help figuring out how to delay a reset on reaction
    T tamorgen

    said in Need help figuring out how to delay a reset on reaction:

    @gwp1 said in Need help figuring out how to delay a reset on reaction:

    @toggledbits gave me very sound advise early on as I was prone to making my rulesets "do too much" in addition to waaaaaay overthinking/overcomplicating things.

    Instead of trying to make a ruleset that determines presence AND tries to set mode, just have it determine presence. Have one for your immediate family and one for your guests. Then use the TRUE FALSE state of them in your mode rules. (Saves you countless hours later, too, when you add/remove people from either presence ruleset.)

    That is essentially what I'm doing. The "Phones Home" doesn't set the mode, except to reset it. I suppose I could make the reset a separate rule, but I'm not sure how that would solve my problem.

    And it's 100% possible I'm overthinking this, or I'm in so deep, that I'm not seeing the obvious. Many of these rules were built on the original Reactor in Vera, before converting to MSR. I had to work with the limitations of Vera at the time, and of course the plug-ins that stopped working quite regularly.

    Multi-System Reactor

  • Need help figuring out how to delay a reset on reaction
    T tamorgen

    @gwp1 ,
    So, the conditions for Away, are essentially the reset of the "Phones Home" rule. If no phones are home, and the conditions for Guest haven't been set, then it's going the "Phones Home" rule becomes false and resets itself.

    The Guest mode is met (or supposed to be) when the user code from my home alarm is read for 2 specific user IDs, or I have manually set the mode to Guest from Home Assistant (it's a input select value, the last screen shot in my last post). Unfortunately, this only works properly if someone in the HA companion app users is home to put the mode into Guest.

    The Guest mode ends when a HA companion app user arrives back home.

    Multi-System Reactor

  • Need help figuring out how to delay a reset on reaction
    T tamorgen

    Sorry for the delay in responses. I've been traveling, and it's been difficult to do any of the troubleshooting on my iPad

    @toggledbits, it's quite the opposite of what you think. The Phones Home rule I mostly use as a rule state for another rule. That other rule is what put's my Home Assistant and Reactor into Home Mode.

    c4c9c626-c54f-44a5-9c70-36e7f82b2fd8-image.png

    When the "Phones Home" rule becomes true, the "GoTo Home Mode" changes settings in the home that puts for the all the other reactions that may or may not occur, depending on time of day, time of year, etc. When the any of the phones leave the geofenced area, and the "guest mode" isn't set (the last of the 6 triggers in the "Phones Home" rule, it reset's the rule state, which changes the House Mode to Away.

    Now, here is the real problem I'm having. As I mentioned in the initial post, I have a guest mode specifically for people that need to come in my home, that don't have the Home Assistant companion app, such as a neighbor that I might need to come over and check on our cats while we're gone, or our house cleaner that comes by once a month. They have a code to the alarm system, and I can tell by the user ID on the panel which user disarmed the system. From there, I want to put the system into Guest mode, so the Phone's Home mode won't reset, and the "Arm Away" rule set's the alarm system to Away, which in turn arms the interior motion sensors, and you can see where it would go badly from there.

    ef085637-2030-4ed4-91b5-06d68f1c0f23-image.png

    dd195622-1dcb-4afa-aca1-18cfedef2837-image.png

    So, what is happening, is when one of the guest's tries to disable the system, it rearms a minute or so later. The "GoTo Guest Mode" doesn't have a chance to put the "House Mode" into Guest.

    Guest Mode does work, if I'm able to have the "House Mode" set to Home first, then change it to Guest, but this unfortunately requires me to be at home to make this work.

    You can see below from Home Assistant, that when I'm away, and I try to manually put the House Mode into Guest, it immediately goes back into Away.

    2f08334f-32f2-4a53-b217-e9173aa08548-image.png

    In the Reator logs, you can see the immediate reset.

    root@hal:/home/tmorgenthaler/reactor/logs# cat reactor.log.1 | grep Phones
    [latest-25139]2025-06-16T13:31:47.275Z Rule:INFO Phones Home (rule-grp19i3lbdi in Phone presence) evaluated; rule state transition from RESET to SET!
    [latest-25139]2025-06-16T13:31:47.307Z Rule:INFO Phones Home (rule-grp19i3lbdi in Phone presence) evaluated; rule state transition from SET to RESET!
    [latest-25139]2025-06-16T13:31:47.316Z Engine:INFO Enqueueing "Phones Home<RESET>" (rule-grp19i3lbdi:R)
    [latest-25139]2025-06-16T13:31:47.318Z Engine:NOTICE Starting reaction Phones Home<RESET> (rule-grp19i3lbdi:R)
    [latest-25139]2025-06-16T13:31:47.346Z Engine:INFO Resuming reaction Phones Home<RESET> (rule-grp19i3lbdi:R) from step 1
    [latest-25139]2025-06-16T13:31:47.346Z Engine:INFO Phones Home<RESET> all actions completed.

    The only thing I can think of is there needs to be some sort of delay for the reset in the "Phones Home" rule, but I'm not sure the best way to approach it.

    Multi-System Reactor

  • Need help figuring out how to delay a reset on reaction
    T tamorgen

    @gwp1, yeah, I collapsed them because of how I’m having to work on my iPad.

    Each of those collapsed rules, are rule states of other rules, which determine the actual presence of the individual users. They are all identical, except for which device they tracking.

    524e8079-d947-468c-8b75-bb088270a2c9-image.png

    0bf03e08-084f-4d2b-a9fe-dff9e236a01c-image.png

    These work nearly flawlessly individually. If a user has the companion app, no issue. It’s when I’m trying to “fool” the system for non users into arming into away mode, shutting everything down, and arming the home alarm system to away, that I’m having issues with, if you follow

    Multi-System Reactor

  • Need help figuring out how to delay a reset on reaction
    T tamorgen

    Good afternoon all,
    I believe I’m having an issue with my logic for setting my home modes in MSR, partially based upon Phone modes in Home Assistant. Users in my family have the Home Assistant companion app installed on their phone, and it geofences the users, so once they are within my home circle geographically, it sets a Boolean to home mode. If they are out it it’s away. I also have a couple of other modes, which I struggle to activate, and it causes issues when I have guests, or pet sitters that come over that do no have the companion app.

    I have a guest mode that has to be manually set in Home Assistant, that disables the Away mode automation (based on the companion app statuses), until either a user with the companion app arrives home, or a guest arms the alarm system (away arm).

    My issue is that I seem to unable to set the system into Guest mode from Home Assistant, because MSR keeps trying to arm the system. I think that I need to have some sort of a delay for the Reset reaction.

    In the rules below, each of the users has a separate reaction that evaluates the state of the iPhone. This rule is a giant OR rule that evaluates the state off all them to decide the mode of the house.

    d70a1267-6966-49fd-8ef9-b6ffa9ccb5c2-image.jpeg

    0104720d-e38f-44f8-8d72-df8b7c6d6ad7-image.png

    Appologizes for the formatting. I’m away from home and doing this on my iPad, so my screenshots can’t display the full rule.

    As you can see in the Rule history, it was rapidly resetting every time I tried to put the house into guest mode around 18:00 yesterday. I was on a plane and my mother-in-law arrived to take care of our pets, and I had to log in on my phone to my server and disable MSR to stop the automation in the house completely.

    767ae3d9-4b10-4763-bc3b-48ac666c0283-image.png

    Any suggestions on how I can handle this flapping?

    I have another set of rules for users that don’t have the companion app, but is rather based on the user ID for the alarm system and put the house into Guest mode, but I’ve never been able to get this to work completely. It exhibits the same behavior of trying to arm the system immediately.

    The only reliable way for me to set the house into Guest mode is to be in at home mode first, then switch to guest mode. I believe this is all linked to this rule in question.

    I appreciate the long read and any advice.

    Multi-System Reactor

  • Advice reqeusted to migrate MSR from Bare Metal to Container
    T tamorgen

    @toggledbits,
    Well, I took a first step. I tried using the docker-compose.yaml file with podman-compose, but it gave me some issues. I fell back on just using docker-compose, and it worked with only a minor hickup. It told me the version tag was depricated and to remove it to prevent problems in the future, so I did so, and it's running without issue. Rules and reactions are working as before, which is fantastic. Reactor on my old server is stopped/disabled, so one more item crossed off. I'm hoping to have the old server fully decommissioned this weekend.

    At some point, I'll go back and try and get it running with Podman, if it's possible. I can engage their community and see if they have any advice, but right now it's more important for me to turn off my office heater going into summer.

    The other major advantage is that in theory, I won't have to manually update nodejs each release, which has been kind of a pain lately.

    Multi-System Reactor

  • Advice reqeusted to migrate MSR from Bare Metal to Container
    T tamorgen

    @toggledbits, thanks for the very detailed reply. One of the things I was struggling with understanding was the reference to the user directory in the example docker compose file.

    In reality, docker and podman aren’t that different. Podman can use docker images without issue. I’m doing so currently with a Plex image. In fact, I didn’t even have to destroy and recreate the container. All I had to do was take the variables out of the docker container and put it into Podman. Podman will even often run with docker compose files.

    And you are right about user privileges. Podman doesn’t need to run things as root. They see it as an advantage.

    Another advantage is that you can run multiple containers in the same network space. For instance, I can run Pi-hole and Unbound in the same private IP space, so they can interact with each other, but nothing that I don’t want to.

    Back to the subject at hand, I need to copy my extras, config, and storage directories into my user directory, and they’ll stay safe, and I should be able to have my reactor service up and running on the new server, is what I’m hearing. I’ll let you know how it goes.

    Multi-System Reactor

  • Advice reqeusted to migrate MSR from Bare Metal to Container
    T tamorgen

    Good day all,
    I'm in the process of trying to shut down my 10 year old Linux home server that served many purposes, but primarily it's what I used for my NAS/Plex Media server. I migrated the NAS aspect of the server in November of last year to a true NAS solution (Ubiquti UNAS Pro), which is rack mount and much more efficient than my old tower, which it's only side benefit was heating my home office during the winter. Unfortunately it also means heating my home office during the summer, which were about to be in full swing.

    I have two things running on this 10 year old server at this point. MSR and pi-hole. I'm running Plex Media Server on Fedora Workstation in Podman on mini PC, which is much more energy efficient than my old tower. My next step is to migrate MSR. I know there are images of MSR out there, and creating it is well documented. I'm going to be using Podman instead of Docker for various reasons, but they work very similar. What I don't know, is what I need to do to migrate my existing Bare Metal installation over to a container.

    Has anyone done this? Any advice?

    Multi-System Reactor

  • Need help reducing false positive notifications
    T tamorgen

    @toggledbits,

    I tried to go about the way you mentioned, but I don't think it was quite suited for my purpose. The purpose of the rule is to send a notification through Home Assistant to my phone, and I didn't want a delay that I believe your method would have introduced. What I came up with was creating a global variable and a helper rule, that sets the global variable to true when the 300 seconds is exceeded of power being above 3.7.

    b0f50fcc-a06f-49a6-9ccb-38f718d7cc42-image.png

    88547953-dbd8-4646-80a9-48b03a6c09ad-image.png

    Then there is a Variable Value check in the Triggers of the Notification rule:
    8b91b3c4-cc46-44db-a4f1-a76408f7c79b-image.png

    The Reaction resets the Global rule back to false, after the cycle is completed.

    It may not be the most elegant method, but it reduces the false positives on my phone when the cycle selector is bumped. For the same reason, I have the reactor uptime checked, because I would get tons of notifications on my phone when I did an update to MSR, or when my server was rebooted. I know I could completely encapsulate the logic within MSR, but the overly simplistic sensor in HAAS serves it's own purpose in HAAS for my dashboard, and HAAS can't read rule states from MSR, so for my purpose, I already have the simple sensor in place, so why reinvent the wheel?

    Multi-System Reactor
  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Unsolved