TTS via NodeRed – Is there a better way?

[TC1]

So I finally got around to labbing the HS4 to NodeRed to Alexa integration. For Alexa TTS I’m using the node-red-contrib-alexa-remote2-applestrudel library, which I've got working.

So from what I’ve figured out so far is that in order to get the text into NodeRed one uses a HS4 virtual device status to hold the contents of what you want spoken. The problem I’ve notice is that when HS4 NodeRed Device nodes are updated that they output two different payloads, the first is the current status of the device and then next the new status of the device. Is this normal?

I’ve noticed that some people get around this by kludging together a bandaid, such as clearing the device status right after a TTS event so that the next TTS event will have a blank payload immediately followed by the desired text. This seems…. silly?

Is there a better, more elegant way to achieve TTS from HS4 into NodeRed? Since NodeRed has MQTT and HTTP In nodes, would it be better to use those somehow?
More importantly, why does the HS4 Device node output two payload messages whenever it is changed? Is this by design or a quirk?

Apologies if some of these points are incorrect or unclear, I’m still wrapping my head around this.

[jon00]

Just bypass Node-Red and use Voice Monkey which uses a virtual speaker client: https://forums.homeseer.com/forum/3r...r-3-homeseer-4

[ksum]

Depending on what you want it to say, you could possibly have Node-Red create the message.

I do not believe 2 messages are sent by HomeSeer when a device is changed. The easy way to tell would be to wire a Debug node to the output of a HomeSeer node. Set the Debug node to report the entire message. Deploy, then change the HomeSeer device using either the HomeSeer interface or a manual control. If you get two Debug messages, then it is outputting 2 messages. I did this and only get 1 message for each change to the HomeSeer device. In the image below I first manually controlled a z-wave wall switch at the switch itself. This is the debug message with the time highlighted blue. I then used the HomeSeer Browser Interface to turn the same device Off and received the message at the top of the debug window.

I then created a flow with 3 nodes. The HomeSeer device used above, a Change node which sets msg.payload.text to the Expression

"The " & msg.nodeName & " is " & msg.payload.status

, and the Alexa Routine node which is set to speak to my Office Echo. This was set up as provided in Mark's write-up, How To Enable Alexa TTS Announcements for HomeSeer Devices, which was based on this thread. I am using the cakebaked contrib branch, as opposed to the applestrudel contrib, but these are branches from the same base and the node configurations, to the best of my knowledge, are identical.

After running through this configuration I DID find ONE instance where 2 messages are sent from HomeSeer. In my above tests, I only turned the switch Off using the HomeSeer Web Interface. I manually turned it On at the physical switch. Since my z-wave switch is a Dimmer, I have the option in HomeSeer for Last, which turns the switch On and then sets it to the last dim level. In this case I do get two messages:

1. "The Basement TV Room TV Light is Last"
2. "The Basement TV Room TV Light is 50%"

We can use a Switch node to filter out the first message. I set it to look at msg.payload.status and see if it matches a regex of last. I also added the Otherwise output so that anything not expect the message where the status is Last has a selection. By not connecting a wire to the top output, I effectively ignore these instances. The settings for this Switch node are as shown below. If you find other instances where HomeSeer sends 2 messages, you can add an entry above the Otherwise option for that as well. Just use the Add button at the bottom left of the node's editor and then use the 3 horizontal bars to the left of the otherwise option to grab and drag that option to the bottom.

If you think about what HomeSeer does when you select Last, this behavior makes sense. You can also see the results in the web interface. The slider for this dimmer first goes to 100% and then bounces down to the last value from in the switch. The HomeSeer device is being set twice and it is only telling Node-Red what it is supposed to. Each change. I have just created an "Issue" post on the contrib's GitHub page regarding this.

The Change node has one item set as shown here and is connected to the bottom output of the above Switch node. Connect the output of this Change node to the Alexa Routine and you should be good.

This leaves the entire flow looking like this:

Here is the JSON you can Import into your flow for the Switch and Change nodes. The HomeSeer and Alexa nodes have been left out so you can use your own and not import my settings.

