RM question - multiple actions


#1

Ok, I am having a senior moment...

Now that we have chromecast integration, I would like to do the following. Anyone have advice on how that would be done in RM?

When front door contact goes OPEN

On Chromecast device specified, do three commands:

  1. setVolume to 50
  2. speak "Front Door Opened"
  3. stop

I need the stop, otherwise my Google Hub stays on the Chromecast screen instead of going back to time/pictures.

I could certainly write an app for this, but it seems like RM should be able to handle this as well (and I'm trying to get better using it instead of writing a custom app for everything).


#2

You have to create a custom command for the set Volume and the Stop as these are not default rule machine commands. Once you have the custom commands set up, you are going to have to do some finagling. The order of execution is working against you in this case. Custom commands execute after the speak command. So, you would have to do a separate command with a delay of a second for the speak and then another for the stop.

However, your life would be much simplified if you took out the volume and the Stop. My Home Hub returns to screensaver without issuing the stop command, so I don't think you need that one. And as far as the set Volume, typically I won't do that simply because whoever is in the room might have it louder or quieter depending on what else is going on.

As far as the speak, it's in the same panel in RM as the notification. You enter the message, toggle the speak message and select the speaker.


#3

How long does it take for your hub to back to picture/screensaver? I ask, because I setup the rule to just do the speak first. Worked fine, but after a minute or two my Google Hub was still at the chromecast screen.

EDIT: It takes 5 minutes for the Hub screen to go from the Chromecast icon display back to the normal Google Home Hub display after sending a message. Kind of long, but maybe I can live with that.

Thanks for the thoughts!


#4

If you do the Stop as a custom command, it will happen after the Speak command is given (just by virtue of the order of doing things in RM). It was the Set Volume that was going to make this more complex. You can put both the Speak and the Stop in the same RM action section, and it should work.


#5

I tested this a minute ago, and can confirm that the Speak and custom Stop command action being in the same RM rule works as expected.

I think I can live without setVolume.

Thank you both for the ideas/comments.


#6

@bravenel RM doesn't wait for the speak command to finish before sending the Stop though. So, when I tried this, the announcement was cut off before it completed. So, wouldn't you have to have a separate action invoked by the rule that had a delayed custom command of stop? I tested them together and it doesn't work. My home hub only got about 3 words out before stopping.

Wouldn't it be easier if the device itself issues the stop command after the speaker was done with the announcement? It can read the device's status going to Idle after the message is played. That would be a perfect time to issue the Stop command. If we wanted to do that through rule machine, we'd have to use WATO with a whole bunch of virtual switches. It would be a mess but we could do it.

I know it's against Hubitat's 4th commandment or something but I actually already implemented a webCoRE piston that did exactly that with the Home Hub's status changing to Idle. Worked perfectly. I'd like to make another +1 for custom device attribute access in RM. It would make some of this stuff a lot easier.

EDIT: Actually, I just went into add a WATO for this, and there is no virtual device necessary. You can access the stop command from directly within WATO. So, I have this set up now and it also seems to be working. Thank you @bangali!! WATO to the rescue again! For anyone interested, here's what I have setup in WATO to get the display to turn "off" after a spoken command.


#7

+1 on the driver sending stop command after it's done, and I'd like to add that it should also check to make sure the file is done playing before it plays another one. I've had several situations where announcements get cut off by another.


#8

I don't know how you would prevent the multiple messages casting over one another. Part of the functionality of the speaker is that you can cast over the previous device. That's how you get over the 5 min timeout if you want to broadcast from something else. But if the driver could store the second message until the idle status is back, that would be ideal. But I think the Stop, at least for GH Hub, would be ideal.

Also, I'm curious as to why the GH mini's and Insignia speakers show up as video. I tried switching them to the Audio driver but everything stopped working so I switched it back.


#9

I guess that's another plus for the Google Broadcast function. It seems to queue the commands so they don't get cut each other off. Too bad Google has decided that we need the somewhat obnoxious prefix to TTS broadcasts.:neutral_face:


#10

And that the functionality just dropped off for Insignia Speakers. Been seeing a whole bunch of other people experiencing that problem.