-
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!
OW-SERVER: 1-Wire to Ethernet Server - MSR Functionality
-
Could the temperature values be pulled into MSR from one of these devices: OW-SERVER: 1-Wire to Ethernet Server
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.
-
@talisker They mention that their web interface uses "AJAX techniques" to update the page dynamically, which suggests there is an HTTP API (they don't say explicitly; it may just be undocumented but could be reverse engineered/guessed). So it seems possible, but you should get some detailed developer documentation out of them before purchase. If it has an HTTP API, you can get what you need through HTTP queries.
I've pondered doing an SNMP interface, but in a year of development you're the first person (I believe) to suggest a device for which SNMP would be a useful comms protocol. It's on my idea list, but not on my schedule.
-
You can do it a lot cheaper using ESP32 board and mqtt.
-
ESP32 With MQTT- Publish DS18B20 Temperature Readings
This tutorial, is to learn how to interface the DS18B20 temperature sensor with ESP32 board and publishing the temperature data on MQTT server using Node-RED....
-
@rogero thanks for the suggestion. Once upon a time I'd have had a go. I am also a little reluctant to dive into mqtt due to me never seeming to have enough time. However one of these days I might make the plunge.
-
@talisker if you use Tasmota, there's also an HTTP API you could call. That's true for ESPHome or Shelly as well.
Right now all my stuff is running thru MQTT (on my own homemade broker) and honestly, it's just fire and forget after the initial setup. MSR can also map MQTT entities quite easily.
-
Which hub are you using? 1-wire is almost plug and play with Home Assistant on a rpi.
-
@rogero I have an old windows xp laptop running a programme called LogTemp. Been running for years and it FTPs a jpg graph and an xml file to a website but my plan is to pull the dozen or so temps into vera or MSR so I can ditch the laptop.
-
In that case my suggestion for the ESP32 board seems easiest. Haven't been following the MQTT to MSR integration that Patrick is building, but I assume you could just publish the readings from the ESP32 to MSR directly. The ESP32 is about $10 and the google has lot's of examples of code.
-
My ESP32 board arrives today and I will be doing something very similar to what you are looking for. Will let you know how it goes. I have been using DS18B20's in RPI's for quite a while so this is first foray into ESP boards.
-
Just looked at Patrick's MQTT add on and it requires an external MQTT broker, so not quite plug and play.
-
There's a plugin for the OW-server that works great. Been using it for years.
-
@rogero Your experience would be very interesting to hear about. Is the ESP board limited to a specific number of one wire devices?
-
This post is deleted! -
@a-lurker Does the Plugin work in U17?
-
@talisker said in OW-SERVER: 1-Wire to Ethernet Server - MSR Functionality:
@a-lurker Does the Plugin work in U17?
Pretty sure it does - I'm using the plugin under openLuup but I used to have it running on a Vera.
-
@a-lurker I took the plunge and purchased an OW server (Ethernet). The system is up an running with my one wire connected devices. I am however having a little problem with the OWServer Vera app on my Vera Plus. On the face of it the app is working and picking up the one wire devices:
However, when I go into the 'Add Devices' menu there are none of the sensors shown - the page is blank:
I did a bit of googling and found the following information: https://github.com/dbemowsk/OW-SERVER_Emulator
I did try uploading the J_OWServer.js file as @dbemowsk suggested, but it did not solve the problem I have with vera not showing the one wire devices. I have no idea what he is explaining is the problem with the original files from the app store.
I appreciate that you don't have a Vera Plus, but if you could make any suggestions as to what to try I'd appreciate any input you can offer!
I guess that unless I get up an running I will need to find another route to pulling the values into MSR.
-
Pretty sure you can get it to work. Use the most recent version of the plugin here. The plugin in the MIOS App Store is well out of date.
Your screen capture can be interpreted as the following - how many devices to you have attached?
Devices: 14 Chn 1 error count: 0 Chn 2 error count: 0 Chn 3 error count: 0 EDS OW server web pageYou need to do a few luup engine restarts to get the child devices to show up.
You can use AltUi to install the plugin from the Alt App Store: see More->AppStore. Not using AltUI? It's highly recommended.
If I remember correctly, all the one wire devices are created automatically on first run of the plugin. So on my dashboard it says "No new devices to add" as they have already been added.
"J_OWServer.js file as @dbemowsk suggested" - this bug has already been resolved in the plugin at the link above, so please use the J_OWServer.js file that comes with the Alt App store plugin.
Many of the plugins in the MIOS App Store are hopelessly out of date - refer to the Alt App store list. for updated versions.
All else fails; check the log - once again this can be seen using AltUi -> Misc -> OS Command --> Tail Logs
-
@a-lurker said in OW-SERVER: 1-Wire to Ethernet Server - MSR Functionality:
Pretty sure you can get it to work. Use the most recent version of the plugin here. The plugin in the MIOS App Store is well out of date.
Noted. I rolled back to my vera backup prior to my attempts yesterday. I then downloaded the files from the github link and loaded into my vera.
I had to set up the OW Server device manually (troubles with ALTUI - see below).Your screen capture can be interpreted as the following - how many devices to you have attached?
Devices: 14 Chn 1 error count: 0 Chn 2 error count: 0 Chn 3 error count: 0 EDS OW server web pageI get the following now:
You can see that it does not show the three channels now, but it confirms that I have fourteen devices (which is correct).
You need to do a few luup engine restarts to get the child devices to show up.
I have done numerous Luup engine restarts, but the devices still do not show up in 'Add Devices'.
You can use AltUi to install the plugin from the Alt App Store: see More->AppStore. Not using AltUI? It's highly recommended.
I did install ALTUI, but I was not able to install OW-Server using it. The first time I pressed the install button it thought about it for a few seconds but did not install the OW Server device. Now when I press it I get an error:
If I remember correctly, all the one wire devices are created automatically on first run of the plugin. So on my dashboard it says "No new devices to add" as they have already been added.
The have not been created, possibly because there is an error.....
"J_OWServer.js file as @dbemowsk suggested" - this bug has already been resolved in the plugin at the link above, so please use the J_OWServer.js file that comes with the Alt App store plugin.
Many of the plugins in the MIOS App Store are hopelessly out of date - refer to the Alt App store list. for updated versions.
All else fails; check the log - once again this can be seen using AltUi -> Misc -> OS Command --> Tail Logs
I get the following error in the Alturi app (similar in the vera UI) and Vera log:
You can see from the vera log (http://192.168.68.103/cgi-bin/cmh/log.sh?Device=LuaUPnP) the requisite jasn.lua library file cannot be found. Now I am hoping this is all I need (deposited in the right place in vera) to get the OW Server device up an running. So, where do I get this file and where do I put it (please be polite!!).![768cd707-8727-4ce9-a06e-717661411e31-image.png]
-
Looking at the log it says its missing json.lua. This message tells me you are still running the old plugin from the MIOS store.
Not sure what hardware you are using? The old Vera 3 can't access the Alt App store as the comms library is too antiquated. Regardless you can just download the files from GitHub and overwrite the mios ones. Use the Vera user interface (ie not directly with SSH) as Vera compresses the files when you upload them via the UI. In Vera 3 they end up in etc\cmh-ludl as "lzo" files
The latest version of the plugin looks for ten different possibly available json libraries - see this GitHub link.
If you look in (a Vera 3) /usr/lib/lua you may find dkjson.lua, which in this case is a sym link to /mios/usr/lib/lua/dkjson.lua
You can use the command in AltUI --> Misc --> OsCommand -->Find Json to see what might be available to you. Note that this search doesn't always find what's available. But I would expect dkjson.lua is available and will be found and used by the latest version of the plugin.
