Google Home is present in many Dutch and Belgian homes. The platform is included as standard on Android phones and can be integrated with almost any hardware provided by Google, sometimes under the Nest label. The platform is also supported by many smart home devices.
For the seasoned smart home fan, the options are somewhat limited, especially in the area of automation. Last month, Google introduced an update to the Google Home platform that should improve this. With the new script editor, users are no longer tied to the app to create automations, but can also write them in yaml scripts. The script editor should also give users more options in terms of triggers, an area where options with Google Home have been limited until now. For example, the automation editor of the application allows to activate a routine on the thermostat, but only on the state (heating/cooling/standby) and not on statistics such as the measured temperature. Response to motion sensors and door/window contacts are not included.
These limited possibilities seem to be largely over with the introduction of scripted automations in Google Home. In this article, we take a look at what the new scripting tool adds and whether Google Home takes a step that allows serious smart home tweakers to take this platform more seriously.
To access the new script editor, you need to sign up for Google Home’s “Public Preview”. You can do this through the Google Home smartphone app settings, after which you can access new functions, including the script editor. Since scripted automations are still in preview, Google notes that some features of these scripts are subject to change. So it’s possible that the scripts you create now will “break” in the near future if Google changes the way the components you use work.
It may take some time to search for the script editor if you want to use it for the first time. At the moment, it is not yet possible to create a scripted automation from a smartphone. You will need to do this in the browser via http://home.google.com/automations. In my opinion, it works best on a laptop or computer; it’s always nicer to type on a real keyboard. Once you’ve created your first scripted automation, it’s also in the smartphone app and you can edit it too.
Scripted automations are not the same as long-running routines. As already explained, the triggers, or starters as Google calls them, are not very extensive. They remain a separate category in the automations section of the Google Home app, and you can’t script or edit your existing routines in the script editor; routines and scripted automations are two separate things.
Google chose to shape scripted automations with yaml. This is not a typo, but a language for defining data objects. It sounds complicated, but luckily yaml’s grammar rules are quite simple and a yaml file is easy to interpret, as there is little use of all sorts of punctuation marks in the formatting. If you are not yet familiar with this text format, it is useful to read the ground rules before you roll up your sleeves. Unnecessary spaces or hyphens can easily be a trap and the script editor doesn’t always help with that.
Google Home’s scripted automations work according to a set pattern. An automation is triggered by entries. At this point you can check on a number of conditions, or terms, is fulfilled. If so, you can create action scripts or Shares, execute. You can add more than one of each of these starters, conditions, and actions to an automation at once.
The desktop editor that you can access through the browser works well and helps you with suggestions to complete your code where possible. For example, once you define a starter or a condition, you get a list of all the possibilities which is automatically filtered and refined as you type more letters. I noticed that this list is not complete in all cases, but in Documentation all options are available.
not quite finished
As mentioned earlier, scripted automations and their editor are still in the preview phase. This means that not all advertised features are available yet. Currently, about 100 launchers, conditions, and actions have been implemented, and not all manufacturers, device types, and properties are supported. For example, at the time of writing only one motion sensor, from Philips Hue, was supported according to the documentation. Now, support for this kind of device is just new to the platform, so maybe the documentation here is still a little behind the reality.
door and window sensor
One device we were able to test with is the Aqara P2 door and window sensor, which works with the Thread radio protocol. We hooked it up to a Google Nest Hub 2 which uses its Wi-Fi connection and the Thread radio as border router functions. The response speed of this configuration was very disappointing. It took a few seconds for the sensor status to update in the Google Home interface. Scripted automations that use this sensor as a starter also run very late. If you use this configuration to turn on your light, you will be halfway through the room before the light turns on. This may be due to the fact that all actions take place through Google’s cloud, as is customary with this platform (until now). Still, I saw faster performance from Google Home’s cloud, for example when controlling switches and lights from the smartphone app. Google plans to run scripted automations locally, which can make a difference in response time.
Other experiments with the platform, including showing an interesting script in this article, also failed due to various limitations. My motion sensors aren’t supported, so automations with this starter weren’t an option. You also cannot retrieve the outdoor temperature displayed by the Google Home app and hubs in a script. With this, the idea of a “sound system for ventilation” fell apart. In the end, I found a, perhaps a bit annoying, addition to my current doorbell automation. At the moment I use Home Assistant to play doorbell sound on all the speakers in the house, but it almost never happens quickly and smoothly in practice. It’s time to let Google Home handle this feature itself. The script I created is the following:
metadata: name: Deurbelmelding description: Wordt bediend vanuit Home Assistant automations: starters: - type: device.state.OnOff state: on is: true device: DeurbelGoogleHome - Hal condition: type: home.state.HomePresence state: homePresenceMode is: HOME actions: - type: device.command.SetVolume volumeLevel: 100 devices: - Hal - Hal - Slaapkamer-Hub - Slaapkamer - Studio klok - Studio - Woonkamer-Hub - Woonkamer - type: assistant.command.Broadcast message: Er staat iemand voor de deur. devices: - Hal - Hal - Slaapkamer-Hub - Slaapkamer - Studio klok - Studio - Woonkamer-Hub - Woonkamer - type: device.command.SetVolume volumeLevel: 75 devices: - Hal - Hal - Woonkamer-Hub - Woonkamer - type: device.command.SetVolume volumeLevel: 25 devices: - Slaapkamer-Hub - Slaapkamer - Studio klok - Studio
The script starts with metadata that gives you a name and description for the automation. This allows you to find the automation later in the preview. Then you define a starter, a condition, and an action. The starter in this case is a doorbell switch that is activated. Home Assistant controls this as soon as the doorbell is activated. The condition I specify is presence. If I’m not at home, starting the automation is useless.
Actions that are performed increase the volume of the speakers, announcing that someone is there outside the door and set the speakers to a volume normally sufficient for that room.
In fact, in this case, the biggest benefit for me personally is that the broadcast notifications that I normally generate via text-to-speech now receive the Google Assistant voice from Home Assistant. Also, this way of triggering works faster in my situation than starting the doorbell sound. For the first reason, I will be running the script editor more often in the near future to achieve more unity in voice announcements.
With scripted automations, a little more is now possible with the Google Home platform, but there’s no talk of a revolution just yet. The increased number of starters and conditions in the preview build by around a hundred is nice, but it still lacks support for many sensors. As a result, it is still difficult to place Google Home at the top of global home automation; it is still too limited for that in its present form.
One downside of the Google Home system that isn’t eliminated with the script editor is the system’s reliance on the cloud. If the internet connection is lost, your automations will no longer work. If you want to base your home automation on Google Home, a stable internet connection is absolutely essential. Also, there is of course a risk that this tool, and with it all your automations, will disappear into the graveyard of discontinued Google products.
Is everything catastrophic then? It wasn’t that bad. It should be noted that in my opinion Google Home is not the ideal center for your home automation, but I am (fortunately) not the measure of things. If you’ve collected quite a few smart home gadgets without being noticed, but don’t intend to invest in a central platform, Google offers a “free” platform with even more automation possibilities. Do you have a Eufy camera (doorbell) in your garden and smart garden lighting? Next, you can now build an automation that turns on the garden lights when the camera detects motion. This means that you should master your minimum knowledge of yaml syntax. You might be wondering how many people are willing to do this.
Readers who have already switched to another smart home platform, but have some Google Home equipment, will recognize that the links between external platforms and Google Home are not always extensive. Scripted automations offer a nice extension to control devices more broadly and use features that have until now been exclusively in the Google Home universe. This may still require some trickery as long as some device types and starters are still missing. It is hoped that the entries and conditions will be greatly expanded for more fun.
You get no warranty on it. We’ve known Google for a while now and no one will be surprised if this feature comes in due time. gravestone field end. Readers who have been using Google Home gear for a while will also recognize that some features remain half-finished or have been announced for ages but never materialize. The development of the Dutch language in particular is lagging behind and in some cases is currently working less well than when the platform was introduced a few years ago. In that sense, it’s nice that there’s clearly still life in the Google Home platform and that serious work is being done.
“Bacon trailblazer. Certified coffee maven. Zombie lover. Tv specialist. Freelance communicator.”