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
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.
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.
@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.
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.
Hello all.. been a minute! I recently rebuilt my Z wave network and migrated to a new z wave stick. In order to prevent any downtime I kept my original z wave network up and ran a docker version of Z Wave JS UI with my new controller. This way I could add device by device without having any devices down.
I finally moved all the devices over to my new stick today. The final step was to migrate everything from my Docker instance of Z Wave JS UI to the HA add-on of Z Wave JS UI. However during this migration some of the names didn't populate correctly which I later managed to import back into Z Wave JS UI. The issue was in Reactor it is stuck on the default names and the entities are not updating. I removed the controller from Reactor, restarted, hard refreshed, and added the controller back however the new entity names have not updated. Also it seems like the old entities from my previous instance of Z Wave JS UI are lingering and not being marked as dead (I believe a certain amount of time needs to lapse before they're marked as dead in Reactor).
My goal is to basically purge all the entities for the 'ZWaveJS' controller in Reactor so it can pull all the updated entity names and only the entities that exist in Z Wave JS UI. I cannot find a quick way to do this, I know entities can be deleted one by one, but with over 100 entities this would take long
I am guessing that if I added the controller with a new name in in the Reactor config it would pull the updated entities and names but I think that would break my rules since the entity IDs would change (I made sure to name all the entities the exact same as they were previously to prevent this issue).
I'm slowly migrating all my stuff to MQTT under MSR, so I have a central place to integrate everything (and, in a not-so-distant future, to remove virtual devices from my Vera and leave it running zwave only).
Anyway, here's my reactor-mqtt-contrib package:
https://github.com/dbochicchio/reactor-mqtt-contrib
Simply download yaml files (everything or just the ones you need) and you're good to go.
I have mapped my most useful devices, but I'll add others soon. Feel free to ask for specific templates, since I've worked a lot in the last weeks to understand and operate them.
The templates are supporting both init and query, so you have always up-to-date devices at startup, and the ability to poll them. Online status is supported as well, so you can get disconnected devices with a simple expression.
Many-many thanks to @toggledbits for its dedication, support, and patience with me and my requests
I don't know if I'm the only one, but managing more than one Reactor installs, the need to have some sort of copy&paste for rules has grown on me.
While I understand the technical challenges, I'm wondering if a "god mode" where I could copy the raw JSON rule and paste it into another rule could be an advanced, flag only feature that could benefit power users.
I know I can copy the JSON file and proceed, but I must stop Reactor and when doing maintenance, it's more clicks to do.
Just an idea
I’ve added a couple of Shelly Wave i4 as scene controllers and I’m planning to add more, since I can just use standard buttons instead of battery-powered scene controllers, which also looks better aesthetically.
That said, I’m struggling to figure out how to write a simple rule that cycles between states every time I press a button.
Example: Light 1 ON → OFF, then Light 2 ON → OFF.
The part I can’t get right is handling the case where Light 1 or Light 2 might already be ON independently of the rule.
Maybe it’s just too much sun and relaxation clouding my brain, but any hint would be appreciated.
Use case:
When performing home maintenance, such as air conditioning, I want all rules involving air conditioning to be disabled.
To do this, to day, I have a virtual switch that I placed within all rules involving air conditioning, meaning that if I turn it off, none of them work.
Then another situation: the water pump system and garden irrigation, another switch.
In short, I had to create several virtual switches in Hubitat to disable rules in MSR.
Unfortunately, however, I was unable to cover all scenarios, so I wondered if it would be possible for MSR to support a virtual MSR switch, which, when configured in the reactor settings, would function as a general on/off switch for MSR.
If it is configured and turned off, the entire rules and actions in MSR stops working, except for the status change reading process, specifically for this switch, which, when turned on, would restart the MSR.
Would it be possible to do something like this? Any recommendations from the experts?
Synology Docker installation
-
Seems like everything is correct. The log timestamps are always UTC. The master timer tick log entry looks correct for about the time of your posting and the time zone you show set below.
-
I was not able to import entities from Ezlo Plus and I was thinking about a problem between time zone and access token.
Now I have also ezlo entities imported ok but only after putting both “offlineAnonymousAccess” and “offlineInsecureAccess” set to true with API call.In all this ways nothing:
config:username: "somebody" # put your username here betw quotes password: "????????" # and passwordthen config
set_anonymous_access: true <--- add this line, same indent as previousthen with
“offlineInsecureAccess” enabled:truethe log was:
2021-08-04T00:08:25.648Z <EzloController:null> EzloController#ezlo created, config { "source": "wss://10.0.4.119:17000/" } 2021-08-04T00:08:25.648Z <EzloController:null> EzloController#ezlo instance log level (null) (4) 2021-08-04T00:08:25.667Z <Controller:INFO> EzloController#ezlo device data loaded; checking structure 2021-08-04T00:08:25.669Z <Controller:INFO> EzloController#ezlo performing hub login without cloud authentication; hub.offline.insecure_access must be enabled! 2021-08-04T00:08:25.696Z <Controller:NOTICE> Controller SystemController#reactor_system is now online. 2021-08-04T00:08:25.743Z <Controller:INFO> EzloController#ezlo opening local hub connection to (undefined) at wss://10.0.4.119:17000/ 2021-08-04T00:08:25.743Z <Controller:NOTICE> EzloController#ezlo configured to ignore host ((undefined)) certificate 2021-08-04T00:08:25.744Z <Controller:NOTICE> EzloController#ezlo connecting via WS to wss://10.0.4.119:17000/ 2021-08-04T00:08:25.750Z <app:INFO> Structure running; pausing for controllers' initial ready 2021-08-04T00:08:25.856Z <Controller:INFO> EzloController#ezlo hub websocket connected; inventory hub... 2021-08-04T00:08:25.905Z <Controller:ERR> EzloController#ezlo stopping; hub's offline insecure access is disabled, and cloud auth info is not configured 2021-08-04T00:08:25.906Z <Controller:ERR> EzloController#ezlo failed to complete inventory: Error: hub offline anonymous access is disabled, and cloud auth info is not configured 2021-08-04T00:08:25.907Z <Controller:CRIT> Error: hub offline anonymous access is disabled, and cloud auth info is not configured Error: hub offline anonymous access is disabled, and cloud auth info is not configured at /opt/reactor/server/lib/EzloController.js:895:27 at processTicksAndRejections (internal/process/task_queues.js:95:5) 2021-08-04T00:08:25.915Z <Controller:NOTICE> EzloController#ezlo websocket closing, 1002After putting both “offlineAnonymousAccess” and “offlineInsecureAccess” set to true with API call, all entities are imported OK. The problem was hub.offline.insecure_access . This is now the log:
2021-08-04T01:01:18.564Z <EzloController:null> EzloController#ezlo created, config { "source": "wss://10.0.4.119:17000/" } 2021-08-04T01:01:18.564Z <EzloController:null> EzloController#ezlo instance log level (null) (4) 2021-08-04T01:01:18.593Z <Controller:INFO> EzloController#ezlo device data loaded; checking structure 2021-08-04T01:01:18.596Z <Controller:INFO> EzloController#ezlo performing hub login without cloud authentication; hub.offline.insecure_access must be enabled! 2021-08-04T01:01:18.626Z <Controller:NOTICE> Controller SystemController#reactor_system is now online. 2021-08-04T01:01:18.675Z <Controller:INFO> EzloController#ezlo opening local hub connection to (undefined) at wss://10.0.4.119:17000/ 2021-08-04T01:01:18.675Z <Controller:NOTICE> EzloController#ezlo configured to ignore host ((undefined)) certificate 2021-08-04T01:01:18.677Z <Controller:NOTICE> EzloController#ezlo connecting via WS to wss://10.0.4.119:17000/ 2021-08-04T01:01:18.682Z <app:INFO> Structure running; pausing for controllers' initial ready 2021-08-04T01:01:18.790Z <Controller:INFO> EzloController#ezlo hub websocket connected; inventory hub... 2021-08-04T01:01:18.896Z <Controller:INFO> EzloController#ezlo data load complete; 2 devices received, 7 entities registered; 12 items. 2021-08-04T01:01:18.897Z <Controller:INFO> EzloController#ezlo hub inventory complete/successful; 105ms 2021-08-04T01:01:18.897Z <Controller:NOTICE> Controller EzloController#ezlo is now online. 2021-08-04T01:01:19.152Z <VeraController:WARN> VeraController#vera ignoring geotag ({ "iduser": 1520131, "geotags": [ { "PK_User": 0, "id": 1, "accuracy": 0, "ishome": 1, "notify": 1, "radius": 100, "address": "Via , fi", "color": "006e45", "latitude": "437930", "longitude": "11210", "name": "testi, fi", "status": --null-- } ] }) for user 1520131, user not in user list 2021-08-04T01:01:20.388Z <OWMWeatherController:NOTICE> Controller OWMWeatherController#weather is now online. 2021-08-04T01:01:22.993Z <VeraController:NOTICE> Controller VeraController#vera is now online. -
OK. So first, you need to learn to post code correctly on this site so I can actually see what you're posting. Any code that you post here (including config and log snippets) should have ``` on a line by itself both before and after.
Please repost your controller config, from the
- id:line to the end of the section, just XXX out your username and password. It looks like your config isn't (and wasn't to start) correctly set up. -
thanks for your advice.
Now seems I'm able to import entities from EzloPlus and to access token.
I put the ezlo plus again with previous API set and did some test againmodel: "h2.1" offlineAnonymousAccess: false offlineInsecureAccess: false serial: "90000XXX"in config
controllers: - id: vera enabled: true implementation: VeraController name: My Vera Lite Hub config: source: 'http://10.0.4.44:3480' - id: ezlo enabled: true implementation: EzloController name: My Ezlo Hub config: source: "wss://10.0.4.119:17000" # change the IP address serial: "90000xxx" # put your hub's serial # here username: "xxx" # put your username here betw quotes password: "xxx" # and passwordin the log:
2021-08-05T18:00:23.085Z <app:null> Reactor "1.0.0-21200-16a604f" starting on v14.17.3 2021-08-05T18:00:23.086Z <app:INFO> Process ID 1; platform linux/x64 #41890 SMP Thu Jul 15 03:37:40 CST 2021 2021-08-05T18:00:23.086Z <app:INFO> Basedir /opt/reactor; data in /var/reactor/storage 2021-08-05T18:00:23.131Z <Plugin:null> Module Plugin v21173 2021-08-05T18:00:23.138Z <default:INFO> Module Entity v21177 2021-08-05T18:00:23.141Z <Controller:null> Module Controller v21191 2021-08-05T18:00:23.141Z <default:null> Module Structure v21196 2021-08-05T18:00:23.148Z <default:null> Module Ruleset v21096 2021-08-05T18:00:23.148Z <default:null> Module Rulesets v21096 2021-08-05T18:00:23.166Z <default:null> Module Rule v21168 2021-08-05T18:00:23.173Z <default:null> Module Engine v21197 2021-08-05T18:00:23.173Z <default:null> Module httpapi v21197 2021-08-05T18:00:23.175Z <default:null> Module httpproxy v21054 2021-08-05T18:00:23.187Z <default:null> Module wsapi v21196 2021-08-05T18:00:23.212Z <app:NOTICE> Starting Structure... 2021-08-05T18:00:23.216Z <Structure:NOTICE> Structure#1 plugin ID influx disabled; skipping 2021-08-05T18:00:23.217Z <Structure:INFO> Structure#1 starting controller interface vera (VeraController) 2021-08-05T18:00:23.221Z <Structure:INFO> Structure#1 starting controller interface ezlo (EzloController) 2021-08-05T18:00:23.222Z <Structure:INFO> Structure#1 starting controller interface weather (OWMWeatherController) 2021-08-05T18:00:23.223Z <Structure:INFO> Structure#1 starting controller interface reactor_system (SystemController) 2021-08-05T18:00:23.265Z <default:null> Module VeraController v21195 2021-08-05T18:00:23.269Z <default:null> Module EzloController v21199 2021-08-05T18:00:23.272Z <default:null> Module OWMWeatherController v21140 2021-08-05T18:00:23.273Z <default:null> Module SystemController v21102 2021-08-05T18:00:23.277Z <VeraController:NOTICE> VeraController#vera starting 2021-08-05T18:00:23.326Z <VeraController:INFO> VeraController#vera loaded mapping ver 21177 rev 1 format 1 notice 2021-08-05T18:00:23.339Z <EzloController:null> EzloController#ezlo created, config { "source": "wss://10.0.4.119:17000", "serial": "90000xxx", "username": "xxx", "password": "xxx" } 2021-08-05T18:00:23.339Z <EzloController:null> EzloController#ezlo instance log level (null) (4) 2021-08-05T18:00:23.360Z <Controller:INFO> EzloController#ezlo device data loaded; checking structure 2021-08-05T18:00:23.362Z <Controller:INFO> EzloController#ezlo performing cloud auth to get local access token 2021-08-05T18:00:23.458Z <Controller:NOTICE> Controller SystemController#reactor_system is now online. 2021-08-05T18:00:23.505Z <app:INFO> Structure running; pausing for controllers' initial ready 2021-08-05T18:00:23.945Z <VeraController:WARN> VeraController#vera ignoring geotag ({ "iduser": 1520131, "geotags": [ { "PK_User": 0, "id": 1, "accuracy": 0, "ishome": 1, "notify": 1, "radius": 100, "address": "Via xxx, xxx", "color": "006e45", "latitude": "43xxx", "longitude": "11xxx", "name": "xxx, xxx", "status": --null-- } ] }) for user 1520131, user not in user list 2021-08-05T18:00:25.770Z <Controller:INFO> EzloController#ezlo cloud auth phase complete (local access token acquired) 2021-08-05T18:00:25.770Z <Controller:INFO> EzloController#ezlo opening local hub connection to "90000464" at wss://10.0.4.119:17000 2021-08-05T18:00:25.771Z <Controller:NOTICE> EzloController#ezlo configured to ignore host ("90000464") certificate 2021-08-05T18:00:25.772Z <Controller:NOTICE> EzloController#ezlo connecting via WS to wss://10.0.4.119:17000 2021-08-05T18:00:25.886Z <Controller:NOTICE> EzloController#ezlo successful hub login; performing inventory 2021-08-05T18:00:25.969Z <Controller:INFO> EzloController#ezlo data load complete; 2 devices received, 7 entities registered; 12 items. 2021-08-05T18:00:25.970Z <Controller:INFO> EzloController#ezlo hub inventory complete/successful; 83ms 2021-08-05T18:00:25.972Z <Controller:NOTICE> Controller EzloController#ezlo is now online. 2021-08-05T18:00:27.923Z <VeraController:NOTICE> Controller VeraController#vera is now online. 2021-08-05T18:00:33.533Z <OWMWeatherController:NOTICE> Controller OWMWeatherController#weather is now online. 2021-08-05T18:00:33.534Z <app:NOTICE> Starting Reaction Engine... 2021-08-05T18:00:33.535Z <Engine:INFO> Reaction Engine starting 2021-08-05T18:00:33.535Z <Engine:INFO> Checking rule sets... 2021-08-05T18:00:33.537Z <Engine:INFO> Checking rules... 2021-08-05T18:00:33.537Z <Engine:INFO> Data check complete; no corrections. 2021-08-05T18:00:33.539Z <Engine:5:Engine.js:1081> _process_reaction_queue() entry 628 2021-08-05T18:00:33.540Z <Engine:NOTICE> Reaction Engine running! 2021-08-05T18:00:33.540Z <app:NOTICE> Starting HTTP server and API... 2021-08-05T18:00:33.545Z <app:NOTICE> Startup complete 2021-08-05T18:00:33.546Z <Engine:5:Engine.js:1144> _process_reaction_queue ending with 0 in queue; none delayed/ready; waiting 2021-08-05T18:00:33.548Z <httpapi:NOTICE> HTTP API v1 21197 base URL http://10.0.4.71:8111; listening 2021-08-05T18:00:33.568Z <app:NOTICE> HTTP server running; registering proxy endpoints. 2021-08-05T18:00:33.568Z <app:NOTICE> Starting WSAPI... 2021-08-05T18:00:33.569Z <wsapi:NOTICE> wsapi: starting version 21196 2021-08-05T18:00:33.639Z <Engine:INFO> Engine#1 master timer tick, local time "8/5/2021, 8:00:33 PM" (TZ offset 120 mins from UTC) 2021-08-05T18:00:35.984Z <wsapi:INFO> wsapi: connection from ::ffff:172.17.0.1 2021-08-05T18:00:36.874Z <wsapi:INFO> wsapi: connection from ::ffff:172.17.0.1 2021-08-05T18:08:33.852Z <wsapi:INFO> client "172.17.0.1#2" closed, code=1001, reason= 2021-08-05T18:08:34.228Z <wsapi:INFO> wsapi: connection from ::ffff:172.17.0.1 2021-08-05T18:35:24.207Z <wsapi:INFO> client "172.17.0.1#3" closed, code=1006, reason= 2021-08-05T18:35:24.208Z <wsapi:INFO> client "172.17.0.1#1" closed, code=1006, reason= 2021-08-05T18:49:28.209Z <wsapi:INFO> wsapi: connection from ::ffff:172.17.0.1 2021-08-05T18:49:38.215Z <wsapi:INFO> wsapi: connection from ::ffff:172.17.0.1 2021-08-05T19:00:05.004Z <Engine:INFO> Engine#1 master timer tick, local time "8/5/2021, 9:00:05 PM" (TZ offset 120 mins from UTC)and the dashboard is so fluid and immediate! I love it!
-
just to ask, Is there Importing ReactorSensors from Vera Reactor in synology docker method?
@noelab said in Synology Docker installation:
just to ask, Is there Importing ReactorSensors from Vera Reactor in synology docker method?
So far as I know, the answer is "Yes" - because that's a built-in feature of MSR, and not dependent on the platform on which it is installed.
Coincidentally, I never used the "Import" feature despite having dozens of rather involved Rules back on Reactor for Vera. My reasoning was, (a) I will likely build them better from scratch, (b) this is my chance to re-think a lot of my logic, and (c) with MSR being immensely more powerful, it was a good excuse to learn lexpjs and contribute (as I wound up doing far more than anticipated) to the bug/suggestion log along the way.
MSR 1.0.0 is a masterpiece. Hope you enjoy the transition.
-
@noelab said in Synology Docker installation:
just to ask, Is there Importing ReactorSensors from Vera Reactor in synology docker method?
So far as I know, the answer is "Yes" - because that's a built-in feature of MSR, and not dependent on the platform on which it is installed.
Coincidentally, I never used the "Import" feature despite having dozens of rather involved Rules back on Reactor for Vera. My reasoning was, (a) I will likely build them better from scratch, (b) this is my chance to re-think a lot of my logic, and (c) with MSR being immensely more powerful, it was a good excuse to learn lexpjs and contribute (as I wound up doing far more than anticipated) to the bug/suggestion log along the way.
MSR 1.0.0 is a masterpiece. Hope you enjoy the transition.
@librasun yes, of course I agree with you. In Vera I based my logic using a virtual dimmer (Switchboard Plugin) per room to interact with Alexa commands behind conditions/rules in a Reactorsensor per room and only some global reactor for the house. In this way it is possible to have until 100 voice commands per room associated to 100 preset rules per dimmer, controlling them in web gui, in mobile app or alexa. So at the moment trying to understand if there is a new approach in MSR to emulate virtual devices or to find another way.
-
thanks for your advice.
Now seems I'm able to import entities from EzloPlus and to access token.
I put the ezlo plus again with previous API set and did some test againmodel: "h2.1" offlineAnonymousAccess: false offlineInsecureAccess: false serial: "90000XXX"in config
controllers: - id: vera enabled: true implementation: VeraController name: My Vera Lite Hub config: source: 'http://10.0.4.44:3480' - id: ezlo enabled: true implementation: EzloController name: My Ezlo Hub config: source: "wss://10.0.4.119:17000" # change the IP address serial: "90000xxx" # put your hub's serial # here username: "xxx" # put your username here betw quotes password: "xxx" # and passwordin the log:
2021-08-05T18:00:23.085Z <app:null> Reactor "1.0.0-21200-16a604f" starting on v14.17.3 2021-08-05T18:00:23.086Z <app:INFO> Process ID 1; platform linux/x64 #41890 SMP Thu Jul 15 03:37:40 CST 2021 2021-08-05T18:00:23.086Z <app:INFO> Basedir /opt/reactor; data in /var/reactor/storage 2021-08-05T18:00:23.131Z <Plugin:null> Module Plugin v21173 2021-08-05T18:00:23.138Z <default:INFO> Module Entity v21177 2021-08-05T18:00:23.141Z <Controller:null> Module Controller v21191 2021-08-05T18:00:23.141Z <default:null> Module Structure v21196 2021-08-05T18:00:23.148Z <default:null> Module Ruleset v21096 2021-08-05T18:00:23.148Z <default:null> Module Rulesets v21096 2021-08-05T18:00:23.166Z <default:null> Module Rule v21168 2021-08-05T18:00:23.173Z <default:null> Module Engine v21197 2021-08-05T18:00:23.173Z <default:null> Module httpapi v21197 2021-08-05T18:00:23.175Z <default:null> Module httpproxy v21054 2021-08-05T18:00:23.187Z <default:null> Module wsapi v21196 2021-08-05T18:00:23.212Z <app:NOTICE> Starting Structure... 2021-08-05T18:00:23.216Z <Structure:NOTICE> Structure#1 plugin ID influx disabled; skipping 2021-08-05T18:00:23.217Z <Structure:INFO> Structure#1 starting controller interface vera (VeraController) 2021-08-05T18:00:23.221Z <Structure:INFO> Structure#1 starting controller interface ezlo (EzloController) 2021-08-05T18:00:23.222Z <Structure:INFO> Structure#1 starting controller interface weather (OWMWeatherController) 2021-08-05T18:00:23.223Z <Structure:INFO> Structure#1 starting controller interface reactor_system (SystemController) 2021-08-05T18:00:23.265Z <default:null> Module VeraController v21195 2021-08-05T18:00:23.269Z <default:null> Module EzloController v21199 2021-08-05T18:00:23.272Z <default:null> Module OWMWeatherController v21140 2021-08-05T18:00:23.273Z <default:null> Module SystemController v21102 2021-08-05T18:00:23.277Z <VeraController:NOTICE> VeraController#vera starting 2021-08-05T18:00:23.326Z <VeraController:INFO> VeraController#vera loaded mapping ver 21177 rev 1 format 1 notice 2021-08-05T18:00:23.339Z <EzloController:null> EzloController#ezlo created, config { "source": "wss://10.0.4.119:17000", "serial": "90000xxx", "username": "xxx", "password": "xxx" } 2021-08-05T18:00:23.339Z <EzloController:null> EzloController#ezlo instance log level (null) (4) 2021-08-05T18:00:23.360Z <Controller:INFO> EzloController#ezlo device data loaded; checking structure 2021-08-05T18:00:23.362Z <Controller:INFO> EzloController#ezlo performing cloud auth to get local access token 2021-08-05T18:00:23.458Z <Controller:NOTICE> Controller SystemController#reactor_system is now online. 2021-08-05T18:00:23.505Z <app:INFO> Structure running; pausing for controllers' initial ready 2021-08-05T18:00:23.945Z <VeraController:WARN> VeraController#vera ignoring geotag ({ "iduser": 1520131, "geotags": [ { "PK_User": 0, "id": 1, "accuracy": 0, "ishome": 1, "notify": 1, "radius": 100, "address": "Via xxx, xxx", "color": "006e45", "latitude": "43xxx", "longitude": "11xxx", "name": "xxx, xxx", "status": --null-- } ] }) for user 1520131, user not in user list 2021-08-05T18:00:25.770Z <Controller:INFO> EzloController#ezlo cloud auth phase complete (local access token acquired) 2021-08-05T18:00:25.770Z <Controller:INFO> EzloController#ezlo opening local hub connection to "90000464" at wss://10.0.4.119:17000 2021-08-05T18:00:25.771Z <Controller:NOTICE> EzloController#ezlo configured to ignore host ("90000464") certificate 2021-08-05T18:00:25.772Z <Controller:NOTICE> EzloController#ezlo connecting via WS to wss://10.0.4.119:17000 2021-08-05T18:00:25.886Z <Controller:NOTICE> EzloController#ezlo successful hub login; performing inventory 2021-08-05T18:00:25.969Z <Controller:INFO> EzloController#ezlo data load complete; 2 devices received, 7 entities registered; 12 items. 2021-08-05T18:00:25.970Z <Controller:INFO> EzloController#ezlo hub inventory complete/successful; 83ms 2021-08-05T18:00:25.972Z <Controller:NOTICE> Controller EzloController#ezlo is now online. 2021-08-05T18:00:27.923Z <VeraController:NOTICE> Controller VeraController#vera is now online. 2021-08-05T18:00:33.533Z <OWMWeatherController:NOTICE> Controller OWMWeatherController#weather is now online. 2021-08-05T18:00:33.534Z <app:NOTICE> Starting Reaction Engine... 2021-08-05T18:00:33.535Z <Engine:INFO> Reaction Engine starting 2021-08-05T18:00:33.535Z <Engine:INFO> Checking rule sets... 2021-08-05T18:00:33.537Z <Engine:INFO> Checking rules... 2021-08-05T18:00:33.537Z <Engine:INFO> Data check complete; no corrections. 2021-08-05T18:00:33.539Z <Engine:5:Engine.js:1081> _process_reaction_queue() entry 628 2021-08-05T18:00:33.540Z <Engine:NOTICE> Reaction Engine running! 2021-08-05T18:00:33.540Z <app:NOTICE> Starting HTTP server and API... 2021-08-05T18:00:33.545Z <app:NOTICE> Startup complete 2021-08-05T18:00:33.546Z <Engine:5:Engine.js:1144> _process_reaction_queue ending with 0 in queue; none delayed/ready; waiting 2021-08-05T18:00:33.548Z <httpapi:NOTICE> HTTP API v1 21197 base URL http://10.0.4.71:8111; listening 2021-08-05T18:00:33.568Z <app:NOTICE> HTTP server running; registering proxy endpoints. 2021-08-05T18:00:33.568Z <app:NOTICE> Starting WSAPI... 2021-08-05T18:00:33.569Z <wsapi:NOTICE> wsapi: starting version 21196 2021-08-05T18:00:33.639Z <Engine:INFO> Engine#1 master timer tick, local time "8/5/2021, 8:00:33 PM" (TZ offset 120 mins from UTC) 2021-08-05T18:00:35.984Z <wsapi:INFO> wsapi: connection from ::ffff:172.17.0.1 2021-08-05T18:00:36.874Z <wsapi:INFO> wsapi: connection from ::ffff:172.17.0.1 2021-08-05T18:08:33.852Z <wsapi:INFO> client "172.17.0.1#2" closed, code=1001, reason= 2021-08-05T18:08:34.228Z <wsapi:INFO> wsapi: connection from ::ffff:172.17.0.1 2021-08-05T18:35:24.207Z <wsapi:INFO> client "172.17.0.1#3" closed, code=1006, reason= 2021-08-05T18:35:24.208Z <wsapi:INFO> client "172.17.0.1#1" closed, code=1006, reason= 2021-08-05T18:49:28.209Z <wsapi:INFO> wsapi: connection from ::ffff:172.17.0.1 2021-08-05T18:49:38.215Z <wsapi:INFO> wsapi: connection from ::ffff:172.17.0.1 2021-08-05T19:00:05.004Z <Engine:INFO> Engine#1 master timer tick, local time "8/5/2021, 9:00:05 PM" (TZ offset 120 mins from UTC)and the dashboard is so fluid and immediate! I love it!
@noelab said in Synology Docker installation:
I put the ezlo plus again with previous API set and did some test again
OK. Now that you have a successful cloud authentication, you can enable anonymous access if you wish on the hub using the procedure described here:
Getting Rid of the Ezlo Cloud Login Requirement
Follow the directions carefully -- they will guide you through telling MSR to set the hub flags for you, and then how to reconfigure MSR so that it stops using cloud authentication for access. Also read the warning about the risks of using anonymous access. The risks of not using it are also described; only you can judge which is the right path for you.
-
For the record, I'm using "Hyper Backup" - a native Synology NAS app - to backup my entire /REACTOR folder structure to a folder in my Google Drive cloud account. Suggest other MSR users consider doing something similar, in the event of a local NAS drive malfunction.
-
T toggledbits locked this topic on
How To: Migrate Rules from the Reactor Vera Plugin - Reactor - Multi-Hub Automation
