-
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. -
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
-
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.
-
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).
-
I've recently moved my Nest Thermostats from Vera to Home Assistant, using the official integration. This is a how-to migrate it completely on Home Assistant, thus retaining control and status in your Vera (i.e.: because you have code/scenes/Reactor rules/whatever to maintain - in my case it was all the above and more).
Prerequisite: goto https://github.com/dbochicchio/vera-VirtualDevices and install the virtual heater/thermostats files. Follow instructions, if in doubt.
First, go to your Vera, enter your thermostat Advanced Settings, under Params be sure to remove the plugin, by setting its value to 0. Then
change device_file to D_VirtualThermostat1.xml change impl_file to I_VirtualHeater1.xml change device_json to D_VirtualThermostat1.json change subcategory_num to 1 (if necessary)Repeat for other thermostats - you could use the first as master, so look for the doc for more info on this point. Be sure to remove the plugin from humidity sensors as well.
After the luup reload, hard refresh (CTRL+F5) your browser and then set all these variables to skip (we will not execute actions on setpoint/mode changes, we'll just save variables).
SetPowerURL SetPowerOffURL SetSetpointURLAt this point, the actions to change mode/setpoint will write your desired value to SetpointTarget and ModeTarget variables. We will use them in MSR to get the actions and execute them in Home Assistant.
Under MSR, be sure to write two rules.
One rule is watching for SetpointTarget and ModeTarget variables under the Vera Virtual Thermostat, to execute the actions on your thermostat.f70a6c94-df72-4b89-8d69-0edced1c5440-image.png
You'll need to translate the values from Vera's mode (Off, HeatOn, CoolOn) to HASS one (off, heat, cool). Since this thermostat is heating only, I'm just translating the ones I have. Repeat these steps for every device you have.
Then, you'll need to write a rule looking for temperature, setpoints, mode and so on. I have a unique rule to synchronize all of them, so I'm looking for humidity entity, temperature entity, and thermostat to update the Vera's variable. I have a set of expressions to translate to Vera's friendly variables:
730b32f0-d232-4bc4-9981-26dfaa00d56c-image.png
You'll need to just set the variables like this:
890083b3-ccd6-4039-99cb-1c90d64f00d5-image.pngVariables involved:
Service Variables Value urn:upnp-org:serviceId:TemperatureSensor1 CurrentTemperature ${{temperature}} urn:micasaverde-com:serviceId:HumiditySensor1 CurrentLevel ${{humidity}} urn:upnp-org:serviceId:TemperatureSetpoint1 CurrentSetpoint ${{setpoint}} urn:upnp-org:serviceId:TemperatureSetpoint1_Heat CurrentSetpoint ${{setpoint}} urn:upnp-org:serviceId:TemperatureSetpoint1 SetpointAchieved ${{setpointachieved}} urn:upnp-org:serviceId:TemperatureSetpoint1_Heat SetpointAchieved ${{setpointachieved}} urn:upnp-org:serviceId:HVAC_UserOperatingMode1 ModeStatus ${{modestatus}} urn:micasaverde-com:serviceId:HVAC_OperatingState1 ModeState ${{modestate}} urn:upnp-org:serviceId:HVAC_UserOperatingMode1 EnergyModeStatus ${{energymodestatus}}Just repeat these steps for every thermostat and you should be good to go. It could be adapted for a different mix of devices/systems, of course. I hope this will help someone else achieving the same results! Now we can control the thermostat from both point and everything is in sync!
InfluxDB - is it possible to log expressions as well as entities?
-
The reason for my question is a rather long story involving a virtual thermostat on my Hubitat and using InfluxDB and Grafana to graph the state of the thermostat.
The TL;DR version is that it would be helpful if I could send MSR expressions (variables) to InfluxDB. I don't currently see any way to do that, and if it isn't a current capability of MSR it might be useful as a future enhancement.
Long version: I have a rule in MSR that runs every minute to pull the thermostat information from my thermostat's cloud API. I parse the response into global variables, and then update a Hubitat virtual thermostat when those global variables change. I added the x_hubitat_Thermostat entity, along with selected capabilities, to my reactor.yaml in the InfluxDB section, 'default_capabilities', so the changes to the virtual thermostat get logged into the db.
It's working OK except when the API reports that the temperature has reached the setpoint but the system is still operating. For example, in the morning when the heat is turned up, the temp will climb until the setpoint == the temperature, but the system will continue heating for a while afterwards. It's a variable speed/heat system so it continues to run at very low output for quite a while after the temps match.
The issue I'm having is that when the temperature matches the setpoint, the Hubitat virtual thermostat switches to idle mode on it's own, despite the fact that the API is still reporting heating mode. When the virtual device sees that the setpoint has been reached, it automatically changes to idle, which makes sense as that's how you'd want a real thermostat to work .
I am working around this by having the rule that updates the temperature on the virtual device also update the operatingState. This fixes it, but for just a few milliseconds the virtual thermostat switches to idle before the rule sets it back to heat, and that state change shows up in Grafana.
If I could just directly log changes to the expressions to InfluxDB I could avoid the issue and get the same data into the database. Also I can see other applications for something like this with other APIs where MSR and InfluxDB could be used to log data without having any virtual device entities involved.
-
Not currently possible, but I'll add it to the wish list.