(Last Updated: June 24, 2020)

Voice Control and TTS Projects

  • 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:

    The equivalent for Apple Siri:

    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:

    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.

  • 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 🙂

  • This is so much faster than the Vera skill


  • 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!

  • 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


  • 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?



  • 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:${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?



  • 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.

  • Fixed the formatting 😄



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

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


  • 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.

  • Wow that's a useful thing to learn.

    Thanks so much!


  • It actually needs to be this:${intensity.percent}


Log in to reply