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.
I am getting a Runtime error on different browsers when I click exit when editing an existing or creating a new global reaction containing a group. If the global reaction does not have a group I don't get an error. I see a similar post on the forum about a Runtime Error when creating reactions but started a new thread as that appears to be solved.
The Runtime Error is different in the two browsers
Safari v18.3
@http://192.168.10.21:8111/reactor/en-US/lib/js/reaction-list.js:171:44
You may report this error, but do not screen shot it. Copy-paste the complete text. Remember to include a description of the operation you were performing in as much detail as possible. Report using the Reactor Bug Tracker (in your left navigation) or at the SmartHome Community.
Google Chrome 133.0.6943.142
TypeError: self.editor.isModified is not a function
at HTMLButtonElement.<anonymous> (http://192.168.10.21:8111/reactor/en-US/lib/js/reaction-list.js:171:34)
You may report this error, but do not screen shot it. Copy-paste the complete text. Remember to include a description of the operation you were performing in as much detail as possible. Report using the Reactor Bug Tracker (in your left navigation) or at the SmartHome Community.
Steps to reproduce:
Click the pencil to edit a global reaction with a group.
Click the Exit button.
Runtime error appears.
or
Click Create Reaction
Click Add Action
Select Group
Add Condition such as Entity Attribute.
Add an Action.
Click Save
Click Exit
Runtime error appears.
I don’t know how long the error has been there as I haven’t edited the global reaction in a long time.
Reactor (Multi-hub) latest-25060-f32eaa46
Docker
Mac OS: 15.3.1
Thanks
I am trying to delete a global expression (gLightDelay) but for some strange reason, it comes back despite clicking the Delete this expression and Save Changes buttons.
I have not created a global expression for some times and just noticed this while doing some clean-up.
I have upgraded Reactor to 25067 from 25060 and the behaviour is still there. I have restarted Reactor (as well as restarting its container) and cleared the browser's cache several times without success.
Here's what the log shows.
[latest-25067]2025-03-08T23:50:22.690Z <wsapi:INFO> [WSAPI]wsapi#1 rpc_echo [Object]{ "comment": "UI activity" }
[latest-25067]2025-03-08T23:50:26.254Z <GlobalExpression:NOTICE> Deleting global expression gLightDelay
[latest-25067]2025-03-08T23:50:27.887Z <wsapi:INFO> [WSAPI]wsapi#1 rpc_echo [Object]{ "comment": "UI activity" }
Reactor latest-25067-62e21a2d
Docker on Synology NAS
Morning, experts. Hard on learning about the internet check script in MSR tools, I was wondering what suggestions anyone has about a local (i.e. non-internet dependent) notification method.
This was prompted by yesterday's fun and games with my ISP.
I've got the script Cronned and working properly but short of flashing a light on and off, I'm struggling to think of a way of alerting me (ideally to my phone)
I guess I could set up a Discord server at home, but that feels like overkill for a rare occasion. Any other suggestions?
TIA
C
Reactor (Multi-System/Multi-Hub) Announcements
-
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.
-
MQTTController build 24085
- Support for Shelly H&T Gen3 (use
shelly_handt3template and settopic). This is a battery-powered WiFi device, so its attributes will not be fully populated until the first wake-up.
- Support for Shelly H&T Gen3 (use
-
C Crille referenced this topic on
-
Reactor build 24115
- Entities UI: When a capability filter is selected, the value column header displays a selector allowing the user to display a value in the column other than the primary value for the filtered entities.
- The extensions subdirectory
extmay now be located underconfig, which makes its location uniform for bare-metal and docker users; this will eventually become the standard location. It is not necessary at this time to relocate your existingextdirectory if you have one — either or both the old and new locations will work for the foreseeable future. - Improve the coordination of the Reactions and Rules displays when open and interacting on multiple displays (e.g. when you delete a reaction on one screen, it should disappear from the other(s)).
- Fix a browser-side performance issue/delay with reconnection to a restarting Reactor service when the Status page is up and displaying the Recently Changed Entities widget. This also improves the memory consumption and performance of the widget generally.
- Increase tolerance for damage to most storage objects, particularly those that only maintain state that can usually be safely rebuilt on the fly. For those that cannot, like rules and expressions, isolate a faulty file and ignore the object with an alert to the user. Preserve the broken file.
- PR 0000367 Localization of the new strings in the rule state override menu and state display have been added.
- PR 0000368 Fix missing localization string for Copy Attributes button in Entities list entity detail card.
- Report detected time zone and offset in startup messages. Add time zone display to hover title on browser and host times in UI header.
- New
wifi_statussystem capability for WiFi-connected devices that can report connection status. - PR 0000369 Docs: Add documentation for
ev_chargersystem capability. - HassController now supports responses from services that support them; whether required or optional, a response will be requested and stored in
x_hass.last_responseon the target Reactor entity. The data returned is not processed in any way; it is written as-received to the attribute. Tip: if possible, always make the service call from the target entity, not from the system entity. - HassController: Bless Hass to 2024.4.4
MQTTController 24114
NOTE: This version requires Reactor build 24115 or higher
- Add template for Shelly RGBW2 (using Gen1 API) called
shelly_rgbw2_color(requirestopic). - Add support for
wifi_statuscapability for some devices; more to come. Previously, those devices stored WiFi status info inx_mqtt_device(extended capability) attributes. Now that a first-class capability is being used, the extended attributes are deprecated and will be removed from a future release. - Templates may now remove an action from an entity if it isn't supported by the device. This is done by specifying the action's value as
false. If a device cannot support any action of a capability, the entire default list of actions for the capability can be removed by specifying the capability value asfalsein theactionssection of the template. For an example, see the templateshelly_rgbw2_colorimplementation for capabilitylight_effectactionset_speed, and the action implementation for thebuttoncapability. - Templates may now define custom actions in
x_mqtt_device. Including anargumentsobject in the standard action arguments format allows the template to notify the UI of the arguments required by the action. For an example, see the templateshelly_rgbw2_coloractionx_mqtt_device.set_white.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
MQTTController 24120
- Soft reconfiguration of entities on configuration changes and system upgrades. This should preserve attribute values when the entity needs to be configured due to implementation changes for capabilities.
-
MQTTController 24142
DEPRECATION NOTICE: The
uses_templateentity configuration directive is now deprecated; useincludeinstead (see below). It will remain functional until build 25091 (Q2 2025).- PR 0000370: Events for tasmota_generic_relay in template have hard-coded device ID (left over from test/dev).
- System templates are now broken up to multiple files in a hierarchy within the
templatesdistribution subdirectory. - New
includedirective in entity configuration or a template can be used to include the data of another template. You may name a single template (string value), or an array of template names. This permits common behaviors across devices to be modularized in templates. This directive also now replacesuses_template, which is deprecated (see above notice). - The user custom template directory (
config/mqtt_templates/) now supports any directory hierarchy the user wishes to maintain within it. It searches for templates in YAML or JSON files in the hierarchy, and will traverse ZIP files as well (so template developers can distribute their products in ZIP archives for easy installation/upgrade).
-
Reactor build 24152
POTENTIAL BREAKING CHANGE: The port on which Reactor provides HTTP(S) service is now determined by the
baseurlconfiguration value first. If no port is given there, the PORT environment variable is then queried; if that's not set, the default port is used (different for HTTP and HTTPS; see below). In previous versions, the PORT environment variable had the highest priority, but this is no longer the case. This will likely have no effect on most users, but if you're having trouble accessing the UI after upgrade, check yourbaseurlconfiguration first (if you don't have one or need an example, refer to the distribution version ofreactor.yamlindist-config. For users using Reactor via HTTPS (SSL/TLS encryption), I recommend using port 8554 inbaseurl; regular HTTP (no encryption) remains on port 8111.- User Authentication and Access Control. See the Access Control documentation. This is feature request PR 0000351.
- The default port for HTTPS-enabled Reactor is now 8554 (8111+443). If your system or docker configuration set the PORT environment variable before starting Reactor, whatever port that specifies will be used as before. See the How-To: HTTPS section of the documentation for information about configuring Reactor for HTTPS.
- The port used for HTTP(S) service is now determined by the port specified in
baseurl(inconfig/reactor.yaml) first; if no port is specified inbaseurl, the PORT environment variable is used if set, and finally the Reactor default of 8111 (or 8554 if TLS is enabled). - If HTTPS (HTTP + SSL/TLS) is enabled and its configured port is other than 8111 (the standard HTTP (non-SSL/TLS) port for Reactor), an HTTP service on port 8111 will now be created to redirect requests from HTTP to HTTPS (no unencrypted service is provided other than redirection). This feature can be disabled by configuring
redirect_httptofalsein thereactorsection ofconfig/reactor.yaml. - The
allow_ipsin thereactorsection ofconfig/reactor.yamlnow allows CIDR address range specification (e.g.10/8or192.168.0/24) for ranges of addresses. - Updated the documentation theme and its supporting plugins; improved the appearance of code snippets with syntax highlighting in most cases; add line highlighting in many code snippets to draw attention to certain elements or changes.
- Dashboard: added new Thermostat type (supported by
Level.updownlayout) for capabilitieshvac_heating_unit/hvac_cooling_unit. Evolving; further improvements coming. - VirtualEntityController: Support for time-series data collection and aggregation. See the docs).
- VirtualEntityController: Preserve attribute values if possible across system updates that affect capability definitions or implementations.
- DynamicGroupController: It is now possible to set the primary attribute of a dynamic group, and determine its value dynamically. Trivial example: add the
binary_sensor.stateattribute to a group to show true when any light in the group is on. Refer to the docs for DynamicGroupController. - The
dist-configdirectory is now copied to the user data virtual path target when running in docker containers so that its contents are more easily accessible to docker users (no need todocker execinto the running container). - Rules: the logging level for most rule evaluation messages has been reduced to
DEBUG0(numeric level 5); rules will now log only startup/shutdown and rule state changes atINFOlevel. Per-object logging configuration can be used to enable more detailed logging for a specific rule when required. - Fixed an issue in the core related to deleting certain objects (a Global Reaction was reported, but could have been many object types).
- Fixed an issue with local service of docs that caused a cross-site scripting error on some browsers (this is the "Initializing search..." bug).
- Developer Tools: the
utilfunctiondeepCompare()now works with JavaScriptSet,Map,Buffer, andRegExpobjects. - Developer Tools: documented
utilfunctionhash()(it's been around a while, just not documented). - HassController: Bless Hass to 2024.5.5
-
MQTTController build 24155
NOTE: This build contains only compatibility changes; no bug fixes or new features.
- Small change to preserve compatibility with older builds of Reactor; this in particular is to ensure that users of the
stablerelease branch are able to use the latest version of this controller.
- Small change to preserve compatibility with older builds of Reactor; this in particular is to ensure that users of the
-
Reactor STABLE Update
The
stablebranch of Reactor is now updated to build 24057. For changes, please scroll back and see the changes and advisory listed since the previous stable branch build (which was 23344).IMPORTANT: Bare-metal users will need to update installed packages (see note here) and be aware of the breaking change notification (same link).
NOTE: This will be the last
stablebranch release that supports versions of nodejs < 18. If you haven't yet upgraded nodejs on your system, you will need to do so before the nextstableupdate (an even-numbered LTS version is recommended). This applies to bare-metal users only; docker users have compatible versions of nodejs built into the Reactor distribution image. -
Reactor build 24190
BREAKING CHANGE: Home Assistant versions prior to 2023.6 are no longer supported. Going forward, you may expect HassController to support Home Assistant releases made in the last 12 months. Older releases may continue to work, but will rececive a warning at startup, and may cause errors (that I will not troubleshoot or fix/work around). Special workarounds for pecularities of releases older than 24 months will be removed from the code (meaning versions of Home Assistant older than that will almost certainly have issues).
- Access Control: setting the session timeout to 0 in
users.yamldisables timed-based session expiration. - PR 0000374: Rolling refresh appears not to work (many UI operations don't cause enough activity to stimulate the refresh).
- PR 0000371: Localization for login page submit button.
- Conditions: Ignore excess whitespace in comma-separated list of values for "in" and "not in" condition operators.
- Rule UI: Hovering over a condition's value in a rule detail card now shows info for current and previous value.
- HassController: Bless Hass to 2024.7.0
MQTTController build 24162
- Address an issue with action configuration in a template stomping on the action definition in the parent capability.
- Ensure deep copy of template applied to entity.
- Fix an initialization issue when multiple instances of MQTTController are configured.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
- Access Control: setting the session timeout to 0 in
-
EnvisalinkController build 24191
This is the initial release of a Controller for Envisalink EVL4 alarm panel interfaces. The controller currently supports only Honeywell panels, but I'm happy to work with anyone who has an EVL4-connected DSC panel to get that working as well.
Distribution package is available in the
extrasfolder of the download site. -
Reactor build 24212
- PR 0000376: Search by name is now available on the Reactions list (similar to Entities list).
- Attribute
security_mode.staterecognizesmaxvalue. - Action
security_mode.set_modenow takescodeargument (if not given, the default code in the Controller's configuration will be applied, if available). - Dashboard: support
/dashboard/group/<group-canonical-id>path for direct display of a group. - PR 0000375: Fix a path where a global variable (expressionless) could have its value modified and not update variables that depend on it.
- HassController: Bless Hass to 2024.7.3
