Voice Control and TTS Projects

[rafale77]

Some of my favorite projects I have been using on my setup for over 5 years:
Bridge the vera or openluup to amazon echo through a local hue emulator. A much faster solution than the vera native bloatware as the only cloud service is used by this alternative is the voice recognition. It was initiated for vera control but later expanded to many other platforms like the logitech Harmony and other controllers. No cloud to cloud so no need for mios servers:

bwssytems/ha-bridge

Home automation bridge that emulates a Philips Hue light system and can control other systems such as a Vera, Harmony Hub, Nest, MiLight bulbs or any other system that has an http/https/tcp/udp int...

The equivalent for Apple Siri:

Hackworth/VeraHomeKitBridge

Contribute to Hackworth/VeraHomeKitBridge development by creating an account on GitHub.

Alternative SONOS TTS implementation from all the plugin versions applicable for any platform since it is an API you can call. It is run also locally on a MacOS desktop in my case but can run on anything running nodeJS. For the TTS to be fully local though, you will need a mac or bear with the robotic voice of maryTTS. I have been hesitant to move my TTS to the amazon echos (project by @therealdb), but the echos lack synchronization and are cloud dependent which causes a 3-5s delay I do not have with this local solution, so this remains my choice:

jishi/node-sonos-http-api

An HTTP API bridge for Sonos easing automation. Hostable on any node.js capable device, like a raspberry pi or similar. - jishi/node-sonos-http-api

Use my fork if you need to install on Catalina because some fixes are needed and my pull request from months ago has not yet been merged.

[therealdb]

My plug-in got device sync lately, but you're right, it's never really sync'ed, it depends on Amazon's servers. Overall I like it and I will move to a similar setup (ha-bridge) very soon, because I want blinds/temp sensors and I'm tired of writing scenes

[CatmanV2]

This is so much faster than the Vera skill

C

[rafale77]

I know... now you understand what I was talking about when I was referring to cloud to cloud nonsense in the old place and my mehhh comments in the "Alexa turn on the Christmas lights on" thread... We have been doing it faster better in every way for over 5 years thanks to the community!

[CatmanV2]

Yep, In for a penny, as we say over here. It'll depend on when my UZB gets here, but I suspect I'll be Vera free by the end of the week.

Is it possible to change the icons that Alexa shows for HA bridge devices? Not that I ever look, but....

Thanks for all your help

C

[CatmanV2]

Where's the best way to get help with creating the specific commands required for HA Birdge to control a thermostat? The build button has created on, off (not hugely useful) and 'Dim' URLs, but I don't see how you can pass a specific temperature to it? Also I'm pretty sure that SetLoadLevel is not the correct command. It should be something like SetCurrentSetpoint?

Cheers

C

[CatmanV2]

As ever a voyage of discovery
So my logs show this when the temperature is changed automatically:

08	06/21/20 16:58:03.905	JobHandler_LuaUPnP::HandleActionRequest device: 80 service: urn:upnp-org:serviceId:HVAC_UserOperatingMode1 action: SetModeTarget <0x73c25520>
08	06/21/20 16:58:03.906	JobHandler_LuaUPnP::HandleActionRequest device: 80 service: urn:upnp-org:serviceId:TemperatureSetpoint1_Heat action: SetCurrentSetpoint <0x73c25520>
06	06/21/20 16:58:03.907	Device_Variable::m_szValue_set device: 80 service: urn:upnp-org:serviceId:TemperatureSetpoint1 variable: SetpointTarget was: 18.00 now: 21.00 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x73c25520>

My new shiny HA Bridge command is this:

http://192.168.70.249:3480/data_request?id=action&output_format=json&DeviceNum=10080&serviceId=urn:upnp-org:serviceId:TemperatureSetpoint1_Heat&action=SetCurrentSetpoint&SetpointTarget=${intensity.byte}

And the log shows this

08	06/24/20 12:17:39.117	JobHandler_LuaUPnP::HandleActionRequest device: 80 service: urn:upnp-org:serviceId:TemperatureSetpoint1_Heat action: SetCurrentSetpoint <0x724d1520>
08	06/24/20 12:17:39.118	JobHandler_LuaUPnP::HandleActionRequest argument DeviceNum=80 <0x724d1520>
08	06/24/20 12:17:39.118	JobHandler_LuaUPnP::HandleActionRequest argument SetpointTarget=57 <0x724d1520>
08	06/24/20 12:17:39.118	JobHandler_LuaUPnP::HandleActionRequest argument action=SetCurrentSetpoint <0x724d1520>
08	06/24/20 12:17:39.118	JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:upnp-org:serviceId:TemperatureSetpoint1_Heat <0x724d1520>
02	06/24/20 12:17:39.118	ZWaveNode::ReceivedMessage serv urn:upnp-org:serviceId:TemperatureSetpoint1_Heat action SetCurrentSetpoint unhandled <0x724d1520>
02	06/24/20 12:17:39.119	JobHandler_LuaUPnP::RunAction device 80 action urn:upnp-org:serviceId:TemperatureSetpoint1_Heat/SetCurrentSetpoint failed with -115/Device does not handle service/action <0x724d1520>

