-
Some background
I have MQTTController based entities that I want to use in time calculations in my rules. These entities represent two separate time ranges, one for the weekdays and the other for the weekends. In this particular example they are used to control my doorbell activity (whether it's enabled or disabled).
MQTT message which is used to update the entities. NOTE: time is in 24h format
{ "data": { "weekdays": { "enable": "09:28", "disable": "20:00" }, "weekends": { "enable": "09:00", "disable": "21:00" } } }Entity definitions (here's only the definition for the weekdays for brevity)
doorbell-weekdays-enable: name: 'Ovikello päälle (arkisin)' topic: 'doorbell/settings' capabilities: - string_sensor primary_attribute: string_sensor.value events: "%topic%": "string_sensor.value": json_payload: true expr: "payload.data.weekdays.enable" doorbell-weekdays-disable: name: 'Ovikello pois päältä (arkisin)' topic: 'doorbell/settings' capabilities: - string_sensor primary_attribute: string_sensor.value events: "%topic%": "string_sensor.value": json_payload: true expr: "payload.data.weekdays.disable"I have verified that the entities are populated correctly and the values are working in local expressions.
The entity (only the range start for brevity):
Screenshot from 2023-03-22 09-27-54.pngThe rule:
Screenshot from 2023-03-22 09-28-28.pngAnd the local expression within the rule:
weekdays_enabled = (time() >= time(getEntity( "mqtt>doorbell-weekdays-enable" ).attributes.string_sensor.value )) && (time() <= time(getEntity( "mqtt>doorbell-weekdays-disable" ).attributes.string_sensor.value ))The problem
Local expression doesn't seem to evaluate to true even if the current time gets within the range. But if the related entities are updated, then the expression is evaluated and the rule is triggered.As seen from the screenshots, the current time is 09:28:12 and the start time in corresponding entity is set to 09:28. But still the rule is not triggered. However, if I update the entity e.g. to 09:27, the local expression will get evaluated and the rule is triggered.
My understanding is that the local expression is working correctly but since it's not evaluated, it will not trigger the rule.
Is this a bug or have I misunderstood something? If so, how should I implement this kind of functionality?
br,
mgvraReactor (Multi-hub) latest-23078-d592d400 + MQTTController [0.1.23010]
-
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.
-
I have a use case where I need to have a boolean variable that will be set to true/false by reactions.
I see that i can define a local variable by giving it a name and leaving the definition empty. This leaves it at state "null" until a reaction tells it that its a boolean.
Is there a way to tell it that it should start out as "false" (i.e when reactor has restarted), and not null?
Am i going about this the wrong way?
-- The use case is that I have a sensor on my fireplace, and the following logic is for notifying when its time to get up en refill with firewood.. I also want to reset the MaxInInterval to CurrentTemp when notification is sent..
1fd2951f-cb6b-4a2f-b957-1e0698171f4d-image.png dd99634e-f0ad-4878-bb87-0284c2df5535-image.png
Edit: better screenhots. Reactor version 23010-7dd2c9e9
-
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. -
Hi guys,
I want to import my reactor sensors in the MSR addon for Home Assistant, but I can't find the app.js file anywhere. So now I don't know where to put the backup file.
I have not tried to put it in the main directory (config/reactor) yet. Wanted to know if I'm the only one with the problem.
Reactor addon: v0.0.8
MSR: 23063-c464b685
Home Assistant 2023.3.3
Supervisor 2023.03.1
Operating System 9.5
Frontend 20230202.0 - latestI started with v0.0.7, have just updated everything. Still no file.
-
I'm a little bit confused how to configure extended capabilities for the entities in the MQTTController.
mqtt_cababilities.yaml states that: "...You can add your own capabilities by adding a "capabilities" section to your own local_mqtt_capabilities.yaml file in your config directory."
So I did this in my local_mqtt_capabilities.yaml in the config directory:
version: 22353 revision: 1 format: 1 capabilities: x_my_config: attributes: partyMode: type: bool actions: some_action: topic: '%topic/write' payload: "some value"And in my reactor.yaml I have following configuration entry:
my-config: name: 'My custom configuration' topic: 'my-config' query: "%topic%/read" init: "%topic%/read" capabilities: - x_my_config primary_attribute: x_my_config.partyMode events: "%topic%/status": "x_my_config.partyMode": json_payload: true expr: "payload.partyMode"This sort of works but not quite. The partyMode attribute gets updated when messages arrive for that specific topic, so that's fine. But I don't see x_my_config capability in the Capabilities list in the UI and also the some_action is missing.
Screenshot from 2023-03-09 19-42-49.png
Addition to that the primary value is not set and I'm getting the following error:
Screenshot from 2023-03-09 19-30-42.pngHave I completely misunderstood the idea behind the capability extension and the attributes? If so, could someone point me to the right direction with few explanatory example configs.
What I'm trying to achieve is a set of configuration options that could be updated thru the MQTT, and also provide some actions that the rules could invoke.
Reactor (Multi-hub) latest-23063-c464b685 + MQTTController [0.1.23010]
br,
mgvra -
-
Installing MQTTController on Home Assistant Core when Reactor is installed as an Add-In (VirtualBox)
Running Home Assistant Core under VirtualBox (on Windows) and Reactor is installed and working fine as an add-in. What I can't figure out is how to install MQTTController in this situation. I can upload the files and unzip them, but I can't run install.sh in a terminal window because npm is not a part of the Core installation.
It does appear that somewhere in the stack there is a version of docker there between VirtualBox and HA, (I see some references go by in the VirtualBox startup log) but it appears minimal and will not execute the install via the docker technique in your documentation from the VB console.
Is there a way to do this?
Thanks.
-
I've done a bit of repackaging of MSR to make it work as an add-on under Home Assistant mostly for my own purposes but hopefully it makes it a bit easier to install and get going.
GitHub - mrw298/hassio-reactor-addon GitHub - mrw298/hassio-reactor-addon
Contribute to mrw298/hassio-reactor-addon development by creating an account on GitHub.
-
@toggledbits somewhere I thought I read that MSR goes thru the items in set reaction and reset reaction in stack order, ie from top to bottom/first to last.
Am I mistaken?
-
Reactor 23063 running on Windows Bare Metal.
Home assistant 2023.3.1
ESPHome 2023.2.4I've been trying a few ways using some results from search to call a Hass service as a reaction in a Reactor rule.
Specifically, when the PIR in the room senses motion, wake the NsPanel screen.
My Reactions otherwise so far are basic If this then that so I'm way behind what others are doing.
What I want to call as a Reaction:
Capture1.PNGWhat I've tried (a few variations on):
Capture2.PNGWhat happens:
[latest-23063]2023-03-07T07:45:21.688Z <wsapi:ERR> wsapi: error thrown handling client message [Object]{ "command": "perform", "entity": "WOKHASS1>system", "action": "x_hass_system.call_service", "parameters": { "service": "ESPHome: nspensuite_send_command_printf", "data": "page home" }, "qid": 75 } [latest-23063]2023-03-07T07:45:21.688Z <wsapi:CRIT> TypeError: Cannot read properties of null (reading '1') [-] TypeError: Cannot read properties of null (reading '1') at HassController.performOnEntity (C:\reactor\reactor\server\lib\HassController.js:584:108) at System.perform (C:\reactor\reactor\server\lib\Entity.js:707:56) at WSAPI.clientMessage (C:\reactor\reactor\server\wsapi\wsapi.js:499:48) at WebSocket.<anonymous> (C:\reactor\reactor\server\wsapi\wsapi.js:290:158) at WebSocket.emit (node:events:520:28) at WebSocket.emit (node:domain:475:12) at Receiver.receiverOnMessage (C:\reactor\reactor\node_modules\ws\lib\websocket.js:1059:20) at Receiver.emit (node:events:520:28) at Receiver.emit (node:domain:475:12) at Receiver.dataMessage (C:\reactor\reactor\node_modules\ws\lib\receiver.js:517:14)If someone can convert the 'call service' to a 'reaction' for me, or share their own similar thing I think that's what I need to achieve this goal.
I suspect if I'm even close to being on the right track, my problems are probably formatting like curly braces etc and lack thereof.
Thanks in advance.
-
@toggledbits was looking thru rule sets and updating which (new) lights I wanted REMII to impact and saw that this...
4711b0df-5e98-4992-bb25-d0e53203f0e8-image.png
...is showing as (missing) in the rule Deactivatedand looking in the dropdown of Variables it appears I cannot select that local expression (only Global) as I did when originally building this out back in 2021.
27f7025c-057e-441a-88ea-dc4bdf39614d-image.png
In looking at the rule Active Period I'm seeing:
487074ef-3bfa-4a84-b03d-ed6d920c118c-image.png which appears to be pointing to setting a variable in a rule?It's admittedly been a couple years since this was built and it's def not fresh in my memory.
-
New installation of Reactor version 23063-c464b685 on a Raspberry PI4 with Portainer/Docker.
Report :
No drop-down list on Entity Attribute in "Creation Rule Sets" interface
I can however visualize the entities.
I have configured HomeAssistant and all entities are coming up fine.
I have an unsupported Hass version 2023.3.0b5.
I'm new to Docker and can someone guide me to a solution?
Christian FABREAlert:
[latest-23063]2023-03-05T09:51:49.575Z <app:null> Process ID 1 user/group 0/0; docker; platform linux/arm64 #1595 SMP PREEMPT Wed Oct 26 11:07:24 BST 2022; locale (undefined) [latest-23063]2023-03-05T09:51:49.576Z <app:null> Basedir /opt/reactor; data in /var/reactor/storage [latest-23063]2023-03-05T09:51:49.577Z <app:null> NODE_PATH=/opt/reactor:/opt/reactor/node_modules [latest-23063]2023-03-05T09:51:49.584Z <app:INFO> Configured locale (undefined); selected locale(s) en-US.UTF-8 [latest-23063]2023-03-05T09:51:49.708Z <app:INFO> Loaded locale en-US for en-US [latest-23063]2023-03-05T09:51:49.725Z <Structure:null> Module Structure v22323 [latest-23063]2023-03-05T09:51:49.729Z <Capabilities:null> Module Capabilities v22356 [latest-23063]2023-03-05T09:51:49.806Z <Capabilities:NOTICE> System capabilities loaded from core distribution, data version 23058 revision 1 [latest-23063]2023-03-05T09:51:49.849Z <Plugin:null> Module Plugin v22300 [latest-23063]2023-03-05T09:51:49.869Z <TimerBroker:null> Module TimerBroker v22283 [latest-23063]2023-03-05T09:51:49.878Z <Entity:null> Module Entity v22353 [latest-23063]2023-03-05T09:51:49.889Z <Controller:null> Module Controller v23044 [latest-23063]2023-03-05T09:51:49.926Z <default:null> Module Ruleset v22293 [latest-23063]2023-03-05T09:51:49.928Z <default:null> Module Rulesets v22146 [latest-23063]2023-03-05T09:51:49.943Z <GlobalExpression:null> Module GlobalExpression v22146 [latest-23063]2023-03-05T09:51:49.977Z <Predicate:null> Module Predicate v22345 [latest-23063]2023-03-05T09:51:49.987Z <AlertManager:null> Module AlertManager v22283 [latest-23063]2023-03-05T09:51:49.995Z <Rule:null> Module Rule v22345 [latest-23063]2023-03-05T09:51:50.004Z <GlobalReaction:null> Module GlobalReaction v22324 [latest-23063]2023-03-05T09:51:50.008Z <Engine:null> Module Engine v23001 [latest-23063]2023-03-05T09:51:50.019Z <httpapi:null> Module httpapi v23058 [latest-23063]2023-03-05T09:51:50.078Z <wsapi:null> Module wsapi v23053 [latest-23063]2023-03-05T09:51:50.080Z <app:NOTICE> Starting Structure... [latest-23063]2023-03-05T09:51:50.100Z <Structure:NOTICE> Structure#1 plugin ID influx disabled; skipping [latest-23063]2023-03-05T09:51:50.106Z <Structure:INFO> Structure#1 loading controller interface hass (HassController) [latest-23063]2023-03-05T09:51:50.210Z <HassController:null> Module HassController v23060 [latest-23063]2023-03-05T09:51:50.639Z <Structure:INFO> Structure#1 loading controller interface groups (DynamicGroupController) [latest-23063]2023-03-05T09:51:50.649Z <DynamicGroupController:null> Module DynamicGroupController v22313 [latest-23063]2023-03-05T09:51:50.659Z <Structure:INFO> Structure#1 loading controller interface reactor_system (SystemController) [latest-23063]2023-03-05T09:51:50.672Z <SystemController:null> Module SystemController v22306 [latest-23063]2023-03-05T09:51:50.680Z <Structure:INFO> Starting controller HassController#hass [latest-23063]2023-03-05T09:51:50.682Z <HassController:NOTICE> HassController#hass starting... [latest-23063]2023-03-05T09:51:50.691Z <Controller:INFO> HassController#hass loaded hass capabilities ver 22312 rev 2 format 1 [latest-23063]2023-03-05T09:51:50.715Z <Controller:INFO> HassController#hass loaded implementation data ver 23058 rev 1 format 1 [latest-23063]2023-03-05T09:51:50.715Z <Structure:INFO> Starting controller DynamicGroupController#groups [latest-23063]2023-03-05T09:51:50.728Z <Controller:NOTICE> Controller DynamicGroupController#groups is now online. [latest-23063]2023-03-05T09:51:50.728Z <Structure:INFO> Starting controller SystemController#reactor_system [latest-23063]2023-03-05T09:51:50.733Z <Controller:NOTICE> Controller SystemController#reactor_system is now online. [latest-23063]2023-03-05T09:51:50.877Z <HassController:INFO> HassController#hass device mapping data loaded; checking... [latest-23063]2023-03-05T09:51:50.881Z <HassController:WARN> HassController: implementation of capability input_select.selector does not provide attribute values [latest-23063]2023-03-05T09:51:50.884Z <HassController:NOTICE> HassController#hass connecting to ws://192.168.1.31:8123/api/websocket [latest-23063]2023-03-05T09:51:50.894Z <app:NOTICE> Starting HTTP server and API... [latest-23063]2023-03-05T09:51:50.901Z <httpapi:NOTICE> httpapi: starting HTTP service on port "8111" [latest-23063]2023-03-05T09:51:50.909Z <app:NOTICE> Starting Reaction Engine... [latest-23063]2023-03-05T09:51:50.910Z <Engine:INFO> Reaction Engine starting [latest-23063]2023-03-05T09:51:50.911Z <Engine:INFO> Checking rule sets... [latest-23063]2023-03-05T09:51:50.916Z <Engine:INFO> Checking rules... [latest-23063]2023-03-05T09:51:50.923Z <Engine:INFO> Data check complete; no corrections. [latest-23063]2023-03-05T09:51:50.938Z <Rule:NOTICE> rule-leu8xfe4 (rule-leu8xfe4 in First Rule Set) starting [latest-23063]2023-03-05T09:51:50.939Z <Engine:NOTICE> Reaction Engine running! [latest-23063]2023-03-05T09:51:50.939Z <Rule:NOTICE> rule-leu8xfe4 (rule-leu8xfe4 in First Rule Set) can't start -- rule is disabled [latest-23063]2023-03-05T09:51:50.952Z <httpapi:NOTICE> httpapi: listening [latest-23063]2023-03-05T09:51:50.981Z <app:NOTICE> Starting WSAPI... [latest-23063]2023-03-05T09:51:50.983Z <wsapi:NOTICE> wsapi: starting version 23053 [latest-23063]2023-03-05T09:51:51.080Z <Engine:INFO> [Engine]Engine#1 master timer tick, local time "3/5/2023 10:51:51 AM" (TZ offset 60 mins from UTC) [latest-23063]2023-03-05T09:51:51.119Z <HassController:NOTICE> HassController#hass connected, starting protocol [latest-23063]2023-03-05T09:51:51.127Z <httpapi:INFO> httpapi: API request from ::ffff:192.168.1.42: GET /api/v1/systime [latest-23063]2023-03-05T09:51:51.145Z <HassController:INFO> HassController#hass successful authentication with ws://192.168.1.31:8123; fetching initial data... [latest-23063]2023-03-05T09:51:51.155Z <HassController:INFO> HassController#hass Hass reports version "2023.3.0b5" location Maison timezone Europe/Paris state RUNNING safe_mode false [latest-23063]2023-03-05T09:51:51.245Z <HassController:NOTICE> HassController#hass no signature match for update.home_assistant_supervisor_update [latest-23063]2023-03-05T09:51:51.248Z <HassController:NOTICE> HassController#hass no signature match for update.home_assistant_core_update [latest-23063]2023-03-05T09:51:51.249Z <HassController:NOTICE> HassController#hass no signature match for update.terminal_ssh_update [latest-23063]2023-03-05T09:51:51.250Z <HassController:NOTICE> HassController#hass no signature match for update.file_editor_update [latest-23063]2023-03-05T09:51:51.251Z <HassController:NOTICE> HassController#hass no signature match for update.samba_backup_update [latest-23063]2023-03-05T09:51:51.252Z <HassController:NOTICE> HassController#hass no signature match for update.home_assistant_operating_system_update [latest-23063]2023-03-05T09:51:51.253Z <HassController:NOTICE> HassController#hass no signature match for sun.sun [latest-23063]2023-03-05T09:51:51.285Z <HassController:NOTICE> HassController#hass no signature match for calendar.calendrier [latest-23063]2023-03-05T09:51:51.413Z <HassController:NOTICE> HassController#hass no signature match for siren.piscine_siren [latest-23063]2023-03-05T09:51:51.419Z <HassController:NOTICE> HassController#hass no signature match for camera.portillon [latest-23063]2023-03-05T09:51:51.607Z <Controller:INFO> HassController#hass 0 dead entities older than 86400000s purged [latest-23063]2023-03-05T09:51:51.633Z <Controller:NOTICE> Controller HassController#hass is now online. [latest-23063]2023-03-05T09:51:51.634Z <DynamicGroupController:INFO> All controllers ready, setting up dynamic groups [latest-23063]2023-03-05T09:51:51.726Z <wsapi:INFO> wsapi: connection from ::ffff:192.168.1.42 [latest-23063]2023-03-05T09:51:55.510Z <wsapi:INFO> client "192.168.1.42#1" closed, code=1001, reason= [latest-23063]2023-03-05T09:51:55.815Z <httpapi:INFO> httpapi: API request from ::ffff:192.168.1.42: GET /api/v1/lang [latest-23063]2023-03-05T09:51:55.843Z <wsapi:INFO> wsapi: connection from ::ffff:192.168.1.42 [latest-23063]2023-03-05T09:51:56.849Z <httpapi:INFO> httpapi: API request from ::ffff:192.168.1.42: GET /api/v1/systime [latest-23063]2023-03-05T09:52:07.392Z <httpapi:INFO> httpapi: API request from ::ffff:192.168.1.42: GET /api/v1/systime---
reactor_20230305_01.png Rule :
reactor_20230305_02.png Entities:
reactor_20230305_03.png log Reactor :Log Portainer:
NODE_PATH /opt/reactor:/opt/reactor/node_modules [latest-23063]2023-03-05T08:55:17.734Z <app:null> Reactor build latest-23063-c464b685 starting on v16.15.1 [latest-23063]2023-03-05T08:55:17.736Z <app:null> Process ID 1 user/group 0/0; docker; platform linux/arm64 #1595 SMP PREEMPT Wed Oct 26 11:07:24 BST 2022; locale (undefined) [latest-23063]2023-03-05T08:55:17.737Z <app:null> Basedir /opt/reactor; data in /var/reactor/storage [latest-23063]2023-03-05T08:55:17.738Z <app:null> NODE_PATH=/opt/reactor:/opt/reactor/node_modules [latest-23063]2023-03-05T08:55:17.875Z <Structure:null> Module Structure v22323 [latest-23063]2023-03-05T08:55:17.879Z <Capabilities:null> Module Capabilities v22356 [latest-23063]2023-03-05T08:55:18.004Z <Plugin:null> Module Plugin v22300 [latest-23063]2023-03-05T08:55:18.023Z <TimerBroker:null> Module TimerBroker v22283 [latest-23063]2023-03-05T08:55:18.032Z <Entity:null> Module Entity v22353 [latest-23063]2023-03-05T08:55:18.042Z <Controller:null> Module Controller v23044 [latest-23063]2023-03-05T08:55:18.079Z <default:null> Module Ruleset v22293 [latest-23063]2023-03-05T08:55:18.080Z <default:null> Module Rulesets v22146 [latest-23063]2023-03-05T08:55:18.096Z <GlobalExpression:null> Module GlobalExpression v22146 [latest-23063]2023-03-05T08:55:18.129Z <Predicate:null> Module Predicate v22345 [latest-23063]2023-03-05T08:55:18.139Z <AlertManager:null> Module AlertManager v22283 [latest-23063]2023-03-05T08:55:18.146Z <Rule:null> Module Rule v22345 [latest-23063]2023-03-05T08:55:18.156Z <GlobalReaction:null> Module GlobalReaction v22324 [latest-23063]2023-03-05T08:55:18.159Z <Engine:null> Module Engine v23001 [latest-23063]2023-03-05T08:55:18.171Z <httpapi:null> Module httpapi v23058 [latest-23063]2023-03-05T08:55:18.232Z <wsapi:null> Module wsapi v23053 [latest-23063]2023-03-05T08:55:18.358Z <HassController:null> Module HassController v23060 [latest-23063]2023-03-05T08:55:18.780Z <DynamicGroupController:null> Module DynamicGroupController v22313 [latest-23063]2023-03-05T08:55:18.803Z <SystemController:null> Module SystemController v22306``` -
Sorry for another dumb question. Migrating from Vera Alexa to HASS Vera TTS. MSR is on bare metal, Debian Bullseye version 23049
I can get TTS from MSR and basic TTS from MSR which is great!
Trying to get some of the variables I used to use though is stumping me.
In the original MSR, I'd use:
It is now ${{OutingDays}} days until we go to ${{OutingName}}. , Sleep well!for example, and that worked fine (I've not bothered to list the variables as I know the worked)
If I use
{ "message":"It is now${{OutingDays}} days until we go to ${{OutingName}}. , Sleep well!", "data":{"type":"announce", "method":"speak"}, "target":["media_player.everywhere"] }In the data field of the hass service system call it doesn't evaluate the variables (Not really surprised)
So might someone take mercy on me and give me a clue?
TIA
C
-
I'm back from a vacation and it was the first winter one with MSR.
I have a special vacation mode that's auto-setting after the house is in away mode for at least 18 hours - and that's mostly OK. In this mode, lights are turned on/off automatically, some things are off to preverse powers, etc. Thermostats are automatically set at 17C unless there's solar power. That's mostly OK, except when you have to deal with winters and clouds on the day back home.
Long story short: back from vacation, we found the house at 17C - wife wasn't impressed.
Back in the luup days I had a special override, that I forgot to port to MSR, that was basically like this in MSR (coded on the fly):
32298706-86f7-451e-9700-2baf5d5a23b6-image.png
So, I could tell my system when I'm on vacation and have a last day flag to re-set the house to normal behavior before I'm back. It was just two strings variable in a virtual binary sensor.
I don't want to code this in global expressions, so I'm wondering if it's possible to accomplish this with a Virtual Device, but I'm failing to visualize the correct answer and I'm here for inspiration for what others are doing to tackle this.
I don't want to create 4 separate devices (start date, end date, status, last day) in order to keep it easy and I want to be able to change the start/end date from the UI, to simplify things. Any hint is appreciated 🙂
-
I updated to the latest version of Reactor this morning. I run reactor (successfully) on a Raspberry PI 4 4GB with SSD 64GB. I also run Home Assistant in Docker. After updating I noticed a disk space critical error warning!
9f4e1ea1-977a-481b-9806-d3d43a4eff04-image.png
I have tried purging the docker install (docker image prune -a)
I have rebooted the Raspberry PI also, and the error messages keep coming.
I have the following disk space:
58742ed7-e10d-4572-b380-0abda64f90b4-image.png
How do I free up space?
Any help would be appreciated.
-
Good morning,
I'm trying to recreate some notifications I received on my old Vera system based upon House mode. I migrated from Vera to Home Assistant about 6 months ago, and all the automation I have set up are working great, however, I'm noticing that there were things that were once simple in Vera that are more involved in Home Assistant.In House Modes in Vera, there was a screen where I could select all the devices I wanted to be armed in various house modes. I recreated those house modes in Home Assistant very early on, but what I'm not getting now is notifications for various sensors. For instance, if the system is in Away mode, and interior motion is detected, I would get a Vera push notification on my phone. I've been setting these up one by one using haas>system --> x_haas_system.call_service, then setting the notify device and the message, one by one, but it's repetitious and tedious. For a few devices, like motion sensors on my ground floor, it's not a big deal, but now I'm looking at all the windows in my home, which have sensors on them.
So, enough of the background thesis. Simply put, is there a way to have a group of devices ( like 16 different window sensors ) as an entity, and when they are tripped, send out a notification and state which of those sensors was tripped, all in a single rule?
If I have to copy and edit 16 different rules, I'll do that, but I'd prefer a more elegant way where there is one rule to send out the notifications that tells me what was opened.
Thanks for all your advice/help in advance.
I'm running MSR latest-23049-1fd87c91 and Home Assistant 2023.2.5, Supervisor 2023.01.1, Operating System 9.5,
BTW, @toggledbits, I noticed on the About screen for MSR it still shows copyright from 2022. I know you've released versions this year.
Reactor (Multi-hub) latest-23049-1fd87c91 © 2020-2022 Kedron Holdings LLC, All Rights Reserved; Patrick Rigney (toggledbits), Principal Engineer.
-
I'd like the "None deferred" Reset Reaction group to have multiple Conditions. Is this not possible?
Running latest version of MSR, 23049-1fd87c91
-
I have upgraded my Hubitat Hub Information Driver to v3 and after the latest MSR update latest-23028 MSR is working ok. The problem is when MSR probes the device it appears to affect the polling in the new Hub Information Device and its data does not update the data fields in Hubitat. If I remove the Hub Information Device from Maker API so MSR can't see it, The Hub information driver updates the data as expected in Hubitat. I added the device back into Maker API the same problem returns in Hubitat. I have tried to have MSR probe a different device by adding a different probe device and probe action in the reactor.yaml per the documentation but it appears then it still uses the Hub Information Device as the probe device instead of the one specified in the reactor.yaml. See Logs below. Is this the intended behavior to always use the Hub Information Driver if found and not use the device in the reactor.yaml file? Any recommendations on how to get MSR and the v3 of the driver to work correctly or can you see what I am doing wrong?
[latest-23028]2023-02-11T23:27:50.471Z <Controller:NOTICE> Controller HassController#hass is now online. [latest-23028]2023-02-11T23:27:50.471Z <Rule:INFO> Internet Check (rule-l44qss4f in Home) starting evaluation; because entity-changed System#reactor_system>system [latest-23028]2023-02-11T23:27:50.471Z <Rule:INFO> MSR Update Version Available (rule-labweim2 in Notify) starting evaluation; because entity-changed System#reactor_system>system [latest-23028]2023-02-11T23:27:50.472Z <Rule:INFO> Internet Check (rule-l44qss4f in Home) trigger evaluation result is false (previously false) [latest-23028]2023-02-11T23:27:50.472Z <Rule:INFO> Internet Check (rule-l44qss4f in Home) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23028]2023-02-11T23:27:50.472Z <Rule:INFO> MSR Update Version Available (rule-labweim2 in Notify) trigger evaluation result is false (previously false) [latest-23028]2023-02-11T23:27:50.472Z <Rule:INFO> MSR Update Version Available (rule-labweim2 in Notify) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23028]2023-02-11T23:27:50.472Z <Rule:INFO> Internet Check (rule-l44qss4f in Home) evaluation complete [latest-23028]2023-02-11T23:27:50.472Z <Rule:INFO> MSR Update Version Available (rule-labweim2 in Notify) evaluation complete [latest-23028]2023-02-11T23:27:50.673Z <HubitatController:INFO> HubitatController#hubitat Maker API responded with 91 devices [latest-23028]2023-02-11T23:27:50.766Z <HubitatController:INFO> HubitatController#hubitat found 'Hub Information Driver v3' device #"481"; using for probe/health checks. [latest-23028]2023-02-11T23:27:50.780Z <Controller:INFO> HubitatController#hubitat 0 dead entities older than 86400000s purged [latest-23028]2023-02-11T23:27:50.780Z <Rule:INFO> Roku Pause (rule-l3nlrzu9 in Home) starting evaluation; because entity-changed BinarySensor#hubitat>519 [latest-23028]2023-02-11T23:27:50.780Z <Rule:INFO> Stairs Light Low Light (rule-kulslls9 in Living Room) starting evaluation; because entity-changed BinarySensor#hubitat>519 [latest-23028]2023-02-11T23:27:50.780Z <Rule:INFO> Porch Motion Extended check (rule-l3kr45m8 in Porch) starting evaluation; because entity-changed BinarySensor#hubitat>519 [latest-23028]2023-02-11T23:27:50.780Z <Rule:INFO> Porch Light Manual On (rule-kmtxw155 in Porch) starting evaluation; because entity-changed BinarySensor#hubitat>519Snippet from the reactor.yaml:
# action_pace: 100 # warn_unresponsive: true # probe_device: hubitat>132 (not needed if Hub Information app installed) probe_device: hubitat>2 # probe_action: x_hubitat_Configuration.configure (not needed if Hub Information app installed) probe_action: x_hubitat_Configuration.configure # probe_action: x_hubitat_Refresh.refreshSynology Docker latest-23028
Hubitat v2.3.4.139
Hub Information Driver v3 -
Hey Patrick,
I’m trying to figure out how to run Home Assistant native push notifications from MSR. I have MSR set up to arm my home alarm every night, and when all users are out of the home. I’ve used it for years through Reactor, and it works fine, but when I ran Vera and Reactor for Vera, I would get notifications from Vera when Vera went into different home modes. (Home, Away, Night, etc). I’ve set up Home Modes in HA as well, so I’m looking to get the native push notifications from the HA companion app (i.e., System in Home Mode, System Armed Away, or Good Night, etc) Can I set up notifications from MSR to use those native push notifications, or does that need to be done from HA exclusively?I’m running latest-23028-ddc3fb14 and Home Assistant 2023.1.7.
Quality of Life Request: Update Button
-
Hey Patrick, along with my request to have a back and restore button it would be nice to also have a update button. Not an urgent request, just would make updates quicker and easier.
-
+1
Requested this way back when MSR was just getting on it's feet. -
+2
C
-
Massive upvote on all 3. Just like back in the old Vera days
(Unsure how easy update would be with the various ways of implementing MSR inside/outside docker etc) - unless a standard install method is specified, and one of the features of that is 'update' capability.
Docker-Compose please -
+1 (could at least make it to the backlog)
EDIT:
-1, after a very good (& long) explanation -
@Cadwizzard said:
Just like back in the old Vera days
How soon we forget the tales of bricked Veras. Who among us didn't have a little sense that they were playing Russian roulette every time we hit that button?
Unsure how easy update would be with the various ways of implementing MSR inside/outside docker etc
OK. He hits it on the head here. Let me explain some of the complications and my reservations around this.
The biggest pitfall is for docker users, IMO; that's the majority of you. The first thing you need to understand about docker is that the image and the container are separate objects in the system. The container is created from the image, but it's basically a copy, not linked in any meaningful way. The container can change, so that's good — I can download a release package and apply it to the container, restart, and the container will now be running the new release files. Unfortunately, that has no bearing on what happens to the image. Changing files in the container does nothing to the image. So let's take a scenario... @tunnus (Docker, Synology) downloads the image for Reactor 22274 and creates a container for it, so he's now running 22274. A little later, 22291 is released, so he hits the handy, flashy new "Upgrade" button and the container is upgraded in place. Perfect. Except, not... his image is still 22274. Stay with me now... In all likelihood, because of the "ease" of the automated upgrade, tunnus never needs to download a new image again (so he thinks), so he never bothers (it's a pain anyway on Synology, I'll agree). So build 22293 comes along, and then 22302, and then 22305, and then 22308, and he upgrades to all of them using the automated process, but the image is still sitting there on his NAS at 22274. The problem strikes if, for any reason (DSM major upgrade?), he decides to reset and rebuild the container, or delete it. He will get.... 22274. Because that's the image he has.
Can I make docker download the newer image as part of the upgrade process? No. Reactor is running inside the container, and the container, by definition, contains Reactor and keeps it from doing anything external to the container (except the limited data volume that's specifically created for the single purpose). So the running Reactor instance has no ability whatsoever to cause docker/DSM to pull later images. Pulling a new image and rebuilding the container is the real "right" way to upgrade, but it's not possible to automate it from within the container itself (and it's darned clunky in Synology's UI, unfortunately).
It's not hard to imagine that this problem would not bite him for months or years. But when it bites, it has the potential to bite hard. Imagine along Reactor's evolutionary path from 22274 to a future 24107 (released in 2024, all automated updates between, no image refreshes), there are changes that needed to be made to the data structures of rules, reactions, stored states, etc. (not at all hard to imagine, it actually happens all the time). It is easy, although sometimes a bit cumbersome, for me to provide forward compatibility: to make sure that newer versions of code read the old data and upgrade the structures, and the mechanisms for those upgrades remain in the code for some time. But there is no way under the sun for 22274, now running once again unexpectedly, to know what to do with data from the future 24107 build, and there's a chance it could do something really bad to it. Now tunnus has an old version running in his container with corrupt data. I hope he has a backup.
I'll take the opportunity to say that this is a cautionary tale for all of you who stay on older builds. I keep the code that reads and upgrades the data, when needed, for a while, so that people who skip a few upgrades can safely do so and "jump in time" when they are ready to apply a new build, but I don't and won't keep that code forever; it becomes a maintenance nightmare and it's beyond my available time and sensibilities to test every possible combination of upgrades between versions. If you're running on a Reactor that's more than a year out (21307 or earlier), you're playing with fire as far as I'm concerned, and you should not expect a smooth upgrade when you get around to it. You may need to upgrade to an interim build still available, which works for bare-metal, but isn't an option for docker users. And before the "I can't have something like that in my home" people start in here, please know that I'm sorry that the free software I offer you and for which I provide ready, quick, and free ongoing support (and upgrades) isn't perfectly to your liking. If you don't like the way it works, you have alternatives, and I fully support your freedom to choose them.
To continue with @Cadwizzard's point: this is equally or more egregious, unfortunately, for docker-compose users, because up to this point, the recommended way for stopping Reactor when using docker-compose is to run
docker-compose down
. This causes Reactor to stop, but also deletes the container. Any upgrades applied to the container are lost in that instant, because the container is discarded. When you later rundocker-compose up -d
, the container is re-created from the (old) image, and will be whatever version that image is. Maybe not a disaster, maybe it is. This could be addressed by retraining docker-compose users to usedocker-compose stop
rather thandocker-compose down
, but the distinction would need to be taught (and learned) as both are useful, and the infrequency of use of these commands would likely suffer from brain-drain over time (i.e. when to use which and what their side effects could be/will be lost on the user a few months from now). But it's such a subtle distinction that people will shoot themselves in the foot easily and regularly, I fear.Bare-metal is somewhat easier, because at least the process can be assured it's writing on the one and only (relevant) image, in the install directory, so that's a bit of relief. Unfortunately, a lot of people really don't understand Linux file permissions, their relations to users and groups, etc., and routinely goof up the permissions of files all over their system, including in the Reactor install directory. This isn't a problem for them after the first "fix," because thereafter they do the manual upgrades the same way, logged in as the same user (in some cases, even as root, which is a serious no-no), and so it works for them as that user in that case, good enough. But for an automated process running in an unprivileged environment, it can mean that some files aren't writable, and the upgrade only half-happens... the upgrade process crashes, some files are new and some are old, and the Reactor install is basically dead and broken. I can't fix the permissions from the running instance, because it's running as an unprivileged user (well, hopefully; woe unto those who run anything as root). The user then manually applies the upgrade to recover the system, which goes fine because of course he's running the privileged user with the right permissions. A bug/post for the upgrade process then gets reported, and I then spend hours or days going back and forth, digging through the user's 3,000+ files in a typical Reactor install, looking for the broken ones and teaching the user how to fix them. (Permissions and their potential brokenness is also an issue for doing automated backups/restores, since that was mentioned as well.)
Oh, and then there's Windows. I won't even start. I've already written a book (again).
With regard to the suggestion of a standard install method: (a) there is no "one size fits all" — what works for Ubuntu doesn't work for Synology DSM or QNAP, and certainly not for Windows; and (b) the install methods that are recommended are all carefully documented; experience shows that I can write out every detail I can think of, and what actually happens on the user's system is 100% of that or some amount less, or the user has some condition in their system/environment that I could not/did not anticipate that causes problems. My preferred method for most users is docker (and specifically, with docker-compose), because the container strategy removes some of these risks, but that's not always the easiest for their environment (e.g. Synology has docker but no -compose), and the accepted mechanisms for upgrading containers in the docker world in general are ironically exactly the subject of complaints by OP and others here, despite the relative ubiquity and ease of these mechanisms.
The point is, there is no panacaea here. You run these systems, not me. You do things I have no knowledge of, and sometimes those things bite back. The majority of my time supporting this product is troubleshooting your environments, not my code (I'm not saying I'm perfect — I make mistakes and bugs are a reality, but they're not the majority of support issues here in terms of time spent). Anything and everything I do in the system is looked at not just through the lens of whether it's convenient for the user, but very much through the lens of supportability. There are lots of features I get asked to do, and as you've seen (even recently), there are some that I refuse to consider simply because it would make the system less supportable, in my view. As features get added, not only is the usability of the system required to improve, but its quality is expected to improve as well (fewer bugs, better support, etc.) — those are my expectations, which I'm sure you share. If one doesn't consider supportability (and that means both in user support and code maintenance/reliability/scalability), one ends up with a lot of features that nobody asked for, don't work, and aren't usable (I can point you in the direction of such a product as an alternative if you're really interested in that).
There is a running, hidden upgrade process in the current build. I've been experimenting with this for a bit, getting to learn it, and discovering these issues. It's not that I won't consider making it available; I'm still studying it, and pondering the wisdom of it. Maybe sometimes I worry too much about things like this, I don't know. But when it goes wrong, there's nobody but you and me to fix it, and there's a lot of you and only one of me, so as I said in another recent conversation, handing out something that feels like a grenade with no pin sometimes doesn't seem like the best idea to me, and there are probably other things this system needs to do that I can better spend my time on. Maybe this is one of those things.
I'll leave this one up to you guys. If you can tolerate these side effects, I'll release the feature. But know that if you break your install because (docker) you somehow delete the container and recreate it from an old image, or (bare-metal) your install has broken permissions or other issues that the upgrade process can't work through, my answer will be short: that's a risk you accepted, do a clean reinstall from a current image, restore your config/state backup, and start over.
-
One more class of knowledge! Really the desire to have an automatic process would be very good, but your explanation makes clear the difficulty and risks, and I do not want to have it. As you said, the errors we generate are enough, I don't want to implement more risks. I think almost everyone here has a wife, so better to stay in the safety of the system working.
Well let's remove this from wishlist request, and could you share this list so we know everything that's coming in the future? Also put an item, display the status widget, in a window/iframe inside the HE dashboard
-
Hey I'd love a button. But I'm bare metal and in honesty it takes me 90 seconds to upgrade so why do I need one?
Given the choice of support and progress vs button I know which I'd chose.
C
-
@toggledbits this makes tons of sense why anyone should want an update button mainly Docker users.
In terms of bare metal users, say if a user messed with their files permissions enough that it would cause issues when updating Reactor, wouldn't they run into the same errors even if they manually updated or used the update button? I wouldn't mind an update button for bare metal users, since from your explanation seems like a possible issue with won't come up with the actually update process itself, it can come with something else (like file permissions etc). Meaning that they'd run into these errors even if they manually updated Reactor like we do now.
Not arguing though, its a fairly low level request from me. I can clearly see why an update button for Docker users could be a slow and silent death. As @CatmanV2 for bare metal the update process really only takes 90 seconds ahah.
-
@pabla said in Quality of Life Request: Update Button:
wouldn't they run into the same errors even if they manually updated or used the update button?
Not necessarily... some users... I've seen it... will run into permission problems and their answer, not understanding the problem or how to fix it, is to use
sudo tar xvf
to just lay tracks over everything. This would eliminate the permissions problem unpackaging the archive, but new files may become root-owned, which isn't right but the code doesn't care as long as its readable. If their umask allows world-readable files (and 022 is a common default that does exactly that), the Reactor runtime will never know permissions are broken, because every file it needs is readable without consideration of ownership. The un-tar'ing doesn't touchlogs
,config
, etc. so any permissions there aren't relevant and aren't changed. And because some of the files are now root-owned that shouldn't be, the permissions problem has been made worse and again, unless they are truly fixed the right way, thensudo
will continue to be the only way upgrades will succeed. It perpetuates and exacerbates.I really get how painful the docker upgrades are on Synology. I'm guessing QNAP is probably not much different, and I think several people have been bitten by Portainer oddities regardless of platform.
The process just needs more thought. I could, for example, from the next build onward, prevent the system from starting if the config and data are from a newer version. The problem there is that it needs to be detected early in startup, and if the system can't use the data, it has to exit hard, because it can't run without any data at all, and it can't touch what it has. There would be no UI feedback other than "DISCONNECTED" (i.e. the behavior when Reactor can't start). A "click-to-upgrade" to fix it wouldn't be an option because the UI would not be running, so a manual upgrade would be required at that point. And maybe that's OK? Maybe that's such an extreme/infrequent circumstance that it should be that way? A manual upgrade once in a blue moon may not be so bad... I don't know... looking for feedback... trying to figure it out...
-
I personally do not think the update process on Synology docker is that bad. A few more clicks than an easy button but not horrible. All my other docker containers are updated the same way. I like the docker image though. I am not familiar with the other platforms so I can’t comment on those update processes.
-
CatmanV2
-
I would upvote the
backup
andrestore
buttons but don't see a need for theupdate
button. I'm bare metal and it's literally a two-minute process. -
I too am happy with the current process. Super fast for me. I run everything under Synology/Docker. I no longer have issues upgrading containers such as Reactor, HA, etc. since I switched to Portainer several months ago. So not sure what those "Portainer" oddities are/were. Something I should keep an eye on? Or I have just been lucky?
-
@snowman said in Quality of Life Request: Update Button:
Something I should keep an eye on? Or I have just been lucky?
I doubt it, it's me who is unlucky with Portainer & MSR.....
-
Some input from a Windows user.
An update button would of course be a nice to have feature, but I also agree with several other here. A "normal" update, aka don't need new dependencies, just take a short moment to install.
Were I usually stumble is when an update of dependencies are needed. That have taken me hours of search-try--error-tryagain before getting that to work sometimes.My dream would be to have a "windows installer" for MSR, that checks dependencies, install a systemservice etc.
Over time I think that would be a safer/more stable way, with fewer user errors.With this said, I can understand really understand that @toggledbits need to handle this "his way" to be able to support differen't enviroments (and users
)
-
I don't know if this helps for other Docker users, but not long after I got started with Docker I found Portainer, and I've been running it alongside Reactor and my other containers on my Raspberry Pi 4. With Portainer, there may not be a one-step update button, but I find it makes updates much easier.
I just updated Reactor to the latest. All I had to do was go to the Portainer URL in my browser, then
- Click on the Reactor container in the Containers list
-
Click 'Recreate"
-
Toggle "Always pull new image" on the window that pops up
- Click "Recreate"
It isn't one click, but it can be done in a browser tab from any machine with network access to the Docker host. No VNC/SSH into the machine, no Docker commands to run from the command line.
Portainer also has links to view the container logs and to open a command window in the container, which I use all the time. You can also use the "duplicate/edit" button to change or add environment variables while updating, which is how I added the NODE_PATH a few updates back.
-
Thanks for the Portainer explanation, I'm certain I've had a spell cast on me. I'll try again once the Pi400 become available once more.
Lastly, I think the point has been lost, it's about QOL, not about how easy it is to do in another way.
From my perspective if it isn't easy to use by 98% of the public then it's too much trouble and they might look at it then discard it for another solution.
The comments so far are from users who are in the 2% and are happy to tinker. I'm happy for you.
If anyone wants to see how Consumer friendly software should be to set up, then have a look at Homeseer4. Update ...no problem with 1 click. -
@black-cat Isn't homeseer a walled garden like Hubitat, Ezlo, etc.? You buy their hub and live within their infrastructure.
That's not MSR. MSR works on various OS/hardware and communicates with multiple hubs.
Whilst I appreciate your POV, it's not apples>apples comparison you're making here.
-
@gwp1 said in Quality of Life Request: Update Button:
You buy their hub and live within their infrastructure.
Nup, you can use any old Laptop or RasPi. Runs on Windows or Lynx. i'd love to promote MSR to Homeseer users but it lacks the simplicity hence the backing of the request.
Realistically, I'm not going to see it happen which is a shame as Patrick has put a lot of time into development for the 2%. -
@sweetgenius I agree, Synology Docker container upgrade process is not too bad.
I frequently keep both MSR and Synology UI open on separate browser tabs and either do a quick upgrade using "reset" or a bit careful upgrade using "duplicate settings" and retaining old container as a backup/rollback option.
Originally I favored a simple update button for MSR, but after Patrick's explanations I realized it's not that simple after all.