[{"id":"9924431ab4d515de","type":"change","z":"13a2d7f7157ad8fd","name":"","rules":[{"t":"set","p":"payload.text","pt":"msg","to":"\"The \" & msg.nodeName & \" is \" & msg.payload.status","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":640,"y":1160,"wires":[["7beb8cf343540e94"]]},{"id":"1ed9f14206562b4c","type":"switch","z":"13a2d7f7157ad8fd","name":"","property":"payload.status","propertyType":"msg","rules":[{"t":"regex","v":"last","vt":"str","case":true},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":450,"y":1160,"wires":[[],["9924431ab4d515de"]]}]

[TC1]

ksum, appreciate the helpful info, but it doesn't really address my main need: Having Alexa speak custom phrases from HS4. I know how to extract and speak the status of regular HS4 devices, but what my goal is to have HS4 events create custom phrases based on my events I run that detect status of other devices, like window and door sensors. Instead of sending Alexa separate speech requests like "Front door is open" and then "Back door is open" and then.... you get the idea. I want to concatenate all the statuses into one phrase for Alexa to speak so I'll construct the text in HS4 first and send it to Node-red. So the final phrase will be variable depending on device statuses, such as "These doors are open, Front Door Back Door"

I made a virtual device in HS4 to hold the phrase and used Easy Trigger to set the Device String... the problem is I don't know how to extract Device String in Node-red, or if it's even being passed by the HS4 node device. It seems like Control Status can only hold numeral values?

Hopefully I explained my use-case better

[ksum]

You can use Node-Red to build the phrase the same as your event does. I will put something together when I'm at a computer to show how this can be done. What are your criteria? If one sensor changes to Open, then report the status of all that are open? Do you wait X second first?

[TC1]

Never mind... I figured it out. In order to get the HS4 node-red node to pass the device string as the payload.status one has to delete the child Control feature on the virtual device in HS4. Works perfectly now.

I'd rather not construct the phrases in Node-red because voice announce is just one of several notification streams. For example, based on other conditions, like we're away from home, the HS4 event will run, construct the message, but it might send it via email. When HS4 knows we're home, messages will then announce via node-red/Alexa. Because of the variable notification methods, it makes more sense to keep the logic and message construction on HS4.

I really do appreciate your helpfulness on node-red, I've read other message threads where you help out and it has greatly increased my understanding of node-red.

[vasrc]

On a related note..
Anyone find a way to send SSML code from HS4 to Node-Red without having all of the SSML tags (html-ish) stripped? I've delimited every way I can think of and they always get removed. Using Events to generate the SSML text strings (I also prefer to generate the text in HS4), but have also tried raw hs.setDeviceString as well.

Tnx
Z

[SteveMSJ]

On a related note..
Anyone find a way to send SSML code from HS4 to Node-Red without having all of the SSML tags (html-ish) stripped? I've delimited every way I can think of and they always get removed. Using Events to generate the SSML text strings (I also prefer to generate the text in HS4), but have also tried raw hs.setDeviceString as well.

Tnx
Z

What I do is use square brackets '[ ]' instead of normal tags '< >' in the HS device string and then I have a replace node in my node-red flow that replaces the square brackets with normal tags. A bit of a hack but it works fine.

Steve

[vasrc]

Great hack. I'll give it try

[ksum]

On a related note..
Anyone find a way to send SSML code from HS4 to Node-Red without having all of the SSML tags (html-ish) stripped? I've delimited every way I can think of and they always get removed. Using Events to generate the SSML text strings (I also prefer to generate the text in HS4), but have also tried raw hs.setDeviceString as well.

Tnx
Z

Place it in the device's Note in HomeSeer and access it via msg.payload.UserNote in your Node-RED flow.

CC: SteveMSJ

[ksum]

So from what I’ve figured out so far is that in order to get the text into NodeRed one uses a HS4 virtual device status to hold the contents of what you want spoken. The problem I’ve notice is that when HS4 NodeRed Device nodes are updated that they output two different payloads, the first is the current status of the device and then next the new status of the device. Is this normal?

I’ve noticed that some people get around this by kludging together a bandaid, such as clearing the device status right after a TTS event so that the next TTS event will have a blank payload immediately followed by the desired text. This seems…. silly?

Is there a better, more elegant way to achieve TTS from HS4 into NodeRed? Since NodeRed has MQTT and HTTP In nodes, would it be better to use those somehow?

Let's investigate this and see if we can figure out what is causing the 2 message instance and if we can fix the apparent problem. Per my tests the Node-RED flow is initiated when the device changes and I am only receiving one message, which is after the change. I have not received messages of the current device value prior to a change unless I ask for such in Node-RED. Can you share an image of your flow and also an Export of the flow where you receive 2 messages? I see you have created a Virtual Device and are setting the device's String. I do not use Easy Trigger, but setting the device string using

hs.SetDeviceString(586, "<span style='color: red; font-size: 10pt;'>Hello World</span>", True)

in an Event only causes one Node-RED message to be received. Can you confirm that setting it via Easy Trigger sends 2 messages? I am wondering if this is from an Easy Trigger nuance. I did look to use the old Event method of setting the Device String without issuing a script command, but cannot find this in the HS4 Events. The other possibility is that there is a setting in the device causing this. Also, make sure "Report state on startup" is not checked in the HomeSeer node in Node-RED.

[vasrc]

Another great option..
Do you know if there is an hs. command to do that, or do you need to insert it into the DeviceClass object?

Tnx

[ksum]

Another great option..
Do you know if there is an hs. command to do that, or do you need to insert it into the DeviceClass object?

Tnx

There is, of course, the Manual setting you are likely aware of as circled in the image below. A quick search of the Scripting documentation only shows one entry for UserNote. That is under the Identity heading. I tried passing a new value to msg.payload.UserNote but it did not update the User Note in the HomeSeer device. Apparently this is a Read Only value. If there is a use case, we could see if the ability to edit this via Node-RED could be added.

[Kevb]

Let's investigate this and see if we can figure out what is causing the 2 message instance

From Fellhahn :

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.

https://forums.homeseer.com/forum/ho...E2%80%9D-guide

Perhaps there's a new way around this?

[spud]

From Fellhahn :

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.

https://forums.homeseer.com/forum/ho...E2%80%9D-guide

Perhaps there's a new way around this?

make sure HS device has the "Last Change Time Updates on status Change Only" setting unchecked
the device update is only sent to Node-Red if the device last change time is updated.