Page 3 of 3 FirstFirst 123
Results 21 to 24 of 24

Thread: Alexa and Evohome

  1. #21
    Automated Home Sr Member philchillbill's Avatar
    Join Date
    Jan 2017
    Location
    Eindhoven, Holland
    Posts
    59

    Default

    Quote Originally Posted by gordonb3
    I get that. That wasn't the point though. On topic is Phil's Alexa bridge and the suggestion to use Domoticz as an intermediate to communicate with Evohome through any of the supported "hardware". My comment was about the integrated Web API method being unmaintained *and* showing issues due to changed policies on the Honeywell side.


    @philchillbill:
    I don't know what methods you'd like to implement in your Alexa bridge, what programming language you use and if you can already communicate with Domoticz, but I have a project named dzEvo on GitHub that allows specifying zone names rather than numeric IDs as well as alternate methods for specifying setpoint and `until` time. Maybe you could use (parts of) it to get a jump start.
    Thanks for the offer, much appreciated. I already have two skills for Alexa running in my personal account for about 2 years now. One is a custom skill written in nodejs and using my own nodejs bindings to the TCC API. The other is a Smart Home skill written in Python that interfaces with Domoticz through JSON calls and controls my Evohome setup through the HGI-80 integration in Domoticz. I wrote those Python bindings myself as they talk to Domoticz and not TCC.

    I originally planned on releasing the custom one as it allows changing and querying schedules by voice and supports scenes. However, the lack of my own API key from Resideo to date has stopped me as I'm not investing more time into a dead end. Also, the 'worry' that a spoken command might not make it to the TCC cloud because of some token or comms glitch always looms and a skill only has 8 sec by definition to do its thing and die, so there's no hanging around to retry. Downside of custom skills is also that the whole voice model has to be handcrafted so it would have been en-US and en-GB only.

    The advantage of having Domoticz in the loop is that there is a command buffer between Alexa and TCC as it were. Domoticz can do the TCC comms retrying if need be. When I originally did the Smart Home skill via Domoticz the potential commands were more limited compared to my custom skill (but still MUCH better than the Resideo skill) but some time back Amazon introduced the Toggle, Mode and Range Controller Interfaces and they are actually quite versatile so I've added per-zone mode controls and also scenes. With the advantage that Smart Home skills support any spoken language that I write up an Amazon store-description for (which is a *lot* less work than translating a voice model).

    I already have a live account-linking oauth flow that I wrote myself for my 2 published skills MediaServer and LMS-lite (for Logitech Media Server) so that concept can be hijacked for an Evohome skill too. By targeting the Domoticz interface to Evohome I avoid TCC altogether when a HGI-80 or one of the homebrew RF equivalents is used. That's a smaller user base but at least it removes depending on the whims of Resideo. I'll put it together in the next few weeks and then ask here for a few beta testers.

    Cheers again!

  2. #22
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    169

    Default

    That was kind of why I wrote dzEvo. Originally I had something offering the same functions directly targetting TCC but as they introduced the login limits I found that my commands started to be (partially) rejected and the better idea was to run the commands through Domoticz as that used a continuous session. As I have part of my infrastructure running on low power CPU I try to avoid using programming languages that implement runtime interpretation, especially python that generates a ridiculous amount of overhead (e.g. watchforstock's implementation adds 40+ seconds to my own C++ based ELF binary running on my 24/7 system).

    Either way, out of the added functions in dzEvo there's one that I use practically every day during Winter:

    set temperature Collin to 20 degrees for 15 minutes

    This creates a cozy temperature in my son's bedroom at bed time and once he's tucked in it's okay for the temperature to drop again to as low as the set default of 15C that rarely requires the heater to turn on in this house. If you haven't implemented such a thing, I'd definitely give it a thought.

  3. #23
    Automated Home Sr Member philchillbill's Avatar
    Join Date
    Jan 2017
    Location
    Eindhoven, Holland
    Posts
    59

    Default

    Quote Originally Posted by gordonb3 View Post
    That was kind of why I wrote dzEvo. Originally I had something offering the same functions directly targetting TCC but as they introduced the login limits I found that my commands started to be (partially) rejected and the better idea was to run the commands through Domoticz as that used a continuous session. As I have part of my infrastructure running on low power CPU I try to avoid using programming languages that implement runtime interpretation, especially python that generates a ridiculous amount of overhead (e.g. watchforstock's implementation adds 40+ seconds to my own C++ based ELF binary running on my 24/7 system).

    Either way, out of the added functions in dzEvo there's one that I use practically every day during Winter:

    set temperature Collin to 20 degrees for 15 minutes

    This creates a cozy temperature in my son's bedroom at bed time and once he's tucked in it's okay for the temperature to drop again to as low as the set default of 15C that rarely requires the heater to turn on in this house. If you haven't implemented such a thing, I'd definitely give it a thought.
    I use nodejs and Python because Alexa skills use Amazon's Lambda compute environment and all the example code snippets are for those 2 languages. Plus, Lambda has resources aplenty.

    Implementing timed overrides was the reason I decided to write my own skill in the first place. The European version of the Resideo TCC skill does not support this (see the first post in this thread) while the Alexa.ThermostatController Interface does have the voice model for it so it was a no-brainer to implement. And as you point out, a hugely useful function. That a product manager at Resideo could skip specifying this when both Alexa and Evohome have the base capability is beyond me. It's what happens in big corporations when somebody with no actual affiliation with the end-product is put in charge. Sigh.

    A feature I also find very useful is a link to Google Calendar. My better half has a Pilates Studio at home. If any entries in her calendar start with 'Client:' then the Studio is automatically set to be at 22 deg at that time. I have a cron job running that polls her calendar and continually edits the TCC schedule for that zone based on what it finds. This also overcomes the max 6 switchpoints per zone per day that Resideo limit us to.

    @DanD figured out a while back how to modify schedules via the HGI-80 and he kindly sent me a script a while back to do this without having to use TCC at all. But I find it sometimes conflicts with Domoticz accessing the HGI-80 so it's a big pity this code never made its way into Domoticz itself.

  4. #24
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    169

    Default

    See? Good ideas rarely pop up in just one mind.

    Shame about Amazon focussing on those 2 languages. In my experience the only interpreted language that works decent on every platform is Perl.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •