Groups with switches don't turn on by setting level

I have a group called "Inside Christmas". This group currently has two outlets on it, set up using "Groups and Scenes" app.

I have a simple automation rule set up that fails to turn on those lights when addressed as a group but succeeds when they are targeted as individual outlets.

Are there known bugs that would cause this?

A Group is activated by a virtual switch. Does turning this switch on from its device page turn on the lights?

Turn on logging in this SAR rule.

The group virtual switch was working only inconsistently. Deleted and recreated it with the exact same devices and now the SAR seems to be working reliably.

Perhaps there was some problem with the creation of groups in the past few weeks?

Anyway, thanks for the pointer. Now I have a ton of groups to delete and recreate.

Ah, I spoke too soon.

Today, automation rule completely failed to trigger group.

Setup:

"Christmas Outside" is set up as three outlets.

Those outlets are successfully triggered via the virtual switch under devices.

Simple Automation Rule (pre 1.1 so preexisting rule) named " Outside/christmas on Sunset -30" is set up to trigger several things, including Driveway 1, Driveway 2, Garage 1, Garage 2, Walkway and Christmas Outside to "turn on and set level to 100" .

The logs say:

dev:472020-12-03 16:23:00.764 infoOutside Front Driveway 2 was turned on

dev:462020-12-03 16:23:00.706 infoOutside Front Driveway 1 was turned on

dev:62020-12-03 16:23:00.697 infoGarage Bulb 2 was turned on

dev:52020-12-03 16:23:00.652 infoGarage Bulb 1 was turned on

dev:2762020-12-03 16:23:00.350 infoChristmas Outside level is 100%

dev:2762020-12-03 16:23:00.345 infoChristmas Outside switch was turned on

app:292020-12-03 16:23:00.185 infoOutside/christmas on Sunset -30 Turn On & Set Level

and yet, the Christmas Outside outlets were not turned on.

Suggestions? Recreate the rule in 1.1?

Please use screenshots for logs, much easier to read.

As for the logs you show, those devices are reporting they were turned on. If they were not in fact turned on, then this is a device/mesh problem, not a Simple Automation Rule or Group problem.

Thanks for the reply but I do have a question that makes your response perhaps incorrect:

Shouldn't a group "device" be followed by the individual devices?

In particular: When I manually trigger "Christmas Outside" off or on, the logs report that some of the underlying devices are turned on (or off). Shouldn't it read:

"christmas outside switch turned on"
"front porch outlet left turned on [digital]"
"front porch outlet right turned on [digital]"

, etc. ?

that's not what these logs show. they show the group (i.e. virtual switch) triggered but none of the component devices triggered.

am i misunderstanding something?

to reiterate: this works 100% of the time when i manually trigger the device from the devices tab where the group devices lives and not from simple automation.

the suggestion that it's a device mesh failure is interesting, but seems unlikely unless you can point to evidence that i should look for for that.

thanks, again!

Logs are read from the bottom up. Time flows up.

Yes. I know that. I think you're not reading what I'm writing or I'm misunderstanding something.

The physical devices are never triggered.

The virtual device is triggered.

The physical devices are not. Ever.

Please suggest troubleshooting or ask clarifying questions.

Aren't those the physical devices?

Those were turned on right after the Group device was turned on by the app:

The two devices from the group were never turned on:

Front porch outlet left
Front porch outlet right.

Those other devices are listed individually in the rule and not part of a group.

There group devices are not triggered.

OK, well, it would help if you showed the Group setup and the Simple Automation Rule setup, as that isn't obvious.

What happens when you turn on the Group activation switch from its device page? What happens when you turn on Front porch outlets left and right from their device pages?

Sorry, let's start over with screenshots.

There's a Group called Christmas outside:

That group includes three devices as listed. those devices are successfully turned on from the devices page for "Christmas Outside":
Screen Shot 2020-12-04 at 06.06.42

There is a rule called 'Outside/Christmas bright 6am':

That rule includes a rule to trigger the Christmas Outside group (among 5 other devices).

That rule triggers at 6am. That rule triggers the Christmas Outside virtual switch. The additional devices (front porch outlet left, front porch outlet right and back porch fairy lights) are never triggered. See evidence here:

Screen Shot 2020-12-04 at 06.04.51

So my contention is that this combination of rules & groups simply does not work. This could be related to the fact that this is a pre-existing rule rather than SAR 1.1 but I don't know.

I'm happy to set up additional special cases for troubleshooting but when I do (one SAR 1.1 rule to a new group with just one thing in it) it works, so there's clearly a bug here but I'm not sure where.

Thanks!

And one additional piece of info: I have a rule that actually works to turn those lights off.

Could it be something about mixing the turning on outlets and setting brightness of dimmable bulbs in the same rule?

I don't know why this doesn't work. You might try SAR 1.1 for it, and see if that makes any difference. Also, you might try putting the group activation device in a rule by itself, and see if that makes it work.

I will try to create something similar to see if I can reproduce what you're seeing.

Update: I can't reproduce this failure.

One other thing to try would be to remove the Group and recreate it. Since the group activation device is clearly being turned on by SAR, it seems whatever problem there is must be in the Group,

OK, I have it and can reproduce it. It is exactly the interaction between a dimmable device where you set a level and an outlet where you just turn it on.

To repro:

  1. create a group with at least one dimmable device (in my case sengled zigbee bulb) and one outlet (in my case a tradfri ikea zigbee device)
  2. create a rule (SAR or SAR 1.1: both fail in the same way) that triggers at a time with "turn on and set level"
  3. observe that the lights are turned on and set to that level but the outlet is not triggered at all.

happy to post screenshots of my config if you're not able to reproduce!

And additional potentially useful information:

If I change the rule so that the action is "Turn on" rather than "turn on and set level" it works for lights and the outlet but that is not my desired result because in the case of the rule I am trying to write, I'm trying to set two lights to full brightness while also turning on three outlets, for example, in a single rule.

Tell me if I'm wrong, but I think "turn on and set level" should do this, no? It is surprising to me that it doesn't.

Don't you logs show the group activation device being turned on by SAR? So isn't this a failure with the Group when a setLevel is sent to it?

Edit: Could you try this from the Group activation device page? See if setting the level turns on the plugs, as opposed to giving on command. Be sure the device is off first.

I can confirm that setting a level on a Group activation device does not turn on a switch that is part of the group. I guess it's debatable whether or not it should, since setting a level is not a function supported by a switch.

And, as i suggested earlier, this really has nothing to do with SAR. It's a Group thing.

sorry, when i read "turn on and set level" i think that it does both "turn on" and "set level." is that incorrect?

here's the current, 100% reproducible, setup that shows this as a pretty clear bug.

"test group 1" has three devices, two dimmers: "third floor office table" "third floor office desk" and one switch: "third floor office fan".

this group works perfectly from the device page:

i created a rule:

This rule fires:

Notice that "test group 1 fires (ignore the name, but was set to fire at 13:56).
notice that it claims that "test group 1 switch was turned on". this seems to be false.

this is the bug, afaict. the switch is never turned on.

the level is set to 100% and the two lights are therefore turned on and set to 100%

i can reproduce this without fail and i believe it to be a bug, although you're right it could be in the group rather than in the automation.

is this test case clear enough for you to reproduce and investigate yet?

Yes, I told you that I figured out what is going on. It's not an issue with SAR. SAR (and other apps as well) don't issue two commands for "turn on and set level". I suppose that is misleading wording. For dimmer devices, setting a level does turn them on, so no separate on command is sent, only a setLevel command is sent. In fact, you wouldn't actually want it to turn it on and then set the level, as that might entail a bright flash followed by a dim light -- not desirable. That's on the SAR side. So SAR is sending a setLevel command to the Group activation device, which is itself a dimmer, albeit a virtual dimmer.

The Group activation device does turn on from the setLevel command sent by SAR, as you can see in the logs. But, as I said above, doing a setLevel on a Group activation device does not turn on any switch in the Group. So the switches in the Group are not being turned on, because they don't have a setLevel command to respond to.

There is no point in debating whether or not a Group should behave differently, of if SAR should behave differently. What both are doing is understandable -- it just doesn't accomplish what you want. As I said above, it could be debated whether or not a Group should turn on switches in response to setLevel -- that could be argued both ways. Suffice it to say that it doesn't turn on switches for setLevel now. Suppose we sent a setColor command to a Group. Should that result in a dimmer having its level set and a switch being turned on? Don't think so... That's the logic that went into the way it works now.

There are several ways for you to get this to work, just not the one you're banging against.

1 Like