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
-
Build 22240 (latest, zwavejs)
BARE-METAL USERS: If you are upgrading to this version from any version earlier than 22233, you need to update your package dependencies. Pleasee see the post for that build for instructions.
ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
- PR 0000327: Reaction Entity Action layout for additional data fields is messy.
- VeraController: Ensure
x_vera_device.failedand.configuredare null if Vera fails to provide state for these values. - EzloController: Dead-marking and automatic removal (after delay) of entities for Ezlo devices/rooms/scenes that no longer exist (functional parity with other hub Controller objects).
- HassController: Implement mappings for scenes, scripts, and automations. All of these can have their actions run via Reactor's
script.runaction. Automations also can be en-/disabled using thepower_switchcapability actions (and entity primary state is the automation's en-/disabled state). All appear as runnable scenes in the dashboard. - UI: Improve highlighting of containing groups when sort/drop changes to conditions are made in the rules editor.
- HassController: Bless Hass to 2022.8.7
-
Just a news item: the ZWaveJSController is now an official add-on, available for download from
extras. Instructions for installing it are in the Reactor documentation.For (only) those users who have been using the zwavejs build series for testing ZWaveJSController, you will now need to go back to the latest build series, and install ZWaveJSController as referenced above. There will be no further builds on the zwavejs branch. Also, ZWaveJSController no longer requires an authentication key to use, so you can remove the
authentry from configuration (it will be ignored and is harmless if you leave it). -
Reactor build 22248
Docker Container Users: After upgrading to this build image, please check your
NODE_PATHenvironment value in your container configuration; it should read/opt/reactor:/opt/reactor/node_modules. If it does not, please correct it (some container managers, including Synology, do not automatically reapply/update values from newer images to existing containers).- Run Reaction action: New option "wait for completion" causes the current reaction to wait for the started reaction to finish. When unchecked (default), the started reaction runs concurrently with the reaction that starts it. This (concurrent) is the behavior of all prior versions of Reactor, and since unchecked is the default, the behavior of your existing reactions does not change (unless you go in and change it). docref
- Internal changes to support general release of ZWaveJSController.
ZWaveJSController build 22248
- Reduce default logging level to 5.
- Remove unused dependency.
-
Reactor build 22251
Bare-metal Install Users: If you are upgrading to this version from any version prior to 22233, you need to update your package dependencies. Please see the announcement for that build for instructions.
Docker Container Users: If you are upgrading to this build from any build earlier than 22248, you need to check that your
NODE_PATHfor your container is correctly updated. See the announcement for that build for details and instructions.ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
- PR 0000328: Rule Editor: editing condition options of parent of nested groups opens child's condition options panel (fixed).
- Entities list: fix name search parity with Entity Picker (ID matches).
- Change the way object arguments to actions in reactions are stored. Previously, they were stored in the reaction as native objects by converting the given string as JSON (the input was expected to be JSON) in the UI. This made expression substitution unavailable in those (object) arguments. Now, they are stored by the UI as given (i.e. a string), so substitutions are now available in those arguments. This specifically removes the limitation that
x_hass_system.call_servicecould not perform substition in itsdataargument. It now works as expected. A deprecation warning has been added to the Engine to detect argument values stored as native objects in actions that will cause an alert to be displayed notifying the user that the reaction/action needs to be edited. Any trivial edit to the field, followed by a save of the reaction, will update the form of the data and eliminate future alerts. - Dashboard: Fix stray "x" displayed on Sensor layout when source entity's units are null.
- HassController: Bless Hass to 2022.9.0
-
Reactor build 22252
Bare-metal Install Users: If you are upgrading to this version from any version prior to 22233, you need to update your package dependencies. Please see the announcement for that build for instructions.
Docker Container Users: If you are upgrading to this build from any build earlier than 22248, you need to check that your
NODE_PATHfor your container is correctly updated. See the announcement for that build for details and instructions.ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
- PR 0000329: Rule Editor: editing sunrise/sunset condition, if only sunrise/sunset selectors are modified last, the rule does not save as configured. If other condition fields are edited after, it saves correctly.
-
Reactor build 22256
Bare-metal Install Users: If you are upgrading to this version from any version prior to 22233, you need to update your package dependencies. Please see the announcement for that build for instructions.
Docker Container Users: If you are upgrading to this build from any build earlier than 22248, you need to check that your
NODE_PATHfor your container is correctly updated. See the announcement for that build for details and instructions.ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
ALL USERS -- IMPORTANT: As a result of entity storage changes in this build, existing entity storage (cache) is invalidated and rebuilt when this build is first run. That will cause all entities to be reported as newly-discovered, even though they were known before. However, this should be minimally disruptive to your logic, if at all. You may also safely ignore any warnings you see in the logs about "incompatible serialization data" on that first run; those are expected.
- PR 0000331: In the "Pulse" output condition options, the option to limit the number of pulses vanished from the editor during the upgrade to Bootstrap 5 (i.e. since 22233). It has been restored. This did not affect the operation of existing repeat count limits on conditions. If a pulsing condition was edited, that would have removed the limit, so if you use this feature, you might check those conditions that should use it. Opening the rule detail in the Rule Sets list of rules to see the condition descriptions is sufficient to see if it's there or not -- you don't need to go into the editor to see it. When present, the condition description will include "repeat after x seconds up to y times."
- Fix spurious data format warning for HTTP Request actions.
- Entities now have metadata (data about data) for each attribute that provides the time last modified, as well as the previous value and the effective time of the previous value. In addition, any data type and other definition information known for the attribute will also be present. The quickest way to see attribute metadata is to hover over the name of an attribute in the detail panel of an entity in the Entities list. The attribute metadata is accessible in expressions via each entity's
attribute_metaproperty. The subkeys of this property are capability names, and within each capability are the attribute names, and within the attribute names are the metadata elements. For example, in the commonly used form of expressiongetEntity( entity_id ).attributes.power_switch.statewe would get the value of thestateattribute in thepower_switchcapability of whatever entity was matched; this tells us if the switch is on or off. To get the time that value was set, we would usegetEntity( entity_id ).attribute_meta.power_switch.state.last_modified. Those of you trying to use thelastupdateproperty on an entity for various purposes (such as failed node detection) should particularly take note of this change and the capability it provides. - Docs: New page Expressions with Entities & Attributes in the How-To section.
- (Advisory) HubitatController: Hub variables are limited to 255 characters by the hub firmware. Attempts to set a hub variable to a longer string will fail. See the Limitations in the HubitatController docs for more details.
- VeraController: The
sys_system.reloadaction was incorrectly reloading the remote Vera hub; that's not really its job, but rather the job ofx_vera_sys.reload. If you have been usingsys_system.reloadto restart Luup, please switch tox_vera_sys.reload. As of this build,sys_system.reloadwill cause VeraController to resync all devices and entities (i.e. it's a restart of VeraController, not your Vera). - HassController: Bless Hass to 2022.9.2
ZWaveJSController build 22256
- Send notice (displays in Status widget) when a new node is discovered.
-
Reactor build 22257
Bare-metal Install Users: If you are upgrading to this version from any version prior to 22233, you need to update your package dependencies. Please see the announcement for that build for instructions.
Docker Container Users: If you are upgrading to this build from any build earlier than 22248, you need to check that your
NODE_PATHfor your container is correctly updated. See the announcement for that build for details and instructions.ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
ALL USERS -- IMPORTANT: If you are upgrading to this build from a build earlier than 22256, please read the advisories for that build prior to proceeding.
- VeraController: Specific support for iBlinds2 (Window Blind Controller mfg 647 prod 3,13) to handle its 50%=fully open way of doing business (since the covering is made up of slats/louvers, the 0 and 100 positions are closed fully tilted one direction or the other, with 50% being "flat" between the two).
- VeraController: The generic
cover.setaction was missing, and nativetoggledcapability support was added for window coverings (toggles between open and closed, as one might expect). - Dashboard: The Cover widget (window covering) was not changing its icon when the covering changed state.
- HubitatController: Tighten checking and handling around oddly-named attributes. Apparently at least one Hubitat user has a device that has a HE-native attribute with a space in its name, causing an exception to attribute naming tightened in 22256. This was causing a no-start on the controller. This build maps out non-alphanumeric characters from Hubitat to underscores, and also provides additional error handling to prevent a single attribute from stopping the controller startup.
-
Reactor build 22258
Bare-metal Install Users: If you are upgrading to this version from any version prior to 22233, you need to update your package dependencies. Please see the announcement for that build for instructions.
Docker Container Users: If you are upgrading to this build from any build earlier than 22248, you need to check that your
NODE_PATHfor your container is correctly updated. See the announcement for that build for details and instructions.ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
ALL USERS -- IMPORTANT: If you are upgrading to this build from a build earlier than 22256, please read the advisories for that build prior to proceeding.
- VirtualEntityController: This new controller type lets you create virtual entities (devices) and manipulate them. docs.
- Entities list: Fix metadata pop-ups that sometimes "stick", caused by the entity updating and the popper losing its reference element in the DOM. Also make the pop-ups more dynamic by updating them when the attribute updates.
- HassController: Devices that Hass identifies in the "motion" device class will get the
motion_sensorcapability in addition to the ubiquitousbinary_sensor, andmotion_sensor.statewill be the primary attribute. - VeraController: Make sure all extended per-Vera-service capabilities are defined as stubs.
- HassController: Bless Hass to 2022.9.4.
-
MQTTController build 22260
- Add new template
owntracks_in_region
- Add new template
-
Reactor build 22264
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build.
- VirtualEntityController: Added ability to make periodic HTTP requests and parse results to apply to attributes (see docs).
- PR 0000332: Fix missing "minutes" label (since BS5) on Interval condition fields (cosmetic).
- Added new
locationcapability for geographic location (attributes: latitude, longitude, elevation). This is intended as a target for geolocation integrations. - Docs: Updated for new
owntracks_in_regiontemplate. - Docs: Fixed an error in the example config for VirtualEntityController.
- HassController: Bless Hass to 2022.9.5
-
Reactor build 22266
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- PR 0000333: EzloController: problem with wss (secure websocket) connection injected at 22264.
-
Reactor build 22274
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- HubitatController: Fix too-aggressive caching of entities that makes entity names too "sticky" when device name or label is changed on hub. Note that a particularity of Hubitat, unlike most other hubs currently supported, requires a soft restart of either the controller instance (using
sys_system.restarton the HubitatController's system entity) or a restart of Reactor to "see" the rename (Hubitat does not send an event when a device is renamed, so Reactor can't know). - HassController: Bless Hass to 2022.9.7
- HubitatController: Fix too-aggressive caching of entities that makes entity names too "sticky" when device name or label is changed on hub. Note that a particularity of Hubitat, unlike most other hubs currently supported, requires a soft restart of either the controller instance (using
-
G gwp1 referenced this topic on
-
Reactor build 22291
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- HubitatController: Breaking change: Devices that use HE's PressureMeasurement capability will now report pressure on
pressure_sensor.valuerather than the genericvalue_sensor.value. I'm not sure this is widely used if at all, so I chose to just make the breaking change rather than deprecate and hold on to the old behavior for months. - PR 0000283: Reactions Editor: allow drag-drop between groups. This still has some minor issues, but these are due to limitations/defects in jquery-ui (so we'll have to live with them for now).
- PR 0000334: Docs, fix an error in the example expression for metadata.
- HubitatController: Implement polling as a replacement for Hubitat's Z-Wave Poller app, which is widely reported to not work well (the author's own experience corroborates these reports). Polling is only needed for legacy Z-Wave devices that do not support instant status or some equivalent (hail, etc.) that Hubitat understands. [docs]
- DynamicGroupController: the
include_entityandexclude_entityselectors now can use a regular expression to match entity canonical IDs. [docs] - InfluxFeed: New advanced attribute handling key
skip_nullto suppress export of null measurement values; [docs] - Fix a sync issue in the UI when deleting entities that previously required a hard refresh of the browser.
- UI: Fixed alignment of icons and buttons for large items in the Alerts widget (Status page).
- Documentation: Updated documentation on building Controllers, and provided new example code (WhiteBITController).
- HassController: Tighten capabilities for voltage, current, energy, power, and humidity sensor types. If you have automations using temperature or humidity sensors in Hass, please make sure your conditions use the
temperature_sensor.valueorhumidity_sensor.valueattributes, and not the genericvalue_sensor.valueattribute -- this generic attribute is now deprecated and will be removed from a future release. - HassController: Bless Hass to 2022.10.4
MQTTController build 22291
NOTE: This version requires Reactor version 22291 or higher.
- Add optional default value in topic substitutions. That is, the substitution string
%flavor:chocolate%would insert the word chocolate if flavor was not defined in the entity configuration. - Template
owntracks_in_regionadds auserfield that can be set if your Owntracks needs it. The Owntracks topic is/owntracks/user/deviceid, so theuserfield should be set in your entity configuration (withtopicandregionNameto whatever is in thatuserportion of the topic (e.g. if your Owntracks publishesowntracks/fred/fredsphonethentopicshould be set tofredsphoneandusershould be set tofred). - Code cleanup and sync with Controller base class updates.
ZWaveJSController build 22291
NOTE: This version requires Reactor version 22291 or higher.
- Code cleanup and sync with Controller base class updates.
- HubitatController: Breaking change: Devices that use HE's PressureMeasurement capability will now report pressure on
-
Reactor build 22293
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- PR 0000337: Condition with "sustained for" less than X seconds malfunctions (triggers immediately).
- PR 0000336: Fix group error indication not clearing when creating new group in a reaction (global or rule-based).
- Fix an error in the translation string for "sustained for" options when the "less than X seconds" form is used (was showing incorrectly in rule status view human-readable form).
- VirtualEntityController: scheduling of HTTP requests can now be done at specific times via the
atsetting for the request (an alternative tointerval). [docs] - VirtualEntityController: the
quiet_failureflag now accepts either a boolean value or integer; if boolean true, notifications are never sent for failed HTTP requests. If numeric, a notification is sent only after that number of requests has failed. [docs]
-
Reactor build 22302
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- UI/Status: Running Reactions widget now has "stop" button to terminate a running reaction (caveat operator).
- UI/Status: Tighten the display up a bit (remove excess whitespace).
- UI/Status: Fix alerts list that can overflow its container horizontally, causing a confusing display with multiple scoll bars.
- UI/Rule Editor: An notice/badge is now shown for collapsed sections that are not empty (i.e. when content is hidden).
- Fix condition operator "is EMPTY" (and its negated partner) on array type operand (only) was incorrectly reporting not empty in some circumstances.
- Additional UI embellishments for condition (triggers/constraints) and action (reactions) drag-drop. Still some limitations/inconsistencies/bugs in jquery-ui (which provides the drag/drop/sort implementation). If you can't get your object exactly where you want it, drop it close (i.e. into the group you want it in), then drag it again to its final position within the group.
- Action logging from all controllers now uses INFO level logging rather than forced logging (this is mostly a help to me because I separately log warning and higher priority in my test and home configurations so I can more clearly see errors -- it removes noise from that).
- HassController: Bless Hass to 2022.10.5
-
Reactor build 22305
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- Engine: fix bug that could cause expressions having array or object results to not detect change reliably.
- UI/Rules/Reactions: the changes operator should not be available in constraints (changes is an event, and constraints are static, not event-driven).
- UI/Rules Editor: enforce minimum size for condition type menu (tidier layout).
- UI/Reaction Editor: improve field layout, prevent fields from pushing controls out of container, enforce minimum size for action type menu (tidier layout).
-
Reactor build 22308
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- PR 0000343: Fix missing fields for notification action (Pushover title reported; 22305 injection).
- PR 0000342: Documentation fix, error in example code for
ifexpressions in Expressions doc. - PR 0000341: Ease entity ID restriction (for users with international characters in entity IDs).
- PR 0000340: Localization of "upgrade available" alert message.
- PR 0000339: push()/unshift() functions not working as expected (not a lexp issue, it's a last-value storage/comparison problem when value is object type).
- PR 0000338: Version/license/meta info for extensions is now displayed on the About page.
-
Reactor 22328
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- The
baseurlconfig key/value is no longer required. It is used only in exceptional circumstances. It is now commented out in default configurations (dist-config/reactor.yaml), and setting it is no longer required as an installation step. Users configuring their systems to use HTTPS access to the Reactor UI should, instead of usingbaseurl: https://..., setuse_tls: truein thereactorsection of their configuration. - Improve messages in Run Reaction actions when there is an error starting the reaction.
- DynamicGroupController: make sure change in group name in configuration is always applied at startup.
- HassController: implementation for
device_trackerservice to location capability. - HassController: since HA appears to provide conversion, enable all color modes if any is supported.
- HassController: Add support for new
xy_colorcapability. - HassController: Allow YAML form service data in
call_serviceactions. The service data can now be formatted as YAML or JSON. The former is the default unless{is the first character in the field, to preserve compatibility with existing actions using JSON data. - Add
xy_colorsystem capability. - Fix a startup issue on Windows.
- PR 0000345: Fix expression doc example for
eachstatement - HassController: Bless Hass to 2022.11.4
ZWaveJSController 22323
NOTE: This version requires Reactor build 22314 or higher.
- Allow
zwave_device.set_configparameter to be either string (property name) or number (property/configuration parameter ID). This should improve usability for this action. - Store property ID in metadata for
x_zwave_valuesattributes. - Improve "first guess" device support for many devices when Z-Wave JS is still running interviews and Reactor comes up (i.e. when data from Z-Wave JS about devices is incomplete).
- Improve device support for multiple Fibaro, Aeotec, Everspring devices.
- Improve manufacturer/device support for Remotec, Poly-Control, Danalock, Zipato, Nortek, NEO, Minoston (EVA Logik).
MQTTController 33326
NOTE: This version requires Reactor build 22306 or higher.
- Allow templates to be stored in individual files in a
config/mqtt_templatessubdirectory. This should improve users' configuration management for community-contributed templates. - Additional error checking in install script.
- Implement entity deadmarking like other controllers.
- Improve entity initialization/resilience to isolated configuration problems.
- Incorporate some device template fixes from @therealdb (with gratitude for his ongoing contributions).
- Support for deterministic updating of attributes on a topic by using a new/alternate array-based configuration syntax. [docs]
- Support for
requireskey in templates to facilitate user-feedback when a template is used but a configuration value required by the template it not provided by the user.
- The
-
Reactor build 22337
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- Rules UI: Improved detection in UI (or more correctly, notification from core to UI) of "trouble" on rules.
- HassController: reconfigure entities on HA version change; support for person, weather, number, button, sun.
- HTTPAPI: API requests are now logged by default.
- HTTPAPI: A malformed
monitored_entitiesconfiguration will no longer prevent theperformAPI request from completing. - HassController: Bless Hass to 2022.11.5
-
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:
