Good morning,
I'm trying to figure out if there is a way to evaluate if a command was completed and retry if it did not complete.
I have 14 iBlinds 3.1 z-wave controllers in my home. 95% of the time, they work just fine. Occasionally, I'll get a blind that does not open on the first attempt. When I go into Home Assistant, and manually open or close the blind, it works.
I have 3 reactions set up for each room. One to open, one to close, and one partial open for sun glare. Each of them is set up as below.
5afc9924-4300-4718-9e23-8855c4a3a9fd-image.png
The reactions are set up to wait for 5 seconds before going onto the next blind, so the z-wave network doesn't get overwhelmed.
In addition, the set command to run the reactions has "Wait for completion" checked.
3919fc06-c1f1-4c49-bf95-716028d18a27-image.png
I also have a routine set up whenever a z-wave device reports as non-functional (dead), it'll get pinged to wake it up. This usually works to wake them up.
16df4bff-c733-4ec2-a55c-c964238ada3b-image.png
Appreciate any ideas to make this more reliable.
I'm running:
Reactor latest-24190-bd310acc, Bare-metal on Fedora WaveJSController [0.1.23326] Home Assistant: 2024.7.0I think this feature request could be accomplished with the use of two or more rules, but it would be great if there was a way to wait for an event or trigger to occur before continuing on in the reactions.
For example, I have a rule that will turn on some exterior lights if you arrive home after the porch lights have been turned off. Right now this rule randomly will turn off between 5-10 minutes after the person has entered the geofence. On some occasions this 5-10 minutes isn't long enough, say if you are unloading the car or something. I would like to kick off the reaction, but pause it part way through and wait for the door to close and lock, then continue it on. Hubitat Rule Machine has a "Wait for event" option, but I really want to keep all my logic within MSR.
Good morning,
I'm going through my ruleset this morning, trying to get away from haas>blahblablah entries and completely migrate them all to zwavejs>xx-0 entries where possible.
I have 3 Aeon MultiSensor 6 devices in my home, all USB powered.
When using Haas entries, I see an entry for hass>binary_sensor_guest_bedroom_multisensor_home_security_motion_detection, and motion_sensor.state (primary)
Screenshot 2024-07-25 at 8.25.53 AM.png
Under ZwaveJS, this entry appears to be missing.
Screenshot 2024-07-25 at 8.26.51 AM.png
From the Entities page:
battery_power.level=1
battery_power.since=1721910337433
binary_sensor.state=false
humidity_sensor.units="%"
humidity_sensor.value=46
light_sensor.units="Lux"
light_sensor.value=5
tamper.state=false
temperature_sensor.units="°F"
temperature_sensor.value=73.8
x_debug.dt={}
x_zwave_values.Basic_currentValue=0
x_zwave_values.Battery_isLow=false
x_zwave_values.Battery_level=100
x_zwave_values.Binary_Sensor_Any=false
x_zwave_values.Configuration_Automatic_Report_Group_1_Battery_1=1
x_zwave_values.Configuration_Automatic_Report_Group_1_Humidity_64=1
x_zwave_values.Configuration_Automatic_Report_Group_1_Luminance_128=1
x_zwave_values.Configuration_Automatic_Report_Group_1_Temperature_32=1
x_zwave_values.Configuration_Automatic_Report_Group_1_Ultraviolet_16=1
x_zwave_values.Configuration_Automatic_Report_Group_2_Battery_1=0
x_zwave_values.Configuration_Automatic_Report_Group_2_Humidity_64=0
x_zwave_values.Configuration_Automatic_Report_Group_2_Luminance_128=0
x_zwave_values.Configuration_Automatic_Report_Group_2_Temperature_32=0
x_zwave_values.Configuration_Automatic_Report_Group_2_Ultraviolet_16=0
x_zwave_values.Configuration_Automatic_Report_Group_3_Battery_1=0
x_zwave_values.Configuration_Automatic_Report_Group_3_Humidity_64=0
x_zwave_values.Configuration_Automatic_Report_Group_3_Luminance_128=0
x_zwave_values.Configuration_Automatic_Report_Group_3_Temperature_32=0
x_zwave_values.Configuration_Automatic_Report_Group_3_Ultraviolet_16=0
x_zwave_values.Configuration_Automatic_Reporting_Interval_Group_1=3600
x_zwave_values.Configuration_Automatic_Reporting_Interval_Group_2=3600
x_zwave_values.Configuration_Automatic_Reporting_Interval_Group_3=3600
x_zwave_values.Configuration_Automatic_Temperature_Reporting_Unit=2
x_zwave_values.Configuration_Battery_Level_Threshold=10
x_zwave_values.Configuration_Current_Power_Mode_65280=0
x_zwave_values.Configuration_Humidity_Above_Lower_Limit_32=0
x_zwave_values.Configuration_Humidity_Below_Lower_Limit_2=0
x_zwave_values.Configuration_Humidity_Change_Threshold=10
x_zwave_values.Configuration_Humidity_Recover_Limit=5
x_zwave_values.Configuration_Humidity_Sensor_Calibration=0
x_zwave_values.Configuration_LED_Blinking=0
x_zwave_values.Configuration_Lighting_Recover_Limit=10
x_zwave_values.Configuration_Lock_Configuration=0
x_zwave_values.Configuration_Low_Battery_Threshold=20
x_zwave_values.Configuration_Low_Temperature_Alarm_15_C=0
x_zwave_values.Configuration_Lower_Humidity_Limit=50
x_zwave_values.Configuration_Lower_Lighting_Limit=100
x_zwave_values.Configuration_Lower_Temperature_Limit_4294901760=320
x_zwave_values.Configuration_Lower_Temperature_Limit_Unit_3840=2
x_zwave_values.Configuration_Lower_Ultraviolet_Limit=4
x_zwave_values.Configuration_Luminance_Above_Lower_Limit_64=0
x_zwave_values.Configuration_Luminance_Below_Lower_Limit_4=0
x_zwave_values.Configuration_Luminance_Change_Threshold=100
x_zwave_values.Configuration_Luminance_Sensor_Calibration=0
x_zwave_values.Configuration_Motion_Sensor_Report_Type_to_Send=2
x_zwave_values.Configuration_PIR_Sensitivity=3
x_zwave_values.Configuration_PIR_Sensor_Timeout=20
x_zwave_values.Configuration_Recover_Limit_Temperature_Unit_255=2
x_zwave_values.Configuration_Report_Above_Humidity_Threshold_32=0
x_zwave_values.Configuration_Report_Above_Luminance_Threshold_64=0
x_zwave_values.Configuration_Report_Above_Temperature_Threshold_16=0
x_zwave_values.Configuration_Report_Above_Ultraviolet_Threshold_128=0
x_zwave_values.Configuration_Report_Below_Humidity_Threshold_2=0
x_zwave_values.Configuration_Report_Below_Luminance_Threshold_4=0
x_zwave_values.Configuration_Report_Below_Temperature_Threshold_1=0
x_zwave_values.Configuration_Report_Below_Ultraviolet_Threshold_8=0
x_zwave_values.Configuration_Reset_Parameters_101_103_to_Default_Values=null
x_zwave_values.Configuration_Reset_Parameters_111_113_to_Default_Values=null
x_zwave_values.Configuration_Reset_to_Factory_Default_Setting=null
x_zwave_values.Configuration_Selective_Reporting=0
x_zwave_values.Configuration_Sleep_State_255=2
x_zwave_values.Configuration_Temperature_Above_Lower_Limit_16=0
x_zwave_values.Configuration_Temperature_Below_Lower_Limit_1=0
x_zwave_values.Configuration_Temperature_Calibration_Offset_65280=0
x_zwave_values.Configuration_Temperature_Calibration_Unit_255=2
x_zwave_values.Configuration_Temperature_Change_Threshold_4294901760=20
x_zwave_values.Configuration_Temperature_Recover_Limit_65280=20
x_zwave_values.Configuration_Temperature_Threshold_Unit_3840=2
x_zwave_values.Configuration_Ultraviolet_Above_Lower_Limit_128=0
x_zwave_values.Configuration_Ultraviolet_Below_Lower_Limit_8=0
x_zwave_values.Configuration_Ultraviolet_Change_Threshold=2
x_zwave_values.Configuration_Ultraviolet_Recover_Limit=2
x_zwave_values.Configuration_Ultraviolet_Sensor_Calibration=0
x_zwave_values.Configuration_Upper_Humidity_Limit=60
x_zwave_values.Configuration_Upper_Lighting_Limit=1000
x_zwave_values.Configuration_Upper_Temperature_Limit_4294901760=824
x_zwave_values.Configuration_Upper_Temperature_Limit_Unit_3840=2
x_zwave_values.Configuration_Upper_Ultraviolet_Limit=8
x_zwave_values.Configuration_Wake_Device_for_10_minutes_After_Power_On=1
x_zwave_values.Configuration_Wake_Up_Timeout=15
x_zwave_values.Manufacturer_Specific_manufacturerId=134
x_zwave_values.Manufacturer_Specific_productId=100
x_zwave_values.Manufacturer_Specific_productType=258
x_zwave_values.Multilevel_Sensor_Air_temperature=73.8
x_zwave_values.Multilevel_Sensor_Humidity=46
x_zwave_values.Multilevel_Sensor_Illuminance=5
x_zwave_values.Multilevel_Sensor_Ultraviolet=0
x_zwave_values.Notification_Home_Security_Cover_status=0
x_zwave_values.Notification_Home_Security_Motion_sensor_status=0
x_zwave_values.Notification_alarmLevel=0
x_zwave_values.Notification_alarmType=0
x_zwave_values.Version_firmwareVersions=["1.17"]
x_zwave_values.Version_hardwareVersion=100
x_zwave_values.Version_libraryType=3
x_zwave_values.Version_protocolVersion="4.54"
x_zwave_values.Wake_Up_controllerNodeId=1
x_zwave_values.Wake_Up_wakeUpInterval=3600
zwave_device.capabilities=[32,48,49,112,113,114,128,132,134]
zwave_device.endpoint=0
zwave_device.failed=false
zwave_device.generic_class="Multilevel Sensor"
zwave_device.impl_sig="23326:1:22315:1"
zwave_device.is_beaming=false
zwave_device.is_listening=true
zwave_device.is_routing=true
zwave_device.is_secure=false
zwave_device.manufacturer_info=[134,258,100]
zwave_device.max_data_rate=null
zwave_device.node_id=53
zwave_device.specific_class="Routing Multilevel Sensor"
zwave_device.status=4
zwave_device.status_text="alive"
zwave_device.version_info=[null,"1.17"]
zwave_device.wakeup_interval=3600
I'm running:
Reactor latest-24190-bd310acc, Bare-metal on Fedora
WaveJSController [0.1.23326]
Home Assistant: 2024.7.0
I'm fetching certain data five past every hour, but I would like to do it closer to the hour, e.g. 1 or 2 past (but not at the hour).
I experimented with the following rule that almost works (triggers also at the hour which is not the intention). Any advice for a solution?
It would be nice to have an ability to bookmark a direct link to a dashboard item. In my case I would use this feature to access a virtual switch directly.
Hi @toggledbits
Would you please consider adding an extra sublevel in the rulesets?
I have grouped my rules in rooms/ areas. This works great for me, but I would also like to group rules for the same functionality (in a room). This would make the rules easier to find and name.
Please let me know if this is an option. Thanks!
@togglebits I am curious as to why the tilt_sensor.state (primary) = NULL. I believe it should show true or false. I have to use binary_sensor.state instead in my rules.
Again, not sure if this is related to Reactor/ZwaveJSController implementation or the actual Z-Wave JS UI docker version. I have copied, below, the attributes of the tilt sensor in hopes it can help.
Thanks in advance.
Reactor version 23302
ZWaveJSController version 23254
Z-Wave JS UI version 9.3.0.724519f
zwave-js version 12.2.3
@toggledbits,
I have this device attached to my system, but use a DSC panel. If you need testers to move forward, I'm happy to help.
I'm curious what your thinking the use case is for this. I currently have it integrated into HomeAssistant, and it works fine for the most part. The one thing I can't do is bypass zones, which I would like to have the ability to do.
Are you looking at more direct control for the panel, as opposed to having to jump through HA (or another system) first?
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.I have the following ruleset which I though had been working well until this morning when I noticed it's not.
I've put four weather conditions in an in array and one of them is the current weather condition - but the rule is not true. Now the cloud cover percentage is not yet met but this is an or rule so as long as the "Current Conditions" are met then it should go true.
What's the obvious thing I'm missing here? (I've tried spaces/no spaces in the in and no difference.)
Hi,
Running the latest MSR latest-24152-3455578a with the latest HA 2024.6.1. When trying to call a service I get the following in the MSR logs. Is this a version mismatch? I am not seeing anything in the HA logs.
[latest-24152]2024-06-11T10:29:56.162Z <Rule:INFO> rule-Monitor-DHW (rule-lsvq5k3x in Central Heating) started [latest-24152]2024-06-11T10:29:58.625Z <HassController:WARN> HassController#hass unknown service opentherm_gw.set_hot_water_setpoint in x_hass.call_service action on Thermostat#hass>climate_living_room_otgw [latest-24152]2024-06-11T10:29:58.626Z <HassController:INFO> HassController#hass: sending payload for x_hass.call_service on Thermostat#hass>climate_living_room_otgw action: [Object]{ "type": "call_service", "service_data": { "gateway_id": "living_room_otgw", "temperature": 65 }, "domain": "opentherm_gw", "service": "set_hot_water_setpoint", "target": { "entity_id": "climate.living_room_otgw" } } [latest-24152]2024-06-11T10:29:58.627Z <HassController:ERR> HassController#hass request 1718101798626<6/11/2024, 12:29:58 PM> (call_service) failed: [Object]{ "id": 1718101798626, "type": "result", "success": false, "error": { "code": "invalid_format", "message": "extra keys not allowed @ data['entity_id']" } } [latest-24152]2024-06-11T10:29:58.627Z <HassController:WARN> HassController#hass action x_hass.call_service([Object]{ "service": "opentherm_gw.set_hot_water_setpoint", "data": "{ \"gateway_id\": \"living_room_otgw\", \"temperature\": 65 }" }) on Thermostat#hass>climate_living_room_otgw failed!Cheers Rene
Some background
I'm trying to integrate a Zigbee device into the MSR using zigbee2mqtt bridge and MQTTController. The device in question is a cheap mood light that has following properties that I'd like to control:
I'v already managed to get the switch part working and can toggle the light on/off. Also the brightness value is mapped back to MSR. In zigbee2mqtt it has a value range from 0 to 254, so this the reason for the expression:
expr: 'payload.brightness / 254'Here's the entity definition (don't know whether the type should be something else than the Switch)
zigbee-lidl-mood-light: name: 'Lidl Mood Light' friendly_name: 'Mood Light' type: Switch uses_template: lidl-moodlightAnd the corresponding template (NOTE: rgb_color has not been defined in this example):
lidl-moodlight: init: "zigbee2mqtt/%friendly_name%/get/state" query: "zigbee2mqtt/%friendly_name%/get/state" capabilities: - power_switch - toggle - dimming primary_attribute: power_switch.state events: "zigbee2mqtt/%friendly_name%": "power_switch.state": json_payload: true expr: 'upper(payload.state) == "ON"' "dimming.level": json_payload: true expr: 'payload.brightness / 254' actions: power_switch: "on": topic: "zigbee2mqtt/%friendly_name%/set/state" payload: 'ON' "off": topic: "zigbee2mqtt/%friendly_name%/set/state" payload: 'OFF' set: topic: "zigbee2mqtt/%friendly_name%/set/state" payload: expr: "parameters.state ? 'ON' : 'OFF'" type: raw toggle: topic: "zigbee2mqtt/%friendly_name%/set/state" payload: 'TOGGLE'The problem
In order to control the brightness or the RGB color values, I would have send a JSON payload in corresponding actions. But I have no idea how to define it in the template. The reason why the switch part is working is that the zigbee2mqtt accepts also plain ON / OFF / TOGGLE string payloads in that case.
But the brightness should be controlled with the following payload:
{"brightness": 196}And the RGB color like:
{"color":{"rgb":"46,102,150"}}Here's the link for the documentation (the Exposes part defines the messages).
So how should I define the JSON payload for example for the dimming action? It definitely should be some sort of expressions since I have to map the MSR real value (0...1) to (0...254) for the zigbee2mqtt.
actions: dimming: set: topic: "zigbee2mqtt/%friendly_name%/set" payload: expr: ????? type: jsonAnother problem is the RGB value. I could use the rgb_color capability for the setting but the problem is that the zigbee2mqtt only reports the current color in hue/saturation or xy coordinates.
Here's an example of published message after setting the color:
Topic: zigbee2mqtt/Mood Light QoS: 0 { "brightness":254, "color":{ "hue":240, "saturation":100, "x":0.1355, "y":0.0399 }, "color_mode":"xy", "color_temp":574, "linkquality":96, "state":"ON" }I would have to map those values back to RGB, but is it even possible with existing constructs in MQTTController's templates?
Help would be appreciated @toggledbits
br,
mgvra
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.
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.
[Solution: Reactor 24115 is not compatible with MQTTController > 24120]
Reactor latest-24115 bare metal.
All MQTT entities stop working after updating MQTTController to 24142, downgrade to 24120 and they are back. Templates and configured entities has not been changed between versions.
I'm not sure if uses_template should be replaced by ìnclude in entity configuration in reactor.yaml but I guess not, I've tried it and it did not do any difference.
I have not tried to update Reactor to userauth version.
Example entity in reactor.yaml that uses MQTTController included template:
entities: "takflakt_kallare": name: "Takfläkt källare" topic: "Källartemp" unit: "" uses_template: tasmota_generic_relay init: "cmnd/%topic%/POWER%unit%"Any hints? Do you need more info, please let me know.
Log from startup:
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:
![](https://github.com/fluidicon.png)
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 🙂
Is the following config correct?
- id: time_series name: "Out temp" capabilities: temperature_sensor: attributes: value: model: time series entity: "hass>sensor_outdoor_temperature" attribute: "temperature_sensor.value" interval: 5 # minutes retention: 20 # minutes aggregate: wma primary_attribute: temperature_sensor.value type: ValueSensorSpecifically, is "depth" directive needed/mandatory here? Reason I'm asking is that I'm not getting a "final" value in MSR, only debug values are shown:
temperature_sensor.units=null temperature_sensor.value=null x_virtualentity.last_request_time=null x_virtualentity.request_failures=null x_virtualentity.template=null x_virtualentity.timeseries_debug=[{"time":1716537360000,"value":22.1},{"time":1716537660000,"value":22},{"time":1716537960000,"value":22},{"time":1716538260000,"value":21.9},{"time":1716538560000,"value":22}]Good morning,
I apologize if this subject has been covered. I did try the search, but I'm not coming up with any topics on my issue.
I'm running userauth-24137-57b41335, bare metal installation on Fedora 39 Server.
I have a rule set up to turn the Eco mode off on my Nest Thermostat when the thermostat is set to Away (Rule State: Away Mode), the user (Driver) presence in my car changes to true, and the destination is set to home.
93804f7c-62d6-42c0-ae04-ff602011a6fd-image.png
This works fine for most days, where I'm headed home from work (commute is about 45 minutes). What I don't want it to do is set change it to Eco mode if my ETA is more than an hour.
There is a sensor/entity for Time to Arrival when the Destination is set. What it appears to provide is the Time OF arrival/ETA, not time until arrival. If it was Time until Arrival, and it was a numeric value, I could simply test if the value is less than 60 and be done with it.
I pulled up the history through Home Assistant for my morning commute and this appears to be what it is providing.
c2a32739-c84f-4a05-95d9-73793ed818f5-image.png
So what I need to do is to do a calculation of the the ETA from the sensor value and subtract the current time, and get a value in minutes that I can determine if it's less than 60.
I believe I can do this with the local expression, but I don't see anything for the system time, or local time. Also, do the local expressions update themselves if the sensors do?
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.
Reactor (Multi-System/Multi-Hub) Announcements
-
Reactor build 23114
- Conditions: add
is NOT TRUE
andis NOT FALSE
operators. Theis NOT TRUE
operator (for example) is unlike theis FALSE
operator in that, if the tested value isnull
, theis NOT TRUE
operator result would be true, while theis FALSE
operator result would be false. This distinction facilitates some tests where it may be desirable to handlenull
as equivalent to eithertrue
orfalse
without having to provide an additional, separateis NULL
condition (and possibly an enclosing OR group). - DynamicGroupController: document group actions; this makes it an official feature (was experimental).
- Engine/Rule: Clean up a misspelled method name.
- InfluxFeed docs: update supported and recommended versions. [doc]
- HubitatController: Tweak reconnect timing decay (allow for longer decay when hub cannot be contacted for an extended period).
- Reactions: Clarify what "Disabled" means in the constraints of a Group action (incl. Repeat...While) of a reaction. It does not disable the actions in the group. The disable flag applies to the constraint conditions only, having the same effect as it would on rule-based triggers and constraints (i.e. it becomes as if the constraint conditions do not exist). [docs] and [docs]
- HassController: Bless Hass to 2023.4.6
- Conditions: add
-
MQTTController 23135
- In action payload, force conversion of all data types to string for "raw" output, rather than assuming result of expression is a string (although docs say to do that, it's just too easy to omit, and too easy to change it so the requirement is moot).
- Add
parameter: name
value form to action payload definition to draw payload value from the named parameter without the need to use anexpr
ession (this follows the implementation of action definitions in other Controller instances as well). That is, you can specify, for example,parameter: level
instead of usingexpr: parameters.level
(assuming the parameter value requires no scaling or other modifications to be compatible with the device). [docs]
-
Reactor Build 23171
NOTE: This build includes fixes made in a prior silent release (where the change(s) affected only one user).
DEPRECATION NOTICE: Support for versions of Home Assistant prior to 2022.5.3 will be removed on the next build. These older versions may continue to operate successfully with HassController going forward, but I will not address/fix issues for them.
- PR 0000356: Fix an issue where a rule with multiple sunrise/sunset conditions using the between operator chooses the first condition's before/after constraints rather than its own (i.e. it was choosing the control states from the first row rather than the current row).
- SystemController: the deprecated
suninfo.sun_angle
attribute is now removed (its replacement issuninfo.elevation
). - HubitatController: Hub variables can now be set up to 1024 characters with hub firmware 2.3.5.135 and above; for earlier firmware, the limit is 255 characters. The length limit is enforced by the hub, not HubitatController.
- HassController: Bless Hass to 2023.6.2
-
Reactor build 23196 (latest and stable branches)
NOTICE: As announced in the release note for the previous build (23171), Home Assistant versions earlier than 2022.5.3 are no longer supported.
- Introduce a maximum delay in the write-back of certain storage containers (e.g. that used for expressions).
- Docs: fix an error in an example on the How-To: Expressions with Entities page.
- HassController: Bless Hass to 2023.7.2
-
Reactor build 23218
- Improve the initialization of new global variables so they don't show "not yet evaluated" until a non-null value is set (null is a valid evaluation result and should remove the "not yet").
- Expressions: improve the display of non-printing characters in the expression editor's "current value" display (they now display as Unicode escape sequences).
- i18n: Fix init of localized weekday names when most recent Sunday occurs in prior month (caused, for example, incorrect weekday checkbox labels in Weekday conditions; cosmetic only, no operational effect).
- SystemController: for Reactor update, include update branch, version, and commit as attributes on system entity.
- Entities page: New Copy Attributes button in entity detail copies all attribute values to the clipboard.
- HassController: Bless Hass to 2023.8.0
-
Reactor Build 23242
- Rules Editor: Fixed an issue where a condition option change to the duration operator with no change to duration value may not be saved.
- HassController: Add mapping for
proximity
domain (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 thetarget
field to specify theentity_id
, rather than the old form which embedded theentity_id
in thedata
field. - HassController: The
x_hass_system.call_service
(system-global service call action) has been extended to allow the user to enter atarget
field for service calls that benefit from it. It should be noted, however, that thex_hass.call_service
action 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
case
with singlewhen
and 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.json
file from your Reactor install directory, and then runnpm i --no-save --no-package-lock --omit dev
to update package dependencies.BREAKING CHANGE: The
valve
capability'sstate
attribute value is now boolean, to match similar system capabilities (was previously/erroneously string). If you are using an entity with thevalve
capability 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
UnsafeLua
flag, required to be on for thex_vera_sys.runlua
action to be available. The value is now also published as an attribute on the system entity. - HassController: Implement new HA
valve
domain with ourvalve
capability. - 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
version
field in user templates). - PR 0000365: Fix broken config for
tasmota_generic_relay
template'stoggle.toggle
action. - New templates for genmon (generator monitoring; see https://github.com/jgyates/genmon)
- Support for new js-yaml
- Support
map
in event handling configuration.
- 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.json
file from your Reactor install directory, and then runnpm i --no-save --no-package-lock --omit dev
to 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.
-
MQTTController build 24085
- Support for Shelly H&T Gen3 (use
shelly_handt3
template 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
ext
may 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 existingext
directory 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_status
system capability for WiFi-connected devices that can report connection status. - PR 0000369 Docs: Add documentation for
ev_charger
system 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_response
on 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_status
capability 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 asfalse
in theactions
section of the template. For an example, see the templateshelly_rgbw2_color
implementation for capabilitylight_effect
actionset_speed
, and the action implementation for thebutton
capability. - Templates may now define custom actions in
x_mqtt_device
. Including anarguments
object 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_color
actionx_mqtt_device.set_white
.
-
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_template
entity configuration directive is now deprecated; useinclude
instead (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
templates
distribution subdirectory. - New
include
directive 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
baseurl
configuration 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 yourbaseurl
configuration first (if you don't have one or need an example, refer to the distribution version ofreactor.yaml
indist-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_http
tofalse
in thereactor
section ofconfig/reactor.yaml
. - The
allow_ips
in thereactor
section ofconfig/reactor.yaml
now allows CIDR address range specification (e.g.10/8
or192.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.updown
layout) 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.state
attribute to a group to show true when any light in the group is on. Refer to the docs for DynamicGroupController. - The
dist-config
directory 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 exec
into 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 atINFO
level. 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
util
functiondeepCompare()
now works with JavaScriptSet
,Map
,Buffer
, andRegExp
objects. - Developer Tools: documented
util
functionhash()
(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
stable
release 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