I installed a new iblind this evening and it is appearing in ZWaveJS. It is operational thru Home Assistant just fine. It is operational thru the HA ZwaveJS plugin just fine.
Where it is non-responsive is in MSR for some reason. The entities are there. Adding the node to a Reaction and then attempting to run said Reaction nets me this:
[latest-23242]2023-09-08T05:33:08.454Z <ZWaveJSController:5:ZWaveJSController.js:655> ZWaveJSController#zwavejs _apply_value motion_sensor.state=false [latest-23242]2023-09-08T05:33:08.455Z <ZWaveJSController:5:ZWaveJSController.js:722> ZWaveJSController#zwavejs setting Binary Sensor#zwavejs>11-0.x_zwave_values.Binary_Sensor_Motion to false [latest-23242]2023-09-08T05:33:08.692Z <ZWaveJSController:5:ZWaveJSController.js:360> ZWaveJSController#zwavejs handling node event statistics updated entity Binary Sensor#zwavejs>11-0 [latest-23242]2023-09-08T05:40:23.960Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs performing cover.open on Cover#zwavejs>20-0 with [Object]{ } [latest-23242]2023-09-08T05:40:23.962Z <ZWaveJSController:5:ZWaveJSController.js:1843> ZWaveJSController#zwavejs no implementation mapped; attempting default [latest-23242]2023-09-08T05:40:25.062Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs performing zwave_device.refresh on Cover#zwavejs>20-0 with [Object]{ } **[latest-23242]2023-09-08T05:40:25.063Z <ZWaveJSController:5:ZWaveJSController.js:1843> ZWaveJSController#zwavejs no implementation mapped; attempting default** [latest-23242]2023-09-08T05:40:25.065Z <ZWaveJSController:5:ZWaveJSController.js:294> ZWaveJSController#zwavejs sending #1694151625064<9/8/2023, 1:40:25 AM>: [Object]{ "command": "node.refresh_values", "nodeId": 20, "messageId": 1694151625064 } [latest-23242]2023-09-08T05:40:26.307Z <ZWaveJSController:5:ZWaveJSController.js:360> ZWaveJSController#zwavejs handling node event statistics updated entity Cover#zwavejs>20-0 [latest-23242]2023-09-08T05:40:26.317Z <ZWaveJSController:5:ZWaveJSController.js:360> ZWaveJSController#zwavejs handling node event value updated entity Cover#zwavejs>20-0 [latest-23242]2023-09-08T05:40:26.318Z <ZWaveJSController:5:ZWaveJSController.js:667> ZWaveJSController#zwavejs update node 20 value "0:128:level:" data [Object]{ "source": "node", "event": "value updated", "nodeId": 20, "args": { "commandClassName": "Battery", "commandClass": 128, "property": "level", "endpoint": 0, "newValue": 100, "prevValue": 100, "propertyName": "level" } } [latest-23242]2023-09-08T05:40:26.319Z <ZWaveJSController:5:ZWaveJSController.js:684> ZWaveJSController#zwavejs updating attributes for node 20 value "0:128:level:"=100: [Array][ "battery_power.level", "battery_power.since" ] [latest-23242]2023-09-08T05:40:26.320Z <ZWaveJSController:5:ZWaveJSController.js:698> ZWaveJSController#zwavejs updating attribute battery_power.level with [Object]{ "entity": "20-0", "impl": { "expr": "float( value ) / 100", "valueId": "128:level:" } } [latest-23242]2023-09-08T05:40:26.321Z <ZWaveJSController:5:ZWaveJSController.js:591> ZWaveJSController#zwavejs _apply_value entity Cover#zwavejs>20-0 battery_power.level [latest-23242]2023-09-08T05:40:26.322Z <ZWaveJSController:5:ZWaveJSController.js:655> ZWaveJSController#zwavejs _apply_value battery_power.level=1 [latest-23242]2023-09-08T05:40:26.323Z <ZWaveJSController:5:ZWaveJSController.js:698> ZWaveJSController#zwavejs updating attribute battery_power.since with [Object]{ "entity": "20-0", "impl": { "expr": "time()", "valueId": "128:level:" } } [latest-23242]2023-09-08T05:40:26.323Z <ZWaveJSController:5:ZWaveJSController.js:591> ZWaveJSController#zwavejs _apply_value entity Cover#zwavejs>20-0 battery_power.since [latest-23242]2023-09-08T05:40:26.324Z <ZWaveJSController:5:ZWaveJSController.js:655> ZWaveJSController#zwavejs _apply_value battery_power.since=1694151626324<9/8/2023, 1:40:26 AM> [latest-23242]2023-09-08T05:40:26.325Z <ZWaveJSController:5:ZWaveJSController.js:722> ZWaveJSController#zwavejs setting Cover#zwavejs>20-0.x_zwave_values.Battery_level to 100 [latest-23242]2023-09-08T05:40:26.333Z <ZWaveJSController:5:ZWaveJSController.js:360> ZWaveJSController#zwavejs handling node event value updated entity Cover#zwavejs>20-0 [latest-23242]2023-09-08T05:40:26.334Z <ZWaveJSController:5:ZWaveJSController.js:667> ZWaveJSController#zwavejs update node 20 value "0:128:isLow:" data [Object]{ "source": "node", "event": "value updated", "nodeId": 20, "args": { "commandClassName": "Battery", "commandClass": 128, "property": "isLow", "endpoint": 0, "newValue": false, "prevValue": false, "propertyName": "isLow" } } [latest-23242]2023-09-08T05:40:26.336Z <ZWaveJSController:5:ZWaveJSController.js:324> ZWaveJSController#zwavejs request 1694151625064<9/8/2023, 1:40:25 AM> (node.refresh_values) success notification [latest-23242]2023-09-08T05:40:26.337Z <ZWaveJSController:5:ZWaveJSController.js:684> ZWaveJSController#zwavejs updating attributes for node 20 value "0:128:isLow:"=false: [Array][ ] [latest-23242]2023-09-08T05:40:26.338Z <ZWaveJSController:5:ZWaveJSController.js:722> ZWaveJSController#zwavejs setting Cover#zwavejs>20-0.x_zwave_values.Battery_isLow to false [latest-23242]2023-09-08T05:40:26.558Z <ZWaveJSController:5:ZWaveJSController.js:360> ZWaveJSController#zwavejs handling node event statistics updated entity Cover#zwavejs>20-0Please note the highlighted logpart - no other iblind has this. In addition, in MSR>Entities several show as null rather than having a value as the others do.
69631fbc-db4e-4e8d-aa98-10565811cd93-image.png
I tried deleting all Entities associated with this device from MSR and then refreshing ZWaveJS in Home Assistant and restarting MSR - the Entities return but in the same state/s.
Admittedly, it's been a very long three weeks at work - I could have missed something obvious during setup but I sure can't figure what it is.
Hi @toggledbits
I'm trying to use OWM, apparently, I receive the correct information, but after a while, the MSR disconnects.
My configuration is as follows.
- id: weather enabled: true implementation: OWMWeatherController name: OWM Weather config: # Place your OWM API key here (remember to enable the controller after adding your appid) appid: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" # How often weather is allowed to be refreshed. This helps limit OWN API use, # to keep you in their good graces (and on their free tier). This value is # in minutes. interval: 30 locations: - id: home name: Home Weather # Set the location by specifying ONE OF: latitude+longitude, OWN city # ID, or location (as postal,country). If none is set, the system # location will be used. latitude: 8.9936 longitude: -79.5197 city_id: 3703443 #location: "30269,us" # Enable "save_full_response" to save the full response (you may have # need to use parts of the response that are not part of the wx # capability in your dashboard widgets). #save_full_response: falseWhen I request a systemctl status reactor I get this message:
root@main:/home/wilson/reactor/logs# systemctl status reactor ● reactor.service - Multi System Reactor Loaded: loaded (/etc/systemd/system/reactor.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2023-09-08 21:03:13 EST; 5s ago Main PID: 194711 (node) Tasks: 11 (limit: 9390) Memory: 82.5M CPU: 2.508s CGroup: /system.slice/reactor.service └─194711 /usr/bin/node app -p Sep 08 21:03:13 main node[194711]: Error: Incompatible serialization data; can't unserialize Sep 08 21:03:13 main node[194711]: at System.unserialize (/home/wilson/reactor/server/lib/Entity.js:624:19) Sep 08 21:03:13 main node[194711]: at /home/wilson/reactor/server/lib/Controller.js:458:70 Sep 08 21:03:13 main node[194711]: at Array.forEach (<anonymous>) Sep 08 21:03:13 main node[194711]: at OWMWeatherController._restoreEntities (/home/wilson/reactor/server/lib/Controller.js:446:36) Sep 08 21:03:13 main node[194711]: at new Controller (/home/wilson/reactor/server/lib/Controller.js:37:45) Sep 08 21:03:13 main node[194711]: at new OWMWeatherController (/home/wilson/reactor/server/lib/OWMWeatherController.js:327:9) Sep 08 21:03:13 main node[194711]: at /home/wilson/reactor/server/lib/Controller.js:93:37 Sep 08 21:03:13 main node[194711]: [latest-23242]2023-09-09T02:03:13.855Z <NUTController:null> Module NUTController v22305 Sep 08 21:03:13 main node[194711]: [latest-23242]2023-09-09T02:03:13.859Z <SystemController:null> Module SystemController v23214 root@main:/home/wilson/reactor/logs# root@main:/home/wilson/reactor# systemctl status reactor ● reactor.service - Multi System Reactor Loaded: loaded (/etc/systemd/system/reactor.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2023-09-08 20:48:36 EST; 2min 58s ago Main PID: 194353 (node) Tasks: 11 (limit: 9390) Memory: 66.0M CPU: 9.493s CGroup: /system.slice/reactor.service └─194353 /usr/bin/node app -p Sep 08 20:48:37 main node[194353]: at System.unserialize (/home/wilson/reactor/server/lib/Entity.js:624:19) Sep 08 20:48:37 main node[194353]: at /home/wilson/reactor/server/lib/Controller.js:458:70 Sep 08 20:48:37 main node[194353]: at Array.forEach (<anonymous>) Sep 08 20:48:37 main node[194353]: at OWMWeatherController._restoreEntities (/home/wilson/reactor/server/lib/Controller.js:446:36) Sep 08 20:48:37 main node[194353]: at new Controller (/home/wilson/reactor/server/lib/Controller.js:37:45) Sep 08 20:48:37 main node[194353]: at new OWMWeatherController (/home/wilson/reactor/server/lib/OWMWeatherController.js:327:9) Sep 08 20:48:37 main node[194353]: at /home/wilson/reactor/server/lib/Controller.js:93:37 Sep 08 20:48:37 main node[194353]: [latest-23242]2023-09-09T01:48:37.017Z <NUTController:null> Module NUTController v22305 Sep 08 20:48:37 main node[194353]: [latest-23242]2023-09-09T01:48:37.024Z <SystemController:null> Module SystemController v23214 Sep 08 20:48:37 main node[194353]: [latest-23242]2023-09-09T01:48:37.475Z <Timer:null> Timer#rule-l7ujwva5 just a note: I'm setting a delay of > lines 1-20/20 (END)I can see this information in the log, but I don't understand what I should do to fix it.
[latest-23242]2023-09-09T02:03:13.838Z <DynamicGroupController:null> Module DynamicGroupController v22313 [latest-23242]2023-09-09T02:03:13.845Z <Structure:INFO> Structure#1 loading controller interface weather (OWMWeatherController) [latest-23242]2023-09-09T02:03:13.847Z <OWMWeatherController:null> Module OWMWeatherController v22294 [latest-23242]2023-09-09T02:03:13.850Z <Controller:WARN> OWMWeatherController#weather failed (1) to restore entity controller_all: [Error] Inco> [latest-23242]2023-09-09T02:03:13.850Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Group.unserialize (/home/wilson/reactor/server/lib/Entity.js:624:19) at /home/wilson/reactor/server/lib/Controller.js:458:70 at Array.forEach (<anonymous>) at OWMWeatherController._restoreEntities (/home/wilson/reactor/server/lib/Controller.js:446:36) at new Controller (/home/wilson/reactor/server/lib/Controller.js:37:45) at new OWMWeatherController (/home/wilson/reactor/server/lib/OWMWeatherController.js:327:9) at /home/wilson/reactor/server/lib/Controller.js:93:37 [latest-23242]2023-09-09T02:03:13.851Z <Controller:WARN> OWMWeatherController#weather failed (1) to restore entity default: [Error] Incompatibl> [latest-23242]2023-09-09T02:03:13.851Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at Entity.unserialize (/home/wilson/reactor/server/lib/Entity.js:624:19) at /home/wilson/reactor/server/lib/Controller.js:458:70 at Array.forEach (<anonymous>) at OWMWeatherController._restoreEntities (/home/wilson/reactor/server/lib/Controller.js:446:36) at new Controller (/home/wilson/reactor/server/lib/Controller.js:37:45) at new OWMWeatherController (/home/wilson/reactor/server/lib/OWMWeatherController.js:327:9) at /home/wilson/reactor/server/lib/Controller.js:93:37 [latest-23242]2023-09-09T02:03:13.852Z <Controller:WARN> OWMWeatherController#weather failed (1) to restore entity system: [Error] Incompatible> [latest-23242]2023-09-09T02:03:13.852Z <Controller:CRIT> Error: Incompatible serialization data; can't unserialize [-] Error: Incompatible serialization data; can't unserialize at System.unserialize (/home/wilson/reactor/server/lib/Entity.js:624:19) at /home/wilson/reactor/server/lib/Controller.js:458:70 at Array.forEach (<anonymous>) at OWMWeatherController._restoreEntities (/home/wilson/reactor/server/lib/Controller.js:446:36) at new Controller (/home/wilson/reactor/server/lib/Controller.js:37:45) at new OWMWeatherController (/home/wilson/reactor/server/lib/OWMWeatherController.js:327:9) at /home/wilson/reactor/server/lib/Controller.js:93:37 [latest-23242]2023-09-09T02:03:13.853Z <Structure:INFO> Structure#1 loading controller interface nut (NUTController) [latest-23242]2023-09-09T02:03:13.855Z <NUTController:null> Module NUTController v22305 [latest-23242]2023-09-09T02:03:13.855Z <Controller:INFO> Loaded NUTController version "0.1.22305"; Patrick Rigney/Kedron Holdings LLC <patrick@> [latest-23242]2023-09-09T02:03:13.857Z <Structure:INFO> Structure#1 loading controller interface reactor_system (SystemController) [And finally, I have a second house, with the same OWM configuration I made today, and it doesn't show any errors.
Please, your traditional help.
Thanks.
After a prolonged power cut, the UPS was unable to cope with the weather and shut down the entire system.
When I returned, I had the problem that the host time displayed in the browser and automatically used in the rules was not correct.
I searched for a topic here on this forum that talked about it, but it referred to a container installation. There was a recommendation to go into the storage/states directory and delete the files and restart MSR, I did it and it didn't solve the problem.
There was also a recommendation to go directly to the browser to check the time, and I did so and I see that the time is correct.
8ad429c8-ea5f-45b4-8670-7d0353a50a0e-image.png
As you can see on the screen above:
MSR browser shows the correct browser time 21:23, but host time 13:02; In the browser below the direct query and the host time is correct 9:22:54 PM; Setting the VM date command on the third screen, the time is 9:23:00 PM.I've opened the entire reactor.log file and searched for any errors, and there aren't any.
^L [latest-23242]2023-09-15T02:11:12.928Z <app:null> Reactor build latest-23242-5ee8e1d4 starting on v18.12.0 [latest-23242]2023-09-15T02:11:12.929Z <app:null> Process ID 1807 user/group 1000/1000; bare-metal; platform linux/x64 #179-Ubuntu SMP Mo> [latest-23242]2023-09-15T02:11:12.929Z <app:null> Basedir /home/leonardo/reactor; data in /home/leonardo/reactor/storage [latest-23242]2023-09-15T02:11:12.929Z <app:null> NODE_PATH=/home/leonardo/reactor [latest-23242]2023-09-15T02:11:12.933Z <app:INFO> Configured locale (undefined); selected locale(s) en_US.UTF-8 [latest-23242]2023-09-15T02:11:12.955Z <app:INFO> Loaded locale en-US for en-US [latest-23242]2023-09-15T02:11:12.958Z <Structure:null> Module Structure v23172 [latest-23242]2023-09-15T02:11:12.959Z <Capabilities:null> Module Capabilities v22356 [latest-23242]2023-09-15T02:11:12.969Z <Capabilities:NOTICE> System capabilities loaded from core distribution, data version 23914 revisi> [latest-23242]2023-09-15T02:11:12.978Z <Plugin:null> Module Plugin v22300 [latest-23242]2023-09-15T02:11:12.981Z <TimerBroker:null> Module TimerBroker v22283 [latest-23242]2023-09-15T02:11:12.983Z <Entity:null> Module Entity v22353 [latest-23242]2023-09-15T02:11:12.986Z <Controller:null> Module Controller v23069 [latest-23242]2023-09-15T02:11:12.992Z <default:null> Module Ruleset v22293 [latest-23242]2023-09-15T02:11:12.992Z <default:null> Module Rulesets v22146 [latest-23242]2023-09-15T02:11:12.996Z <GlobalExpression:null> Module GlobalExpression v23211 [latest-23242]2023-09-15T02:11:13.003Z <Predicate:null> Module Predicate v23093 [latest-23242]2023-09-15T02:11:13.005Z <AlertManager:null> Module AlertManager v22283 [latest-23242]2023-09-15T02:11:13.007Z <Rule:null> Module Rule v23107 [latest-23242]2023-09-15T02:11:13.009Z <GlobalReaction:null> Module GlobalReaction v22324 [latest-23242]2023-09-15T02:11:13.010Z <Engine:null> Module Engine v23231 [latest-23242]2023-09-15T02:11:13.012Z <httpapi:null> Module httpapi v23058 [latest-23242]2023-09-15T02:11:13.019Z <wsapi:null> Module wsapi v23172 [latest-23242]2023-09-15T02:11:13.019Z <app:NOTICE> Starting Structure...As you can see, the time in the log is 02:11, which is correct, because I'm in time zone -5, which means it's 09:11PM for me.
I've restarted the VM, the computer hosting the VM, and the MSR a few times and the same difference remains. What do you recommend for the next step in understanding and solving the problem?
Thanks.
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.Good afternoon,
I'm running my MSR instance on an old NAS server running Fedora 37 Server. This is an older Core i5-4690K server that has served me well overall, but it's showing it's age, and will often reboot into maint mode if it applies updates overnight. I've been trying to troubleshoot, but it's also in my office (makes my office hot), and I'm looking at getting either a QNAP or Syslogy rack mount NAS to replace it.
What I'm wondering is what the process would be to migrate my current MSR config and move it to a different platform. I have quite a large ruleset that I don't want to have to recreate. I know I can run it in a container on either platform, but I'm not sure how I would migrate all my rules over. Is there one config file that has all of the rules, or could I simply copy my /reactor directory over to a enw platform?
I am also considering moving the MSR instance to a stand alone RPI 4 with a SSD. This way, while I'm migrating all of my files off of my NAS, I'm not loosing Reactor's functionality until I have whichever rack mount NAS I go with up and running, with all of the data migrated.
Thoughts?
Hello,
I've installed MSR in a Docker container on my Synology NAS. I'm able to access my Vera, but I'm having trouble using the Reactor import within the Docker environment. I'm using the Docker terminal, and I've navigated to "/opt/reactor". However, when I try to run the command, it's telling me I'm not in the installation directory, even though I can see the "tools" directory and the "apps.js" file there. I've also tried changing the file permissions, but nothing seems to work. How do you manage this in a Synology Docker container? Do you use the terminal inside Docker, or SSH into the Synology itself? I'm not finding the "/opt/reactor" path, but I see a "/var/reactor" directory, which I placed in my storage folder.
ERROR: This script must only be run from the Reactor app directory.
Maybe I'm missing something, but this appears to be a bug.
I'm troubleshooting a rule to see if one of the system participants is arriving (presence changes from not home to home). I want this arriving state to be less than 5 minutes (300 seconds), to differentiate between being home for a longer period of time, and just getting home.
In the restrictions sections of the Trigger, I set "Condition must be sustained for less than 300 seconds", and I save the trigger.
After I save and exit, I'm looking at the rule, and it's changed itself to x_hass.state == home; for at least 300 secs. I go back into edit the rule, and it in fact shows "at least" from the drop down.
This logic is of course failing and I can't seem to get it to work.
Changed to less than, and saved:
10a57ff9-4d8c-46b3-b594-399ef2a6d320-image.png
Exited:
a81587d6-f0fa-4518-ad00-a9f601f14509-image.png
Back in rule:
b8e27dd2-e6e7-4f93-844e-83e2b11e976d-image.png
I'm running latest-23218-ebab7a1b.
I added the Proximity integration to HA to create automations based on if a person is on vacation or not. The integration creates an entity and its x_hass.state is the distance to the zone you have setup in HA. For some reason MSR sees that value as a string so I am not able to use the<, >, etc operators as a trigger. Is there anyway this could be fixed without needing to convert the string in a local expression?
MSR 23218
HA 2023.8.3
Entity Attributes if needed
x_hass.domain="proximity" x_hass.entity_id="proximity.arman_proximity" x_hass.services=["proximity"] x_hass.state="0" x_hass_attr.dir_of_travel="unknown" x_hass_attr.friendly_name="arman_proximity" x_hass_attr.nearest="Arman’s iPhone" x_hass_attr.unit_of_measurement="km"MSR Version: latest-23218
Running as Docker Container : Docker version 24.0.5, build ced0996
OS: Linux 15BPMSR1 6.1.26-05272-g26c406245a2c #1 SMP PREEMPT_DYNAMIC Thu Apr 27 10:15:40 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
SMTP notifications had been working fine and I am unsure exactly what action(s) stopped it from working.
I have verified that the SMTP server configured in notifications.yml is working properly.
To duplicate the problem I am forcing an SMTP email notification using the set reaction play button, the reactor.log shows the following errors:
[latest-23218]2023-08-21T14:23:22.462Z <wsapi:ERR> [WSAPI]wsapi#1 can't queue reaction rule-lgxmrba4:S: [Error] Engine has not been started [-] [latest-23218]2023-08-21T14:23:22.463Z <wsapi:CRIT> Error: Engine has not been started [-] Error: Engine has not been started at Engine.queueReaction (/opt/reactor/server/lib/Engine.js:1494:46) at WSAPI.clientMessage (/opt/reactor/server/wsapi/wsapi.js:782:64) at WebSocket.<anonymous> (/opt/reactor/server/wsapi/wsapi.js:301:157) at WebSocket.emit (node:events:527:28) at WebSocket.emit (node:domain:475:12) at Receiver.receiverOnMessage (/opt/reactor/node_modules/ws/lib/websocket.js:1068:20) at Receiver.emit (node:events:527:28) at Receiver.emit (node:domain:475:12) at Receiver.dataMessage (/opt/reactor/node_modules/ws/lib/receiver.js:517:14) at Receiver.getData (/opt/reactor/node_modules/ws/lib/receiver.js:435:17)I have tried:
OS level: apt udate and apt upgrade and reboot
docker pull toggledbits/reactor:latest-aarch64 latest-aarch64: Pulling from toggledbits/reactor Digest: sha256:d8a019d457c9fef61f7c3e6908db1f1d0a2d14b6f7c5e9d4fc536c791503d152 Status: Image is up to date for toggledbits/reactor:latest-aarch64 docker.io/toggledbits/reactor:latest-aarch64docker stop reactor
docker start reactor
docker compose down
docker compose up -d
To no avail.
I feel like I'm missing something obvious but can't put my finger on it.
Thank you in advance for any guidance.
-bh
I have a rule that's driving my pool heater to match the solar excess. In the previous iteration, I checked for the status every minute, but I wanted something different and smarter. The logic is basically:
run continuously from 9:15 to 18:15 check for conditions, and if there's solar excess, use the power to turn on the heater, then wait 1 minute to check again turn off the heater, then wait 5 minutes to prevent frequent on/off cyclesI thought that this could be very similar to Reactor-Ex machina's logic, so I crafted a rule that's basically doing the same: an infinite loop from 9:15 to 18:15 that's checking for status and has a delay based on the heater's condition.
All went well, but after a couple of hours, I got this:
Reaction task "49683" failed due to an exception. Please see the log. rule-liy7z3gf:S (Pool-Heater-Solar) step 0: Error: Task has run too much! Runaway?and the rule was reset (and the heater was left on). Is that by design and I should adopt another strategy? What are others doing when they have a state machine?
With the EV charger I did two groups of condition, each triggering every x minutes based on the charger status, but this seems less smarter and very rudimental. Any suggestion is appreciated. Thanks.
I have a Tripp-Lite UPS (https://www.tripplite.com/smartpro-lcd-120v-1500va-900w-line-interactive-ups-avr-tower-lcd-usb-10-outlets~smart1500lcdt) that connected by a USB cable to my computer, reports various power supply and failure information, as shown in the panel below.
b9f0ea34-d654-4b26-b968-4f8cf0a4e0c1-image.png
afa73913-5318-42c6-af9a-02d36e2e6ea1-image.png
The application I installed runs Java and opens the console to send the information.
Has anyone tried to bring the information into the MSR? Or even a VeraPlus?
Thanks.
Hi
I am stuck trying to extract the "SignalLevel" value which is the WIFI Signal Strength off my Foscam via a http request. The request returns this, which isn't Json formatted data I don't think.
<CGI_Result> <result>0</result> <SignalLevel>52</SignalLevel> </CGI_Result>I created a rule that saves the http response into a Global Expression
872f534e-5899-43e4-ade5-f2b8ab54a412-image.png
But I am struggling to work out what is the correct expression code to extract the value?
Can anyone more knowledgeable please help?
Thank you.
Hi
Today in MSR alerts I see 100 alerts saying that the devices on my Ezlo controllers no longer exist.
They do still exist. I checked some of these devices in the Ezlo Online API Tool doing a hub.devices.list query.
I then checked that the ID numbers were the same for the devices and they are the same device ID's still.
So my devices do still exist with the same device ID's it seems.
So not sure why MSR has over 100 alerts saying otherwise.
9d7c4732-40f3-4551-b8d4-e24e0e8dda10-image.png
I then looked in Entities selected my Ezlo Plus controller and it listed all my devices OK I think and nothing looked out of place.
Thanks
I just discovered there is a secret webpage I didn't know about for my Asus Merlin router that when I run it in a browser gives me all the routers current temperatures.
http://192.168.0.1/ajax_coretmp.asp
249c6e47-38ae-4812-b149-da1fd22072cb-image.png
I have to be logged into the router to access it however.
I tried to create an MSR rule with a HTTP request to store all this data in to a local expression.
But it looks like its not passing or accepting the username and password for my router, I tried Basic and Digest.
I just get this back in the local expression in the rule.
(string) "<HTML><HEAD><script>window.top.location.href='/Main_Login.asp';</script>\n</HEAD></HTML>\n"The data returned in the browser looked like this:
curr_coreTmp_wl0_raw = "43°C"; curr_coreTmp_wl0 = (curr_coreTmp_wl0_raw.indexOf("disabled") > 0 ? 0 : curr_coreTmp_wl0_raw.replace("°C", "")); curr_coreTmp_wl1_raw = "49°C"; curr_coreTmp_wl1 = (curr_coreTmp_wl1_raw.indexOf("disabled") > 0 ? 0 : curr_coreTmp_wl1_raw.replace("°C", "")); curr_coreTmp_wl2_raw = "disabled"; curr_coreTmp_wl2 = (curr_coreTmp_wl2_raw.indexOf("disabled") > 0 ? 0 : curr_coreTmp_wl2_raw.replace("°C", "")); curr_coreTmp_wl3_raw = "disabled"; curr_coreTmp_wl3 = (curr_coreTmp_wl3_raw.indexOf("disabled") > 0 ? 0 : curr_coreTmp_wl3_raw.replace("°C", "")); curr_cpuTemp = "66.495"; fanctrl_info = "";I know how to do this for webpages and sites that give back JSON data, however this data I am not sure what format it is, Javascript ? The page is a .asp ajax page.
So not sure if this is possible ?
I really wanted to monitor the CPU temps on my router as its been getting very hot, even with extra USB fans now on the back of it. Think its a firmware bug maybe in the Asus firmware as others have been talking about it online.
Thanks.
So, I've just installed two venetian blinds and I want to control their lamellas with Fibaro FGRM222.
According to the old place, this could be accomplished with some Zwave raw messages and I'm OK with it.
Since I've moved (mostly) everything virtual in MSR, I'm now ready to add a virtual device with actions.
Looking at the docs, it seems possible, but it's not documented. @toggledbits any hints? I want to define a cover and send Zwave commands to the existing x_vera_svc_micasaverde_com_ZWaveNetwork1.SendData action. Thanks.
@toggledbits,
I'm not sure if this is something you've looked into (or something I'm completely missing in the installation documentation), but would it be possible to add user authentication to the MSR frontend? On my Home Assistant instance, I have external access set up using Cloudflare, and I can add other instances within my network to that Cloudflare configuration, but without any sort of authentication to access MSR, I obviously can't open it to the internet, unless I want random people screwing around with my home automation.
I've just updated to 23218 and now I'm getting this:
27a959bd-486b-41ae-8137-c5f456044a82-image.png
There seems to be related to global variables. The first and last ones are global reactions, while the second is a normal one. All are setting global variables.
Hey @toggledbits was wondering if we could have the latest reactor version number as an attribute for the Reactor System entity. It would be useful for me so I can use it for my wget command to automatically download the latest .tar.gz file. Ideally the complete version number like this 23171-85463e02.
@toggledbits ,
I was just taking a look at some of my scheduling to adjust for a new work schedule, and I noticed that the checkboxes for days of the week appear to be off.
75e1b936-1693-4db1-8ed5-ecfae57d3abf-image.png
if you'll notice in the screenshot, Sun - Tuesday are good, but then Sat comes next, then Wed, then Sat again, then Wed again. No TGIF in this week.
I know this isn't how I set up the rules (which would explain the behavior I was investigating).
Edit: BTW, I checked all my Week Day entries, and they are all like this.
I'm running latest-23196-40ef07f4 on Fedora 37 Server w/o Docker.
Category Topic Guide -- Read Before Posting
-
Everyone:
The quality of questions is a common complaint among those of us that provide "support" for things that we build and offer. As evidence of that, I'll direct you to this post over on the Home Assistant community, which apparently itself was inspired by a similar post in the OpenHAB community.
It opens by explaining the obvious: they are volunteers (as am I), the ratio of supported to supporters is high (i.e. there are far more people asking for help than people providing it), everyone's time is valuable, and it's actually disrespectful of people's time to not put up front effort into your questions and structure them in a way that speeds the resolution process along. The common sense of this should be obvious: if you have a problem or question for which you need a fast answer or solution, should you not then give as much information as possible so that the first reply could be the answer, rather than being only the first of what becomes a back-and-forth exchange that could take hours or days to conclude?
So, I am shamelessly plagiarizing the Home Assistant post for my guidelines here, as it is a good summary of both the ubiquitous problem contributors face in these environments, and what is generally needed to make things more manageable and agreeable. I will say, this is a great summary, and it should be applied everywhere you post, not just here. I'm sure everyone here and everywhere reading your posts, not just the contributors, will appreciate it.
Here we go...
Language
I'm opening with this because the Hass post opens with it, but it hasn't been an issue here yet, so simply for the sake of completeness: support here is given in English. Please make your posts in English, if you can. If you can't, please make your post in your preferred language, but start it with a request to the group for a translation; maybe someone can/will help. We'll try web-based translators, too, of course, but technical language is rarely their strong point. This is one of many areas where community help really makes the experience for everyone.
Try Search First
As the product matures and the community becomes increasingly adept with it, it’s increasingly likely that your question has been asked and answered already. If you search the forum, you may find an answer and save yourself a lot of time. It may not be a perfect answer to your question, but it could get you close enough to start.
The forum search here has a tendency to default to "Titles" (as in, search only in post titles), which is a bit restrictive, so remember to expand your search to "Posts," but from there, hopefully, you'll find something useful.
Try to search only for what is the core of your question - the error message text/keywords (without your specific data), component or add-on name, the operation you want to perform, etc.
Try the Documentation
Every version of Reactor has a "Manual" link in the UI's left navigation that will take you to the locally-installed, version-specific documentation. There is also an online version here, but it may document changes and new things that were not available in the version you are using, so be careful there.
Be Up To Date
Before reporting an issue, be on the latest release. If you are not on the latest release, upgrade to it and try again before posting. If you post and are on an earlier release, it's almost guaranteed that the first thing you'll be instructed to do is upgrade to the latest release.
New Topic Guidelines
If you haven't found anything in Search or Documentation, then make a new topic, following these guidelines:
If a search or your casual reading brings you to a topic/post is somehow similar to, but not exactly, your question, it's better to start a new topic and link to the similar in your introduction than it is to post a reply on the topic you found. This is especially true if the topic you found has gone stale and hasn't had a reply in months or years.
A good opening (head) post a new topic will have most, if not all, of the following:
- A concise title;
- Details of runtime environment (Reactor version, platform info);
- If your question is related to a hub/controller, the type of controller and its running software or firmware version information;
- A complete description of your objective;
- A description of your approach/solution/implementation so far (what you did, how it's intended to work), and what isn't meeting expectations;
- Show the work.
Let's look at the details of that:
Title. Having a good topic title is essential. It should summarize your post so that without even opening it people can have a good idea of what it’s about. A good title generally:
- Includes the unique part of the error you’re getting (redact specifics of your system, e.g. device IDs);
- Contains the integration name, condition or action type, etc.;
- Describes the thing you’re having an issue with;
- Is emotionless.
Examples:
- Good: Action runs before delay action completes
- Bad: Timer not working
- Ugly: Problem/Need help
- Good: Hubitat - Not able to perform dimming.set on Zooz switch
- Bad: Can't control Zooz switch
- Ugly: Switch problem
If you’re having a problem writing a good topic title, leave it for last — once you’ve written the whole question, it might be easier to write a summary title for it.
Describe Your Runtime Environment. It doesn't matter if you did it on a post last week, yesterday, or two minutes ago, every post should include a description of your environment, because I don't keep your system configuration in my head, and future readers will need to know. There are too many people and too many details for me to remember those things, anyway. So each post should include:
- What version of Reactor you are using (upper-right corner of UI);
- What OS your Reactor is running on (Ubuntu, Windows, Synology DSM, Raspbian, etc.);
- How you installed/run Reactor: bare metal, Docker, etc.;
- Specifics of any hubs and devices involved (manufacturer, model, software/firmware versionetc.) in the issue.
Example:
Reactor 21308-afecb92a; docker on Synology; Hubitat
orVer 21262; Raspian bare-metal (RPi4); Vera 7.32; Fibaro FGZ-712
Describe the objective, not the problem with your implementation. It’s all too easy to fall into the trap of the XY Problem. If you describe your objective first, then others can understand what you’re trying to achieve. Remember, your objective is not a description of how you're implementing your solution, it's a description of the problem you are trying to solve with your implementation.
- Good: I am trying to get an outdoor light to be on from the day after Thanksgiving through the end of the year.
- Bad: I'm trying to figure out a condition to detect the day after the fourth Thursday in a month.
- Ugly: The date condition in the screen shot below doesn't work.
- Approaching Crime: I tried X and it didn't work (and that's the entire substance of the post).
The first description is (much) better not just because it's concise about timing, but also complete: it lays out the entire problem, not just the one part of it that's giving you trouble right now. Often, good solutions will vary based on the full understanding of the objective (imagine trying to help someone solve the problem of getting fresh air into a large space if they didn't bother to tell you they were building a submarine). It is confusing to other readers and frustrating to helpers when you focus on one step, and when that's resolved, you then add "OK, and now it also needs to...". In the worst case, it can make the entire discussion prior useless.
Show Your Work. Think mathematics class in school: you got no credit for having the right answer if you didn't show how you got there. Worse, if you're sure you have the method correct but you got the wrong answer, nobody could see anything to help you figure out why, including yourself. A big part of the completeness of your response is showing what you've done to try to address it:
- Describe (and show) what you’ve tried, and what the problems were;
- Almost every question about rules or reactions needs to have accompanying screen shot(s) showing the rules and/or reactions you've built; if your description says "I made a rule/reaction that does X", you need to show it; if you say "I tried to do X but it didn't work", you need to show what you tried to do, and you need to explain what you expected, what happened, and how that didn't meet your expectations;
- Check the logs, and post log snippets if you find something you think is relevant;
- Link to some other threads that you’ve found, and tried, and explain why they didn’t help you.
If you haven't tried anything because you're not sure where to begin, the best way to learn is to experiment. Embrace failure, because it's a great learning tool. Remember you are playing with switches and lights, not launch codes for nuclear missiles, so aside from getting "that look" from your spouse, errors are unlikely to have serious consequences.
This also seems a good point for me to offer this: I wrote Reactor as a tool for you to use to solve your automation/logic problems, not as a tool for me to use to solve your automation/logic problems. I am going to increasingly leave logic-only posts that don't involve bugs or specific Reactor operational questions to the community for response. Having me answer every question doesn't improve the ability of the group; that needs to change.
Make good screen shots. If you screen shot your entire display and post it, scaling and downsampling will make it unreadable. If you zoom out your window/browser/screen to get everything in one image it will not be readable. Before taking a screen shot, un-maximize your window and reduce it to a reasonable size, and then screen shot just the window, or better still, grab the relevant rectangle where the action is (but remember, context is important, so be wary of over-cropping — a screen shot of a field with an error flag that doesn't include the condition or action type is probably over-cropped). Do not screen-shot code, log snippets, or formatted text like configs — please use fenced code blocks and paste the real code/data/text (see Format Posts Properly below).
Make good log snippets. When posting logs, always post several dozen lines before anything you find relevant, and a few lines after. Context is important. Think crime scene: it's much easier to determine what happened when a witness describes it than it is to show up to find a dead body on the floor and nobody around. All of the events and messages leading up to the entry that drew your attention may contain vital clues about what was going on to get to that condition. It is also often useful to post (in addition) the startup messages for the most recent restart of Reactor. Do not screen-shot log snippets — post the actual text in a fenced code block (see Format Posts Properly below).
Explain Your Work. It is a nightmare to see posts that contain pages of screen shots of rules and reactions, and yet have no explanation of how they are intended to solve the problem. Do not assume that just because we can read every rule and action, we can understand what that means for your system or how you're thinking about the problem and solution. With your screen shots, provide an explanation of what everything does along the way, why things are done the way they are, and what you think they are intended to do.
Format posts properly. The forums are a tool, and like any tool, you should learn to use it properly if you're going to use it frequently. Learn how to format code, inline and blocks, and use the fenced code block formatting for all code and code-like text (config/YAML, JSON, etc.) and log snippets. Improper formatting can hide errors, or make them more difficult to see. Here's a cheat-sheet for Markdown formatting; it's easy to use fenced code block formatting for code blocks and log snippets.
Redact personal information. Please remember, when posting logs or screen shots, to redact any personal information. This includes serial numbers, API keys, email addresses, lat/long of your home, etc. Remember you are posting this stuff into a public forum, to be captured by search engines and Internet archivers. Forever.
Make sense. Don't let your haste to get your question asked overwhelm good communication. Re-read your post and make sure you've addressed all of the above, and that the post is organized and makes sense. In particular, watch your antecedents. I can't tell you how many "I have two switches but when I turn it on the status doesn't change" posts I've had to straighten out before I can even start guessing what the problem is.
Use (keyword) tags. We're all not using enough keyword tags (full disclosure: I didn't even know they were possible in these forums until recently). Tags can help the search a lot. Common tags may be
zwave
,hass
,hubitat
,conditions
,reactions
,expressions
, etc. Hubs, device types, condition or action types are all good candidates for tags. Don't useMSR
,msr
, orreactor
as a tag unless you are posting outside of the Multi-Hub Reactor category; it isn't necessary. Everyone understands that the Reactor category contains Reactor topics/posts, and search lets you limit its breadth to specific categories, so the extra tags are just redundant. In this forum's software (NodeBB), you can enter tags in the bottom of the composer when writing/editing your topic/head post.Don't tag people/leads in the head post. If you are starting a new topic and writing the opening post for it, and you begin it by tagging me (or whoever the lead(s) is(are) for whatever category), it comes across as bad manners and demanding of an answer. I don't know of any forum in which the category moderators aren't subscribed to their categories (I certainly am), so notifications of new topics go out automatically and such tagging is redundant.
Don't DM product questions. If you have a product question or problem, odds are someone else has or will have the same question/problem at some future date, so having the conversation recorded and searchable in the public forum threads is useful (and respectful of the time invested to help you).
Fix your topic head post. If you are asked to revise your head post because it didn't meet the above guidelines, please edit/correct the head post itself, don't post an add-on reply down below in the thread with the additions or corrections. It's important that the head posts in each topic are high quality and meet these guidelines.
Replies and Discussion
Don't non-answer or distract. If someone asks how to do something in a particular way, unless you are certain that it can't possibly be done the way they are asking, don't reply with an answer that doesn't address the method.
It's sometimes the case that when you feel a need to answer with a different method than OP has inquired about, OP's question/post is posing an X-Y Problem, and in this case, it's likely the post title and description are poor (asking about method rather than goal is a clue), so address that first (e.g. "What is it you are actually trying to accomplish?"). Then you'll have a perfect opportunity to point out different methods.
Don't "Me Too". Don't reply to just say "I'm having this problem too." You can do that if you have additional information to offer that may help in isolating a problem; that's always welcome. But if all you're saying is "me too," that's not really useful and doesn't contribute to the discussion/solution.
Don't use a non-contributing reply as a way to start watching a thread. You may find yourself interested in a thread and want to be notified when there are replies. The bad "Facebook way" is to reply "Following..." (or, again, "me too") in the thread, which makes the forums automatically subscribe you to the thread. It clogs the thread with useless replies. The preferred way is to use the "bell" icon button in the topic header to set a watch on the thread.
Tag people in discussion only when it's relevant to call their attention. Personal tagging can and should be used when mentioning others to thank them for earlier thread responses (i.e. when they are already part of the thread discussion), or add them to the discussion as a link perhaps to another thread on a similar issue going on at the same time, etc. But tagging someone to add them should be considered carefully: consider how welcome that call for attention may be, and how they may feel about the relevance of the discussion or their involvement in it.
Don't hijack or wander. Hijacking or thread-jacking is making a reply that takes the thread off topic. Instead, start a new thread and link to the related thread if there is a relevant connection.
Solved It! When your problem is solved, whether you solved it yourself or someone else did, please mark the head post title
[SOLVED]
. Ideally, also add a link to the end of your head post to the solution post: you can right-click on the date/time of the solution post and choose "Copy Link..." to get the link, and then paste at the end of your head postSolved here: <paste link>
. If you solve your own problem, please make your own post describing what you did (and link to that in the head).DO NOT FLAIL! If I am working with you on troubleshooting/investigation, asking you to try specific things and give me the results, do not start random experiments, change your entire approach to the problem, make changes I didn't direct, delete things, etc. At that point, I am troubleshooting and need you to be my hands and eyes. If I get the impression that you are making a moving target for me to hit, I'll just stop working with you on it. This is such a serious matter for me that repeated instances may affect your future support.
__________________________________
Inspired by this awesome post in the Home Assistant forums, which itself was inspired by this awesome post over in the OpenHAB forums.
Updated 2023-04-03
-
T toggledbits pinned this topic on
-
T toggledbits locked this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on