Alexa and Evohome

[philchillbill]

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!

[gordonb3]

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.

[philchillbill]

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.

[gordonb3]

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.

[bruce_miranda]

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

Both Dan and I couldn't work out how to integrate the schedule features of the HGI-80 with the rigid code base structure of Domoticz. So we just abandoned the idea. Javascript wasn't either of our strength.

[gordonb3]

Both Dan and I couldn't work out how to integrate the schedule features of the HGI-80 with the rigid code base structure of Domoticz. So we just abandoned the idea. Javascript wasn't either of our strength.

Same applies to the integrated Web API method. The code to manipulate schedules is all in there but there is no user interface that targets it and neither has the API been extended to allow this through some other front-end. The Web API method does use the schedules however to provide direct feedback on (cancellations of) overrides and preload `until` times to the next switch point. I think Dan commented on finding that a useful feature, didn't he implement it for the HGI80?

[philchillbill]

Both Dan and I couldn't work out how to integrate the schedule features of the HGI-80 with the rigid code base structure of Domoticz. So we just abandoned the idea. Javascript wasn't either of our strength.

I wonder if it would be possible to support schedule save/retrieve at least via the JSON API if not graphically? Or are the GUI and JSON in Domoticz too interwoven? I have it the other way around, unfortunately - strong with JS but not with CPP.

[philchillbill]

By the way, Amazon announced a boatload of new smart home features for Alexa yesterday. In this blog https://developer.amazon.com/en-US/b...ome-with-Alexa the name Resideo is mentioned several times as working on integrating the new features. But, it's the Home stuff and not TCC so it will happen for Lyric and such and not for Evohome is my guess. Sigh.

[gordonb3]

I wonder if it would be possible to support schedule save/retrieve at least via the JSON API if not graphically? Or are the GUI and JSON in Domoticz too interwoven? I have it the other way around, unfortunately - strong with JS but not with CPP.

In theory, yes. The so-called JSON API in Domoticz is in fact not JSON at all, it just returns JSON in response to a string of URI GET parameters. Trying to pass complex data like a JSON string as a parameter value will prove to be very ugly. And of course you need to convince the Domoticz project owner that such a feature is desirable. One of the most feasible options that I came up myself is to let the Evohome worker thread itself inspect a queue directory for uploads of such more complex inputs. Never implemented it though as I get by just fine with normal overrides and on the rare occasions that I do want to update schedules I just use my own backup-restore app for that.

[philchillbill]

In theory, yes. The so-called JSON API in Domoticz is in fact not JSON at all, it just returns JSON in response to a string of URI GET parameters. Trying to pass complex data like a JSON string as a parameter value will prove to be very ugly. And of course you need to convince the Domoticz project owner that such a feature is desirable. One of the most feasible options that I came up myself is to let the Evohome worker thread itself inspect a queue directory for uploads of such more complex inputs. Never implemented it though as I get by just fine with normal overrides and on the rare occasions that I do want to update schedules I just use my own backup-restore app for that.

Where I would envisage using it is with schedule pull-forward or delay. For example, "Alexa, delay bedtime by 30 mins" would move all the scheduled switchpoints to a later time if e.g. I wanted to stay up to finish a movie. Similarly, "Alexa, early start tomorrow by 45 mins" would be useful if I need to go somewhere early in the morning. I like the idea of having a simple/compact Alexa command do things that otherwise need several steps if using the Evotouch or the phone App (or even Domoticz).