Rule to turn specific lights on/off. Created a virtual switch âAll lightsâ and a rule to test and act upon the VS state. Rule should turn on/off all lights as stated in the rule regardless of their current states. There are two issues.
First the rule appears to run twice. The state of the lights is only changed once per rule execution.
Second, if one of the physical lights referenced in the rule is on (via a dashboard or the logical device itself), and the VS toggled to on, the rule may or may not run. Same is true if one light is off and the VS is toggled to off. As just described, the rule may operate properly 7 of 10 times. Adding the delay seemed to help, although it shouldnât matter as the delay is after the trigger. Otherwise the rule operates as it should.
Iâve deleted the VS and rule, and rebuilt but both issues persist.
dev:8332022-11-04 11:10:34.464 AMinfoSecond floor light was turned on
dev:10302022-11-04 11:10:34.259 AMinfoBedroom light was turned on
app:9352022-11-04 11:10:34.223 AMinfoAction: END-IF
app:9352022-11-04 11:10:34.221 AMinfoAction: Off: Second floor light, Bedroom light (skipped)
app:9352022-11-04 11:10:34.219 AMinfoAction: ELSE (skipping)
app:9352022-11-04 11:10:34.202 AMinfoAction: END-IF
app:9352022-11-04 11:10:34.199 AMinfoAction: Off: Second floor light, Bedroom light (skipped)
app:9352022-11-04 11:10:34.162 AMinfoAction: ELSE (skipping)
app:9352022-11-04 11:10:34.153 AMinfoAction: Set color: Bedroom light Blue Level: 10
app:9352022-11-04 11:10:34.133 AMinfoAction: Set color: Bedroom light Blue Level: 10
app:9352022-11-04 11:10:34.130 AMinfoAction: On: Second floor light
app:9352022-11-04 11:10:34.127 AMinfoAction: IF (All lights(on) is on(T) [TRUE]) THEN
app:9352022-11-04 11:10:34.101 AMinfoAction: On: Second floor light
app:9352022-11-04 11:10:34.097 AMinfoAction: IF (All lights(on) is on(T) [TRUE]) THEN
app:9352022-11-04 11:10:34.074 AMinfoDelay Over: Delay 0:00:01
app:9352022-11-04 11:10:34.042 AMinfoDelay Over: Delay 0:00:01
app:9352022-11-04 11:10:33.010 AMinfoAction: Delay 0:00:01
app:9352022-11-04 11:10:33.006 AMinfoAction: // Delay seems to aid reliability, or rule may not run. Also, rule is duplicated in logs.
app:9352022-11-04 11:10:32.986 AMinfoAction: Delay 0:00:01
app:9352022-11-04 11:10:32.981 AMinfoAction: // Delay seems to aid reliability, or rule may not run. Also, rule is duplicated in logs.
app:9352022-11-04 11:10:32.931 AMinfoTriggered: All lights(on) turns on
app:9352022-11-04 11:10:32.893 AMinfoEvent: All lights switch on
app:9352022-11-04 11:10:32.890 AMinfoEvent: All lights switch on
dev:10422022-11-04 11:10:32.622 AMinfoAll lights was turned on
The biggest issue I see is that (assuming All Lights is a switch) your rule will trigger twice any time the switch turns on or off, these being the only two possible states: you have a trigger for on, a trigger for off, and a "changed" trigger that will capture any transition of this attribute (so these). I'd look at that before anything else.
The purpose of including on/off/changed was to capture all possible switch modes. Removing the on/off, or the changed mode, stopped the rule from repeating.
The second issue remains. What is happening is if the VS is on, turning it on again does not initiate a RM triggered event, therefore, the rule does not run.
Groups and scenes wonât work because they donât have precise enough control (color, level) over a device. But a scene comes close.
I am trying to implement a manual rule â one without a trigger other than a request â tap (click) or voice. âAlexa, turn all lights onâ where âall lights onâ is a command.
There are only two states, on and off. An "on" trigger and "off" trigger will capture both, and so will a "changed" trigger. There is no need for both, and having both is a recipe for concurrent execution (not always a problem, but not always desirable).
This isn't really a RM-specific issue, and using the triggers you have now won't solve it if that's why you tried this. In general, events represent state changes. Commanding "on" to a switch that is already on will not result in one, thus no event. There are ways around this: a virtual butron (all button events generate, well, events), a virtual switch with "auto off" so it's a ways ready to turn on again (getting a state change when you do), or perhaps a custom virtual a witch driver that a ways generates events with commands regardless of states.
For your particular automation: I'm not sure what all your goals are, but have you looked at Room Lighting? It seems like it can do what you want, and you'll get an (optional) activation device you can use like this switch.
A manual rule â associate is some manner 5 lights together and give one command to turn all five on. If two are already on, turn the remaining 3 on (or resend the âonâ command to all.)
Room Lighting controls the light level, so itâs closer. Problem is that if the Activator Device is off, sending another off does nothing other than âAlready Turned Offâ in the logs. That is no different than my original rule in RM (minus the changed-state test.)
I did find that âAll lights onâ is a reserved phrase with Alexa. Without a device named âAll lights onâ, Alexa turned on all devices that are lights â physical and virtual. The command even went to my Vera controller and turned on some of its lights. Iâve been renaming the Vera scenes with the prefix Veraâ to avoid confusion and ensuring device names are unique between the systems. Maybe itâs just gremlinsâŚ
You can use command device irispective of state in Room lighting. Sounds like your devices are not reporting correctly. You can also turn on indicator in room lighting and select the option of ON if any of the devices are ON. That way when any of your device get turned on it will show ON so that allows your to do a off.
To close this topic, my solution uses Room Lighting. My goal as stated is to associate any number of lights together and issue one command to turn all on (or off). If two are already on, turn the remaining on. My solution uses a virtual switch to control the Room lightening âruleâ because it controls lights more precisely (color, level) and it has fewer device options than the Activator Device generated by Room Lightning. Room Lighting, however, like Rule Manager, is not triggered by an âonâ if the VS is already on. (Running the actions in the rule I created (image above) works perfectly, but thereâs no access from outside RM.) The solution, therefore, is not exactly what I wanted, but it will work for now.
