Announcement

Collapse
No announcement yet.

Alexa/Echo TTS using HomeSeer and Node Red - A “begginers” guide.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Alexa/Echo TTS using HomeSeer and Node Red - A “begginers” guide.

    [I'll try to add more screenshots to this and clean up the spelling in the future]

    I haven’t been particularly active on the forums lately but ~1 year ago when I was, “how to get Alexa to speak custom TTS phrases” was a common area of discussion.


    HST have recently updated HS4 to support Node Red, which is awesome because we now have a fairly straight forward method to send TTS phrases to Echo devices.


    This was achievable already in the past using MQTT as an intermediary, but with the native HomeSeer nodes now available, it’s a heck of a lot easier.


    This post hopefully provides some simple-ish instruction for achieving this.


    A rough outline of what we're going to go thorugh:


    - Install Node-Red.
    - Configure the web hook setting in HS4.
    - Install the HomeSeer module inside Node Red.
    - Install the Amazon Alexa module inside Node Red.
    - Configure the HomeSeer module inside Node Red
    - Configure the Amazon Alexa module inside Node Red.
    - Create an event to set a device’s string to a desired TTS phrase in HomeSeer.
    - Configure a “flow” in Node Red that will take the device string and pass it to an Echo device to be spoken aloud.
    - Modify the event and flow to support trigger reset. (Work around).


    Install Node Red.


    I’m a big fan of Docker, as it simplifies the deployment of things like Node Red greatly, without having to worry about dependency and compatibility headaches. I’d recommend installing Node Red (and a lot of your other home services) this way if you can.


    For Linux users, instructions for NPM, Snap or Docker deployment:


    https://nodered.org/docs/getting-started/local


    For Windows users:


    https://nodered.org/docs/getting-started/windows



    Configure the web hook setting in HS4.


    See official HST documentation:


    https://docs.homeseer.com/display/HS...r+use+with+HS4


    Configuring this will allow HS4 to tell Node Red when the value or status of a device has changed, without Node Red having to poll for updates.


    Install the HomeSeer and Alexa modules inside Node Red:


    Open the Node Red browser interface, sign in if you configured security.


    In the top right corner, click the hamburger icon.
    Select “Manage palette”
    A slide out window will open, select the “Install” tab along the top.
    Type “homeseer” into the search bar. You should get a single result “node-red-contrib-homeseer
    Click install.
    Search in the install tab again for “alexa-remote2”. You should get a single result again “node-red-contrib-alexa-remote2”. Install it.


    You can now close the slide out window.


    Configure the HomeSeer module inside Node Red.


    Before proceeding here, go to your HS4 web interface. Create a new virtual device and name it something like “TTS Alexa”. You may want to create new virtual locations to keep it in. I have a virtual device for each of the Echo dots in my house, so I organise them all into Floor: Virtual and Room: TTS. Once created, you can delete the controls from the Status/Graphics tab if you like. This device will be used to store strings only and so does not need controls.


    Return to the Node Red browser interface.


    In the Node Red browser interface, you will have a left hand bar with a collection of different “nodes” in it. Scroll through the list until you find the “HS Device” node under the “HomeSeer” header section. Click and drag it into the main window area (Called a “flow” btw).


    Double click the node you just dragged on. A slide out window will open with some configuration options. One of them is “HS Server”. As you have never configured a HS Server in Node Red before, you need to create a new one here. Click the pencil icon next to the field. The slide out window will change to one for entering the details of you HS4 server. Name it something simple like HomeSeer or HS4, as it’s likely you only have a single instance of HS running. Enter the server’s IP address and listening port. If you have installed Node Red on the same server as HomeSeer, you can probably leave these at the default values of “localhost” and “80”. If you have Node Red and HomeSeer on different machines, ensure the firewall setting on your HomeSeer server is going to allow Node Red to connect, and that the port is open. Enter a username and password that has access to HomeSeer. If, in your HomeSeer config, under Setup > Network you have the “No Password Required for Local (same subnet) Login” checkbox ticked, a username and password shouldn’t be required.
    Click “Add”. The slide out window will return to the node configuration. Now that you’ve created the HS Server config once, you won’t have to do it again as you will be able to re-use this same config in all future nodes.
    The device drop down list should now be populated with a list of all your homeseer devices. If not, click the refresh icon. (If it’s still empty, something is wrong with the HS Server config. Check things like server address and port, is it definitely reachable? Check the username and password.)
    From the drop down list, select the TTS Alexa device you created in HS4 at the start of this section. “Feature” should be greyed out as there are no child devices. In the name field for the node, I’d recommend giving it the same name as the device has in HS4, ie TTS Alexa.
    Click done.


    Now, one thing to note about Node Red, nothing goes into effect until you “deploy” the flow. Clicking “deploy” is like clicking save, it’s what will actually fix all the changes you’ve just made in place. If you’ve just changed something in Node Red and it’s not doing what you thought it would, did you click deploy? A node that has pending changes and has not been fully deployed yet, will be indicated by a blue circle on the top right corner of a node.


    Configure the Alexa module inside Node Red.

    We’ve connected Node Red to our HomeSeer server, now it’s time to connect Node Red to our Alexa account.


    On the left side panel, scroll down until you find the “Alexa” header section. Click and drag an “Alexa Routine” node onto your flow. There’s actually a lot you can make Alexa do from Node Red, as you might have guessed from all the different node types. But we are focused on just the TTS aspect here.


    Double click the Alexa node you just dragged on, a slide out window with propeties opens. We need to configure an Amazon account/credentials, similar to how we configured HS Server credentials in the previous step. Click the pencil icon to create a new one as this is the first time deploying an Alexa node. The slide out window changes to “Add new Alexa Account”. Give the account a name, something simple will do like “alexa-account”. Almost all the settings can be left at the default here, you’ll likely only need to change the file path field. Enter a file path (including the filename itself) where Node Red will store the authentication cookie for re-use.


    Sidebar:


    Understanding this section might require some expanation of what’s actually going to happen here. Alexa is a web/cloud service, and as such cannot be accessed without credentials. But in the era of modern authentication methods and security concerns, statically storing a username and password won’t cut it. Instead, we’re going to allow Node Red to store a cookie that it can pass to the cloud service, authenticating Node Red to perform actions against our Alexa account (such as speaking messages out loud). How do we get that cookie? Well, one way is to use firefox, install the cookie export extension, sign into Amazon using firefox, then export the cookie and paste it into Node Red. But that sounds hard, we want easy and shiny.
    Instead, Node Red is going to (automagically) setup a man-in-the-middle proxy running on the same server you are using to run Node Red. You browse to this proxy, and Node Red presents (proxies) the Amazon sign in page to you. You log in, and Node Red will capture the cookie automagically, because it’s proxying in between you and Amazon and can see all the traffic going back and forth.
    At this point you’re probably thinking “Gee, that sounds a little sketchy”. But remember, Node Red is running on your server, in your house. This isn’t a foreign external proxy running somewhere out on the big bad web. More importantly, all the code for the Alexa module is open source, you can go review it yourself at github: https://github.com/586837r/node-red-...-alexa-remote2 . So, no, it’s not secretly caching your Amazon credentials and forwarding them to a collector server. If it was, it would have been spotted in the code by the community of developers and the project removed.
    So, after it’s intercepted the cookie, Node Red will store it in a file and refer back to it for future authentication. It will refresh the cookie every few days, meaning you won’t have to be bothered signing in again to get your TTS back up and working.


    End Sidebar.


    With that explained, hopefully you now grasp the need for the “This IP” and “Port” settings. These are the IP and port combo that Node Red is going to setup it’s man-in-the-middle proxy on and which you will navigate to. You should be able to leave them at the defaults, but if you do just make sure port 3456 is open in the firewall on the machine you are running Node Red on.


    The “Service Host”, “Page” and “Language” are only relevant if you are outside of the USA, which I’m guessing 90% of you aren’t. These affect what geographic regions (and therefore what physcial datacentres) the authentication will be performed against. If you are outside the US, refer to the github page linked just above to determine the correct settings for your region.


    Click “Add” to finalize the settings, the slide out window returns to the Edit Alexa Routine window. Click “Done”, then click “Deploy” in the top right corner. You will now see a flashing message below the Alexa Routine node telling you the address to browse to. Copy this address into your browser, you will see the Amazon log in window. Sign in, and you will be shown a success message and that you can close the tab. When you return to the Node Red interface, the message below the Alexa routine node should eventually change to a green box saying “Ready”. To be doubly sure, open your file browser. Navigate to the folder you specified as the file location for the cookie. The single file there can be opened with a text editor. This confirms Node Red successfully stored the cookie.


    Congratulations! The bulk of the pain in the *** stuff is now done. You have connected Node Red both to your HomeSeer server, and connected Node Red to your Alexa account. You are now ready to start passing strings from your HomeSeer events, up to Alexa to be spoken aloud.


    Create an event to set a device’s string to a desired TTS phrase in HomeSeer.


    Return to the HomeSeer browser interface. For this section, I’m going to be making use of Spud’s most excellent “EasyTrigger” plugin. If you are not already using it, I strongly recommend that you install it. It will make configuring events in HomeSeer a lot easier. If you don’t want to use it for some reason, you are going to have to find a way to set a device’s string value. This should be possible using the “Run a Script or Script Command” event action, but for this guide I’ll be using EasyTrigger.


    Go to events, create a new event, call it something like “TTS Test”. For the trigger, select “This event is manually triggered”. In the actions, select “EasyTrigger: Set Device’s string”. Choose the Virtual TTS device we created in HomeSeer earlier, and put in a simple test message like “test message”. Save the event, do not run it yet.

    Edit:

    Thanks to KSUM for providing details on how to easily set a device string in a HS event using a script command:

    Click image for larger version

Name:	Screenshot_20201006_125518.png
Views:	472
Size:	147.9 KB
ID:	1424292

    This replaces the need for EasyTrigger for those that don't already own it.


    Configure a “flow” in Node Red that will take the device string and pass it to an Echo device to be spoken aloud.


    Return to the Node Red interface. In your flow area, you should already have the HS Device node and Alexa Routine node present. Place the HS node to the left and the Alexa node to the right, to represent the left to right order that the flow will occur in. Then, click the grey dot on the right edge of the HS node, and connect it to the grey dot on the left of the Alexa node. This will make the message payload flow out of the HS Device, into the Alexa node.


    I’m not going to get into Node Red message (msg) structure too much here, as there are more complete guides out there for that. For this just know that the msg payload that will flow out of the HS Device is an “object” payload. That is to say it is a collection of properties, and each of those properties has a value. In our case, we are interested in the value of the “Status” property, because this is where HS4 is going to write the string value.


    Double click the Alexa node. Give the node a name, a good suggestion is to name it the same as whatever Echo device will be speaking, for example “Living-Room-Dot”.
    For account you should have the Alexa account we configured previously selected.
    Select “Speak” from the next drop down box.
    The next box gives you three choices. Regular is hopefully self explanatory. Announcement is almost the same as Regular, but the speaking will be preceded by a chime sound. SSML is a type of markup language that can be used to alter pronounciation, it is beyond the scope here. Choose either Regular or Announcement.
    For Text, select msg from the dropdown box, and enter “payload.status” in the adjacent field. This tells the node to only speak the contents of the “Status” property in the payload object.
    The last drop down box, Devices, should now be populated with a list of your Echos, as well as any multi-room music groups you’ve configured in the Alexa app. Select the Echo device you want to speak.


    Click done, and click deploy. That’s it, at the most basic level, you only need these two nodes (HS Device and Alexa Speak Routine) to perform TTS from HomeSeer. The Alexa node should have a green box on the bottom left indicating it’s ready, and the HS Device should have a yellow box, also indicating it’s ready. A grey line should connect the two nodes.


    Return to the HomeSeer interface, and manually run the event we configured earlier. If all works, two things will happen:


    Your Echo device will speak your message.
    In Node Red, the yellow box on the HS Device node will now also have your message text next to it.


    So now you perform event driven TTS announcements, by having the HomeSeer event write your message to the virtual device string. If you have multiple Echos, create multiple virtual TTS devices in HomeSeer. You will then add a HS Device node in Node Red for each HomeSeer virtual device, and join it to a corresponding Alexa Routine node, just as we’ve done up to now. You will not have to recreate the HS Server settings or Alexa account settings each time, so adding these extra node pairs should be quite quick. Just make sure to select a different Echo device in each of the Alexa nodes.


    A necessary workaround: resetting the device string.


    Now for an irritating addendum. Currently, unless the device string actually changes to a different value, the flow will not be retriggered in Node Red.


    So for example, someone presses your doorbell and triggers a HS event that makes a TTS announcement: “There’s someone at the front door”.
    Some time passes, no other TTS announcements occur. Someone else comes to your door and rings the doorbell, the HS event triggers and the device string is set. BUT, the value of the device string has not actually changed. As a result, the flow in Node Red does not re-trigger. So no TTS announcement occurs.


    How do we work around this? The simplest way seems to be to set the string value of our HS TTS device back to blank after each announcement. That’s easy enough to do in HS.


    What I’ve found is this can result in some inconsistent behaviour with Alexa, as the flow is triggering twice in close succession. The second half of this work around, is to add a function node, that will cause messages with a blank status to be ignored.


    For brevity, here is a screen shot of an example HS event:


    Click image for larger version  Name:	event.png Views:	346 Size:	311.6 KB ID:	1416536





    Here is an example flow, note the function node sits in between the HS Device and Alexa node:


    Click image for larger version  Name:	flow.png Views:	632 Size:	141.7 KB ID:	1416534



    Here is the contents of the function node:


    Click image for larger version  Name:	function.png Views:	350 Size:	70.9 KB ID:	1416535



    The text contents for you to copy/paste:


    Code:
    var status=msg.payload.status;
    if (status===""){
    return null;
    }
    else {
    return msg;
    }


    What’s it doing? First it sets the contents of the payload.status property into a variable.
    Then it checks if that variable is blank. If it is blank, the function returns null, meaning the flow stops there and nothing further occurs.
    If it’s not blank, the flow continues as normal.


    This means that although the device string is being set twice by homeseer each time (once for our message and again to reset to blank), only one message is reaching the Alexa node, the one that’s not blank.


    This last work around is annoying but it’s early days for the HS4 Node Red integration, hopefully this can be ironed out in the near future.


    Hopefully this guide helps some of the less IT-centric users get enough of a foot hold to achieve TTS in their home setups.

    #2
    Works great, thanks for the update!

    Comment


      #3
      Nice work. We were discussing something exactly like this in the Node Red forum.

      Comment


        #4
        worked great, thanks for the tutorial

        Comment


          #5
          i am getting this error ?
          4 Sep 10:07:13 - [warn] [alexa-remote-account:amazon alexa] EISDIR: illegal operation on a directory, read
          4 Sep 10:07:13 - [info] [alexa-remote-account:amazon alexa] intialising "amazon alexa" with the PROXY method and NO saved data...
          4 Sep 10:07:13 - [warn] [alexa-remote-account:amazon alexa] open localhost:1885 in your browser
          4 Sep 10:07:57 - [warn] [alexa-remote-account:amazon alexa] EISDIR: illegal operation on a directory, open '/home/pi/Desktop'

          any ideas

          Comment


            #6
            Originally posted by sirbooker View Post
            i am getting this error ?
            4 Sep 10:07:13 - [warn] [alexa-remote-account:amazon alexa] EISDIR: illegal operation on a directory, read
            4 Sep 10:07:13 - [info] [alexa-remote-account:amazon alexa] intialising "amazon alexa" with the PROXY method and NO saved data...
            4 Sep 10:07:13 - [warn] [alexa-remote-account:amazon alexa] open localhost:1885 in your browser
            4 Sep 10:07:57 - [warn] [alexa-remote-account:amazon alexa] EISDIR: illegal operation on a directory, open '/home/pi/Desktop'

            any ideas
            Make sure the directory you are storing the cookie in has write permission

            Comment


              #7
              I don't use docker right now. Here is something I found about file access problems when using docker. Might not be the root cause of your issue.

              https://nodered.org/docs/getting-sta...sues-and-hints

              Comment


                #8
                Installed node-red on same Win 10 PC that's running HS 4.1.4.0

                I ran into an error when trying to add the alexa proxy; kept getting a 'debug module' not found. I rebooted the pc and the error cleared.

                I updated the recommended reset event. Interestingly when I tried using the guides event to reset the string using 'new message' I actually got the 'new message' announcement.

                I updated the event a bit; weirdly when I tried to use easy trigger's string changes and is not <blank> as the sole trigger, the event wouldn't trigger; however by placing it behind device value changes it works flawlessly. Note, if you forget the And If easy trigger part you'll create a loop.
                Attached Files
                HS4 Pro on Shuttle NC10U, Win10; Z-NET
                Number of Devices: 449
                Number of Events: 210

                Plug-Ins: Arduino, BLLock, DirecTv, EasyTrigger, Honeywell WiFi Thermostat, MeiHarmonyHub, PHLocation2, Pushover 3P, UltraM1G3, WeatherXML, Worx Landroid, Z-Wave

                External applications: Homebridge-homeseer, Geofency, EgiGeoZone.

                Comment


                  #9
                  Thanks for the guide its really good and I setup easily on same homeseer PC.

                  I am new to Alexa TTS with Homeseer so my issue is probably easy to solve

                  I installed node-red, linked to HS and alexa.

                  when run the HS event the variable passes across to node-red and the box goes yellow as per below

                  Click image for larger version

Name:	hserror1.png
Views:	791
Size:	9.2 KB
ID:	1418478

                  The only issue is Alexa does not speak

                  Click image for larger version

Name:	hserror2.png
Views:	741
Size:	74.9 KB
ID:	1418480

                  Have I done something stupid ?

                  Also I have quite a few alexa's and sonos but notice alexa touch devices do not show in the list ?
                  Attached Files

                  Comment


                    #10
                    I had tried to get this working before, and failed. However, I now have success thanks to this excellent guide. Thank you. :-)

                    Comment


                      #11
                      I’ve fixed my issue. I am in UK and had to change mode red to amazon..co.uk

                      All working really useful guide thanks again.

                      Comment


                        #12
                        I have written a few and they are mostly working, however I keep getting an error intermittently on different devices;
                        Click image for larger version

Name:	Flow.PNG
Views:	673
Size:	183.3 KB
ID:	1421786
                        The flow sends a message to 4 echos if the front door is opened. As you can see there is an error on the bedroom. It happens from time to time on any of my echos.

                        Not only do I not know what the error is, I don't know how to get to the full text!

                        Any suggestions welcome

                        Comment


                          #13
                          Originally posted by IanIreland View Post
                          I have written a few and they are mostly working, however I keep getting an error intermittently on different devices;
                          Click image for larger version

Name:	Flow.PNG
Views:	673
Size:	183.3 KB
ID:	1421786
                          The flow sends a message to 4 echos if the front door is opened. As you can see there is an error on the bedroom. It happens from time to time on any of my echos.

                          Not only do I not know what the error is, I don't know how to get to the full text!

                          Any suggestions welcome
                          I would use device groups for the echos, then just send the announce to the group. Amazon will handle the individual devices. I do this, and it works quite well.

                          Comment


                            #14
                            Originally posted by mterry63 View Post

                            I would use device groups for the echos, then just send the announce to the group. Amazon will handle the individual devices. I do this, and it works quite well.
                            Is that 'Audio Groups'?

                            Edit - I worked it out, thanks.

                            Comment


                              #15
                              In my phone app, it's listed as speaker groups, but sounds like the same thing.

                              Sent from my Pixel 2 using Tapatalk

                              Comment

                              Working...
                              X