How do you get rule to trigger when ON or OFF is pressed and the device is already ON or OFF?

šŸ“ Rule MachineĀ®
2

Hi Glenn
My understanding of the trigger function is "when something changes" If the virtual switch is on and you tell Alexa to turn it on, nothing changes, therefore no trigger. I suppose you could define another virtual switch for off (with a reset on both) so when Alexa changes one there is a trigger and the switch is reset for the next "change".
I've not tried this as I use the grouping function in Alexa, not Hubitat. This seems to avoid the issues you are having. Good luck on sorting it out.

3

Yes, that's the part I'm trying to get around or find another way.

4

You could make a custom virtual switch driver that always sends the on/off event with the flag isStateChange: true in the event. That would fire the event no matter what the state was.

5

I didn't mention it but the same issue occurs with dimming. If you set a dimmer to the value it already set too nothing is triggered.

6

Never created a custom virtual switch. Are there instructions or examples around for that?

7

Something like this:

metadata {
    definition (name: "Virtual Always Switch", namespace: "dan.t", author: "Daniel Terryn") {
        capability "Switch"
    }   
}

def on() {
    sendEvent(name: "switch", value: "on", isStateChange: true)
}

def off() {
    sendEvent(name: "switch", value: "off", isStateChange: true)
}

def installed() {
}
6 Likes
8
  • Go to "Drivers Code" -> "New Driver"
  • Copy the above in there, hit save
  • Go to "Devices" -> "new Virtual Device"
  • Give it a name and select "Virtual Always Switch" as the driver
  • Share that driver in the Amazon Echo app
2 Likes
9

Here is the same thing as a dimmer

metadata {
    definition (name: "Virtual Always Dimmer", namespace: "dan.t", author: "Daniel Terryn") {
        capability "Switch"
        capability "Switch Level"
    }   
}

def on() {
    sendEvent(name: "switch", value: "on", isStateChange: true)
}

def off() {
    sendEvent(name: "switch", value: "off", isStateChange: true)
}


def setLevel(value, duration = 1) {
    sendEvent(name: "level", value: value, isStateChange: true)
    if (value == 0)
        off()
    else if (device.currentValue("switch") == "off")
        on()
}

def installed() {
}
5 Likes
10

Thanks, I'll give that a try.

The more I think about it, I kind of want it to work like a button. Button 1 is On, Button 2 is Off. These would always get picked up by a trigger. Problem is, Alexa doesn't work with buttons.

11

That is correct, you can't do that, buttons can't be done with Alexa, stick to the virtual switches

In addition, buttons canā€™t be On or Off, they can only be pushed or released. On and off is a switch which is exactly what is above

2 Likes
12

@dan.t your "always" virtual drivers completely solved the issue. They even work with Mirror Me app! :grinning:

Is what you shared common knowledge and I somehow just missed it?

An additional feature I noticed is that when you turn on the virtual dimmer it sends the On as well as its current dim level. The standard virtual dimmer doesn't do that.

Thank you very much. You have no idea how much this is going to improve my automation.

Glenn

1 Like
13

Is it common knowledge? I donā€™t know as most people only want to react to events when there is an actual change. E.g. you donā€™t want to get an announcement if there wasnā€™t a real change. What I did above is surely no secret, there are several others that could have done the same. There are scenarios where it does make sense to always react to an event even without change, like your scenario. All we want is to keep the WAF high. And that is the beauty of this platform. Allowing to create custom drivers and apps allows us to build a home automation system that fits OUR needs and we donā€™t have to work around that ā€œstandardā€ way that works for 90% of people.

Glad that it worked for you!

4 Likes
14

This shouldn't be needed if you have your lights set up in Alexa by rooms. In google at least, if you say turn off the "room" lights, you get an off command sent to every switch in that room. How do you have your lights assigned in Alexa? Do you have them set up in Groups in Hubitat and is that how you're trying to cross them over into Alexa?

Also, having a virtual switch that you can issue a command to multiple times isn't going to help this situation. Obviously Alexa tried to turn off what she thought she should. Doing it multiple times isn't going to get the lights to turn off.

15

It actually does in his case.

  • He had one virtual switch that was exposed to Alexa
  • he has a rule in RM that acts on the state changes for that switch and controls other devices
  • one device could have been manually controlled on not received a command for some other reason
  • being able to issue multiple off commands will trigger the rule multiple times and control these devices

One thing I have learned and embrace is that there are several ways to achieve a goal. It might not be the most logical for you but it is the most logical for another person. It wouldnā€™t be the first time that a user only shares virtual devices with Alexa and not the actual physical device. There might be other reasons on why a system is structured a certain way that we donā€™t know about.

1 Like
16

Why? There is no need for all of that complexity.

Personally, if I'm "Rube Goldberging" something and someone sees an easier way to do it, I wanna hear it.

In this case, if you don't say the name of the virtual switch exactly right, it won't turn off the lights. If you use the room name, you can say "Turn off the bedroom lights." or "Turn the lights in the bedroom." If you use a virtual switch titled "Bedroom lights" both those commands would not work correctly.

Plus, you remove one extra RM rule that is not really adding any value. With everyone bitching about hubs acting slow, shouldn't we do all the easy things we can to reduce overhead? I mean, why make it more complicated just because you can?

17

Not sure where to go from here based on your response, he has a solution that works for him and he is happy with. That is what counts

4 Likes
18

You don't have to "go" anywhere. Every response doesn't necessitate that you respond too. You thought that was the best way to do it. I was proposing a simpler way to do it. You don't have to agree with me. That's okay. My feelings won't be hurt I promise.

19

I like to use HE with a Virtual Switch rather than Alexa or Google Groups to control groups of lights. This way Alexa (or Google) only need send one command across the internet to HE and HE handles the On/Off and Dimming locally. Additional, by setting up my groups locally I don't have to replicate groups across the various platforms I'm using.

Another benefit of grouping with the HE is you can put groups within groups. I've created Virtual Dimmer [Groups] for each of the rooms in my house. Then I created another Virtual Switch called Main Floor Lights and put all the Main Floor Virtual Switches into it.

20

In my opinion, it was much easier and way less maintenance to use a Virtual Switch for groups of Light and use Mirror Me or a simple rule. The lights response quicker and Alexa always replies with ok because she's only looking for a response from the Virtual Switch, not every light she changed.

I still put the the virtual switch into an Alexa Group (room). That way no matter what room I'm in (have an Echo in and assigned to each room) you can just say Alexa, dim the light to 25% or turn the lights off.

Now if Amazon (or Google) would finally implement the ability to create "device room aliases" we'd really be getting somewhere.

21

You can choose to do it however you want but you can't say it's less maintenance. If you are syncing the lights to Alexa anyway, the work is done. If you have to swap out a light, you sync it to Alexa and assign a room. If you do that with your implementation, you would have to do that and then add it to Mirror.me. So, your method has more steps. You can't say it's simpler or shorter if it has more steps involved.

Why would you have groups just to turn lights off? You realize that having a light in a group adds extra overhead to your hub even when you are not controlling the group, right? If you have the group set to indicate if any of the lights in it are on, the group subscribes to all of the devices in it. So, if any change, then the app has to handle it. This is unnecessary extra work the hub is going to do just so you can turn off the lights by a group rather than by a rule or letting Alexa do it. That will likely cause ALL your automations to run slower, including this one. And groups of groups? Why would you ever do such a thing? You should only create a group if you want all of the lights in that group to match each other all the time. Otherwise, if you're only using it to turn lights off, it's just a waste of hub resources.

You can choose to do it that way...but you can't argue that it is simpler or uses less resources or has less steps. It just doesn't.