So clearly I'm not quite there. Also my Set to 22 appears to have been converted to 57? In case that was out of range I tried to set to 10 and that logged a SetpointTarget of 26.

Any thoughts on that?

Cheers

C

[rafale77]

This is likely a formatting problem just like your post
I have not actually implemented voice control of my thermostat. I instead created a plugin to make it completely automated so I never have to touch it. It uses the room feature, combining data inputs from temperature sensors in each room and outdoor, motion and door/window sensors to set actions on register vent openings and the thermostat.
But back to topic: There maybe some conversion going on between temperature and percentage/hex. It looks like it is taking your input as a percentage (0-100) and outputting it as a byte (0-255), basically using a x2.55 factor. It is actyally in your code: "intensity.byte"
try "intensity.percent" which will not convert the numeral since the echo api uses percentages.

[CatmanV2]

Fixed the formatting

Thanks!

C

[CatmanV2]

OK, thanks. intensity.percent worked perfectly in terms of passing the SetpointTarget to 22

Can't figure out why SetCurrentSetpoint doesn't work though.

C

[rafale77]

That's because the parameter you use is incorrect. The parameter for SetCurrentSetpoint is NewCurrrentSetpoint. You can see that by going into ALTUI, open the device, under the action menu... Look up SetCurrentSetpoint.

[CatmanV2]

Wow that's a useful thing to learn.

Thanks so much!

C

[CatmanV2]

It actually needs to be this:

http://127.0.0.1:3480/data_request?id=action&output_format=json&DeviceNum=10080&serviceId=urn:upnp-org:serviceId:TemperatureSetpoint1&action=SetCurrentSetpoint&NewCurrentSetpoint=${intensity.percent}

C

[LibraSun]

Meanwhile (and PLEASE correct/guide me if I'm in the wrong sub-Topic to ask this), I'm back in the mid-2020 era of trying to get my Vera Plus back to doing TTS through my Sonos Beam device, with the help of @toggledbits latest hotfix 21314.1625 grafted onto the SONOS 2.0 plugin.

Thing is, I've gone through all the traditional routes:

• Ensured my MS Azure Cognitive account is up-to-date;
• Double-checked all settings* (IP, Volume, Zone, etc.) and keys are current;
• Checked Vera's LuaUPnP logs, and found:

50	03/16/21 17:45:17.880	luup_log:321: Sonos: (TTS) Engine "Azure Speech Service" created "http://192.168.86.30/port_3480Say.322.mp3" <0x773df320>
06	03/16/21 17:45:17.981	Device_Variable::m_szValue_set device: 322 service: urn:upnp-org:serviceId:AVTransport variable: TransportStatus was: ERROR_RESOURCE_NO_LONGER_AVAILABLE

which to my eye indicates a pathname issue (after port_3480)?

But I can't find any current discussion among others having the same SILENCE problem.

Anyone in the same boat? Got a new list of Troubleshooting Steps for me to undertake?

THANKS! - Libra

OTHER SETTINGS TO NOTE, in case they matter:

TTS SETTINGS
Default Engine: Azure Speech Service
Region: southcentralus
Voice: engine default: Jessa
Endpoint: https://vera-tts.cognitiveservices.azure.com/
Requestor: automatic (recommended)
UPnP Proxy: Installed

SONOS VARIABLES
TTSBaseURL = (blank)
TTSBasePath = (blank)

[mrFarmer]

Hi Libra,

In the file name for the mp3 the slash charter between port_3480 and Say is missing. I.e. it should read .../port_3480/Say...

Cheers Rene

[toggledbits]

It's not just the slash that's missing; there's a directory name before it as well. Really the only way that happens is a problem with the content of TTBaseURL. But, if during experimentation you have a problematic value, it's entirely possible that (broken) URL gets stored in the cache entry for the speech item, and then every time you speak it and it gets a cache hit, it will pull out that broken URL. So a few things to do here:

First, let's disable the cache during testing/troublesheeting: set UseTTSCache to 0.

Then, let's make sure TTSBasePath and TTSBaseURL get their default (computed) values, and not rely on the Vera UI to tell us they "look" blank:

luup.variable_set( "urn:toggledbits-com:serviceId:SonosSystem1", "TTSBaseURL", "", sonos-master-device-num)
luup.variable_set( "urn:toggledbits-com:serviceId:SonosSystem1", "TTSBasePath", "", sonos-master-device-num)

Finally, debug on for "Plugin" and "TTS" in the master device settings, reload Luup, hard refresh browser.

Getting as far as it did to see the error message you posted is a good sign. With this clean slate, if there's still something causing a problem, it will be easier to run down.

[LibraSun]

YES! Did all the things, and voilà!! Didn't even have to check the logs... Sonos she talk to me now!!

THANK YOU SO MUCH. I'll go turn off the extra logging now.

[toggledbits]

OK. And you can probably turn the cache back on as well. I'm betting is just had some cached bad URLs, so before turning it back on, SSH into your Vera and rm -rf /www/sonos/ttscache to clear the cache entirely. It will be recreated as you go.