Posts made by gwp1 | Smart Home

gwp1

@CatmanV2 reactor_inet_check.sh and it's in your Reactor /tools directory. You don't touch it, just call it.

Then pull the output into a rule
and trigger whatever alerting you'd like.

gwp1

@Maipensato

@Maipensato said in Migration Vera to HA > how to send sensor data from Vera to HA?:

HA offers a huge amount of integrations and a big community of users and developers

Yep. And it's all available in MSR when you configure the connection between them.

@Maipensato said in Migration Vera to HA > how to send sensor data from Vera to HA?:

The biggest disadvantage in my case is that MSR can not handle LUA code and my most complex Reactors use quite some LUA code

You may find that MSR replaces the need for this level of hand-coding.

@Maipensato said in Migration Vera to HA > how to send sensor data from Vera to HA?:

Switching from the Vera Reactor to MSR is doable but takes time and it is different.

IIRC, there's a script to migrate Vera's Reactor to MSR. I used it several years ago.

I use MSR as my rules engine between Hubitat and HA. HA provides many great integrations as well as controlling some ZWave devices and has the dashboarding I want. Hubitat controls most devices and has some integrations it does better than HA.

In the end it's up to you, of course. I have everything running in Proxmox containers.

gwp1

@toggledbits Most days I'm not very smart... but I'm stubborn.

This is working.

It has kept working thru multiple MSR restarts. (I have not yet tested a container restart.)

I'm not 100% sure why it's working, tbh. I think one more MSR restart cleared the cobwebs and it was suddenly fine. I then added an ACL before putting back Access Control which brings me to...

I also have Access Control back in place and using a hashed pwd (which for some reason eluded me when I tried to enable it previously.)

On this day we're calling it "Two steps back, three forward."

Thanks for your help as always.

gwp1

@Crille @Maipensato I cannot possibly endorse more positively the standalone MSR. https://reactor.toggledbits.com/docs

I recommend the containered approach having done so just this week after using an RPi for years (since MSR was released). Just a much easier approach.

gwp1

@toggledbits I know how to tick code - I just didn't think at that hour it would be necessary. Apologies.

Because, YES, trying to configure this from the Proxmox host is devilish, I've added this now to Unbuntu root crontab with:

sudo crontab -e

# MSR script to perform internet check every minute
* * * * * cd /home/reactor/reactor && tools/reactor_inet_check.sh

~~Looking into the ACL now as I do have Access Control enabled.~~

EDIT

Taking things in smaller bites... I've renamed users.yaml so Access Control is disabled. Let's start easy

Cron is running. To me, this reads like it's running just fine.

2025-01-18T13:08:01.129250-05:00 msr CRON[21717]: (root) CMD (cd /home/reactor/reactor && tools/reactor_inet_check.sh)
2025-01-18T13:09:01.161220-05:00 msr CRON[21737]: (root) CMD (cd /home/reactor/reactor && tools/reactor_inet_check.sh)
2025-01-18T13:10:01.223057-05:00 msr CRON[21769]: (root) CMD (cd /home/reactor/reactor && tools/reactor_inet_check.sh)
2025-01-18T13:10:18.126046-05:00 msr systemd[1]: Starting sysstat-collect.service - system activity accounting tool...
2025-01-18T13:10:18.131608-05:00 msr systemd[1]: sysstat-collect.service: Deactivated successfully.
2025-01-18T13:10:18.131786-05:00 msr systemd[1]: Finished sysstat-collect.service - system activity accounting tool.
2025-01-18T13:11:01.254645-05:00 msr CRON[21797]: (root) CMD (cd /home/reactor/reactor && tools/reactor_inet_check.sh)
2025-01-18T13:12:01.315036-05:00 msr CRON[21821]: (root) CMD (cd /home/reactor/reactor && tools/reactor_inet_check.sh)
2025-01-18T13:13:01.347216-05:00 msr CRON[21844]: (root) CMD (cd /home/reactor/reactor && tools/reactor_inet_check.sh)

Looking at the Reactor System Entity, however, I still see

reactor_system.internet_ok=null

gwp1

To bring this all full circle, I had installed Portainer just to see what it was/did. Rereading the manual for MSR I stumbled across Portainer-specific instructions.

Short story long, I deleted the original container and created a new one thru the Portainer path. Done in mere minutes, runs flawlessly and I don't need to worry about the docker-compose errors I was getting.

Going to mark this topic as solved as all of the three issues were addressed.

gwp1

When on my bare metal RPi with MSR I had a rule that ran every minute to check Internet status via a script in MSR called reactor_inet_check.sh

I've moved to containerized MSR and see in the instructions that this cannot be run from the container.

The script cannot run within the Reactor docker container. If you are using Reactor in a docker container, the script needs to be run by cron or an equivalent facility on the host system (e.g. some systems, like Synology NAS, have separate task managers that may be used to schedule the repeated execution of tasks such as this).

I've put a script on my container host that calls the reator_inet_check.sh script and it isn't erroring... but I still see the internet status within MSR as null.

Before I go diving down the rabbit hole... should this work?

My cronjob on the proxmox host:

The contents of msr_internet_check_caller.sh

gwp1

@CatmanV2Last night I said "Siri, turn on the TV" and my Alexa device replied "TV is not responding."

Just to reinforce that I'd not stuttered or mispoken, Siri had (in fact) turned on the TV.

They're all in cahoots.

gwp1

@toggledbits Confirmed. Added test Ruleset and Rule. Tools>Restart, they stuck. Deleted test Rule and Ruleset, Tools>Restart, they were still gone.

Next up: docker-compose

gwp1

@toggledbits AH - will do that post-haste. Thanks. And fully appreciate the "on the run".

gwp1

@toggledbits Fair enough

gwp1

@toggledbits the link to @cw-kid's issue was the key: what he saw was exactly what I saw. 1kb file size, all of it.

I did copy the entire storage folder (along with the rest) vs cherry-picking but somehow the file size thing he saw was replicated here. I recopied but checked <user> <group> the expressions.json file (after confirming both file size and contents) and started the new MSR and it's all there. I even did a test Rule Set > Rule create/del and all is well.

I've shut down the RPi legacy system for now... gonna test run the new one.

QQ... at the bottom of the rules now I see a history that I don't recall seeing in my legacy system (which is bare metal and current). I went back and it's in the legacy system - very nice. Shamefully going to ask when that was added.

gwp1

@toggledbits very helpful on the docker explanation - this is my very first foray into docker (using it with MSR) so it's all fresh and new to me. Thank you.

I resolved the HA <-> MSR issue - it was a bad IP in the reactor.yaml file.

What file do Global Expressions live in? They are literally gone from the UI.

And I have LOTS of them in production.

The log shows this, which is not surprising given none of them are there:

[latest-24366]2025-01-12T16:58:29.554Z <Rule:ERR> Predicate#rule-m34m60yh/trig condition refers to undefined global `ambient_windspeed'

gwp1

So I searched this forum earlier but didn't find this thread. A generic global Internet search netted me this old nugget of info on exactly the first issue, the MSR>HA connectivity.

Using @toggledbits one-liner

    curl -o - 'http://192.168.0.15:8123/api/config'

returned just what I needed to determine it was an IP configuration error. I'd taken painstaking efforts to re-IP the new HA to the old HA's original IP... and then (for some inexplicable reason) updated the reactor.yaml with the new long-lived access token AND the temporary IP. Dunno what I was thinking... or if I was thinking... in that moment. But that's fixed now and MSR and HA are happily chatting away.

So now I have the two issues remaining:

My first issue: I'm logged into the msr CT as reactor (I used the suggested username just to keep things simple as this is new space for me and I was high off my success of migrating HA over).

When I run

docker pull toggledbits/reactor:latest-amd64
... it assigns the \reactor\ subdirectory where installed root ownership. I am absolutely logged in with the correct non-root user.

Second issue: I copied over the following folders:

When MSR loads, all of my Global Expressions are missing.

gwp1

Zero issues installing Proxmox on a new MiniPC.
Zero issues migrating my HA instance over to the new hotness (I know, I was surprised, too!)

And then MSR...

My first issue: I'm logged into the msr CT as reactor (I used the suggested username just to keep things simple as this is new space for me and I was high off my success of migrating HA over).

When I run

docker pull toggledbits/reactor:latest-amd64

... it assigns the \reactor\ subdirectory where installed root ownership. I am absolutely logged in with the correct non-root user.

Second issue: I copied over the following folders:
When MSR loads, all of my Global Expressions are missing.

Third issue:
All controllers connect wonderfully (Hubitat, etc)... except HA.
After changing ownership of the logs to reactor again I can see this when MSR calls HA:


[latest-24366]2025-01-12T00:03:43.128Z <HubitatController:INFO> HubitatController#hubitat successful connection to ws://192.168.1.214/eventsocket
[latest-24366]2025-01-12T00:03:43.151Z <HubitatController:NOTICE> HubitatController#hubitat current mode is Evening (2)
[latest-24366]2025-01-12T00:03:43.212Z <HubitatController:NOTICE> HubitatController#hubitat HSM status is disarmed
[latest-24366]2025-01-12T00:03:43.214Z <Controller:NOTICE> Controller HubitatController#hubitat is now online.
[latest-24366]2025-01-12T00:03:43.255Z <MQTTController:INFO> MQTTController#mqtt2 connected; opening subscriptions
[latest-24366]2025-01-12T00:03:43.371Z <MQTTController:INFO> MQTTController#mqtt2 sending inits and going online!
[latest-24366]2025-01-12T00:03:43.373Z <Controller:NOTICE> Controller MQTTController#mqtt2 is now online.
[latest-24366]2025-01-12T00:03:47.179Z <HassController:NOTICE> HassController#hass connecting to ws://192.168.1.123:8123/api/websocket
[latest-24366]2025-01-12T00:03:47.180Z <HassController:WARN> HassController#hass websocket error during open/negotation: [Error] connect ECONNREFUSED 192.168.1.123:8123 [-]
[latest-24366]2025-01-12T00:03:47.180Z <HassController:WARN> HassController#hass ws error code ECONNREFUSED
[latest-24366]2025-01-12T00:03:47.180Z <HassController:NOTICE> HassController#hass websocket to ws://192.168.1.123:8123/api/websocket closed during open/negotiation
[latest-24366]2025-01-12T00:03:47.180Z <HassController:WARN> HassController#hass failed to connect/initialize communication: [Error] connect ECONNREFUSED 192.168.1.123:8123 [-]
[latest-24366]2025-01-12T00:03:52.181Z <HassController:NOTICE> HassController#hass connecting to ws://192.168.1.123:8123/api/websocket
[latest-24366]2025-01-12T00:03:52.183Z <HassController:WARN> HassController#hass websocket error during open/negotation: [Error] connect ECONNREFUSED 192.168.1.123:8123 [-]
[latest-24366]2025-01-12T00:03:52.183Z <HassController:WARN> HassController#hass ws error code ECONNREFUSED
[latest-24366]2025-01-12T00:03:52.183Z <HassController:NOTICE> HassController#hass websocket to ws://192.168.1.123:8123/api/websocket closed during open/negotiation
[latest-24366]2025-01-12T00:03:52.183Z <HassController:WARN> HassController#hass failed to connect/initialize communication: [Error] connect ECONNREFUSED 192.168.1.123:8123 [-]

Yes, I created a fresh new long-lived access token for the MSR containerized install and updated the reactor.yaml config file correctly.

Honestly, all-in-all, for my total lack of expertise here I'm very pleased that I only have these three issues. But they are def blockers atm.

My RPi bare metal install of MSR hooked right up to the new HA and is humming along just fine (I used hostnames were possible and shuffled some IPs in other places so I wouldn't run into things later that were mapped incorrectly that I'd forgotten about.)

Proxmox 8.3.2
MSR lives in an Ubuntu 24.04 Proxmox container
MSR is latest docker version

What else can I provide to those smarter than me here?

gwp1

@cw-kid I feel like there was a thread on this or something in the release notes of a recent version that called this out but I cannot find it in the few minutes I had to search.

gwp1

@tunnus yes, the rule is working and @toggledbits indicated as such (that it would work) but he raised a potential issue regarding the crossing of midnight that I was asking about there being a better approach.

gwp1

@tunnus would that not create the condition of starting at 2200 on 10/01 and staying on until 0600 04/01?

That's not what I'm after. I'm after a daily window of hours for those months.

gwp1

@toggledbits what would be a better approach to ensuring it starts at 2200 EDT on 10/01 and runs thru 0600 03/31?

gwp1

@toggledbits I incorrectly correctly used ruleset as there will be a couple/three rules

So if I want it on between two specific times I would update what you show to

gwp1

latest-25016 toggle.toggle on VeraController Lock entity not working

[SOLVED] reactor_inet_check script... and containers

Apple Home Automation Issue

Migration Vera to HA > how to send sensor data from Vera to HA?

[Solved] Migrating MSR to Docker on Proxmox

Runtime error latest-24366 when Create New Reaction

Reactor (Multi-System/Multi-Hub) Announcements

'Random' lights turning on

Hello and first network question

Vera reload detected where there does not appear to be one.

Has something changed with the "Changes" operator in Constraint groups ?

Reactor-Editor / Reactor-ui-Status Errors

[Solved] Error dialog running reaction in build 24302

every X days field uneditable

[Reactor] Use VirtualEntityController actions to drive a Reolink spotlight

Darker Reactor style

Which user to install nodejs as ? Debian Linux

OpenAI Controller for Reactor

Thanksgiving lighting took a holiday

[How-to] Managing holidays in Reactor

Posts

EDIT