Using Node-Red for Google Home TTS announcements and other stuff eWeLink

UPDATE

This is the final version of dynamic Http URLs for TTS Cast / Google Home.

Many thanks to @ ElCid it was his solution !

EXAMPLE URLs:

Single IP address of a Cast / Google Home Device:

http://NODE-RED-IP:1880/sceneTrigger?message=TEST&ip=192.168.0.16

Multiple IP addresses of Cast / Google Home Devices:

http://NODE-RED-IP:1880/sceneTrigger?message=TEST&ip=192.168.0.16|192.168.0.17|192.168.0.18

To send from a vera scene use luup.inet.wget e.g

luup.inet.wget("http://NODE-RED-IP:1880/sceneTrigger?message=TEST&ip=192.168.0.16")

I hope this is formatted correctly. If not I’ve attached the json file.flows.zip (850 Bytes)

[{"id":"3a72f933.689e06","type":"tab","label":"TTS-Dynamic","disabled":false,"info":""},{"id":"c994868d.7f48d8","type":"function","z":"3a72f933.689e06","name":"create response","func":"msg.payload = {\"message\": msg.payload.message,\n \"ip\": msg.payload.ip\n }\nreturn msg;","outputs":1,"noerr":0,"x":1120,"y":220,"wires":[[]]},{"id":"47fdc09d.f9c04","type":"cast-to-client","z":"3a72f933.689e06","name":"","url":"","contentType":"","message":"","language":"En-gb","ip":"","port":"","volume":"","x":550,"y":140,"wires":[["3495f4ac.b008ec"]]},{"id":"3495f4ac.b008ec","type":"debug","z":"3a72f933.689e06","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":710,"y":140,"wires":[]},{"id":"8fe0bf3c.4e32","type":"comment","z":"3a72f933.689e06","name":"TTS Cast - Specify IP(s) in the URL","info":"","x":160,"y":60,"wires":[]},{"id":"e482f40a.8af9b8","type":"http in","z":"3a72f933.689e06","name":"http request from scene","url":"sceneTrigger","method":"get","upload":false,"swaggerDoc":"","x":120,"y":100,"wires":[["fc546d4b.dd073"]]},{"id":"1d4c3b30.18d375","type":"http response","z":"3a72f933.689e06","name":"http response","statusCode":"200","headers":{},"x":580,"y":100,"wires":[]},{"id":"fc546d4b.dd073","type":"function","z":"3a72f933.689e06","name":"IP-Addresses-Function","func":"var IPS = msg.payload.ip.split(\"|\");\nfor (var i in IPS) { \nmsg.payload = {\"message\": msg.payload.message, \"ip\": IPS[i]};\nnode.send([null, [msg]]);\n}\nmsg.payload = \"ok\"; // the response message\nreturn [msg];","outputs":2,"noerr":0,"x":350,"y":100,"wires":[["1d4c3b30.18d375"],["47fdc09d.f9c04"]]}]

END OF UPDATE


I’ve been playing around with node-red for the first time today. I just installed node-red on my Windows 10 laptop as a test. Following these instructions here.

I have been able to set up a HTTP IN endpoint in node-red, so I can send a http command to node-red from Vera for example, to then do something, in this case to send a TTS announcement of “Hello” to two of my Google Home speakers.

http://[IP-ADDRESS-NODE-RED-DEVICE:1880/hello

I used the node-red-contrib-cast

image

Unrelated but I also managed to setup a eWeLink node to control my WIFI oil diffuser. I setup a HTTP IN for the on command and a HTTP IN for the off command. I can now turn on and off the diffuser by sending http commands to node-red from Vera.

node-red-contrib-ewelink

image

What else are other Vera users using Node-Red for ?

There is also a node for MIOS Vera here

I got that up and running and was able to set dim levels on one of my lamps in Vera in Node-red.

image

Not sure what I would really use the MIOS node for however?

UPDATE:

So this is how I have been getting a Vera scene to do something in node-red.

In this example it sends a TTS to a Google Home speaker, using the node-red-contrib-cast

image

HTTP IN node:

Method is GET
URL: /whatever-you-want

image

Template Node:

Text “OK” response

image

HTTP Response node:

Status Code = 200

image

Cast Node:

Send TTS to a Google Home speaker

So in the actual Vera scene under “Also, execute the following Luup code:”

Send the http command to node-red e.g.

