Hey @toggledbits I'm back to trying to optimize a couple of things based on dynamic group.
First of all, I think I found a typo in the doc:
primary_attribute: "binary_sensor.state"
primary_attribute_value: |
d = false;
each id in members: d = getEntity(id)?.attributes?.power_switch?.state or d,
d
I think the correct code snippet is d = false,
All that said, my use case for dynamic groups is to group 3 different climate devices, so I could easily command them at the same time. Commands are good, but sometimes I want to check if any of the devices are on, and that's easily done with a similar snippet as the one you have in the docs. But this is limited to the primary attribute, while I want to have any of the attributes in the group to be driven by a similar logic (while all are null in the group). ie, access hvac_control.mode and see if any of the unit is set to cool, or heat. Is that possible, without re-defining an expression in each of my rules? Thanks!
Edit: Solved in latest-26221.
Bare-metal latest-26193
I have this group:
"OKforLarm":
name: OK för Larm
select:
- include_controller: vera
- include_capability: door_sensor
filter_expression: entity.attributes.door_sensor.state
It contains the entities I expect but behaves a bit odd. When I open vera>device_10097 the entity attribute door_sensor.state changes to true but it won't show up as member in the group, when I also open vera>device_10095 they both shows as members and when I close vera>device_10095 it disappear from the group but when I close vera>device_10097 it lingers in the group until I restart Reactor.
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.
Hey @toggledbits
One thing that bothers me while doing work on new systems/new features, is that I cannot copy&paste actions, and I cannot drag&drop between set and resets.
#1 is for when I want to copy an action between different rules opened in two separate browser windows, while #2 is when I just need to flip a bunch of actions in the reset, or move some logic back and forth.
Both will be appreciated, but I understand the technical challenges. Thanks!
I'm currently on version 26011. I understand that the aarch64 image is no longer supported. So, I therefore need to update to the ARM64 image. Can anyone possibly suggest how I update my docker compose.yaml file (see below). Ideally I'd like to keep my existing reactions etc. rather than start from scratch.
# Multi-System Reactor template docker-compose.yml (version 22160)
#
# Change the lines indicated by "DO"...
#
services:
reactor:
container_name: reactor
environment:
# DO change the TZ: line to set your local time zone.
# See valid TZ list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
TZ: GB
#
# DO NOT change this path. Your directory location is in "source" below.
REACTOR_DATA_PREFIX: /var/reactor
# DO change the image below to the one you are using (e.g. armv7l or aarch64 for RPi 4)
image: toggledbits/reactor:latest-aarch64
restart: "always"
expose:
- 8111
ports:
- 8111:8111
volumes:
# DO change the /home/username/reactor below to the directory you created for
# your local data; DO NOT change the /var/reactor part
- /home/pi/docker/reactor:/var/reactor
- /etc/localtime:/etc/localtime:ro
tmpfs: /tmp
If you are using the armv7l docker image, the OpenJS Foundation that publishes node is no longer producing 32-bit builds as of v24. That means the last supported LTS version of node for armv7l is v22, which will go End-of-Life in May 2027.
Therefore, the Reactor armv7l image is now deprecated and will only be produced until node v22 goes EOL, and I will not publish armv7l images beyond that date.
If you are running an RPi 3 or earlier with Reactor, you are on this image, and will need to upgrade hardware to a 64-bit model and use the arm64 image. If you need help getting it done, ask in this category.
TimeStamp variable in MSR
-
from the docs
Time Handling Functions time( [ year [, month [, day [, hour [, minute [, second ]]]]]] ) — returns the current time if no arguments are given; otherwise a date/time is constructed using as many arguments as are provided; the result is a Unix Epoch time in milliseconds;
http://192.168.1.10:8111/docs/Expressions-%26-Variables/#time-handling-functions -
You may recall I cooked up a human-readable "Timestamp" expression in MSR and posted the recipe here. But like @Elcid pointed to in the Docs, you can likely get away with just using
${{ time( ) }}in your[ Set Variable ]step, and simple subtraction in your Expressions area. Don't forget to divide by 1000 forsecondsrather thanmilliseconds! -
T toggledbits locked this topic on
