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.
Reactor (Multi-System/Multi-Hub) Announcements
-
Reactor build 22349
NOTE: If you get missing entity errors from your rules when you first start this version, don't panic. Just wait a few seconds and then restart Reactor; it should then start clean.
IMPORTANT: The bare-metal distributions no longer include package dependencies pre-installed. It is therefore critical that you install/update dependencies every time you upgrade by running
npm run depsin the Reactor install directory (for Linux users; Windows users please refer to the installation documentation. This advisory does not apply to docker-based installs — Reactor docker images always include package dependencies pre-installed.- Expressions:
isNaN()now returns false when passednull. This is now different from JavaScript, whereparseFloat(null)/parseInt(null)returnNaN, butisNaN(null)(oddly, IMO) returns true. - Fix an error in Group class implementation that was causing spurious errors from DynamicGroupController after a member entity was deleted or purged.
- VeraController: Improve detection of UV sensor child devices registered as GenericSensor device type and having LightSensor1/CurrentLevel state variable when LightSensor1 isn't even a declared service for the type (i.e. a mess). This applies specifically to Aeotec Multi-Sensor 6 devices on 7.32beta4, but may apply to other devices/firmware.
- EzloController: Sound sensors are now handled with Reactor value_sensor capability.
- EzloController: Guard against missing item enumerated in data for a device (data inconsistency in Ezlo API's returned device data).
- UI Entities List: UI now stores the last 10 actions and their parameters, and restores the parameters when an action is repeated.
- UI Entities List: Action parameter default values for certain types are now provided correctly (some types would come up blank even though a non-blank default was provided in the parameter definition).
- HassController: Bless Hass to 2022.12.6
- i18n: Improve messages for Rules/Predicates when dependent objects are missing.
- Improvements from the 22343 silent release (see below).
MQTTController build 22350
- Improve handling of
x_mqtt_device.onlineattribute for templates that have custom LWT event.
- Expressions:
-
Reactor build 23010
- Stop Reaction action now allows you to stop the current/running reaction. This is intended to be used in constrained groups, where a match to the constraints may stop the reaction to prevent it from doing anything else.
- New
ev_chargersystem capability. - Reaction Editor: Fix incorrect storage type for boolean arguments affecting some controllers.
- HassController: Bless Hass to 2023.1.2
MQTTController build 23010
- Fix spurious message when stopping MQTTController instance.
ZWaveJSController build 23011
- Fix a possible runtime error during node configuration if the target node isn't yet fully ready.
- Support for iblinds V3.
-
Reactor build 23028
- UI/Rules Editor: Collapsed sections now change the color of the "hidden content" badge -- red if the hidden content contains an error that needs to be corrected before save, green if it contains modified conditions or actions, and info blue (as before) if no errors and unmodified. No badge is shown if the section is empty (as before). The badge icon has been changed to a crossed eye.
- Docs: Add Portainer installation instructions: https://reactor.toggledbits.com/docs/Installation-docker-portainer/
- EzloController: If there are too many consecutive timeouts on requests to the hub, recycle the hub connection.
- HassController: Bless Hass to 2023.1.7
-
Reactor build 23049
- Rule and Reaction Editors: Use fixed "helper" for drag/drop to circumvent limitations in jQuery-UI causing odd restrictions and side-effects when dragging large objects (like HTTP Request actions). It's not as cool-looking, but function over form is required here.
- Docs: Provide installation link for community-supplied HassOS add-on; thank you to mrw298 for this.
- HubitatController: Do not automatically select the Hub Information device for health probes; the new Hub Information v3 operates differently from previous versions and now is longer usable for health probes. A device will be chosen at random unless the
probe_deviceconfig is set. [docs] - HassController: Bless Hass to 2023.2.5
-
Reactor build 23063
- Reaction Editor (UI): restore wide fields in HTTP Request action; injection from changes in 23049.
- Reaction Editor (UI): fix detection of substitution in some cases that would cause single-action "try" button to not be disabled when a substitution was in the action's parameters (substitution isn't performed on single-action try).
- Entities Page: Action dialog now warns that substitution isn't performed in that tool (launching an action from entity detail panel).
- HassController: support for humidifier/dehumidifier (domain/service and device class, respectively).
- VirtualEntityController: Fix an error in config check that was not allowing underscore (
_) in entity IDs. - VirtualEntityController: Enforce
x_virtualentity.set_attributeparameters more aggressively (better error message when not provided). - VirtualEntityController: Fix an error in
x_virtualentity.set_attributethat would cause the HTTP API to not give a response when the action completed. - I18n: Rework the loading of locale settings files, their relation to the node or browser locale, and the configurable overrides. Reactor will now use the requested locale (host config, browser config/URL, Reactor config) even if a translation file is not available for it. This places the burden on JS' native Intl, which is ample, and reduces some complexity in Reactor's model.
- HassController: Bless Hass to 2023.3.1
ZWaveJSController build 23063
- Command class
Sound Switchnow maps tochimecapability (Aeotec Siren 6, others) - Support multi-step action implementations (e.g.
chime.playneeds to set two values sequentially (volume then sound).
-
Reactor build 23078
- Fix loading of local capabilities definitions broken in a previous build.
- HassController: Bless Hass to 2023.3.5
-
Reactor build 23114
- Conditions: add
is NOT TRUEandis NOT FALSEoperators. Theis NOT TRUEoperator (for example) is unlike theis FALSEoperator in that, if the tested value isnull, theis NOT TRUEoperator result would be true, while theis FALSEoperator result would be false. This distinction facilitates some tests where it may be desirable to handlenullas equivalent to eithertrueorfalsewithout having to provide an additional, separateis NULLcondition (and possibly an enclosing OR group). - DynamicGroupController: document group actions; this makes it an official feature (was experimental).
- Engine/Rule: Clean up a misspelled method name.
- InfluxFeed docs: update supported and recommended versions. [doc]
- HubitatController: Tweak reconnect timing decay (allow for longer decay when hub cannot be contacted for an extended period).
- Reactions: Clarify what "Disabled" means in the constraints of a Group action (incl. Repeat...While) of a reaction. It does not disable the actions in the group. The disable flag applies to the constraint conditions only, having the same effect as it would on rule-based triggers and constraints (i.e. it becomes as if the constraint conditions do not exist). [docs] and [docs]
- HassController: Bless Hass to 2023.4.6
- Conditions: add
-
MQTTController 23135
- In action payload, force conversion of all data types to string for "raw" output, rather than assuming result of expression is a string (although docs say to do that, it's just too easy to omit, and too easy to change it so the requirement is moot).
- Add
parameter: namevalue form to action payload definition to draw payload value from the named parameter without the need to use anexpression (this follows the implementation of action definitions in other Controller instances as well). That is, you can specify, for example,parameter: levelinstead of usingexpr: parameters.level(assuming the parameter value requires no scaling or other modifications to be compatible with the device). [docs]
-
Reactor Build 23171
NOTE: This build includes fixes made in a prior silent release (where the change(s) affected only one user).
DEPRECATION NOTICE: Support for versions of Home Assistant prior to 2022.5.3 will be removed on the next build. These older versions may continue to operate successfully with HassController going forward, but I will not address/fix issues for them.
- PR 0000356: Fix an issue where a rule with multiple sunrise/sunset conditions using the between operator chooses the first condition's before/after constraints rather than its own (i.e. it was choosing the control states from the first row rather than the current row).
- SystemController: the deprecated
suninfo.sun_angleattribute is now removed (its replacement issuninfo.elevation). - HubitatController: Hub variables can now be set up to 1024 characters with hub firmware 2.3.5.135 and above; for earlier firmware, the limit is 255 characters. The length limit is enforced by the hub, not HubitatController.
- HassController: Bless Hass to 2023.6.2
-
Reactor build 23196 (latest and stable branches)
NOTICE: As announced in the release note for the previous build (23171), Home Assistant versions earlier than 2022.5.3 are no longer supported.
- Introduce a maximum delay in the write-back of certain storage containers (e.g. that used for expressions).
- Docs: fix an error in an example on the How-To: Expressions with Entities page.
- HassController: Bless Hass to 2023.7.2
-
Reactor build 23218
- Improve the initialization of new global variables so they don't show "not yet evaluated" until a non-null value is set (null is a valid evaluation result and should remove the "not yet").
- Expressions: improve the display of non-printing characters in the expression editor's "current value" display (they now display as Unicode escape sequences).
- i18n: Fix init of localized weekday names when most recent Sunday occurs in prior month (caused, for example, incorrect weekday checkbox labels in Weekday conditions; cosmetic only, no operational effect).
- SystemController: for Reactor update, include update branch, version, and commit as attributes on system entity.
- Entities page: New Copy Attributes button in entity detail copies all attribute values to the clipboard.
- HassController: Bless Hass to 2023.8.0
-
Reactor Build 23242
- Rules Editor: Fixed an issue where a condition option change to the duration operator with no change to duration value may not be saved.
- HassController: Add mapping for
proximitydomain (tovalue_sensor). - HassController: Bless Hass to 2023.8.2
-
ZWaveJSController build 23254
- Some versions of iBlinds v3 report CC 38 (Multilevel Switch) and some report 106 (Window Covering), no obvious way to tell if there's a config parameter that controls this, or if it's a firmware change (firmware versions report same even when command class is different). Update handles both based on what's available (this is the first time I've seen a 106-reporter in the wild).
-
MQTTController build 23254
- Improve recovery time when broker is starting up, accepts our connection, but then refuses subscription (i.e. it's not fully ready).
-
Reactor build 23302
- Expressions: functions
asin(),acos(),atan(), andatan2(), and the reserved wordpi(lowercase), are now supported (identical to their JavaScript equivalents). - Update the documentation for migrating (importing) rules from Reactor for Vera (the Vera Reactor Plugin).
- HassController: All use of
x_hass.call_service(the entity-based service call action) now uses thetargetfield to specify theentity_id, rather than the old form which embedded theentity_idin thedatafield. - HassController: The
x_hass_system.call_service(system-global service call action) has been extended to allow the user to enter atargetfield for service calls that benefit from it. It should be noted, however, that thex_hass.call_serviceaction on a Reactor entity (mapping a HA entity) should be used in preference to the system-global service call whenever possible, as changes in ID by HA will break the system-global call without warning (entity-based service call actions will simply use the new ID given by HA). - HassController: Bless Hass to 2023.10.5
- Expressions: functions
-
Reactor Build 23338
DEPRECATION WARNING (bare-metal installs only): all nodejs versions earlier than 18 are now end-of-life; these versions will not be supported for Reactor after 1-Mar-2024. You should upgrade nodejs as soon as possible. The minimum supported version is now 18.18, but for longevity, upgrading to the current LTS version is recommended. Users of Reactor running in docker containers are not affected, as the image always embeds a supported LTS version of nodejs (that is, no action is required for docker users).
- Expressions: Update lexpjs to fix degenerate case of
casewith singlewhenand anelse(which is better written as anif...then...else, but shouldn't throw an error in any case). - CallMeBot: the built-in CallMeBot notifier is now deprecated. There are no plans to remove it right now, but it will not receive future updates. Use HTTP Request actions directly in Reactions instead.
- Reduce the frequency of reminder alerts when an upgrade is available.
- HassController: Bless Hass to 2023.11.3
- Expressions: Update lexpjs to fix degenerate case of
-
Reactor Build 23344
This is a "silent" release (you won't get upgrade notices) and available for docker containers only at this time.
- PR 0000294: InfluxFeed now supports exporting of global variable values to InfluxDB. See docs.
- VirtualEntityController: Fix issue where a global variable dependency (value change) was detected, but the old GV value was always retrieved.
- Dashboard: Strings displayed by ValueSensor widgets are now elastic-sized to reduce overflow.
- Dashboard: Fix group spec handling so that custom top-level dashboards for a group can be created. This needs documentation.
- HassController: Bless Hass to 2023.12.1
-
Reactor Build 24052
BARE-METAL USERS: It is recommended that you update package dependencies when installing all Reactor updates. After unpacking the Reactor archive, remove any existing
package-lock.jsonfile from your Reactor install directory, and then runnpm i --no-save --no-package-lock --omit devto update package dependencies.BREAKING CHANGE: The
valvecapability'sstateattribute value is now boolean, to match similar system capabilities (was previously/erroneously string). If you are using an entity with thevalvecapability in conditions or actions, make sure the type for the current or target state is boolean now.- Update support for many packages. Please remember to do
npm i --no-save --no-package-lock(bare-metal installs only; docker containers are always up-to-date). - Add ability to override the state of a rule from the UI, for logic debugging purposes. A disabled rule will have its state forced, but will not run its reactions. An enabled rule will also have its state forced, but the corresponding rule reaction will run on the state transition. When overridden, the trigger and constraint conditions have no effect on the overall rule state, but (if rule enabled) are still evaluated and their status is still accurately displayed on the status card for the rule in the UI.
- PR 0000357: Implement
getRule()extension function to get rule metadata; refer to the docs for more. - Fix an error in the handling of the entity action cache in the UI (occurred when running actions from the entity detail in the Entities list).
- Docs: improvements to description of custom event handlers for HassController (still a work in progress, but isn't everything?).
- Docs: add a section in VeraController doc for the firmware's
UnsafeLuaflag, required to be on for thex_vera_sys.runluaaction to be available. The value is now also published as an attribute on the system entity. - HassController: Implement new HA
valvedomain with ourvalvecapability. - HassController: Bless Hass to 2024.2.2
MQTTController Build 24050
NOTE: Either 24049 or 24050 of MQTTController is required for Reactor 24052.
- Rebuild entity when configuration change detected (supports
versionfield in user templates). - PR 0000365: Fix broken config for
tasmota_generic_relaytemplate'stoggle.toggleaction. - New templates for genmon (generator monitoring; see https://github.com/jgyates/genmon)
- Support for new js-yaml
- Support
mapin event handling configuration.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
- Update support for many packages. Please remember to do
-
Reminder for Bare-Metal Installs
Friday, March 1 2024 is the last day for Reactor support on nodejs versions earlier than 18. The next build of Reactor releasing after March 1 will not operate on any earlier version. If you haven't upgraded your system to nodejs version 18 or higher, please read the earlier advisory for details and upgrade ASAP.
For the removal of doubt, builds 24052 (most recent build) and prior will continue to run on and after March 1 on earlier nodejs versions; there is not enforced stop on this date. It is only future builds that will refuse to start on out-of-date nodejs versions.
Docker images are always up-to-date and therefore this notice does not apply to them (no action required for docker users).
-
Reactor build 24057
NOTE (BARE-METAL ONLY): If you are upgrading to this build from a build earlier than 24052, please update your package dependencies. After unpacking the Reactor archive, remove any existing
package-lock.jsonfile from your Reactor install directory, and then runnpm i --no-save --no-package-lock --omit devto update package dependencies.- PR 0000366: Fix an injection caused by the rule state override option added in 24052, which results in constraints on rules being handled incorrectly.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