luup.inet.wget(“http://NODE-RED-IP:1880/doorbellstatus”)

Where “/doorbellstatus” = URL: /whatever-you-want

What you specified the URL as in the “http in” node.

So when you run the Vera scene the URL is sent to node-red and any associated actions in node-red will be carried out.

3 Likes

Playing around some more with the MIOS node there is a more elegant way to do the Google Home TTS announcements based on the status of a Vera device.

I used a MIOS IN node for my Fireplace appliance plug / switch.

image

The Fireplace appliance plug is either ON = True or OFF = False

image

I then used two “Swtich” nodes.

One for True

image

and another one for False

image

I then created two CAST nodes for my Google Home Mini in my lounge.

The True Cast node does a TTS saying “Turning on Fireplace”

The False Cast node does a TTS saying “Turning off Fireplace”

1 Like

Here is another example for a door sensor.

image

MIOS Node In (Patio Door)

image

Patio Door Open - Tripped = 1
Patio Door Closed - Tripped = 0

image

Switch Node - Patio Door = Opened

image

Switch Node - Patrio Door = Closed

image

Cast Node - TTS says “Patio Door Opened”

Cast Node - TTS Says “Patio Door Closed”

This works really well and the TTS messages sent to the Google Home speaker are pretty much instant.

Here is another node-red example using a Vera virtual switch to control a eWeLink cloud device.

This is a virtual switch I created in Vera UI7

image

In node-red I created a new MIOS IN node for this virtual switch to watch its status.

image

TURN ON Diffuser:

Switch Node - If the status of the Vera virtual switch = 1

image

I also had to add a Change node (named msg.payload.on), as the eWeLink Api / device only accepts string commands for controlling its power state e.g.

“toggle”
“on”
“off”

Change Node - Set msg.payload = on (string)

image

eWeLink Power State (Write) Node

image

The eWeLink Device ID number can be found by watching the debug window for the “eWeLink Devices” node.

You can also watch this Youtube video for tips about node-red and eWeLink.

And finally I added a Cast Node to TTS say “Turning on Diffuser”

For the OFF flow just use a “0” in the second switch node and use the string “off” in the second change node. And add a second cast node with the TTS for the device turning off e.g. “Turning off Diffuser”.

Now in Vera or Imperihome when I turn on or off this Diffuser virtual switch, node-red is used to control the Diffuser device via the eWeLink cloud API and I hear my Google Home speaker confirm the actions via TTS announcements.

1 Like

Here is mine The ewelink listener updates any Virtual http switch on the vera controller.
The Routine and Smarthome flow listen for http request from vera and use alexa-remote2 node to turn them on. It will do any device connected to alexa.
I am still working on a listener to update vera for other devices(not ewelink).

1 Like

Also note that ewelink is limited to 6 devices per account. You can up this by adding other accounts and sharing the devices.

So each node instance logged on to the ewelink Api is classed as one of the 6 devices?

Yeah good idea, I will try it in reverse going back into Vera.

I dont use Alexa, I just have one Echo Dot in the lounge and no smart home devices are connected to it.

I have a Google Home speaker in every room, however I have no devices connected to Google Home that aren’t already in Vera anyway. Except this one WiFi diffuser that uses ewelink.

I dont plan to buy any other devices that Vera does not support natively as all my devices are Z-Wave.

Although the new Ezlo VOI will allow you to control devices in Alexa or Google Home that Vera doesn’t natively support. Or so Ezlo say.

Yes, in my early days i ran into the 6 limit. But worked around it.

Just wondering why you have it then?

Kept it to keep my toe in and for testing stuff, like the Vera Alexa TTS plugin.

OK I have two way comms now with the eWeLINK integration.

So using the eWeLink Event Listener I first created a Switch Node named “DiffuserOn”

And used msg.payload.params.switch with a value == “on”

image

Then I used a Template node to send a msg.payload with a value = 1 to the Vera virtual switch.

image

I then used a MIOS IN node to specify the “Diffuser” virtual switch device in Vera to set its “Target” variable.

image

So if I use the eWeLink app to turn on the Diffuser this flow will now also turn on the “Diffuser” virtual switch in Vera as well.

Although doing it this way that I have, I’m not sure how it would work if you have more than one device in your eWeLink account? As the Event Listener is just looking out for the item: msg.payload.params.switch and not specifically linking to a particular DeviceID from the eWeLink account etc.

Anyway to do the off part, I created a second Switch node named “Diffuser Off” with a value == “off”

image

And a second Template node to send a payload of 0 to the Vera virtual switch “Target” variable.
I named the template node “msg.payload.0”

image

And a second MIOS OUT node for the “Diffuser” virtual device in Vera etc.

image

I’m sure there are better ways of doing all this in node-red but as I don’t know what I am doing in node-red then this is it.

It works anyways for two way comms with the eWeLink API / App

And here is the final flow for eWeLink IN and OUT

Can you show us how you do that ? Can you post screen shots of each nodes setup ?

And how do you determine what DeviceID from the eWeLink account links to what Vritual switch in Vera?

Thanks

I don’t have any Tuya Smart Life devices but looks like there are some node modules for their cloud API so this could also be used to integrate those Tuya devices in to Vera and virtual swtiches.

Tuya have just pulled their IFTTT support as well.

Just out of curiosity (and since I wouldn’t ask this elsewhere in the Forum), what is it about “special” devices like Tuya / Smart Life that renders them so dependent – under normal circumstances – on their own proprietary API?

If they are WiFi, shouldn’t the commands they send/receive be HTTP? And if so, shouldn’t those commands be effectively universal? And if so, shouldn’t a controller like Vera be natively able to communicate with them in this way without going through the API?

Perhaps I’m naive. Perhaps there is encryption involved, or complicated handshake protocol. But when I hear “Node-RED has a module for that” I can’t help wondering, “Why doesn’t everyone have a module for that?”

Please enlighten. Sorry for the n00b question.

1 Like

here is full msg object you can get from listener

{"action":"update","deviceid":"1000273353","apikey":"db4444449-4cf0-45aa-a9ab-b664c328c085","userAgent":"app","sequence":"1589297052686","ts":0,"params":{"switch":"on","partnerApikey":"4bd3333332603-4f13-a3d4-7fba161a1014"},"tempRec":"1000733253"}

The individual deviceid is 1000733253, you can get this for each device from the ewelink app

1 Like

This is the context data that is stored in a global context on the node-red server. it links vera deviceid to ewelink id

edit/ You need to edit the node-red setting.json to allow the context data to be stored to survive reloads

https://nodered.org/docs/api/context/store/localfilesystem

This creates the pyload for the http request

Best Home Automation shopping experience. Shop at getvera!

© 2020 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules