-
Could the temperature values be pulled into MSR from one of these devices: OW-SERVER: 1-Wire to Ethernet Server
71.57 GBP OW server (Ethernet) OW server (Ethernet)Description The OW-SERVER is an inexpensive Ethernet to 1-Wire interface that is designed to efficiently monitor and control 1-Wire devices. The OW-SERVER will allow you to use industry standard Ethernet products (switches, hubs, etc.) to build the backbone of your 1-Wire based sensor / control...
Thanks.
-
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:a398c3ff-2735-4116-8038-de74a9ea270c-image.png
That expression is being updated as expected:
65884882-389a-4497-b125-e28a6e7ccf30-image.png
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:
397cea16-6af4-4919-b858-add26fc53d0d-image.png
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:
b7f5cd4a-e1de-4b86-81d5-2ef79a65996c-image.png
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".
-
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
I added today a Centralite Zigbee Water Leak sensor device to my Ezlo Plus.
I created a rule in MSR for when it detects water to alert me and that is all working fine no problems.
I then wanted to add a panel in Grafana to show the leak sensor status etc.
The MSR user manual says that leak_detector is one of the default capabilities that will be exported.
In Grafana I was able to find the new Water Leak sensor device and add it to a new panel. however it always says "No data".
I tried various visualisation types and also for the field value tried mean, distinct, last etc but nothing ever appears data wise, tried Table View only and also changing the time range of the query.
I have actually tested the Water Leak Sensor by putting water down underneath it and it does trip OK.
I don't know how to directly query the InfluxDB, I only know how to add panels in Grafana to see the data.
1fb7aa75-06ee-447a-8a73-a3ea23ea858b-image.png
Thanks
-
This is tough to explain, saying that right up front.
HTTP Request GET to Ambient Weather API, capturing to ambient_api and the subsequent expressions for temp, UV, wind, etc. . It should be noted, this ruleset has been in place for months, working as intended.
Disclaimer: I'm not pointing the finger at build 22021/22022 - but - using Tech Support rule #1 ("What changed?") it's in my peripheral vision.
Initial Observations:
Upgraded from build 22004
The ruleset runs every five minutes, like usual, resetting when the call is done. It is NOT updating the global expressions. The data is stale. It is also not returning NULL (which sometimes the Ambient API flakes and does that and I have failover rulesets to cover that.)
Running the ruleset manually with the Reset button returns either an API 429 or 421 error, NULL as the result which triggers the failover as it should.
On the next scheduled run the ruleset the API errors go away and we're back to the first bullet point.
rolling back to build 22004 resolves the issue, everything goes back to working as intended, proven multiple times yesterday working thru the unrelated issues build 220021 had.
Other APIs appear to be working as intended. UPDATE: this is not the case, all three APIs are behaving the same as far as updating their children.
Troubleshooting:
I've copied the URL directly from the original ruleset and run it in a browser, no 429/421 errors no matter how many times I hammer on it.
I've copied the URL and used it to create a duplicate replacement ruleset.
Copied a working non-Ambient ruleset and updated the URL to make it an Ambient ruleset, which has picked up it's own oddities (noted below).
Current oddities:
The replacement ruleset runs on five minute schedule - and stays SET, prohibiting it from doing anything at the next five minute interval. (This only appears in build 22022.)
because of the above, I turned off that ruleset and re-enabled the original which immediately performed the GET 100% as expected - only to fail to update the child expressions after updating the ambient_api expression on the very next scheduled run.
Logs:
The first screenshots are the scheduled run at 0900 ET.log-0900ET-part1.png log-0900ET-part2.png log-0900ET-part3.png log-0900ET-part4.png log-0900ET-part5.png log-0900ET-part6.png
The next screenshot is the manual (via Reset) at 0905 ET
The next screenshot is the scheduled run at 0910 ET after the last run set the ruleset to SET
The last screenshot is the rulesets including the new one that is stuck in SET
I have the actual logs that go with the screenshots and can provide if necessary.
UPDATE: solved here https://smarthome.community/topic/872/expressions-not-auto-updating-when-dependencies-change-22022/8
-
Hi
I've just put a motion sensor under my bed so when I get up in a morning it will open the curtains.
However how do you make it so that action only happens once until the next morning?
For example if I later in the day enter the bedroom again, I don't want this rule to be triggered again and its action run again etc.
Thanks
-
Engine: New and very experimental Repeat While action group, repeats as long as its conditions are met. The group must have at least one condition or it will not run at all. The repeat will stop if either (a) the conditions result in false, or (b) if it's in a rule-based reaction, the contra-reaction is started by a change of rule state. It is quite possible to make reaction groups that never stop, so be careful with your logic here.
@toggledbits I'm struggling to find this - I'd like to test it for a couple of interval-based rules, but I'm not able to find it. Thanks!
-
i get the following error when i run
~/reactor $ npm i --no-save --omit dev npm ERR! code EBADPLATFORM npm ERR! notsup Unsupported platform for inotify@1.4.6: wanted {"os":"linux","arch":"any"} (current: {"os":"android","arch":"arm"}) npm ERR! notsup Valid OS: linux npm ERR! notsup Valid Arch: any npm ERR! notsup Actual OS: android
~/reactor $ npm i --no-save --omit dev
Reactor is running and i see no ill effects so far
Thought i would report for info.and here is log for more info
0 info it worked if it ends with ok 1 verbose cli [ 1 verbose cli '/data/data/com.termux/files/usr/bin/node', 1 verbose cli '/data/data/com.termux/files/usr/bin/npm', 1 verbose cli 'i', 1 verbose cli '--no-save', 1 verbose cli '--omit', 1 verbose cli 'dev' 1 verbose cli ] 2 info using npm@6.14.10 3 info using node@v14.15.4 4 verbose npm-session e65bf5b70b2ee3fd 5 silly install loadCurrentTree 6 silly install readLocalPackageData 7 http fetch GET 200 https://registry.npmjs.org/dev 1079ms 8 http fetch GET 200 https://registry.npmjs.org/dev/-/dev-0.1.3.tgz 161ms 9 silly pacote tag manifest for dev@latest fetched in 1336ms 10 timing stage:loadCurrentTree Completed in 2965ms 11 silly install loadIdealTree 12 silly install cloneCurrentTreeToIdealTree 13 timing stage:loadIdealTree:cloneCurrentTree Completed in 11ms 14 silly install loadShrinkwrap 15 timing stage:loadIdealTree:loadShrinkwrap Completed in 316ms 16 silly install loadAllDepsIntoIdealTree 17 silly resolveWithNewModule dev@0.1.3 checking installable status 18 http fetch GET 200 https://registry.npmjs.org/inotify 788ms 19 http fetch GET 200 https://registry.npmjs.org/inotify/-/inotify-1.4.6.tgz 796ms 20 silly pacote range manifest for inotify@>= 0.1.6 fetched in 1636ms 21 silly resolveWithNewModule inotify@1.4.6 checking installable status 22 timing stage:rollbackFailedOptional Completed in 2ms 23 timing stage:runTopLevelLifecycles Completed in 4975ms 24 verbose stack Error: Unsupported platform for inotify@1.4.6: wanted {"name":"inotify","version":"1.4.6","engines":{"node":">=0.8"},"os":["linux"],"dependencies":{"bindings":"^1.3.1","nan":"^2.12.1"},"optionalDependencies":{},"peerDependenciesMeta":{},"devDependencies":{},"bundleDependencies":false,"peerDependencies":{},"deprecated":false,"_resolved":"https://registry.npmjs.org/inotify/-/inotify-1.4.6.tgz","_integrity":"sha512-WW8/uqIA04O3AePQVe/Ms3ZLR0yGamaz8YOEpaXc4WBAGOPZfzu58wWErEPSUYaPyDrJRIeCn6PEIQgC1ZyQ5w==","_shasum":"c5a51852df1647d1a589d46c4baa2771ed36b8d2","_shrinkwrap":null,"_id":"inotify@1.4.6","_from":"inotify@>= 0.1.6","_requested":{"type":"range","registry":true,"raw":"inotify@>= 0.1.6","name":"inotify","escapedName":"inotify","rawSpec":">= 0.1.6","saveSpec":null,"fetchSpec":">= 0.1.6"},"_spec":"inotify@>= 0.1.6","_where":"/data/data/com.termux/files/home/reactor/node_modules/dev"} (current: {"os":"android","cpu":"arm"}) 24 verbose stack at checkPlatform (/data/data/com.termux/files/usr/lib/node_modules/npm/node_modules/npm-install-checks/index.js:46:14) 24 verbose stack at thenWarnEngineIssues (/data/data/com.termux/files/usr/lib/node_modules/npm/lib/install/validate-args.js:63:5) 24 verbose stack at /data/data/com.termux/files/usr/lib/node_modules/npm/node_modules/iferr/iferr.js:3:64 24 verbose stack at checkEngine (/data/data/com.termux/files/usr/lib/node_modules/npm/node_modules/npm-install-checks/index.js:25:10) 24 verbose stack at module.exports.isInstallable (/data/data/com.termux/files/usr/lib/node_modules/npm/lib/install/validate-args.js:60:3) 24 verbose stack at resolveWithNewModule (/data/data/com.termux/files/usr/lib/node_modules/npm/lib/install/deps.js:677:10) 24 verbose stack at /data/data/com.termux/files/usr/lib/node_modules/npm/lib/install/deps.js:600:7 24 verbose stack at /data/data/com.termux/files/usr/lib/node_modules/npm/node_modules/iferr/iferr.js:3:64 24 verbose stack at /data/data/com.termux/files/usr/lib/node_modules/npm/node_modules/call-limit/call-limit.js:28:43 24 verbose stack at processTicksAndRejections (internal/process/task_queues.js:75:11) 25 verbose pkgid inotify@1.4.6 26 verbose cwd /data/data/com.termux/files/home/reactor 27 verbose Linux 4.9.76 28 verbose argv "/data/data/com.termux/files/usr/bin/node" "/data/data/com.termux/files/usr/bin/npm" "i" "--no-save" "--omit" "dev" 29 verbose node v14.15.4 30 verbose npm v6.14.10 31 error code EBADPLATFORM 32 error notsup Unsupported platform for inotify@1.4.6: wanted {"os":"linux","arch":"any"} (current: {"os":"android","arch":"arm"}) 33 error notsup Valid OS: linux 33 error notsup Valid Arch: any 33 error notsup Actual OS: android 33 error notsup Actual Arch: arm 34 verbose exit [ 1, true ]Depandencies
{"dependencies": { "@influxdata/influxdb-client": "^1.18.0", "@mdi/font": "^5.9.55", "body-parser": "^1.19.0", "bootstrap": "4.6.0", "bootstrap-icons": "1.5.0", "cookie": "^0.4.1", "digest-fetch": "^1.2.1", "diskusage-ng": "^1.0.1", "express": "^4.17.1", "feather-icons": "^4.28.0", "font-awesome": "^4.7.0", "gridstack": "^5.0.0", "jquery": "3.6.0", "jquery-ui-dist": "1.12.1", "js-yaml": "^3.14.1", "node-fetch": "^2.6.7", "nodemailer": "^6.5.0", "qs": "^6.10.1", "serve-static": "^1.14.1", "uuid": "^8.3.2", "ws": "^7.5.6" } -
The node-fetch package, which is used by Reactor for several purposes, was reported to have a security vulnerability, and when you update packages (as is required for the recent 22021 release), you get a warning about it.
NIST currently reports that all versions of node-fetch prior to 3.1.1 are vulnerable, but since the 2.x and 3.x release paths are incompatible, I cannot easily or quickly update Reactor to use 3.1.1. Further, the author of the package now reports that version 2.6.7 is patched against the vulnerability. It may take some time before NIST lists this fact on their web site and npm's audit info is also updated. His patch was made a week ago, so it's clearly not an instantaneous process.
If you do npm ls in your Reactor install directory (bare metal users only), you will see what version you currently have installed.
DO NOT run npm audit fix as recommended by npm. This will just break your Reactor installation by installing the incompatible 3.1.1 version. If you do this, you can undo it by running npm install --no-save --omit dev again. If that doesn't do it, delete your entire node_modules subdirectory and any package-lock.json file in the Reactor install directory, and run the command again.
-
Hi
I have the same situation as the Reactor interface wouldn't load in the browser, I use Windows bare-metal installation.
Unlike the previous comment, looking at the log file I have no error, everything is loaded, and I see that the Reactor is operating, the actions are happening, only the interface in the browser that does not open.
Thanks
-
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: 0xbe86958cThe 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 traceI 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_lastI 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.
-
Greetings,
I'm not a Docker expert hence the choice of using unRaid but I would like to install MSR in a Docker and I'm looking for details on the settings used as I have not installed one manually yet.
I have installed MSR on Windows Server 2019 but I'm receiving (3 vulnerabilities (1 low, 2 high)) error messages with 'npm' and the audit fix breaks it ('npm').
Thanks for any help you can provide.
David
-
The recently changed entities no longer updates when added to the status page. It does display some initial entries. Other widgets do update as do Entities. (Docker)
-
I could not find a post or PR for this so apologies if it has been answered.
There seems to be a fixed width for the columns in the Entities page making it impossible to see the full Canonical ID of long ID's and a lot of white space in the Entity Name column.
I tried to adjust the width in Chrome and Edge without success, is it a feature or or am I doing it wrong?latest-22004-6d6c6b7 bare metal.
-
Using Brave browser (which triggers on nothing shield-wise) clicking thru to Status page nets me a blank main portion of the page. Left pane all good, top bar all good. Doubled-check with Safari browser, same outcome.
The notification bell is also red... but I can't get to the Status page to see what it's on about! 🙂
90d62b31-2737-4ec0-b9d9-928000f41584-image.pngI did go re-read the release notes just in case I missed a "and do this thing" but didn't see anything. I do have a log I pulled after doing a Restart Reactor but I see nothing jumping out at me.
-
There are "select_entities" and "select_capabilities" configuration keys in InfluxFeed, but is it currently possible to select & export global expression values? If not, hoping that this capability would be implemented in some point.
-
Could MSR at some point support openHAB as a controller?
-
Hi
I've just done a clean install of Bullseye OS on my Raspberry Pi and I am trying to setup MSR with InfluxDB.
I have managed to get the old VeraFlux plugin working OK with the new InfluxDB installation on the Pi, so think I have the InfluxDB installation correct and working.
However ideally I'd like to use MSR instead. I created a "reactor" database and created a username and password.
In the reactor config file I added this at the end of it
plugins: - id: influx name: InfluxDB 1.x Feed enabled: true implementation: InfluxFeed config: influx_url: http://192.168.0.36:8086 influx_database: reactor influx_username: myuser influx_password: "mypassword" # note use of quotesHowever when I restart MSR it doesn't come back up again. If I comment out all of that plugins section in the config file and restart the box, then MSR loads OK again. So I must be doing something wrong?
Influx running on the Pi is version 1.8.10.
MSR is running on a different Linux Debian box.
Not sure how to update to InfluxDB 2.0, maybe I should do that?
I looked in the log file and searched for "Influx" but nothing was found.
Thanks
-
I know I have mentioned this before somewhere, but i simply can't find the thread..
Plugins like Auto Virtual Thermostat and Delaylight from Vera/openLuup are functions that whould be lovely to have in MSR - is there any possibility to implement these in some way?
I could offcourse program them myself and copy them to where i want to use them, but if i'm not wrong that would be a fairly advanced ruleset that in any case would be beneficial to share with the community in some way when they are made and done.
-
I'm probably going to release my first pass at the MQTTController for Reactor (aka MSR) this week. It doesn't yet intrinsically know about a lot of devices, but you can train it for pretty much anything, I think, and it would be great if a couple of our heavy MQTT users could help check it out and maybe help contribute some device templates.
I'm hoping to package it up for mid-week, assuming the rest of life stays on track.
Success factors for the test: solid familiarity with MQTT, a big mix of devices, and comfortable editing YAML (for creating the templates/mappings).
Logic loop? Throttling...
-
Hi Patrick! @toggledbits
I don't remember before version 21277 receiving this kind of message.
This is in the log, this warning appears hundreds of times, every 1 second it repeats.
[latest-21281]2021-10-10T16:13:46.107Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-10T16:13:46.482Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-10T16:13:46.835Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...As you can see, the rule that has generated this warning is run on demand at 10am, where the information is loaded into local variables, and then I use it to send the information by Telegram, only once a day.
I started using this matchEntities() instruction recently when it was made available, and I see you have been making recent adjustments. Wouldn't this situation of continuing to evaluate be related?
I will turn the rule off, so as not to generate this situation that surely damages the functioning of the MSR, and I look forward to your comments please.
Thanks
-
Update to 21281. It would be great if everyone would make sure they are on the latest release before reporting problems.
-
@toggledbits master I am already with version 21281, the error started at 21277.
-
Sigh. Sorry, I'm running fast today... way too fast, much on my plate.
So looking at what you've done... I would not do it this way. Put those expressions in the variables they are meant to manipulate.
Also, your
matchEntities()forBatterySensor, you should not includelevel. That is an attribute of the capabilitybattery_power, and since we're matching capabilities, it won't match anything and creates needless work. You can list capabilities here, but not attributes. All attributes of the capability come with the capability. Same forFaultSensor: removefailed; it's an attribute, not a capability.And please, when posting log snippets, showing me just the error is one line away from showing me nothing. I need to see several dozen lines from before the error for context.
-
@toggledbits master, as you instructed, I believe this is the correct way to do it, and apparently, the error is gone.
Thanks!
-
LOL! OK. Yes, this is better structure-wise. It is much less efficient to use
SetVariableto accomplish what is effectively the same as putting the expressions on the variables as you have now done.I did replicate your prior structure on my system to try it out, but I was unable to replicate the throttling. Nonetheless, I think I understand why it would have happened... and I'm guessing you have significantly more devices on your system than I have on my development system (maybe, I've got about 100 across the four hubs I use for development). I can see why it would throttle, I just could not make it do it. Nonetheless, I'm going to see what I can do about preventing it, based on my assumption about how it happened for you.
Another thing... mentioned in another thread is a small step up you could take in efficiency in
BatteryMSG: you are doinggetEntity()twice on the same ID. You can improve on that by using a temporary variable inside the loop to store thegetEntity()result, and use that temporary variable in the string assembly:join( each id in BatteryLow: do e = getEntity( id ), e.name + " " + int( e.attributes.battery_power.level * 100 ) + "%" done, ', ' )The
do...doneblock looks like a single expression toeach. The result of ado...doneblock is the result of the last expression executed within it. That block contains two expressions, the first being thee = getEntity()which does the lookup and stores the value in a temporary variable, and the second which uses the temporary variable to build the result string for the entity. This saves you the cycles looking up the same entity twice. -
@toggledbits hi my friend!
The warning message has appeared again.
Looking at the log, it is not an error, this message appears several times intermittently, only being interrupted when another action occurs.
[latest-21281]2021-10-12T13:30:35.222Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-12T13:32:10.561Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-12T13:32:10.695Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-12T13:32:11.054Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-12T13:32:12.810Z Rule:INFO Internal Motion (Rule#rule-kpq9tnbr) SET!
[latest-21281]2021-10-12T13:32:22.152Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-12T13:33:15.364Z Rule:INFO Internal Motion (Rule#rule-kpq9tnbr) RESET!
[latest-21281]2021-10-12T13:33:55.112Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-12T13:34:29.630Z Rule:INFO Internal Motion (Rule#rule-kpq9tnbr) SET!
[latest-21281]2021-10-12T13:35:27.808Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-12T13:35:40.960Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-12T13:35:41.809Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-12T13:35:50.185Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...Here is another cut of the log, 45 minutes later the warnings follow.
[latest-21281]2021-10-12T14:16:04.876Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-12T14:16:05.201Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-12T14:16:05.389Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...I will stop the task again, I am concerned, even though a safe warning is consuming MSR processing.
A topic that catches my attention. The action is scheduled to run on my schedule from 8:00am to 8:05am (-5), and because it is a local variable, it should not be updated outside this time, is my understanding.
If it is a global variable, the update is recurrent, because it is active 24 hours, now why is an action with a defined time, and local variable still being executed in a loop?
-
@wmarcolin said in Logic loop? Throttling...:
A topic that catches my attention. The action is scheduled to run on my schedule from 8:00am to 8:05am (-5), and because it is a local variable, it should not be updated outside this time, is my understanding.
That's incorrect. Any changes to a watched device will cause the rule to re-evaluate. The first step in re-evaluating the rule is re-evaluating all of the rule's expressions; only after that are the conditions then evaluated, because the conditions may reference the rule's variables. This is documented behavior. So given that you may be doing a
getEntity()on several dozen, or hundred, devices, you are making that rule subject to re-evaluation any time any of those devices changes, for any reason. Reactor does not "see through" to the attribute you are eventually referring to; it does not and could not (reasonably) do that.To reduce the evaluation rate of the rule, you'd have to make your expressions global. There is (currently) no throttling on the evaluation of global expressions, and they evaluate/update much faster than rules. I suggest you move all of your expressions that perform
getEntity()on the result ofmatchEntities()into global expressions; specifically, I meanBatterySensorwhich creates the battery-operated device array, andBatteryLowwhich checks and evaluates (usinggetEntity()) the battery level of each matching device inBatterySensor, andBatteryMSGwhich builds the text fromBatteryLow. You can then use an Expression Value condition in your rule to check the value ofBatteryMSGfor a non-empty string. This will be the most efficient setup for the potentially large number of devices these expressions have to sift through.The same method should be applied to
FaultSensorand its progeny.I would also update to 21286.
-
@toggledbits ok master, I will download version 21286, move these expressions to global variables, and come back tomorrow after operating 24 hours with the changes.
I really worry about not having actions that are exhaustively generating processing.
-
When you train a rule or expression on a large number of devices, you're going to get activity when those devices change, and that can be a lot. There's more activity than you know, normally. Not everything gets logged at the default level. 21286 does contain a bit more logging.
-
@toggledbits your suggestion worked perfectly!!
With the version updated to 21286, moving all rules to the Global variable, the warnings ended, and I can see in the log that the action started to be invoked only at the given times, and the variable update as Global occurs only when there is an effective change in the device.
Great knowledge exercise and one more lesson from you.
Thanks @toggledbits !
-
Locked by toggledbits