This article is about using Google Assistant within Home Assistant, chances are you are running Home Assistant on a raspberry PI and have found stuff that’s compatible with Home Assistant and Google Assistant Maybe Homekit and Siri and Amazons Alexa. Trouble is making this work together and you have probably heard about Tuya (and the many companies that rebrand Tuya). Home Assistant is the thing that can join these many parts together so they do what you want, but there are complications, you probably know that already.
If you are a parent , you may find yourself switching lights off after your child has switched them on and then gone to another part of the house. That’s the way it used to be growing up in the 70’s and a lot of power was wasted with things being left on all the time and a parent (paying the bills) switching them off. When did you know that things had been left on, when you found them of course.
Now lets say you build a simple automation to turn a light off after 5 minutes. Easy enough in Home Assistant, If it turns the light on it runs a timer and after the light has been on 5 minutes it turns it off. The timer starts once home assistant turns the light on. But what if you used Google Assistant (and from here in called GA and HA for Home Assistant). Well since the light was turned on by GA then HA doesn’t know it was turned on immediately, it will find out at some point since it will poll the devices in your system to check the status and once it’s found the light on it will then start running the timer on your automation and turn off after 5 minutes. This checking maybe around once every 600 seconds or 10 minutes so your timer maybe doesn’t turn off until 15 minutes has passed.
The two systems are working independently of each other a bit like you and your child if you turn the light on, you know to turn the light off but if your child turns the light on you can’t turn the light off until you know it’s been turned on. It’s not totally a bad thing that they work this way as if one control system fails the other can be used.
Ok here’s the flow for GA
Trigger ” Hey Google turn on the kitchen light”
Action Google knows the kitchen light is integrated via a tuya and sends a message to Tuya’s “cloud server” hey Tuya turn off the kitchen lamp. Tuya who is watching the kids, then tells the kitchen light bulb to turn on.
The flow for HA is pretty much the same, but note that GA and HA are not talking to each other, much like some parents, which can lead to some household tension. The solution is to make GA talk to HA to turn on the light.
So Trigger “Hey Google turn on the kitchen light”
Google knows the automation is provided by Smart Nora, Smart Nora talks to Node Red who talks to Home assistant which then talks to Tuya who tells the kitchen light to turn on. Now it’s possible to have local control of Tuya devices you just need the local key. You can get this by going to iot.tuya.com registering as a free developer, scanning a QR code on their site with the Tuya App which then enrols your tuya devices into your developer account and you can submit the device id and tuya will provide the local key, once you have the local key HA can talk with the bulb directly on your lan.
I believe that once this integration is done GA learns the device is on the same lan and it can work without needing Internet Access. There are a couple of integrations for Tuya devices for home assistant which involve HA talking to Tuya cloud and Tuya cloud instructing your devices what to do.
The other way is to flash your Tuya device with Tasmota or ESP home. Sometimes the firmware on the device is too new or Tuya put a different card in the device other than the one ESP home works with. If you can’t flash it then using a Tuya integration will be necessary. If you do flash it, then it becomes a device that GA will not work with since it’s now not registered with the Tuya cloud.
To be fair the best option is to flash these devices to use Tasmota or ESPHome. I believe that HA can talk directly to ESPHome flashed devices while Tasmota uses MQTT which requires a server (usually running on the same Raspberry PI you run HA on. ESPHome requires a binary to be compiled and flashed to your device while tasmota just needs a configuration file to say what pin does what, usually you can find one for your device.
Ok back to smart nora , and node red. Smart Nora is an integration for GA so any devices created using the smart nora nodes are available to google. Now for anything that is essentially a switch with two states its very simple in node red you wire the Smart Nora node to a switch node and then you wire to a HA Service Node for turn on and wire the other to a HA service node for switch off.
Where it gets complicated is when you have message parameters how do you pass them to the entity? well you use the data field and jasonata basically a message is an object a simple two state object is just on and off or true and false. However an object can have attributes and its passing these attributes which is the headache so here I give you some data for a smart bulb which has the ability to set a brightness and a color temperature in jasonata format
{
"transition": 9 ,
"brightness_pct": payload.brightness,
"kelvin": payload.color.temperatureK
}
Lets explain the meaning of this block its in jasonata format (it could be in json but lets not bother with that).
The first line transition is a time for the effect to take place e.g brightness from say 10% to 50% this isn’t passed from the smart nora node its just a value i chose for this automation if it wasn’t there it would just use the existing value (which might be a default) , it isn’t necessary and could be omitted.
The payload is the message the smart nora light node gets from google it’s most basic form is on/off and online/offline. payload here has two primary attributes brightness and color.
The first attribute is brightness so e.g
brightness: 50 #a brightness value of 0 to 100% whatever is in the message under brightness gets sent to the entity. note that the entity has an attribute brightness_pct (brightness percent) but the payload attribute is brightness this data field basically says use the value found in brightness for the attribute brightness_pct.
You could get creative here and use that value for something else with a different type of entity GA thinks its a lamp your entity could be something else.
The next attribute is color which has a list of secondary attributes an RGB bulb would have maybe values for red green and blue or HSV i’m not going into it in this case there is just one secondary attribute for color called temperatureK by Smart Nora which is mapped to your bulbs attribute kelvin. Another thing to realise is that you can ignore part of the payload e.g if I missed out the value for brightness then the lamp would be at the same brightness as when it last turned on.
I mean you can tell google just turn on the lamp or you can tell google to turn on the lamp at a particular brightness or color temperature. Make it brighter and google will increase the brightness a bit (the bit is the step size that google chose to make it. E.g the volume on a google mini has steps 0 (muted) to 10. It used to be that telling it to set the volume at 11 would give a message ‘i can’t do that the limit is 10’, these days it responds by saying setting volume to 11 and setting it to 10 anyway. (see spinal tap these amps go to 11)
Home assistant is mostly a list containing lists and dictionaries and an entity has a list of dictionary pairs for attributes so yaml like
Mybulb:
state: on / off
online: true / false
Brightness: 0 - 100
color:
-kelvin : 2700 - 6500
or payload
on/off
Brightness: 0- 100
Color:
-kelvin: 2700 - 6500
payload message is on or off (and online) the first attribute is a single item list brightness
payload.brightness: value # the second attribute is color which is another list in this case a single item temperatureK
payload.color.temperatureK
consider a person object
person:
-name: "kevin"
-age: 32
-Shirt: true
color: blue
style: "short sleeves"
-Pants: true
type: jeans
color: black
so person.name is kevin and person.shirt.color is blue
and person.pants.color is black
blue is an attribute of shirt which is an attribute of person
where as black is a color like blue but an attribute of Pants
which is an attribute of person, kevin.
It’s good to get your head around that your home assistant is an object that is essentially a huge list of attributes with dictionary pairs of values. This is what configuration.yaml is really part of Home Assistants big list. behind that list is a bunch of functions getters and setters which retrieve and set the values in the system. An integration is python code to do the getting and setting of that integrations objects. The cool thing is that you can write a method for setting and getting color say and reuse it where you need to set or get a color. You can also create new sensors which use some of the attributes of other sensors at a high level e.g i could create a sensor watts value which could take a sensors voltage attribute and multiply it by another sensors current to produce a sensor with a value derived from two different sensors.
Ok so this is a long post but if you were just looking to pass attributes from a payload message the bit in gray is for you. The rest pretty much is background information so you know why you are doing it. Hope you found it interesting.
