I'm running MSR build 25139 on Docker, using MQTT controller 24293, and everything working as expected. But if I try to upgrade to MQTTController build 25139, I'm getting the following errors on MSR UI:
An Entity Attribute condition in "Lay-Z-Spa auto heating off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.god
Last 11:20:37
An Entity Attribute condition in "Lay-Z-Spa auto heating off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute temperature_sensor.green
Last 11:20:37
An Entity Attribute condition in "Lay-Z-Spa filter pump auto off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute temperature_sensor.red
Last 11:20:37
An Entity Attribute condition in "Lay-Z-Spa filter pump auto run" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.pump
Last 11:20:37
An Entity Attribute condition in "Lay-Z-Spa watchdog" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.status
Last 11:20:37
My MQTT configuration (local_mqtt_devices.yaml) for the related entity is:
layzspa_message:
type: ValueSensor
capabilities: ["temperature_sensor", "value_sensor", "power_sensor"]
primary_attribute: power_sensor.value
events:
"layzspa/message":
"power_sensor.value":
json_payload: true
if_expr: '! isnull( payload?.PWR )'
expr: "float(payload.PWR)"
"value_sensor.air":
json_payload: true
if_expr: '! isnull( payload?.AIR )'
expr: "float(payload.AIR)"
"value_sensor.pump":
json_payload: true
if_expr: '! isnull( payload?.FLT )'
expr: "float(payload.FLT)"
"value_sensor.god":
json_payload: true
if_expr: '! isnull( payload?.GOD )'
expr: "float(payload.GOD)"
"value_sensor.lock":
json_payload: true
if_expr: '! isnull( payload?.LCK )'
expr: "float(payload.LCK)"
"value_sensor.unit":
json_payload: true
if_expr: '! isnull( payload?.UNT )'
expr: "float(payload.UNT)"
"value_sensor.error":
json_payload: true
if_expr: '! isnull( payload?.ERR )'
expr: "float(payload.ERR)"
"temperature_sensor.green":
json_payload: true
if_expr: '! isnull( payload?.GRN )'
expr: "float(payload.GRN)"
"temperature_sensor.red":
json_payload: true
if_expr: '! isnull( payload?.RED )'
expr: "float(payload.RED)"
"temperature_sensor.target":
json_payload: true
if_expr: '! isnull( payload?.TGT )'
expr: "float(payload.TGT)"
"temperature_sensor.value":
json_payload: true
if_expr: '! isnull( payload?.TMP )'
expr: "float(payload.TMP)"
"temperature_sensor.virtual":
json_payload: true
if_expr: '! isnull( payload?.VTM )'
expr: "round(float(payload.VTM), 1)"
"temperature_sensor.ambient":
json_payload: true
if_expr: '! isnull( payload?.AMB )'
expr: "float(payload.AMB)"
"layzspa/Status":
"value_sensor.status":
if_expr: '! isnull( payload )'
expr: "payload"
"layzspa/button":
"value_sensor.button":
if_expr: '! isnull( payload )'
expr: "payload"
and in reactor.yaml I have:
"layzspa_states":
name: "Lay-Z-Spa States"
friendly_name: 'Lay-Z-Spa States'
include: layzspa_message
I realize my MQTT configuration might be a bit unorthodox, but could there still be something unintentional in the latest MQTTController build? If needed, I can provide detailed logs.
Since today is my birthday - and I still pretend to be unconventional - I'm giving away a present to this wonderful community and I'm releasing my first OpenSprinkler controller for MSR. It was real fun to code it - and while it's still WIP, it seems to work OK for me. It's polling-based at the moment, but I'll add support for updates via MQTT very soon (it's already partially coded).
Get it at (install is similar to MQTTController and such):
https://github.com/dbochicchio/reactor-opensprinkler
Feel free to try it. It's beta software, but it's stable. I'll update it weekly until all the tasks from my todo list are empty.
Since I've learnt a lot from this controller, I'll explore new controllers soon.
Good day all,
I'm in the process of trying to shut down my 10 year old Linux home server that served many purposes, but primarily it's what I used for my NAS/Plex Media server. I migrated the NAS aspect of the server in November of last year to a true NAS solution (Ubiquti UNAS Pro), which is rack mount and much more efficient than my old tower, which it's only side benefit was heating my home office during the winter. Unfortunately it also means heating my home office during the summer, which were about to be in full swing.
I have two things running on this 10 year old server at this point. MSR and pi-hole. I'm running Plex Media Server on Fedora Workstation in Podman on mini PC, which is much more energy efficient than my old tower. My next step is to migrate MSR. I know there are images of MSR out there, and creating it is well documented. I'm going to be using Podman instead of Docker for various reasons, but they work very similar. What I don't know, is what I need to do to migrate my existing Bare Metal installation over to a container.
Has anyone done this? Any advice?
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here.
Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions;
Fix an error in OWMWeatherController that could cause it to stop updating;
Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later;
Improve error detail in messages for EzloController during auth phase;
Add isRuleSet() and isRuleEnabled() functions to expressions extensions;
Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases);
Fix a place in the UI where 24-hour time was not being displayed.
Hi guys,
Just wondering how you guys organize your rule sets and rules. I wish I had an extra layer to have some more granularity, but my feature request was not popular.
Maybe there are better ways to organize my rule sets.
I use the rule sets now primarily for rooms. So a rule set per room. But maybe grouping by functionality works better. Any examples/ suggestions would be appreciated.
I have the following yaml configuration in local_mqtt_devices file
x_mqtt_device:
set_speed:
arguments:
speed:
type: str
topic: "command/%friendly_name%"
payload:
type: json
expr: '{ "fan": parameters.speed }'
While this works fine, I'm wondering how this could be changed to "fixed" parameters, as in this case "fan" only accepts "A", "Q" or a numeric value of 1-5?
Hi!
I get this message when I'm on the status tab:
System Configuration Check
The time on this system and on the Reactor host are significantly different. This may be due to incorrect system configuration on either or both. Please check the configuration of both systems. The host reports 2025-04-01T15:29:29.252Z; browser reports 2025-04-01T15:29:40.528Z; difference 11.276 seconds.
I have MSR installed as a docker on my Home Assistant Blue / Hardkernel ODROID-N2/N2+. MSR version is latest-25082-3c348de6.
HA versions are:
Core 2025.3.4
Supervisor 2025.03.4
Operating System 15.1
I have restarted HA as well as MSR multiple times. This message didn´t show two weeks ago. Don´t know if it have anything to do with the latest MSR version.
Do anyone know what I can try?
Thanks in advance!
Let's Be Careful Out There (Hill Street reference...)
/Fanan
I have a very strange situation, where if InfluxDB restarts, other containers may fail when restarting at the same time (under not easy to understand circumstances), and InfluxDB remains unreachable (and these containers crashes). I need to reboot these containers in an exact order, after rebooting InfluxDB.
While I understand what's going on, I need a way to reliable determine that InfluxDB is not reachable and these containers are not reachable, in order to identify this situation and manually check what's going on - and, maybe, in the future, automatically restart them if needed.
So, I was looking at HTTP Request action, but I need to capture the HTTP response code, instead of the response (becase if ping is OK, InfluxDB will reply with a 204), and, potentially, a way to programmatically detect that it's failing to get the response.
While I could write a custom HTTP controller for this or a custom HTTP virtual device, I was wondering if this is somewhat on you roadmap @toggledbits
Thanks!
Hi ,
I'm on
-Reactor (Multi-hub) latest-25067-62e21a2d
-Docker on Synology NAS
-ZWaveJSUI 9.31.0.6c80945
Problem with ZwaveJSUI:
When I try to change color to a bulb RGBWW, it doesn't change to the RGB color and the bulb remains warm or cold white.
I tryed with Zipato RGBW Bulb V2 RGBWE2, Hank Bulb HKZW-RGB01, Aentec 6 A-ZWA002, so seems that it happens with all RGBWW bulb with reactor/zwavejsui.
I'm using from reator the entity action: "rgb_color.set" and "rgb_color.set_rgb".
After I send the reactor command, It changes in zwavejsui the rgb settings but doesn't put the white channel to "0", so the prevalent channel remains warm/cold White and the bulb doesn't change into the rgb color.
This is the status of the bulb in zwavejsui after "rgb_color.set" (235,33,33,) and the bulb is still warmWhite.
x_zwave_values.Color_Switch_currentColor={"warmWhite":204,"coldWhite":0,"red":235,"green":33,"blue":33}
The "cold white" and "warm white" settings interfer with the rgb color settings.
Reactor can change bulb colors with rgb_color set — (value, ui8, 0x000000 to 0xffffff) or rgb_color set_rgb — (red, green, blue, all ui1, 0 to 255) but if warm or cold white
are not to "0", zwavejsui doesn't change them and I can't find a way to change into rgb or from rgb back to warm white.
So if I use from reactor: rgb_color set_rgb — (235,33,33) in zwavejsui I have
x_zwave_values.Color_Switch_targetColor={"red":235,"green":33,"blue":33}
14/03/2025, 16:43:57 - value updated
Arg 0:
└─commandClassName: Color Switch
└─commandClass: 51
└─property: targetColor
└─endpoint: 0
└─newValue
└──red: 235
└──green: 33
└──blue: 33
└─prevValue
└──red: 235
└──green: 33
└──blue: 33
└─propertyName: targetColor
14/03/2025, 16:43:57 - value updated
Arg 0:
└─commandClassName: Color Switch
└─commandClass: 51
└─property: currentColor
└─endpoint: 0
└─newValue
└──warmWhite: 204
└──coldWhite: 0
└──red: 235
└──green: 33
└──blue: 33
└─prevValue
└──warmWhite: 204
└──coldWhite: 0
└──red: 235
└──green: 33
└──blue: 33
└─propertyName: currentColor
In zwavejsui, the bulb changes rgb set but warm White remains to "204" and the bulb remais on warm White channel bacause is prevalent on rgb set.
x_zwave_values.Color_Switch_currentColor_0=204
x_zwave_values.Color_Switch_currentColor_1=0
x_zwave_values.Color_Switch_currentColor_2=235
x_zwave_values.Color_Switch_currentColor_3=33
x_zwave_values.Color_Switch_currentColor_4=33
Is it possible to targetColor also for "warmWhite" and "coldWhite" and have something similar to this?
x_zwave_values.Color_Switch_targetColor={"warmWhite":0,"coldWhite":0,"red":235,"green":33,"blue":33}
Thanks in advance.
MSR had been running fine, but I decided to follow the message to upgrade to 25067. Since the upgrade, I have received the message "Controller "<name>" (HubitatController hubitat2) could not be loaded at startup. Its ID is not unique." MSR throws the message on every restart. Has anyone else encountered this problem?
I am running MSR on a Raspberry Pi4 connecting to two Hubitat units over an OpenVPN tunnel. One C8 and a C8 Pro. Both are up-to-date. It appears that despite the error message that MSR may be operating properly.
Urgent Help MSR stopped running
-
Ok, so now look at the logs again. Disk space problem hiding others, now you should be able to see them.
-
OK these are the latest entries in the syslog to do with reactor
Mar 18 22:07:48 HP-Thin01 node[522]: NODE_PATH /home/stuart/reactor Mar 18 22:07:48 HP-Thin01 node[522]: FileLogStream { type: 'file', name: 'reactor.log', maxsize: 2, keep: 5 } Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.123Z <app:null> Reactor latest-22069-ebeefad starting on v16.13.1 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.126Z <app:INFO> Process ID 522; platform linux/x64 #1 SMP Debian 4.19.208-1 (2021-09-29); locale en_GB.UTF-8 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.127Z <app:INFO> Basedir /home/stuart/reactor; data in /home/stuart/reactor/storage Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.128Z <app:INFO> NODE_PATH=/home/stuart/reactor Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.135Z <app:INFO> Configured locale (undefined); selected locale(s) en_GB.UTF-8 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.195Z <app:INFO> Loaded locale en-US Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.223Z <Capabilities:null> Module Capabilities v21333 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.354Z <Plugin:null> Module Plugin v21186 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.369Z <TimerBroker:null> Module TimerBroker v21333 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.381Z <default:INFO> Module Entity v22042 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.391Z <Controller:null> Module Controller v22003 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.392Z <default:null> Module Structure v22047 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.413Z <default:null> Module Ruleset v21096 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.414Z <default:null> Module Rulesets v21096 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.433Z <GlobalExpression:null> Module GlobalExpression v21333 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.474Z <Predicate:null> Module Predicate v22067 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.484Z <AlertManager:null> Module AlertManager v21355 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.490Z <default:null> Module Rule v22043 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.500Z <GlobalReaction:null> Module GlobalReaction v21333 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.504Z <default:null> Module Engine v22053 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.505Z <default:null> Module httpapi v22021 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.510Z <default:null> Module httpproxy v21333 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.554Z <default:null> Module wsapi v21334 Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.558Z <app:NOTICE> Starting Structure... ar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.558Z <app:NOTICE> Starting Structure... Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.567Z <IndividualFileStrategy:ERR> [IndividualFileStrategy][IndividualFileStrategy#/home/stuart/reactor/storage] failed to read sys_alerts in /home/stuart/reactor/storage/states/sys_alerts.json: [SyntaxError]SyntaxError: Unexpected end of JSON input Mar 18 22:07:48 HP-Thin01 node[522]: Trapped unhandled Promise rejection SyntaxError: Unexpected end of JSON input Mar 18 22:07:48 HP-Thin01 node[522]: at JSON.parse (<anonymous>) Mar 18 22:07:48 HP-Thin01 node[522]: at IndividualFileStrategy.getDataObject (/home/stuart/reactor/server/lib/IndividualFileStrategy.js:123:47) Mar 18 22:07:48 HP-Thin01 node[522]: at Container.getDataObject (/home/stuart/reactor/server/lib/Container.js:98:51) Mar 18 22:07:48 HP-Thin01 node[522]: at Structure.start (/home/stuart/reactor/server/lib/Structure.js:280:631) Mar 18 22:07:48 HP-Thin01 node[522]: at Object.<anonymous> (/home/stuart/reactor/app.js:288:80) Mar 18 22:07:48 HP-Thin01 node[522]: at Module._compile (node:internal/modules/cjs/loader:1101:14) Mar 18 22:07:48 HP-Thin01 node[522]: at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10) Mar 18 22:07:48 HP-Thin01 node[522]: at Module.load (node:internal/modules/cjs/loader:981:32) Mar 18 22:07:48 HP-Thin01 node[522]: at Function.Module._load (node:internal/modules/cjs/loader:822:12) Mar 18 22:07:48 HP-Thin01 node[522]: at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) Mar 18 22:07:48 HP-Thin01 node[522]: SyntaxError: Unexpected end of JSON input Mar 18 22:07:48 HP-Thin01 node[522]: at JSON.parse (<anonymous>) Mar 18 22:07:48 HP-Thin01 node[522]: at IndividualFileStrategy.getDataObject (/home/stuart/reactor/server/lib/IndividualFileStrategy.js:123:47) Mar 18 22:07:48 HP-Thin01 node[522]: at Container.getDataObject (/home/stuart/reactor/server/lib/Container.js:98:51) Mar 18 22:07:48 HP-Thin01 node[522]: at Structure.start (/home/stuart/reactor/server/lib/Structure.js:280:631) Mar 18 22:07:48 HP-Thin01 node[522]: at Object.<anonymous> (/home/stuart/reactor/app.js:288:80) Mar 18 22:07:48 HP-Thin01 node[522]: at Module._compile (node:internal/modules/cjs/loader:1101:14) Mar 18 22:07:48 HP-Thin01 node[522]: at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10) Mar 18 22:07:48 HP-Thin01 node[522]: at Module.load (node:internal/modules/cjs/loader:981:32) Mar 18 22:07:48 HP-Thin01 node[522]: at Function.Module._load (node:internal/modules/cjs/loader:822:12) Mar 18 22:07:48 HP-Thin01 node[522]: at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) Mar 18 22:07:48 HP-Thin01 node[522]: Promise { Mar 18 22:07:48 HP-Thin01 node[522]: <rejected> SyntaxError: Unexpected end of JSON input Mar 18 22:07:48 HP-Thin01 node[522]: at JSON.parse (<anonymous>) Mar 18 22:07:48 HP-Thin01 node[522]: at IndividualFileStrategy.getDataObject (/home/stuart/reactor/server/lib/IndividualFileStrategy.js:123:47) Mar 18 22:07:48 HP-Thin01 node[522]: at Container.getDataObject (/home/stuart/reactor/server/lib/Container.js:98:51) Mar 18 22:07:48 HP-Thin01 node[522]: at Structure.start (/home/stuart/reactor/server/lib/Structure.js:280:631) Mar 18 22:07:48 HP-Thin01 node[522]: at Object.<anonymous> (/home/stuart/reactor/app.js:288:80) Mar 18 22:07:48 HP-Thin01 node[522]: at Module._compile (node:internal/modules/cjs/loader:1101:14) Mar 18 22:07:48 HP-Thin01 node[522]: at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10) Mar 18 22:07:48 HP-Thin01 node[522]: at Module.load (node:internal/modules/cjs/loader:981:32) Mar 18 22:07:48 HP-Thin01 node[522]: at Function.Module._load (node:internal/modules/cjs/loader:822:12) Mar 18 22:07:48 HP-Thin01 node[522]: at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) Mar 18 22:07:48 HP-Thin01 node[522]: } Mar 18 22:07:48 HP-Thin01 node[522]: Trace Mar 18 22:07:48 HP-Thin01 node[522]: at process.<anonymous> (/home/stuart/reactor/app.js:271:162) Mar 18 22:07:48 HP-Thin01 node[522]: at process.emit (node:events:390:28) Mar 18 22:07:48 HP-Thin01 node[522]: at process.emit (node:domain:475:12) Mar 18 22:07:48 HP-Thin01 node[522]: at emit (node:internal/process/promises:136:22) Mar 18 22:07:48 HP-Thin01 node[522]: at processPromiseRejections (node:internal/process/promises:242:25) Mar 18 22:07:48 HP-Thin01 node[522]: at processTicksAndRejections (node:internal/process/task_queues:97:32) Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.582Z <app:ERR> Trapped unhandled Promise rejection: [SyntaxError]SyntaxError: Unexpected end of JSON input Mar 18 22:07:48 HP-Thin01 node[522]: [latest-22069]2022-03-18T22:07:48.582Z <app:ERR> Please refer to the console log for trace Mar 18 22:07:48 HP-Thin01 systemd[1]: reactor.service: Succeeded.Mar 18 22:05:28 HP-Thin01 node[402]: [latest-22069]2022-03-18T22:05:28.048Z <IndividualFileStrategy:ERR> [IndividualFileStrategy][IndividualFileStrategy#/home/stuart/reactor/storage] failed to read sys_alerts in /home/stuart/reactor/storage/states/sys_alerts.json: [SyntaxError]SyntaxError: Unexpected end of JSON input Mar 18 22:05:28 HP-Thin01 node[402]: Trapped unhandled Promise rejection SyntaxError: Unexpected end of JSON input Mar 18 22:05:28 HP-Thin01 node[402]: at JSON.parse (<anonymous>) Mar 18 22:05:28 HP-Thin01 node[402]: at IndividualFileStrategy.getDataObject (/home/stuart/reactor/server/lib/IndividualFileStrategy.js:123:47) Mar 18 22:05:28 HP-Thin01 node[402]: at Container.getDataObject (/home/stuart/reactor/server/lib/Container.js:98:51) Mar 18 22:05:28 HP-Thin01 node[402]: at Structure.start (/home/stuart/reactor/server/lib/Structure.js:280:631) Mar 18 22:05:28 HP-Thin01 node[402]: at Object.<anonymous> (/home/stuart/reactor/app.js:288:80) Mar 18 22:05:28 HP-Thin01 node[402]: at Module._compile (node:internal/modules/cjs/loader:1101:14) Mar 18 22:05:28 HP-Thin01 node[402]: at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10) Mar 18 22:05:28 HP-Thin01 node[402]: at Module.load (node:internal/modules/cjs/loader:981:32) Mar 18 22:05:28 HP-Thin01 node[402]: at Function.Module._load (node:internal/modules/cjs/loader:822:12) Mar 18 22:05:28 HP-Thin01 node[402]: at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) Mar 18 22:05:28 HP-Thin01 node[402]: SyntaxError: Unexpected end of JSON input Mar 18 22:05:28 HP-Thin01 node[402]: at JSON.parse (<anonymous>) Mar 18 22:05:28 HP-Thin01 node[402]: at IndividualFileStrategy.getDataObject (/home/stuart/reactor/server/lib/IndividualFileStrategy.js:123:47) Mar 18 22:05:28 HP-Thin01 node[402]: at Container.getDataObject (/home/stuart/reactor/server/lib/Container.js:98:51) Mar 18 22:05:28 HP-Thin01 node[402]: at Structure.start (/home/stuart/reactor/server/lib/Structure.js:280:631) Mar 18 22:05:28 HP-Thin01 node[402]: at Object.<anonymous> (/home/stuart/reactor/app.js:288:80) Mar 18 22:05:28 HP-Thin01 node[402]: at Module._compile (node:internal/modules/cjs/loader:1101:14) Mar 18 22:05:28 HP-Thin01 node[402]: at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10) Mar 18 22:05:28 HP-Thin01 node[402]: at Module.load (node:internal/modules/cjs/loader:981:32) Mar 18 22:05:28 HP-Thin01 node[402]: at Function.Module._load (node:internal/modules/cjs/loader:822:12) Mar 18 22:05:28 HP-Thin01 node[402]: at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) Mar 18 22:05:28 HP-Thin01 node[402]: Promise { Mar 18 22:05:28 HP-Thin01 node[402]: <rejected> SyntaxError: Unexpected end of JSON input Mar 18 22:05:28 HP-Thin01 node[402]: at JSON.parse (<anonymous>) Mar 18 22:05:28 HP-Thin01 node[402]: at IndividualFileStrategy.getDataObject (/home/stuart/reactor/server/lib/IndividualFileStrategy.js:123:47) Mar 18 22:05:28 HP-Thin01 node[402]: at Container.getDataObject (/home/stuart/reactor/server/lib/Container.js:98:51) Mar 18 22:05:28 HP-Thin01 node[402]: at Structure.start (/home/stuart/reactor/server/lib/Structure.js:280:631) Mar 18 22:05:28 HP-Thin01 node[402]: at Object.<anonymous> (/home/stuart/reactor/app.js:288:80) Mar 18 22:05:28 HP-Thin01 node[402]: at Module._compile (node:internal/modules/cjs/loader:1101:14) Mar 18 22:05:28 HP-Thin01 node[402]: at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10) Mar 18 22:05:28 HP-Thin01 node[402]: at Module.load (node:internal/modules/cjs/loader:981:32) Mar 18 22:05:28 HP-Thin01 node[402]: at Function.Module._load (node:internal/modules/cjs/loader:822:12) Mar 18 22:05:28 HP-Thin01 node[402]: at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) Mar 18 22:05:28 HP-Thin01 node[402]: } Mar 18 22:05:28 HP-Thin01 node[402]: Trace Mar 18 22:05:28 HP-Thin01 node[402]: at process.<anonymous> (/home/stuart/reactor/app.js:271:162) Mar 18 22:05:28 HP-Thin01 node[402]: at process.emit (node:events:390:28) Mar 18 22:05:28 HP-Thin01 node[402]: at process.emit (node:domain:475:12) Mar 18 22:05:28 HP-Thin01 node[402]: at emit (node:internal/process/promises:136:22) Mar 18 22:05:28 HP-Thin01 node[402]: at processPromiseRejections (node:internal/process/promises:242:25) Mar 18 22:05:28 HP-Thin01 node[402]: at processTicksAndRejections (node:internal/process/task_queues:97:32) Mar 18 22:05:28 HP-Thin01 node[402]: [latest-22069]2022-03-18T22:05:28.097Z <app:ERR> Trapped unhandled Promise rejection: [SyntaxError]SyntaxError: Unexpected end of JSON input -
The disk going full has resulted in the corruption of your storage folder. You will need to restore a backup.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
The disk going full has resulted in the corruption of your storage folder. You will need to restore a backup.
-
@cw-kid it's the folder called
storagein your Reactor folder.Is that the folder with the rulesets in it ?
I have a backup of all the folders and files, but it's not very recent.Hope I am not going to lose the more recent changes to the rules.
-
-
That's good sleuthing and good work. Yes, the
statesfolder gets most of the I/O. If it looks like everything else is intact, that's fine. Rules and rule sets would only be damaged if you happened to edit them during the time the disk was full.On the Reactor master device, there are flags for warning you when disk space is becoming limited; rules with notifications may be a good idea, to avoid future unpleasant surprises.
-
I am assuming I have had a lucky escape here then, all my rules look to be present still, I am assuming "States" is just that as the name suggests the current state of the rules and that they will rebuild and repopulate themselves.
I didn't have any auto backup in place as not really sure how to do that in Linux command line, so I was just now and again manually copying the entire contents of the /reactor folder down on to my PC.
-
All correct.
-
In Entities under Reactor System I have all this information
reactor_system.alert_count=0 reactor_system.alert_last=1647657325518 reactor_system.alert_severity=null reactor_system.alerts=[] reactor_system.arch="x64" reactor_system.hostname="HP-Thin01" reactor_system.internet_ok=null reactor_system.platform="linux" reactor_system.reactor_memory_used=138702848 reactor_system.reactor_uptime=1082 reactor_system.system_load=[0.13,0.15,0.11] reactor_system.system_memory_free=2020356096 reactor_system.system_memory_size=3537993728 reactor_system.system_uptime=17002.98 reactor_system.volume_critical_reactor_base=false reactor_system.volume_critical_reactor_data=false reactor_system.volume_critical_reactor_logs=false reactor_system.volume_reactor_base=[5390756,13825496,0.389,"/home/stuart/reactor"] reactor_system.volume_reactor_data=[5390756,13825496,0.389,"/home/stuart/reactor/storage"] reactor_system.volume_reactor_logs=[5390756,13825496,0.389,"/home/stuart/reactor/logs"] sys_system.state=true Capabilities: reactor_system, sys_system Actions: reactor_system.clear_alert, reactor_system.clear_alerts, sys_system.restartMemory free is that disk or RAM ?
-
-
Losing state will cause rules to possibly run unexpectedly. For example, say you had a rule that triggers between sunrise and sunset. If state was lost due to disk full corruption such as this in mid-day, discarding the state at restart will cause the rule to have no state, therefore think it has a transition into the sunrise (triggered) period and fire. This may or may not be a desirable side-effect, depending entirely on how the user determines the rules to work, and I cannot predetermine whether re-running a rule would have side-effects in the user environment or not. Since this can occur unattended (such as while on vacation or at a remote vacation home), it's potentially very troublesome and should at least be corrected with the full awareness of the user, as you have in this case.
My number one recommendation is that you manage filesystem space well on the system. This is always an issue on all systems, and in Linux/Unix systems in particular, processes can die (due to errors) and files can become (logically) corrupt due to disk full conditions. It is something that needs to be managed. In your case, I would remember what log files were deleted, and investigate why those were so large and not being rotated and expired or archived. In your case, it appears you have a single root volume with everything on it. That means any subsystem running on the box can potentially fill the filesystem and cause other applications to misbehave. Best practices for system management often call for segmenting files/directories out. It is not uncommon, for example, to have
/var,/usrand/homeall on separate filesystems, that any one of them filling (/varoften has this issue because it holds system logs and other fast-changing files) would not result in other files in the other directories to become corrupt or truncated. Taking this to an extreme, but if hardening Reactor is mission-critical to you, it is possible to create a small volume and mount it as/var/reactorat boot time, and use that as the home for thestoragedirectory (andconfig, but not Reactor'slogs), thereby isolating and protecting Reactor's storage from everything else. This is all Linux system management stuff, so not really appropriate to deep dive into, but if you're going to use and maintain these systems as part of your infrastructure, well worth spending the time to learn. A must really, because when it goes wrong, and it will go wrong, your fluency in system management will directly determine the time it takes to recover, and how well (or not) you recover.I can take more mitigating steps to harden startup, and I will definitely do that. I will also see about adding Status page alerts for disk space problems. The way Reactor works, if the disk space problem is mitigated before a restart of Reactor (i.e. while Reactor is running), Reactor will (eventually) rewrite the files with state (which is cached in RAM during operation) -- at shutdown, Reactor writes the RAM state back to disk as a final assurance that they are in sync, just for this reason. But I cannot protect those files from every eventuality, and every other subsystem on the machine works pretty much the same way (rebooting after fixing a no-space condition is always recommended, because many daemons will just die when they can't write a file).
And as I've said again and again and again, please read the documentation and look at your log files. If you see something in the log files that points to obvious issue, handle it. If you don't know how to handle it, post the log file snippet and remember that context is vital, so posting 2-3 lines of a log file may provide little or no useful information (even when the error contains module names and line numbers); it often takes a dozen or more lines of context prior to really interpret how the system got to the crash point, so you must post a least a dozen or more lines prior to any error message you are inquiring about. Fortunately in this case, it was pretty obvious.
Pardon errors. Tapping this out on a bluetooth keyboard and over my home VPN on sketchy Internet made this a bit of a chore. Onward.
-
T toggledbits locked this topic on
SystemController - Reactor - Multi-Hub Automation
