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

log-0905ET.png

The next screenshot is the scheduled run at 0910 ET after the last run set the ruleset to SET

log-0910ET.png

The last screenshot is the rulesets including the new one that is stuck in SET

rulesets.png

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
Reactor is running and i see no ill effects so far
Thought i would report for info.

~/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

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: 0xbe86958c

The logs continued throwing errors with different object IDs.

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

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

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

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

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

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

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?

columns.PNG

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.png

I 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

Hope I am allowed to post this here?

I can't figure out how to correctly show device battery levels from the Vera Plus via MSR in Granfana.

These devices don't have the battery levels that its displaying in Granfana. I've tried messing about with various settings like units and decimals but its still not right.

dc0736f2-3821-436c-97ea-09eddb397346-image.png

Hi @toggledbits,

i tried the ezmqtt today, i have some issues most likely that i'm doing something wrong.

i have on my ezlo hub 3 switches, 1 dimmer and 1 motion sensor

i can control the dimmer via ezmqtt/set/device/<device-id>/item/<item-name>
but i can't control the switches.

i receive on ezmqtt/tele/device/61e8937e124c35129921171d/item/switch payload true or false depending on the state of the switch, but when i send on ezmqtt/set/device/61e8937e124c35129921171d/item/switch payload true or false nothing happens, its the same for all switches.

what i'm doing wrong?

Cheers

Everyone,

As a side project, building on some deep innards borrowed from Reactor, I have released two new projects (unrelated to Reactor). Both are published on npmjs (for installation via npm), and on GitHub.

ezmqtt — a standalone app that acts as a conduit between Ezlo hubs and MQTT. It's published on npmjs.com and on Github. node-red-contrib-ezlo — Node-RED nodes (installable package) for Ezlo hubs. It's published in the Node-RED Nodes Library, at npmjs.com, and on Github

Why? Because choices are a good thing.

There are docker containers available for ezmqtt, but I haven't finished the work there, so they may not be quite ready for prime time; but feel free to test/play if you want.

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 quotes

However 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