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.
3

3rdStng

@3rdStng
Home Assistant Connect ZWA-2 & ZBT-2
therealdbT
Topic thumbnail image
Hardware
[MSR] Feature request: For Each action on arrays/groups
therealdbT
Topic thumbnail image
Multi-System Reactor
[Solved] 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
Issue with MSR UI becoming unresponsive
S
I'm having an issue with MSR's UI being very unresponsive. It started happening a couple days ago and I didn't make any changes that would have caused this except adding some meross lan devices in HA. When I go into an entity action and use the search functionality, it usually will start filtering and then get to a place after a few letters are entered where it will take 30 seconds or more (sometimes minutes) for the UI to show what I am typing. During this time MSR ui is completely unresponsive. I've tried multiple browsers and multiple computers. HA and MSR are both deployed in docker. I have run HTOP on the host and when the problem happens there are no CPU/Memory spikes at all. From a functionality standpoint MSR is working perfectly. This seems to be an UI issue only. Do i need to ditch Docker and run MSR on a Proxmox VM? I have both stand alone Docker and Proxmox environments. I dont mind doing that I just want to be able to use the UI again... Installation method Home Assistant Container Core 2025.7.3 Frontend 20250702.3 nothing crazy in the logs except some openweather map stuff that doesn't make any sense as it is working fine in MSR Any help would be greatly appreciated Reactor latest-25328-b2ed1365 app 25328 configuration from /var/reactor/config NODE_PATH /opt/reactor:/opt/reactor/node_modules [latest-25328]2025-11-30T20:01:53.843Z <app:null> Reactor build latest-25328-b2ed1365 starting on v24.11.1 /usr/local/bin/node [latest-25328]2025-11-30T20:01:53.844Z <app:null> Process ID 1 user/group 0/0; docker; platform linux/x64 #161-Ubuntu SMP Tue Jul 22 14:25:40 UTC 2025; locale (undefined) [latest-25328]2025-11-30T20:01:53.844Z <app:null> Basedir /opt/reactor; data in /var/reactor/storage [latest-25328]2025-11-30T20:01:53.844Z <app:null> NODE_PATH=/opt/reactor:/opt/reactor/node_modules [latest-25328]2025-11-30T20:01:53.865Z <app:null> Resolved timezone=America/New_York, environment TZ=America/New_York; offset minutes from UTC=-300 [latest-25328]2025-11-30T20:01:53.867Z <default:null> Module i18n v25141 [latest-25328]2025-11-30T20:01:53.867Z <app:null> Configured locale (undefined); selected locale(s) en-US.UTF-8 [latest-25328]2025-11-30T20:01:53.879Z <app:null> Loaded locale en-US for en-US [latest-25328]2025-11-30T20:01:53.879Z <app:null> Local date/time using configured timezone and locale formatting is "11/30/2025, 3:01:53 PM" [latest-25328]2025-11-30T20:01:53.889Z <Structure:null> Module Structure v25326 [latest-25328]2025-11-30T20:01:53.890Z <Capabilities:null> Module Capabilities v24312 [latest-25328]2025-11-30T20:01:53.904Z <Plugin:null> Module Plugin v25141 [latest-25328]2025-11-30T20:01:53.923Z <Timer:null> Module Timer v25279 [latest-25328]2025-11-30T20:01:53.924Z <TimerBroker:null> Module TimerBroker v25314 [latest-25328]2025-11-30T20:01:53.927Z <Entity:null> Module Entity v25251 [latest-25328]2025-11-30T20:01:53.929Z <Controller:null> Module Controller v25253 [latest-25328]2025-11-30T20:01:53.930Z <AlertManager:null> Module AlertManager v25318 [latest-25328]2025-11-30T20:01:53.937Z <default:null> Module Ruleset v25283 [latest-25328]2025-11-30T20:01:53.937Z <default:null> Module Rulesets v25141 [latest-25328]2025-11-30T20:01:53.942Z <GlobalExpression:null> Module GlobalExpression v25258 [latest-25328]2025-11-30T20:01:53.953Z <Predicate:null> Module Predicate v25328 [latest-25328]2025-11-30T20:01:53.956Z <Rule:null> Module Rule v25323 [latest-25328]2025-11-30T20:01:53.958Z <GlobalReaction:null> Module GlobalReaction v25292 [latest-25328]2025-11-30T20:01:53.959Z <Engine:null> Module Engine v25325 [latest-25328]2025-11-30T20:01:53.964Z <httpapi:null> Module httpapi v25328 [latest-25328]2025-11-30T20:01:53.972Z <wsapi:null> Module wsapi v25328 [latest-25328]2025-11-30T20:01:53.994Z <TaskQueue:null> Module TaskQueue 24138 [latest-25328]2025-11-30T20:01:53.994Z <VeraController:null> Module VeraController v25141 [latest-25328]2025-11-30T20:01:54.179Z <HassController:null> Module HassController v25325 [latest-25328]2025-11-30T20:02:13.797Z <OWMWeatherController:null> Module OWMWeatherController v25268 [latest-25328]2025-11-30T20:02:13.800Z <SystemController:null> Module SystemController v25323 [latest-25328]2025-11-30T20:02:13.807Z <MQTTController:null> Module MQTTController v22092 [latest-25328]2025-11-30T20:02:20.630Z <OWMWeatherController:CRIT> FetchError: request to https://api.openweathermap.org/data/2.5/weather?lat=xxxxxxxxxx&lon=-xxxxxxxxx&appid=xxxxxxxxxxxxxxxxxxxxxxxxxx&units=standard&_r=1xxxxxxxxxxxxxxfailed, reason: [-] FetchError: request to https://api.openweathermap.org/data/2.5/weather?lat=xxxxxxxxxxx&lon=-xxxxxxxxxxxxxxxxxx&appid=xxxxxxxxxxxxxxxxxxx&units=standard&_r=xxxxxxxxxxxxxxxfailed, reason: at ClientRequest.<anonymous> (/opt/reactor/node_modules/node-fetch/lib/index.js:1501:11) at ClientRequest.emit (node:events:508:28) at ClientRequest.emit (node:domain:489:12) at emitErrorEvent (node:_http_client:108:11) at TLSSocket.socketErrorListener (node:_http_client:575:5) at TLSSocket.emit (node:events:508:28) at TLSSocket.emit (node:domain:489:12) at emitErrorNT (node:internal/streams/destroy:170:8) at emitErrorCloseNT (node:internal/streams/destroy:129:3) at processTicksAndRejections (node:internal/process/task_queues:89:21
Multi-System Reactor
Date/time condition
tunnusT
Topic thumbnail image
Multi-System Reactor
Is there a way to turn this section (image in post) off?
toggledbitsT
Topic thumbnail image
Comments & Feedback
Device log?
G
@toggledbits is there a log that will show me what rule is turning on a specific device? I've got a switch that has been kicking on at 2200 ET for several nights now and the reactor.log doesn't have a thing in it that I can see on a device level (it being more rules-based).
Multi-System Reactor
Midnight crossing not working in date/time condition (build 25325)
tunnusT
Topic thumbnail image
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
About
Posts
113
Topics
26
Shares
0
Groups
0
Followers
0
Following
1

Posts

Recent Best Controversial

  • Rule Set UI bug - RESOLVED
    3 3rdStng

    Docker image "latest-25264-2fbe9217" running on unRAID.
    Running this in Chrome Version 140.0.7339.[128 or 208] with the same results in Edge.

    The UI, when searching within the Rule Set, does not reset/self clear when you click outside of the rule set area.

    To reproduce the issue:
    Click on Rule Sets and type in something within the Search window that does not exist for a rule name. "french" in my example.
    12295a06-0fc3-444d-94c9-9522b26dad42-image.png 397bdea2-670c-4600-8c09-03c169b8b5d9-image.png

    Click outside of the gray area, where my mouse is in the screen grabs, which will close the Rule Sets pop over.
    Click on Rule Sets again and none of the rules will appear. The search term isn't sticky either.
    e0a29f89-abcd-4afa-9bfa-56e5e1871f04-image.png

    The rules won't appear again until you type any character, or press the backspace, in the "Search for rule" field.
    10ddb064-86e1-446c-a69b-a8297f6d90f1-image.png

    Multi-System Reactor

  • [Reactor] Variables not updating correctly in latest-25201-2aa18550
    3 3rdStng

    I don't know if my issue is related or not here. It seems like it should, but I also understand that local expression handling has changed within the last couple of builds. I don't know exactly when my issue started, nor what build I was on. My guess would be Sept 7th as my rule was last "SET" on that date.

    I am running latest-25254-f6a45e41 in a docker on unRAID. The following rule has been in place for years and has been working pretty reliably, until recently.

    image.png

    The Set Reaction is just to turn on the shower exhaust fan. I collapsed it for screenshot space.
    If I change the Local Expressions to: (and in this order)

    MBath_HumityRise = "CurrentHumidity - MBath_prevHumidity"
    MBath_prevHumidity = "CurrentHumidity"
    CurrentHumidity = (some # value like 48)
    

    And then manually change the CurrentHumidity value to 54 (something >=3), the rule triggers. The MBath_HumidityRise value changes to 6 too. Setting the CurrentHumidity to 50, changes the HumidityRise value to -4.

    When I set these expressions back to pull from the device, I see the prevHumidity value change, but the HumidityRise value always stays 0. I set up global expression under different names and watched the values too. In the same order with the Rise expression above the Prev expression, I never see the Rise value change.

    I will see if I have 25260 available for my docker update and test that, but for the life of me I cannot figure out why this rule stopped working.

    EDIT: Updated to 25260 and I'm still not seeing the HumidityRise expression change. I kept my global expressions since they update and refresh on the page, where the local expressons don't appear to do so within the rule. Watching these two expressions, as soon as the prevHumidity sensor updates, the expression turns green. But the Rise expression didn't and still showed 0. In this screen grab, the humidity went from 46 to 45. I would have expected the top expression to show a -1.

    d9db6c59-4592-4acb-8baf-87dc8ae1a5dd-image.png daaa5ce6-8bd1-440c-af88-b3870297a781-image.png

    Multi-System Reactor

  • Feature Request - Wait for an event/trigger within Reaction [Solved with Work Around]
    3 3rdStng

    Refined my actions to include a timeout, just in case someone comes home, but they leave without entering the door.

    Actions:
    Set variable 'lastLockEvent' to "pending entry"
    Turn on porch light
    Turn on driveway lights
    Repeat While:
    -- Triggers:
    -- [lastLockEvent] contains "manually locked"
    -- [OR]
    -- [lastLockEvent] contains "pending entry" (condition sustained for 20 minutes)
    -- Actions:
    -- Delay 10 seconds
    Delay random between 1 to 5 minutes
    Turn off porch light
    Turn off driveway lights

    Multi-System Reactor

  • Feature Request - Wait for an event/trigger within Reaction [Solved with Work Around]
    3 3rdStng

    @toggledbits said in Feature Request - Wait for an event/trigger within Reaction:

    hub variable should appear as an entity with the string_sensor capability, and it should have an extended action (x_hubitat_Variable.setVariable) to let you change the value.

    Worked perfectly!

    Thank you for the feedback and allowing me to type out my thoughts to refine this rule.

    Multi-System Reactor

  • Feature Request - Wait for an event/trigger within Reaction [Solved with Work Around]
    3 3rdStng

    @toggledbits said in Feature Request - Wait for an event/trigger within Reaction:

    As you disclose details, it's beginning to look like you've imagined a solution based on some other product, and you're trying to get Reactor to work its way, instead of doing it "the Reactor way."

    That is very possible. I'm still mentally mapping this out too. And I 100% know that an image of my rule set would really help clear things up. I'm not in a position to get a screenshot at the moment. I'll try to put my thoughts in to text. (scary)

    Rule set as of today:
    Triggers:
    After midnight AND
    Before sunrise AND
    Any Presence Sensor in the group changes from Not Present to Present

    Actions:
    Turn on the porch light
    Turn on the driveway lights
    Wait for a random period of time between 10-15 minutes
    Turn off the porch light
    Turn off the driveway lights

    What I am after is within the Actions only. The Triggers are still the same.

    Actions:
    Turn on the porch light
    Turn on the driveway lights
    Wait until the HE Hub variable "lastDoorLockEvent" reports "Manually locked"
    Wait for a random period of time between 10-15 minutes
    Turn off the porch light
    Turn off the driveway lights

    The waiting until the hub variable is what's potentially causing the issue. When I go to bed, and assuming the door was open, I'll close it and lock it. So the hub variable now reports "Manually locked". If someone arrives after midnight and before sunrise, the variable will still report "Manually locked" since the lock status hasn't changed yet. So theoretically MSR won't wait since it already sees the variable as what it is looking for.

    And as I type this out, I suppose I could insert a set variable into the actions. I honestly haven't looked yet, but can MSR set a variable that is local to the hub only? Not within MSR.

    Actions:
    Turn on the porch light
    Turn on the driveway lights
    Set HE Hub variable "lastDoorLockEvent" to "waiting entry"
    Repeat Until the HE Hub variable "lastDoorLockEvent" reports "Manually locked"
    Wait for a random period of time between 10-15 minutes
    Turn off the porch light
    Turn off the driveway lights

    The entire concept stems from Hubitat's Rule Machine's "Wait for event" that you can define in a rule. I have a couple of these at my remote HE, where I can't run MSR easily.

    Multi-System Reactor

  • Feature Request - Wait for an event/trigger within Reaction [Solved with Work Around]
    3 3rdStng

    Hmm.... Thanks for this, I think I can make it work, but it may take two Repeat While actions. It doesn't appear that I can wait for a change. It's only waiting for a True or False and not a change from Opened to Closed.

    I believe in my rule I would need a "Repeat While the door is false" (open) to wait for someone to actually open the door. Then a "Repeat While the door is true" (closed) to wait for them to close the door and then continuing on the actions to turn off the lights.

    Multi-System Reactor

  • Feature Request - Wait for an event/trigger within Reaction [Solved with Work Around]
    3 3rdStng

    I think this feature request could be accomplished with the use of two or more rules, but it would be great if there was a way to wait for an event or trigger to occur before continuing on in the reactions.

    For example, I have a rule that will turn on some exterior lights if you arrive home after the porch lights have been turned off. Right now this rule randomly will turn off between 5-10 minutes after the person has entered the geofence. On some occasions this 5-10 minutes isn't long enough, say if you are unloading the car or something. I would like to kick off the reaction, but pause it part way through and wait for the door to close and lock, then continue it on. Hubitat Rule Machine has a "Wait for event" option, but I really want to keep all my logic within MSR.

    Multi-System Reactor

  • Free to a new home
    3 3rdStng

    I have an older Vera Plus controller that has been collecting dust for a little while. I know the hardware is no longer supported but I would prefer it to go to a good home vs the eWaste center. No charge, just pay for shipping and it's yours. If you are interested, let me know.

    Vera

  • [RESOLVED] Troubleshooting assistance/ideas needed
    3 3rdStng

    I love it when solutions come to you in your dreams. It dawned on me that my Hub Security on the hub was reset but I still had it enabled on MSR. As soon as I enabled it on my hub and restarted MSR, and literally had a kid walk through the entire house, every motion sensor was tripping back and forth from inactive to active back to inactive.

    Multi-System Reactor

  • [RESOLVED] Troubleshooting assistance/ideas needed
    3 3rdStng

    Running MSR latest-23344-ca53d088 within a Docker.

    My Hubitat (HE) hub suffered almost a 4 day outage from a corrupt backup that failed to restore. During this time I had my MSR docker stopped. Well, I didn't stop it until the the hub had been down for 24 hours. Anyway, I finally got the hub back online this morning and am fixing my MSR rules for everything that was lost. Support needed to purge out the Apps section of the backup.

    So my issue. So far everything I have fixed is working as expected, with the exception of my motion controllers. I can see them go "Active" within my HE, but the Entity within MSR never changes from false to true. I ran through a slew of rooms that have motion sensors and only 1 out of 6 changed to true.

    I removed the sensor I'm testing with from Maker API, restarted MSR, re-added it, restarted MSR, but no difference. I then Deleted it from MSR and restarted MSR. It was re-added, but again no change. How can I go about testing this further to find out why/what is going on?

    Multi-System Reactor

  • [RESOLVED] PSA for Hubitat 2.3.7.x upgrade
    3 3rdStng

    Hmm.. OK. I was re-reading the HubitatController section of the docs and realized that I removed my Hub Information device a couple of months back. Perhaps that was part of the issue? I put it back and then upgraded to 2.3.7.140. So far so good. Hopefully it was the missing Hub Information device, or perhaps my HE was just having an off day? I'll monitor things and report back if there is any issues. Thanks all.

    Multi-System Reactor

  • [RESOLVED] PSA for Hubitat 2.3.7.x upgrade
    3 3rdStng

    Same here. Docker image latest-23344-ca53d088. And I am aware that he would need more details. I'm not reporting this has a bug since he hasn't blessed 2.3.7 yet. I actually upgraded earlier in the day and some rules were triggering just fine. It wasn't until the evening when a lot of my logic was SUPER slow, delayed, or not working at all. Which would make sense if MSR couldn't chat with the hub.
    I don't subscribe to the remote backups, so I don't think that bug will effect me. But good to know, thanks.

    Multi-System Reactor

  • [RESOLVED] PSA for Hubitat 2.3.7.x upgrade
    3 3rdStng

    If you are thinking about upgrading your Hubitat Elevation hub from 2.3.6 to 2.3.7, and you are using MSR.... wait! I was trying to resolve a different issue with the HE and didn't even think twice about how MSR would react. Well... MSR was not happy and was complaining that the events feed had become unresponsive. And my automations were not working either. I have since reverted back to 2.3.6 and will happily wait for @toggledbits to do his magic.

    5a147634-6008-4d4c-a698-c22f6936ee0c-image.png

    Multi-System Reactor

  • Possible Typo/Correction in Manual
    3 3rdStng

    Hi @toggledbits,

    I had an idea about my Echo speaking which windows or doors are open when an announcement is made reminding the family to close things up when it is hotter outside. Let me start off by saying I'm not great with expressions and in no way any programmer. To get started I read the How To: Expressions and what do you know, you have an example on how to do exactly what I am looking for. However I think I found a typo/correction that may be needed? Again, not a programmer here.

    In the How To: Expressions with Entities section you state the new expression called open_perimeter_doors and give the example with the end of null : doorid. In the description you state you order them this way because when the door_sensor.state is true, the door is closed/secure. I have a few different brands of contact sensors and all of them are just the opposite. They are true when they are open and false when they are closed. For me, this was an easy fix. I swapped them.

    What blew my mind and took a bit of thinking was a little further down in your example of joining the getEntity ID and getName.

    join( each doorid in perimeter_doors: do
               e = getEntity( doorid ),
               e.attributes.door_sensor.state ? null : e.getName()
           done
        , ", " )
    

    The "e.getName()" in the example would cause the expression to never evaluate. I needed to change this to "e.name". With e already being set as "getEntity( doorid )", only name was needing to be appended. In your example you are appending ".getName()", resulting in "getEntity( doorid).getName()"

    Again, NOT a programmer, but perhaps a stale How To example from before a major update to the expression logic? Just wanted to share my results in case the manual does need an update.

    295ee66b-f5a2-437f-8686-4a835db6c02d-image.png

    Multi-System Reactor

  • Reactor Ex Machina
    3 3rdStng

    I'm not in need of it. As I was moving off Lighting Director I just happened to notice they had a max number of lights. I think the OG DeusExMachina did too. I think how you have it would be more lifelike. Especially when you couple of a few specific OFF rules so the lights turn off faster than 10-20 minutes.

    Multi-System Reactor

  • Function sanity check please
    3 3rdStng

    MSR: latest-23078-d592d400
    --Docker image on unRAID
    Hubitat C-7: 2.3.5.121

    I'm always looking to simplify my rules and reactions and having finally grasped the Array function with a loop of perform.Action, I decided to re-write one of my rules. The kids like to play music on the Echo devices at a high volume, and I also have TTS loud during the night if a door/window are to open. In order to not have her yell at me later, I wrote a rule that resets the volume on each Echo device to a level of 2. However having 7 Echo's, there are many steps in my Reaction. Set the volume on device 1, wait a few seconds, set the volume on the device 2, wait, and so on.

    Sample snippet of the set reaction: (This works BTW.)
    2f5aafc0-bf97-4622-b41c-60649253590e-image.png

    To make it better, I created an array of the devices and want to run a perform.Action command. Less steps with the same results. Or so I thought. The end result is now a volume level of 0 or 1. I think the Echo gets confused. Either way, not a level of 2 like I was expecting. BTW volume 1 across the room is too low, in case you were wondering.

    New set reaction:
    da62dfb0-f433-4fc6-897f-d38c190f8c9a-image.png

    ${{ each device in Echo_devices: performAction( device, 'volume.set', { level:0.20 } ); 0 }}
    

    The av_transport.stop works as expected. The issue is with the volume.set, {level:0.20}. Do I have something wrong in my command?

    Global expressions used:
    8d054dca-20dc-4e97-aa6d-4537c9da4ea9-image.png

    e3e388d3-f18e-4744-8eee-432234161739-image.png

    Multi-System Reactor

  • Reactor Ex Machina
    3 3rdStng

    @kellyjelly32 Is there a way to specify how many lights should be on at one time? I tested REM last night and the most on at the same time appeared to be two. I'm fine with this, but curious if there was an option or way to adjust it. Again, thanks for sharing your logic.

    Multi-System Reactor

  • Reactor Ex Machina
    3 3rdStng

    Ahh... I miss that app. Probably one of my favorites from my Vera days. The "Lighting Director" app on Hubitat just isn't the same.

    Thanks for posting your setup @kellyjelly32. I've mocked this into my MSR and if all works well, DeusExMachina returns. Well kinda

    Multi-System Reactor

  • [RESOLVED] How quickly should logs rotate?
    3 3rdStng

    @toggledbits Awesome. Thank you.

    I know you know, but for others, the rule ID is also noted in the logs. Makes it easier to copy and paste without having to look up the ID within the GUI.
    f5fc7a07-2b33-4574-b3ec-d2dca45c70f6-image.png

    Multi-System Reactor

  • [RESOLVED] How quickly should logs rotate?
    3 3rdStng

    Thank you. I changed all my rules that had a presence sensor written in them. As well as a few other rules that have an app that phones home every minute. Just restarted MSR for good measure and can see a different. I'm over 30 minutes right now between .log and .log.1.

    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