I need a handful of victims volunteers to help test previews of the next build of Reactor. A long-standing request was for "a simple login mechanism," but in practice, adding user authentication and competent access control turned out to be a pretty big project with a lot of big changes on both server and client sides. It's a bit more than I'm comfortable testing myself and springing out to everyone at once, so I'd like to work with a small group to put it through "sea trials."
Major changes/features include:
User authentication with hashed password storage; User group configuration with application restriction (admin, dashboard, API); Detailed control over API access, with user- and token-based authentication/authorization; Improvements to the HTTPS service; Improvements to UI coordination with the core for Rules and Reactions.If this sounds like something you'd like to help with, drop me a reply here in this thread or privately.
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.That's probably more appropriate to post on Mantis for @toggledbits, but since I know there's at least @Crille publishing templates, my intent with this post is to open a broader discussion.
Long story short: I'm starting to slowly add new template for Shelly Plus and I noticed I'll end up with a dozen more templates, all similar but simply different in trivial details, all sharing a large amount of code and all needing special cares when fixing bugs/adding features (as the latest wifi_status addition).
So, I'm wondering if it's time to start thinking of some sort of inheritance in templates, where I could just create a generic shelly_gen1 and use it as a base for shelly_relay, and this be used as the base for shelly_relay_power and so on.
I could probably achieve this with some sort of scripting on my side to generate templates via code, but maybe there's a better way of doing this, or it's already on the radar.
Good morning,
I'm running userauth-24137-57b41335 on Fedora 39, bare metal installation.
ZWaveJSController 0.1.23254
Home Assistant:
Core, 2024.5.3 Supervisor, 2024.05.1 Operating System, 12.3 Frontend, 20240501.1I'm trying to troubleshoot a Dynamic Group Controller and notification alert that I've set up for low battery level.
In my Reactor.config, I have the following lines:
name: "Dynamic Group Controller" implementation: DynamicGroupController config: groups: "zwavejs_dead": select: - include_group: "zwavejs" filter_expression: "entity?.attributes?.zwave_device?.status == 3" group_actions: true "low_battery": select: - include_capability: battery_power filter_expression: > entity.attributes.battery_power.level < 0.35The idea here is that I should only have members of this group that have a battery level below 35%. When I go into Entities, I show a whole slew of devices, none of which have a battery level below the threshold.
a77e445b-ab78-4752-a624-3c4117f34f90-image.png
I also tried setting up a rule to generate a push notification once a day, but with all of the group members, I've had to disable the rule. I believe I have it set up correctly, but I'm not 100% sure. I want the notification to tell me the battery level for that device as well.
289b4f68-03ba-49c0-8275-f0f197d13a3a-image.png
ce24a76e-6865-40bd-bd85-632e54d315a8-image.png dc837424-deb5-4ef7-8f0d-3676f1769535-image.png
Can anyone point to me what I may have misconfigured to get these results?
I should also note I'm only interested in ZWaveJS devices. It's showing me battery status for my iPad and car as well, which I don't need it to send me.
I have a case where I'm trying to send a MQTT message similar to the example below:
Topic: pool/set { "command": 4, "value": 1, "time": 0, "interval": 0 }But I need to set "value" so that it is an integer between 20-30. I thought I could use "dimming" capability here, but there's probably a better way. @therealdb ?
(Using userauth-24120-7745fb8d build in Docker)
There's a filtering capability for entities in reactor.yaml, but I have a case where I don't want to filter an entity altogether, but would like to "throttle" it, as this sensor updates every 1-2 seconds (and therefore unnecessarily takes database space).
Sensor data comes through home assistant, and seems that there's no way to control update interval at that end.
So I'm asking if plugin configuration could support limiting/throttling updates for certain entities?
Good morning,
Hopefully this is a simple request. I believe the title should be self explanatory, but just in case, I'll elaborate.
On the status tab, we all get alerts if a device state has changed (i.e., been removed). This is great, but when I go into the entities tab, I have to either type the name (or a portion thereof) of the device that has been removed, or I need to scroll all the way through my list of devices. This is infrequent, however, yesterday I replaced a failed device in my HAAS environment. It was a Z-Wave switch that is added using the Smart Scan QR code, which normally makes it pretty easy. However, some devices don't get fully added the first time around, so it'll add multiple entries into HAAS until it get's the S2 authentication correct and the device fully included. It did this to me yesterday, and I had to delete the incomplete device from my installation. MSR still saw the entities of that failed/incomplete switch entity, and I was left with 8 alerts and entities that I needed to removed.
It's not a huge problem, but this example was just one switch. If I were to add replace multiple devices at once, this could be a bit more annoying to remove. It would be helpful to be able to filter by removed entities, so I can find them all quickly and delete them. Continuing that train of thought, it would also be useful to have check boxes next to those lines, and perhaps do a select all type of thing so they could be deleted in one mouse click.
@toggledbits I have finally finished up the SSL using Let's Encrypt and am getting this from my local browser:
f3d0ac22-272e-46c1-b7e3-57b08bdd1555-image.png
21c04fe1-1760-4ce6-a4de-2285d3349940-image.png
3a7022db-5add-40a1-b9a2-0c0b97fa211b-image.png
I know you said in the docs that using a self-signed could lead to this but this is LE.
Hi @toggledbits,
I don't know if I'm the only one, so I'm reporting here first instead of opening a bug.
Basically, with the latest 2-3 updates of Reactor and MQTTController, after a restart previous statuses are lost (for both Virtual and MQTT entities), until they're restored.
It's particularly annoying for Virtual Entities, because I have to set them all over again (I've coded some defaults at startup if the values are empty, but sometimes these are not the correct values before the update).
Not easy to reproduce, and logs are gone, but the first time I tought it was me hallucinating, the second one didn't bother too much, after the third I realized it's something not coming from me.
the behavior could be seen in this screenshot:
1c007fc2-4dbc-4476-8dca-e5aa111e4642-image.png
Any hint is appreciated.
I'm slowly migrating all my stuff to MQTT under MSR, so I have a central place to integrate everything (and, in a not-so-distant future, to remove virtual devices from my Vera and leave it running zwave only).
Anyway, here's my reactor-mqtt-contrib package:
Contrib MQTT templates for Reactor. Contribute to dbochicchio/reactor-mqtt-contrib development by creating an account on GitHub.
Simply download yaml files (everything or just the ones you need) and you're good to go.
I have mapped my most useful devices, but I'll add others soon. Feel free to ask for specific templates, since I've worked a lot in the last weeks to understand and operate them.
The templates are supporting both init and query, so you have always up-to-date devices at startup, and the ability to poll them. Online status is supported as well, so you can get disconnected devices with a simple expression.
Many-many thanks to @toggledbits for its dedication, support, and patience with me and my requests 🙂
Good morning,
So Home Assistant decided to change the default weather home format that I've been using for the past year and a half. I had two Global Expressions set up to pull the high and low temp forecast for the day. Now it's pulling null values.
094c9205-cc9e-4fcc-ac4f-1bf54acea299-image.png
In the dev tools, it now uses a new service (Weather. get forecasts), plural, where the old Weather.get forecast is depreciated and now longer functions.
8c7a1fcc-dd3f-4268-a0b7-29d542f86adc-image.png
It shows a templow field, and a temperature field, which I presume is the forecast high.
When I head back over to MSR, I'm having a hard time finding those values in the Entities tab.
c5ea1048-a72e-4647-9c50-9d0c5fd20767-image.png
wx.asoftime=null wx.ceiling=null wx.ceiling_unit=null wx.cloud_cover=null wx.condition_code=null wx.description="partlycloudy" wx.feels_like=null wx.humidity=57 wx.humidity_unit="%" wx.icon=null wx.location=null wx.precipitation_1hr=null wx.precipitation_24hr=null wx.precipitation_other=null wx.precipitation_type=null wx.precipitation_unit="in" wx.pressure=30 wx.pressure_unit="inHg" wx.temperature=55 wx.temperature_unit="°F" wx.visibility=null wx.visibility_unit="mi" wx.wind_compass=210.3 wx.wind_conditions=null wx.wind_direction="SSW" wx.wind_gust=null wx.wind_speed=6.28 wx.wind_speed_unit="mph" x_hass.domain="weather" x_hass.entity_id="weather.forecast_home" x_hass.services=["weather"] x_hass.state="partlycloudy" x_hass_attr.attribution="Weather forecast from met.no, delivered by the Norwegian Meteorological Institute." x_hass_attr.cloud_coverage=85.9 x_hass_attr.dew_point=40 x_hass_attr.friendly_name="New Windsor Weather" x_hass_attr.humidity=57 x_hass_attr.precipitation_unit="in" x_hass_attr.pressure=30 x_hass_attr.pressure_unit="inHg" x_hass_attr.supported_features=3 x_hass_attr.temperature=55 x_hass_attr.temperature_unit="°F" x_hass_attr.visibility_unit="mi" x_hass_attr.wind_bearing=210.3 x_hass_attr.wind_speed=6.28 x_hass_attr.wind_speed_unit="mph"There is a x_hass_attr.temperature, but that appears to be the current temperature, not the high that I found on the dev tools screenshot.
Any ideas?
Running:
Core
2024.4.3
Supervisor
2024.04.0
Operating System
12.2
Frontend
20240404.2
MSR: latest-24057-e9add9f5
Hey Patrick, I recently have been noticing that MSR has been acting up ie. it's been needing restarts and has been slow. I began trouble shooting by looking at the logs and have noticed the following errors for a lot of entities. I thought maybe a simple reboot of RPi was needed and I kept seeing the same errors in the system logs. I am oddly enough not seeing these same errors in the MSR logs. Where things started getting weird is whenever I rebooted MSR it wouldn't come back online .I would have to restart the RPi then it would come back online. I just restarted MSR again to capture logs and it restarted fine, so I guess its good for now? I think this is more or so a corrupted SD card issue rather a MSR issue but well being troubleshooting from here. The SD card is about 1-2 years old.
Apologies if this post is everywhere, I cannot consistently recreate any oddities that are happening, that's what is leading me to believe my SD is going bad.
PS: If anyone knows how to diagnose a corrupt SD card please chime in.
MSR latest-24057-e9add9f5
Home Assistant 2024.4.3
Raspberry Pi 3b+
This system has been running flawlessly year after year for the time changes twice a year literally since MSR came out so I was caught off-guard when this happened this morning.
Time in MSR browser is EST, time on RPi is local time (DST).
76ed5313-b9b9-46d4-b0f9-462c40e99750-image.png
195e61c5-58a7-4453-b96a-18cebae75550-image.png
I've rebooted the RPi I've restarted MSR after double-checking the time on the RPi. Used a completely different browser to eliminate any caching concerns. Double-checked MSR reactor.yamla5f23151-d691-4343-8499-8e77a55528e5-image.png
What am I missing here @toggledbits ?
Hi,
For the standard capabilities MSR sends both a value record and a units record to InfluxDB. The latter I would like not to send as they are not really any use for me and it will reduce the number of records send to my InfluxDB.
Is there a quick way to do this with a filter_entities line like: *>units?
Or do I have to update all capabilities to read like this:
power_sensor:
attributes:
value: true
Cheers Rene
I'm trying to replicate this
wallbox_set_number.PNG
into a MQTT entity where I could set a number with a min and max value.
I can't find a standard capability that fits or any documentation on local MQTT capabilities and the only post on the forum mentioning local MQTT capabilities is this post, is it even possible in current release?
My trial and error work in local_mqtt_capabilities.yaml isn't much to show as it's just a copy of mqtt_capabilities.yaml with changed names and then I got stuck.
Any guidance, examples, documentation, future feature request or denial would be much appreciated, thanks!
Reactor 24057-e9add9f5 bare metal
MQTTController 24050
Hi guys,
I've recently bought a new Govee outdoor permanent lights set, and I love it. WAF is pretty high, and the product is good quality. I hope to never run lights in the front of the house.
This new addition has found me searching for something to control these lights, locally. Govee has officials remote and LAN APIs and Home Assistant has it supported, but some undocumented stuff that's integrated into an Homebridge plugin that seems very promising. Without this plugin, my playlist is orchestrated via the cloud and that makes zero sense.
In the past I got some inspiration from plugins running on other platforms and Homebridge seems one of the most active. I could map its devices via HomeKit-local on HA, but I've decommissioned Homebridge years ago when we settled to Alexa (and I want to stay simple), so I had an idea: why get inspiration and rewrite things, when you could write an Homebridge adapter that could load any Homebridge plugin and run them natively under Reactor (MSR)?
I'm not sure if that's viable or made any sense, so I'm posting here to get feedback, encouragement and your thoughts. Anyone could be potentially interested in such a thing?
Hi- looking for a hint in where to start. My goal is to set a PIN code in a zwave kwikset lock triggered in a rule.
The device isn’t exposing methods to help. The x-hass.call-service looks promising, but what would the service name be?
Plan b would be send the zwave controller a config command- I don’t see any way to explicitly send a command through JS Zwave in my environment.
Running reactor bare metal. JS Zwave is running as an add on inside HASS OS.
Any tips are appreciated.
Hey crew, I'm trying to use MSR to control the RGB values of a Z-Wave bulb in Home Assistant.
Problem I'm running into - I would like to use 'rgb_color.set' to control this, but it doesn't work, instead it always passes the values '255,255,255' to HA no matter what values I enter within MSR.
More notes and examples below - I'm wondering if this is a formatting issue that I'm missing? Thanks for any help!
NOTES FROM TROUBLESHOOTING:
'rgb_color.set_rgb' works successfully, which seems strange. You'd think they would both be affected I've tried a couple different formats, like adding quotes, adding/removing spaces between the RGB values, nothing has fixed it.EXAMPLES:
When I use 'rgb_color.set_rgb', the values successfully carry over to Home Assistant:
f0f4befc-a642-428e-8923-e5f856ca7e2b-image.png
0af0a4f8-50b9-4100-b1e8-52a0de4cbcbb-image.png
But when I use 'rgb_color.set', the values DO NOT successfully carry over to Home Assistant:
9e2d7004-8085-4b70-bb3e-45614b7260a0-image.png 0d630228-c74b-4db8-89bd-2572a08608a3-image.png
DETAILS:
Bulb is LZW42 by Inovelli MSR version: stable-23242-5ee8e1d4HA DETAILS
Core 2024.2.5 Supervisor 2024.02.1 Operating System 12.0Reactor (Multi-System/Multi-Hub) Announcements
-
Build 22142 (latest, zwavejs)
- PR 0000321: HTTP API
perform
action does not send response when it succeeds (clients then time out waiting for the response that never comes). - PR 0000320: API Docs: Fix
entity
API examples.
- PR 0000321: HTTP API
-
Build 22149 (latest, zwavejs)
- PR 0000322: EzloController: provide mapping for Xiaomi Mini Switch (a single-button remote).
- Rule: make sure clear of trouble state (on startup) is saved if necessary (so UI updates properly without need to refresh).
- VeraController: Hack for variables named
sl_
, which are the special Luup state variables that always send updates/call watches even when set to the same value they already have (all other state variables in Vera/Luup do not behave this way, they only trigger events when their values change). In particular, thesesl_
states are changed when lock codes on locks are entered, or buttons on scene controllers are pressed. For these uses, it is important that a repeated use of the same code or button signals an additional event, so Vera/Luup's uses these specialsl_
states for those. VeraController now inserts an extra_updated
attribute of the same name that can be used with the changes operator to detect when thesl_
states are updated. Refer to this forum post for more information.
-
Build 22168 (latest, zwavejs, stable)
REMINDER: As previously announced, all docker images are now named with the release branch and target architecture only. The
latest
branch docker image for all x86_64/amd64 systems is now namedlatest-amd64
(was previouslylatest-generic-amd64
). Thelatest
branch image for armv7l, which includes Raspberry Pi systems on Raspbian Buster, is now namedlatest-armv7l
(was previouslylatest-raspbian-armv7l
). Please adjust your upgrade procedures and, if used, docker-compose or Portainer configurations accordingly.- NUTController (for Network UPS Tools) is now available as an installable extra.
- Documentation updates to reflect updated installation archive and docker image names.
-
Build 22178 (latest, zwavejs)
NOTE: I will be on holiday for most of the month of July, and with limited Internet access. During this time, I will not be able to provide software support, fixes or builds, and likely will not have much time or means to read and answer questions. Please step up and provide support to your peers if questions come up!
- HassController: Set null state for switches and sensors when Hass reports them unavailable.
- HassController: Bless Hass to 2022.6.7.
- Docs: Improve details in Synology/Docker installation.
-
Build 22179 (latest, zwavejs)
NOTE: I will be on holiday for most of the month of July, and with limited Internet access. During this time, I will not be able to provide software support, fixes or builds, and likely will not have much time or means to read and answer questions. Please step up and provide support to your peers if questions come up!
- HassController: Fix an issue that may randomly affect/disable assignment of primary attributes (since 22118).
- Fix a problem in after...within (time-restricted) sequence conditions.
-
Build 22203 (latest, zwavejs)
- Expressions: the
time()
function has been extended to allow parsing of date/time values in strings in forms beyond ISO-8601; most simple date/time forms should work, particularly those that closely adhere to your locale's default. A string that contains only a time will be converted to that moment on the current date; a string that contains only a date will yield midnight on that date. If a given string cannot be converted, an error will be thrown. Refer to the documentation for Expressions for more information. - HassController: Bless Hass to 2022.7.6
- Docs: documentation for Reactions now includes additional information about rule-based reaction behaviors and action groups, and has been "modernized" to use the terminology of Multi-Hub Reactor rather than that of the Reactor for Vera plugin.
- Expressions: the
-
Build 22233 (latest, zwavejs)
BARE-METAL INSTALL USERS: When upgrading to this version, you must upgrade package dependencies after unpacking the archive file (delete any existing
package-lock.json
file and then runnpm install --no-save --omit dev
). The UI will not function properly if you fail to perform this upgrade.ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
- Upgraded the Bootstrap library to 5.2, which gave rise to a large number of required UI changes, and an opportunity for some useful cleanups. The Bootstrap Icons library was also upgraded to 1.9. All of this also means that Internet Explorer is no longer a supported browser (use its replacement, Edge).
- HassController: Bless Hass to 2022.8.6
-
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.failed
and.configured
are 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.run
action. Automations also can be en-/disabled using thepower_switch
capability 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
auth
entry 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_PATH
environment 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_PATH
for 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_service
could not perform substition in itsdata
argument. 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_PATH
for 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_PATH
for 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_meta
property. 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.state
we would get the value of thestate
attribute in thepower_switch
capability 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 thelastupdate
property 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.reload
action 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.reload
to restart Luup, please switch tox_vera_sys.reload
. As of this build,sys_system.reload
will 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_PATH
for 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.set
action was missing, and nativetoggled
capability 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_PATH
for 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_sensor
capability in addition to the ubiquitousbinary_sensor
, andmotion_sensor.state
will 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
location
capability for geographic location (attributes: latitude, longitude, elevation). This is intended as a target for geolocation integrations. - Docs: Updated for new
owntracks_in_region
template. - 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.restart
on 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
-
-
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.value
rather 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_entity
andexclude_entity
selectors now can use a regular expression to match entity canonical IDs. [docs] - InfluxFeed: New advanced attribute handling key
skip_null
to 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.value
orhumidity_sensor.value
attributes, and not the genericvalue_sensor.value
attribute -- 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_region
adds auser
field that can be set if your Owntracks needs it. The Owntracks topic is/owntracks/user/deviceid
, so theuser
field should be set in your entity configuration (withtopic
andregionName
to whatever is in thatuser
portion of the topic (e.g. if your Owntracks publishesowntracks/fred/fredsphone
thentopic
should be set tofredsphone
anduser
should 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