That was likely it now that you mention it. I did have a problem awhile back where I fat fingered a 2:00AM cron job that was supposed to trim backup files to only keep the last x days of *.tar.gz files which filled the partition. I bet the file date reflects when that happened

Thanks again for the help and clarifying. Take care,
-bh

Thanks for the input.

I'm not sure if deleting this zero length file was the right thing to do or not but it fixed the problem, the engine starts now and SMTP works.

From the log:
[latest-23218]2023-08-21T20:55:09.695Z <IndividualFileStrategy:ERR> [IndividualFileStrategy][IndividualFileStrategy#/var/reactor/storage/states] failed to read cs-rule-lbhys108 in /var/reactor/storage/states/cs-rule-lbhys108.json: 

So basically the file /var/reactor/storage/states/cs-rule-lbhys108.json had a file length of "0"
-rwx------ 1 501 staff 0 Jul 20 02:00 cs-rule-lbhys108.json

I moved the file in question to a tmp directory, restarted reactor, the engine started and SMTP works now.

Question:
Was moving / effectively deleting this file from reactors view a bad thing to do that will cause future problems and is there anything else that need to do other than getting rid of that zero length file?

Thanks,
-bh

MSR Version: latest-23218
Running as Docker Container : Docker version 24.0.5, build ced0996
OS: Linux 15BPMSR1 6.1.26-05272-g26c406245a2c #1 SMP PREEMPT_DYNAMIC Thu Apr 27 10:15:40 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

SMTP notifications had been working fine and I am unsure exactly what action(s) stopped it from working.

I have verified that the SMTP server configured in notifications.yml is working properly.

To duplicate the problem I am forcing an SMTP email notification using the set reaction play button, the reactor.log shows the following errors:

[latest-23218]2023-08-21T14:23:22.462Z <wsapi:ERR> [WSAPI]wsapi#1 can't queue reaction rule-lgxmrba4:S: [Error] Engine has not been started [-]
[latest-23218]2023-08-21T14:23:22.463Z <wsapi:CRIT> Error: Engine has not been started [-]
Error: Engine has not been started
    at Engine.queueReaction (/opt/reactor/server/lib/Engine.js:1494:46)
    at WSAPI.clientMessage (/opt/reactor/server/wsapi/wsapi.js:782:64)
    at WebSocket.<anonymous> (/opt/reactor/server/wsapi/wsapi.js:301:157)
    at WebSocket.emit (node:events:527:28)
    at WebSocket.emit (node:domain:475:12)
    at Receiver.receiverOnMessage (/opt/reactor/node_modules/ws/lib/websocket.js:1068:20)
    at Receiver.emit (node:events:527:28)
    at Receiver.emit (node:domain:475:12)
    at Receiver.dataMessage (/opt/reactor/node_modules/ws/lib/receiver.js:517:14)
    at Receiver.getData (/opt/reactor/node_modules/ws/lib/receiver.js:435:17)

I have tried:

OS level: apt udate and apt upgrade and reboot

docker pull toggledbits/reactor:latest-aarch64
latest-aarch64: Pulling from toggledbits/reactor
Digest: sha256:d8a019d457c9fef61f7c3e6908db1f1d0a2d14b6f7c5e9d4fc536c791503d152
Status: Image is up to date for toggledbits/reactor:latest-aarch64
docker.io/toggledbits/reactor:latest-aarch64

docker stop reactor
docker start reactor

docker compose down
docker compose up -d

To no avail.

I feel like I'm missing something obvious but can't put my finger on it.

Thank you in advance for any guidance.
-bh

I think this would be an interesting sensor to have. I’m guessing you are sensing pressure / weight and returning a numeric value based on that vs a simple open / close. The reason being you is that you would need a base (empty bed) value in order to make decisions whether someone / thing is in bed or not or how many are in bed for that matter. The second reason is that beds have different numbers of legs depending on the type of bed and therefore weight distribution comes into the picture, so sensing pressure or weight vs open / close seems like it would give you more options and even interest from other markets.

Meaning, if this is a pressure / weight type sensor it could have other applications as well expanding your market. For example, I have a salt tank that holds a few hundred pounds of salt for my water treatment system. I could record the initial numeric values at different levels and use that information to know when it is low and needs more salt. I would be interested in doing that.

Just my $.02

Take care and good luck.

-bh

Howdy,

Has anyone successfully installed 22337 via Docker Hub?

I'm currently running latest-22310 on Qnap NAS 5.0.0.1986

My usual method which is normally successful, is that in the Qnap CLI I run a docker pull (stdout below of what I got for 22337):

>basai ~]$ docker pull toggledbits/reactor:latest-amd64
> latest-amd64: Pulling from toggledbits/reactor
> 8663204ce13b: Already exists 
> 8c392e9e905c: Already exists 
> 36ce72f2f129: Already exists 
> 2e8529c47e46: Already exists 
> 26c2865d7fe4: Pull complete 
> b45a2cf2a065: Pull complete 
> ac02d13d40de: Pull complete 
> 2bd82a6d3d8c: Pull complete 
> Digest: sha256:a192e403200a62664cec40f40f61499218ac9a0cae3b8ed8390f87679505105d
> Status: Downloaded newer image for toggledbits/reactor:latest-amd64
> docker.io/toggledbits/reactor:latest-amd64

But when I go into the Qnap's container station (part of my usual process) and search for reactor and do the install for 'latest-amd64' it installs latest-22310 and not latest-22337.

Sanity checking before I go down the path of chasing down Qnap and/or Container Station problems.

TIA
-b

I'm not exactly sure here trying to follow the logic, but since you are using constraints, could that be the reason? Meaning, there is a section in the manual that talks about constraints eg: "Unlike triggers, changes in the conditions of constraints do not cause the rule to set or unset. They are only used as filter to allow or prevent the rule from setting."

Happy Birthday !! Also, thanks for doing this. Take care, -b

Thank you all for your responses, you are an awesome bunch in this group and I have what I was looking for.

Essentially toggling a rule as active or inactive can only be done manually, so I wasn't going crazy because this was something I could do in the Vera Reactor to another Reactor

I have been using toggles in HAAS to toggle a state which I include as a 'constraint' within multiple MSR rules which works.

What I was looking for is more of a 'kill switch’ to completely disable a rule or set of rules for reasons that come up from time to time where I manually disable them so there is no chance of them running. Not a show stopper by any means.

Thanks again,
-b

Howdy,

My goal is to have a rule that when triggered will disable other certain pre-defined rule sets, but I can't seem to find a way to do it in MSR. Is it possible?

In the MSR UI, rule sets are toggled manually to be enabled (green) and disabled (red). I would like to do this from within a rule.

Running MSR version latest-22274-24dfd72c

TIA,
-bh

Howdy, Honestly I didn’t really think this was an MSR Set Reaction pandemic and was more than likely a locally induced error of some sort.

This is fixed now based on something you said in your last reply suspecting an update problem which pulled me out of a loop and put me on the right path.

Summary: Upgrading to latest-22274 fixed the problem but QNAP’s Container Station using the Docker Hub Tab would only download and install latest-22179. Not sure if this is a QNAP bug or feature.

Detail: For the benefit of any QNAP NAS users out there I’ll explain.

Using QNAP NAS’s Container Station, searching for “reactor” in the “Docker Hub” tab I would select "latest-amd64”, but it would only install latest-22179 and not the actual latest-22274. Picking up the NAS and shaking it a few times, turning it off and on again, or putting more quarters in it didn't help.

In the past I didn’t find a need to do the following since I believe Container Station should be doing this all by self, and if not, user error on my part.

So to fix this I ssh’d to the QNAP NAS CLI and ran.

docker pull toggledbits/reactor:latest-amd64

Which returned the following, I was feeling optimistic seeing the "pull completes' "

[basai@basai ~]$ docker pull toggledbits/reactor:latest-amd64
latest-amd64: Pulling from toggledbits/reactor
8663204ce13b: Already exists 
8c392e9e905c: Already exists 
36ce72f2f129: Already exists 
2e8529c47e46: Already exists 
26c2865d7fe4: Pull complete 
b45a2cf2a065: Pull complete 
ac02d13d40de: Pull complete 
2bd82a6d3d8c: Pull complete 
Digest: sha256:a192e403200a62664cec40f40f61499218ac9a0cae3b8ed8390f87679505105d
Status: Downloaded newer image for toggledbits/reactor:latest-amd64
docker.io/toggledbits/reactor:latest-amd64
[basai@basai ~]$

After this completed, now when I went to create a new docker by going into container station, searching for “reactor” in the “Docker Hub Tab” and selected “latest-amd64” it correctly installed latest-22274 and also pre-populated the NODE_PATH variable correctly which wasn’t happening before.

Problem solved and MSR is working as expected again.

Thanks you for your help, MSR Rocks!
-bh

@toggledbits

Apologies for the confusion.

I was trying to indicate, although poorly, that I did install 'latest' at first which didn't correct the problem and then opted to go with 'stable' thinking that was the better choice.

As far as the MSR Set Reaction using haas vs vera per my report, I was testing both and neither worked when the rule is triggered, however the light does turn off when I manually select the play button next to the Set Reaction Rule for either the set haas or vera case. Unfortunately I neglected to reflect that correctly in my report and hence the mismatch / confusion

HTH
-bh

Iron: QNAP NAS
Running MSR and HAAS on Docker (QNAP Container Station)
Reactor (Multi-hub) stable-22203-81a2f3cc
Home Assistant Core 2022.6.7
Vera 1.7.5186 (7.31)
Config files are stored in shared volumes on the NAS.
Office light in example is joined to Vera-Plus

Hello all,

I decided to upgrade MSR to latest-amd64. It wasn’t until afterwards that I noticed all rulesets broken. So unfortunately I’m not sure if this was already broken before or I broke it after upgrading. Yes poor judgement on my part for being complacent.

Never the less, this is broken globally across all rulesets, even though I can see the triggers change to “True” (Turn green).

For this example, I have a boolean helper toggle in HAAS called “TV MODE HAAS SW”.

When toggled ‘on’, MSR should turn my Vera office light OFF and it doesn’t, but if I manually select the play button to the right of the line in the Set Reaction, it executes properly and turns off the Vera office light.

The MSR Rule does not have any Constraints set.

I can see in MSR it recognizes the state changes yet doesn’t execute the “Set Reaction”.

Any help greatly appreciated.

Log files from reactor.log and screen shots to follow:

Reactor.log when toggling the haas helper, Set Reaction doesn’t execute.

[stable-22203]2022-10-02T21:21:34.799Z <Rule:INFO> TV MODE ON (Rule#rule-l2hvuz8r) starting evaluation; because entity-changed Entity#hass>input_boolean_tv_mode
[stable-22203]2022-10-02T21:21:34.800Z <Rule:INFO> TV MODE ON (Rule#rule-l2hvuz8r) evaluated; rule state transition from RESET to SET!
[stable-22203]2022-10-02T21:21:34.819Z <Rule:INFO> TV MODE ON (Rule#rule-l2hvuz8r) evaluation complete
[stable-22203]2022-10-02T21:21:34.820Z <Engine:INFO> Enqueueing "TV MODE ON<SET>" (rule-l2hvuz8r:S)
[stable-22203]2022-10-02T21:21:34.835Z <Engine:NOTICE> Starting reaction TV MODE ON<SET> (rule-l2hvuz8r:S)
[stable-22203]2022-10-02T21:21:34.835Z <Engine:INFO> TV MODE ON<SET> all actions completed.

Reactor.log when manually triggering the Set Reaction with the play button which correctly turns off the light

[stable-22203]2022-10-02T21:23:25.035Z <HassController:null> HassController#hass: sending payload for power_switch.off on Entity#hass>light_office_86 action: [Object]{ "type": "call_service", "service_data": { "entity_id": "light.office_86" }, "domain": "homeassistant", "service": "turn_off" }

When toggled ON

Rule config screen

It may be that you need to pull "latest-[flavor]" and not just "latest" eg: latest-amd64 etc. dependent on the image specific to your installation type.
-bh

@toggledbits Thank you for the reply and solution.

What confused me was that as an expression created within a Rule it worked fine, but now that I read your reply I see why, this was a "Doh!" on my part, I hadn't thought of it like that.

Thanks again!,
-b

I’ve looked and can’t find the answer which concerns me that the answer is obvious and thats why I can't find the answer to this.

I’m new to MSR and this is my first post, so please bare with me

What I’m trying to do is have a global expression that contains the current time so I can use it in Global reactions as well as Rulesets as part of my syslog messages.

Example of what I’m experiencing:
In Expressions, create a global expression: gMyTOD = strftime("%T %D”)
In Rulesets, in a rule, create a local expression: MyTOD = strftime("%T %D”)

In that same rule create a Notify type of Syslog.
Set syslog message to: gMyTOD time is ${{gMyTOD}} and MyTOD time is ${{MyTOD}}
Trigger the rule.

The result is that the local expression (MyTOD) contains the correct time but the global expression (gMyTOD) does not update and reflects the wrong time in the final syslog message.

Is there a different approach I should be using?

Thank you in advance for any insight.

-bh