Description
To simplify a dashboard, an admin may remove a large number of sensors and put them in a secondary board. The user must navigate to that board to see the status of its items. Currently, you can use triggers and flow in the rules engine to write a variable that indicates if all items are inactive or active and can display that state on the primary board via a variables tile. This involves two triggers and one flow per device. After a few devices, this becomes error-prone.
In the example show, there is a dashboard called lights, and a variable called $Lightstatus. If all lights are off, the variable is set to false (inactive). If any light is on, it is set to true (active).
User Stories
As an end-user, I want to know the status of a second board by viewing a tile on the current board so I know if something needs my attention.
As an admin, I want to set up a status tile without coding or rules engine, so that active/inactive status can be displayed to end-users.
Acceptance Criteria
System-level function to assess the active/inactive status of any dashboard. If any tile is active, the dashboard is active. If all tiles are inactive, the dashboard is inactive.
Configuration on the dashboard tile that enables showing the system level active/inactive status of the connected dashboard.
Probably better assign a tag to a group of the devices, or group them some other way and then in the rule engine support boolean operations on the group like and [true] or or [true] meaning all the devices in the group in a certain state (state can be any attribute) value can be configurable, then you can write simple aggregation rules with one-liners.
I don’t follow. This request is for the ability to aggregate the status of multiple devices into a single value.
eg. If there are 10 light switches, you could know if any of them are on or if they are all off.
Today, you would have to either aggregate these using SharpTools rules or using an app or feature from your source smart home platform. Some source platforms have grouping features, but others don’t.
That being said, you can remove your vote from a feature request at any point to move it to another feature request if you’d like.
Yes. But the request was there because the rule engine was not supporting multidevice I think and made it hard to aggregate. Today it is really a simple rule
Ah, I see what you’re saying. It’s much easier to create these kind of aggregation rules with the Multi-Device selectors in Triggers and Conditions within rules now.
I’m still going to leave the request open for the aforementioned reasons. It hasn’t picked up much interest from the community, so we’ll continue to focus on other more highly requested features in the meantime.
How do I write this new, simpler rule. If I have 5 devices that I want to see show the status of (all off , or any one on), how do I write this simple trigger? Any one on is easy. If one toggles on, set the state. A simple toggle off of a device does not work because others may be on. The rule needs to evaluate state, not changes in state. The rule is “are any of the devices on?” If yes set state 1, if no, set state 2.
I am still looking for help on how to do this simplified method.
How do I write this new, simpler rule. If I have 5 devices that I want to see show the status of (all off , or any one on), how do I write this simple trigger? Any one on is easy. If one toggles on, set the state. A simple toggle off of a device does not work because others may be on. The rule needs to evaluate state, not changes in state. The rule is “are any of the devices on?” If yes set state 1, if no, set state 2.
I believe @Ilia_Gilderman was trying to say that the configuration is significantly simplified. The approach itself doesn’t change.
Trigger:
When Device 1, Device 2, or Device 3 changes
Flow:
IF Device 1, Device 2, or Device 3 is on
THEN
→ Set $AllLights = true
ELSE
→ Set $AllLights = false
The main thing is that you can easily select multiple devices in a single Trigger block or IF Condition block which makes it easier to build the rule (rather than having to create N blocks for each device).
