I updated to the latest version and it is working with Digest auth and the new username / password fields. You are going to spoil us with this pace of development

@wmarcolin

I'm still trying to try one of these things and not have @toggledbits come in right behind me and show a much easier way. Maybe this time I'll get lucky.

I came up with this:

Based on the comments from the more experienced users here I ordered a Hubitat this morning and Amazon had it to my door about 3 hours later. After a few z-wave network resets to try to resolve one switch that just won't configure, I have about 90% of everything migrated over to Hubitat. Vera still has a few SiteSensors (I need to read up on the threads about replicating site sensors on MSR) and some Yeelight bulbs that are on a separate VLAN from the Hubitat. I haven't found a way to connect them manually yet and the Hubitat can't discover them across the VLANs.

I'm still trying to figure out a way to use Google Home to flip a virtual switch in Hubitat to then trigger a http call from MSR. There are a few things I was doing with Vera scenes to achieve a similar effect, but MSR doesn't seem to be able to see Hubitat virtual devices.

I'll probably keep the VeraPlus going for a while with the Yeelights and the SiteSensors while I figure the rest of this out.

Thanks for the advice.

+1

I am getting occasional network timeouts on a http request that repeats every two minutes (it is emulating a SiteSensor that I had on Vera). I'd like to be able to suppress those alerts as they are expected to happen from time to time and not anything I need to be notified about.

Edit:
Nevermind.... I posted here before looking at the update you just posted in the announcements thread... I see you already made this change.

I took the UserName and Password, used a base 64 encoder and input "UserName:Password" into the encoder. I took the output of the encoder ("ABCDEFGXXX") and entered (no quotes) "Authentication: Basic ABCDEFGXXX" into the http headers field. I have another http request in another rule that hits an API to control my thermostat and it work correctly using exactly the same process.

The logs don't appear to make any reference to the http header:

[latest-21297]2021-11-01T22:21:55.816Z Engine:INFO Set PTZ Camera to Day Mode rule<SET> all actions completed.
[latest-21297]2021-11-01T22:21:55.845Z Engine:ERR Engine#1 reaction Set PTZ Camera to Day Mode rule<SET> step 3 HTTP request to http://xxx.xxx.xxx.xxx/cgi-bin/ptz.cgi?action=start&channel=0&code=GotoPreset&arg1=0&arg2=18&arg3=0 failed: 401 Unauthorized
[latest-21297]2021-11-01T22:21:55.854Z Engine:ERR Engine#1 reaction Set PTZ Camera to Day Mode rule<SET> step 1 HTTP request to http://xxx.xxx.xxx.xxx/cgi-bin/configManager.cgi?action=setConfig&VideoInMode[0].Config[0]=0 failed: 401 Unauthorized

Prior to attempting to use the http header field I had tried the below format, with the username and password in front of the URL:

[latest-21297]2021-11-01T12:58:08.125Z Engine:ERR Engine#1 reaction Set PTZ Camera to Night Mode rule<SET> step 3 HTTP request to http://UserName:Password@xxx.xxx.xxx.xxx/cgi-bin/configManager.cgi?action=setConfig&VideoInExposure[0][1].Value1=1000&VideoInExposure[0][1].Value2=1000 failed: 401 Unauthorized

I did get this working in Node-Red using digest authentication in a http-request node, so it probably isn't worth too much of everyone's time to track it down. I would prefer to have it in MSR because it is so much more user-friendly for me, but I can leave it in Node-Red if I can't figure out how to do it in MSR.

@toggledbits - Long overdue additional donation on its way. Thanks for all your efforts and the end-user support.

Resurrecting this older thread... does this answer mean there is no way to react to the presence of an alert within MSR? If not, this would be a useful enhancement.

I have a camera that is switched between day and night settings by http requests sent by MSR near sunset and sunrise. Yesterday the camera stayed in night mode most of the day while there was an alert showing in MSR that the http request had failed. I realize I could capture the http response to an expression/variable and then write a rule based on that variable to notify me, but I'd have to do this for every http request in every ruleset, and I'd have to make sure I evaluate the response correctly (which is likely to be a hit or miss operation for me). That still wouldn't capture other alerts that MSR might display outside of failed http requests, but I'd like to push all alerts to my notification system. Basically, I don't want to have to check the MSR interface to make sure it's happy, I'd like it to tell me when it's not.

Just a note for posterity that alerts are now available as an entity as of version 21356.

@cw-kid I'm sure there are multiple ways to do this, and probably some better than what I'm thinking...

Create an expression "g_curtains_open_today"

Create a rule. At midnight every day set g_curtains_open_today to false

Motion sensor rule: If motion sensor trips AND g_curtains_open_today is false then:

-> Open curtains
-> set g_curtains_open_today to true

The next time the motion sensor trips before midnight the curtains will not open

@gwp1

I searched through old topics looking to see if this was already reported, but somehow i missed your post.

I'm also seeing the issue where even when I update the expression, the new value doesn't appear in a rule that references it unless I manually reset the rule.

Reactor 22022, Raspberry PI4 Buster, Docker

What is expected: When an expression value changes, dependent expression values will also change

What is occurring: When an expression changes, dependent expressions only update if I click "Try this expression".

After updating to 22021 and then 22022 I noticed that my Thermostat routine started having issues. While looking into the cause I found that dependent expression were not updating automatically.

My specific application is as follows: I have MSR poll the Lennox "iComfort" API to get the current state of the Thermostat via an HTTP request every minute.
The request returns a JSON response. The polling rule captures that response to an expression:

That expression is being updated as expected:

Other expressions are set to the values of various parts of the g_iComfort response. For example the cool set point expression is set as follows:

These screen shots show that g_iComfort has the cool set point at 74, but g_tstat_csp is still 72 as I hadn't clicked the "Try this expression" button.

I have additional expressions set up for the heat set point, the operation mode, the humidity, etc.

Since g_tstat_csp is dependent on g_iComfort, if g_iComfort changes g_tstat_csp should change. When the polling rule runs each minute the g_iComfort expression updates, but none of the expressions that are dependent on g_iComfort update. If I click the "Try this expression" button, they update. On versions before 22021 they updated as expected.

As a test I set up two simpler expressions, one a string and one set to mirror that string:

The attached screen shot was after I set g_test3 to "bar" and clicked Save, then clicked "Try this expression" on g_test4 which caused it to update to "bar". I then changed g_test4 to "foo" and clicked Save which resulted in this screen shot where g_test3 is "foo" but g_test4 is still showing "bar".

After barking up many wrong trees I found this: https://www.giters.com/SensorsIot/IOTstack/issues/401

Which provided these steps to fix the issue

$ sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com:443 --recv-keys 04EE7237B7D453EC 648ACFD622F3D138
$ echo "deb http://httpredir.debian.org/debian buster-backports main contrib non-free" | sudo tee -a "/etc/apt/sources.list.d/debian-backports.list"
$ sudo apt update
$ sudo apt install libseccomp2 -t buster-backports

After running those command, MSR is back in business on the latest build.

That wasn't a log snippet... at least not the first one. That was the entire log after upgrading to latest. The issue doesn't appear to be that MQTT controller won't load on latest. With MQTT set to false I still get nothing in the log file but "Fatal Error at line 0".

I assume something in my config file is the issue, so I'll start commenting out sections that aren't default and hope I can get it working.

Edit: I think I see one source of confusion... that first set of log entries is from the logs of the docker container, which I pulled from Portainer (used to manage my Docker containers). While Portainer shows the container as running, Reactor itself is not saving any logs at all. I guess that makes sense if it crashed out on line zero...

How can I get a new/clean version of reactor.yaml? I tried deleting my docker image, renaming the existing file, and pulling/running the docker image again, but it doesn't create a new reactor.yaml.

I also tried making sure my RPi4 was up to date (apt update / apt full-upgrade) then rebooted, but I'm still stuck.

@toggledbits Setting aside the hijack of my Raspberry Pi Docker thread by a Windows bare metal issue... any thoughts on why my docker install of "latest" failed?

@cw-kid I'm sure there are multiple ways to do this, and probably some better than what I'm thinking...

Create an expression "g_curtains_open_today"

Create a rule. At midnight every day set g_curtains_open_today to false

Motion sensor rule: If motion sensor trips AND g_curtains_open_today is false then:

-> Open curtains
-> set g_curtains_open_today to true

The next time the motion sensor trips before midnight the curtains will not open

I attempted to upgrade my Docker container to "toggledbits/reactor:latest-raspbian-armv7l" and the container started but the Reactor interface wouldn't load in the browser. The logs showed this:

#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xbec2458c


#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xbedec58c


#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xbed3358c


#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xbef7f58c


#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xbedd958c


#
# Fatal error in , line 0
# unreachable code
#
#
#
#FailureMessage Object: 0xbe86958c

The logs continued throwing errors with different object IDs.

I removed the container and tried to install again using toggledbits/reactor:1.0.2-raspbian-armv7l and now the container won't start and the logs show this:

NODE_PATH /opt/reactor
FileLogStream { type: 'file', name: 'reactor.log', mode: 438, maxsize: 2, keep: 5 }
[1.0.2-21350]2022-01-22T14:35:21.715Z <app:null> Reactor "1.0.2-21350-252f948" starting on v16.11.1
[1.0.2-21350]2022-01-22T14:35:21.717Z <app:INFO> Process ID 1; platform linux/arm #1457 SMP Tue Sep 28 11:26:14 BST 2021; locale (undefined)
[1.0.2-21350]2022-01-22T14:35:21.718Z <app:INFO> Basedir /opt/reactor; data in /var/reactor/storage
[1.0.2-21350]2022-01-22T14:35:21.719Z <app:INFO> NODE_PATH=/opt/reactor
[1.0.2-21350]2022-01-22T14:35:21.727Z <app:INFO> Configured locale (undefined); selected locale(s) en-US.UTF-8
[1.0.2-21350]2022-01-22T14:35:21.786Z <app:INFO> Loaded locale en-US
[1.0.2-21350]2022-01-22T14:35:21.812Z <Capabilities:null> Module Capabilities v21333
[1.0.2-21350]2022-01-22T14:35:21.890Z <Plugin:null> Module Plugin v21186
[1.0.2-21350]2022-01-22T14:35:21.902Z <TimerBroker:null> Module TimerBroker v21333
[1.0.2-21350]2022-01-22T14:35:21.908Z <default:INFO> Module Entity v21334
[1.0.2-21350]2022-01-22T14:35:21.916Z <Controller:null> Module Controller v21333
[1.0.2-21350]2022-01-22T14:35:21.917Z <default:null> Module Structure v21338
[1.0.2-21350]2022-01-22T14:35:21.934Z <default:null> Module Ruleset v21096
[1.0.2-21350]2022-01-22T14:35:21.935Z <default:null> Module Rulesets v21096
[1.0.2-21350]2022-01-22T14:35:21.956Z <GlobalExpression:null> Module GlobalExpression v21333
[1.0.2-21350]2022-01-22T14:35:21.986Z <default:null> Module Rule v21348
[1.0.2-21350]2022-01-22T14:35:21.994Z <GlobalReaction:null> Module GlobalReaction v21333
[1.0.2-21350]2022-01-22T14:35:21.997Z <AlertManager:null> Module AlertManager v21333
[1.0.2-21350]2022-01-22T14:35:21.998Z <default:null> Module Engine v21346
[1.0.2-21350]2022-01-22T14:35:21.999Z <default:null> Module httpapi v21345
[1.0.2-21350]2022-01-22T14:35:22.004Z <default:null> Module httpproxy v21333
[1.0.2-21350]2022-01-22T14:35:22.037Z <default:null> Module wsapi v21334
[1.0.2-21350]2022-01-22T14:35:22.048Z <app:NOTICE> Starting Structure...
[1.0.2-21350]2022-01-22T14:35:22.131Z <InfluxFeed:null> Module InfluxFeed v21345
[1.0.2-21350]2022-01-22T14:35:22.135Z <Structure:INFO> Structure#1 starting plugin influx (InfluxFeed)
[1.0.2-21350]2022-01-22T14:35:22.137Z <Structure:INFO> Structure#1 loading controller interface hubitat (HubitatController)
[1.0.2-21350]2022-01-22T14:35:22.162Z <HubitatController:null> Module HubitatController v21338
[1.0.2-21350]2022-01-22T14:35:22.174Z <Structure:INFO> Structure#1 loading controller interface hubitat_11705 (HubitatController)
[1.0.2-21350]2022-01-22T14:35:22.180Z <Structure:INFO> Structure#1 loading controller interface weather (OWMWeatherController)
[1.0.2-21350]2022-01-22T14:35:22.194Z <OWMWeatherController:null> Module OWMWeatherController v21313
[1.0.2-21350]2022-01-22T14:35:22.198Z <Structure:INFO> Structure#1 loading controller interface reactor_system (SystemController)
[1.0.2-21350]2022-01-22T14:35:22.205Z <SystemController:null> Module SystemController v21345
[1.0.2-21350]2022-01-22T14:35:22.211Z <Structure:INFO> Structure#1 loading controller interface mqtt (MQTTController)
[1.0.2-21350]2022-01-22T14:35:22.223Z <MQTTController:null> Module MQTTController v21361
[1.0.2-21350]2022-01-22T14:35:22.227Z <Controller:CRIT> Controller: failed to load mqtt implementation file:///var/reactor/ext/MQTTController/MQTTController.js: [TypeError]TypeError: require(...).requires is not a function
[1.0.2-21350]2022-01-22T14:35:22.229Z <Controller:CRIT> TypeError: require(...).requires is not a function
TypeError: require(...).requires is not a function
    at Object.<anonymous> (/var/reactor/ext/MQTTController/MQTTController.js:14:53)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:196:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:183:25)
    at async Loader.import (node:internal/modules/esm/loader:178:24)
    at async importModuleDynamicallyWrapper (node:internal/vm/module:437:15)
Trapped unhandled Promise rejection TypeError: require(...).requires is not a function
    at Object.<anonymous> (/var/reactor/ext/MQTTController/MQTTController.js:14:53)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:196:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:183:25)
    at async Loader.import (node:internal/modules/esm/loader:178:24)
    at async importModuleDynamicallyWrapper (node:internal/vm/module:437:15)
TypeError: require(...).requires is not a function
    at Object.<anonymous> (/var/reactor/ext/MQTTController/MQTTController.js:14:53)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:196:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:183:25)
    at async Loader.import (node:internal/modules/esm/loader:178:24)
    at async importModuleDynamicallyWrapper (node:internal/vm/module:437:15)

{
  <rejected> TypeError: require(...).requires is not a function
      at Object.<anonymous> (/var/reactor/ext/MQTTController/MQTTController.js:14:53)
      at Module._compile (node:internal/modules/cjs/loader:1101:14)
      at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
      at Module.load (node:internal/modules/cjs/loader:981:32)
      at Function.Module._load (node:internal/modules/cjs/loader:822:12)
      at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:196:29)
      at ModuleJob.run (node:internal/modules/esm/module_job:183:25)
      at async Loader.import (node:internal/modules/esm/loader:178:24)
      at async importModuleDynamicallyWrapper (node:internal/vm/module:437:15)
}
Trace
    at process.<anonymous> (/opt/reactor/app.js:267:142)
    at process.emit (node:events:390:28)
    at process.emit (node:domain:475:12)
    at emit (node:internal/process/promises:136:22)
    at processPromiseRejections (node:internal/process/promises:242:25)
    at processTicksAndRejections (node:internal/process/task_queues:97:32)
[1.0.2-21350]2022-01-22T14:35:22.234Z <app:ERR> Trapped unhandled Promise rejection: [TypeError]TypeError: require(...).requires is not a function
[1.0.2-21350]2022-01-22T14:35:22.234Z <app:ERR> Please refer to the console log for trace

I noticed the reference to MQTT so I changed MQTT controller to enabled:False in my reactor.yaml file. I tried reinstalling latest with the same results as before. I was then able to install 1.0.2 successfully and Reactor is running. I'm only getting this error on the status page:

An Entity Attribute condition in rule "Notify when Reactor Alert is raised" failed because the referenced entity Reactor System (reactor_system>system) does not have attribute reactor_system.alert_last

I assume that 1.0.2 was prior to that feature being implemented.

Any advice on how to successfully upgrade to 22021 would be appreciated. I saw the instructions for bare metal, but I don't think that applies when I'm pulling the docker image and creating a new container.

@gwp1

I played around with the from/to specific dates and it looks like you have two choices...

Option 1: break it into two rules connected with an OR... rule 1: "After Nov 1st any year" and rule 2: "before Jan 7th any year". Or

Option 2: add specific years... "From Nov 1st 2021 to January 7th 2022" works as you want it to.

@wmarcolin

I'm still trying to try one of these things and not have @toggledbits come in right behind me and show a much easier way. Maybe this time I'll get lucky.

I came up with this:

@toggledbits I'm using a self-hosted notification system (Gotify) so when I said 'send notification' it would have been more precise to say "use as the JSON content in an http post request". The " definitely broke the request when it was substituted in to the middle of the request body. I also tried to urlencode the string but while that didn't break the request, it was super ugly as it passed all the encoded characters into the displayed message. I'm not very proficient at regex, so it took an online regex tester and a bit of trial and error to arrive at the right number of backslashes to finally make it work.

Another lesson learned: turn off 'auto evaluate expression' when trying to write expressions that refer to the alerts, 'cause if you get the expression wrong and throw an alert that causes the expression to reevaluate which throws an alert... I had to restart my Reactor Docker container a few times before I turned off 'auto evaluate' ¯_(ツ)_/¯