Originally posted by philchillbill
View Post
Alexa and Evohome
Collapse
X
-
Last edited by gordonb3; 20 September 2020, 07:51 PM.
-
-
Originally posted by gordonb3 View PostYes, I'm sure. Session renewal right was stripped last December and I submitted a fix for that issue when the errors started popping up. Three months later they changed the HTTP return code on the explicit session renewal request and that causes the module to fail and keep trying to use the expired session ID. The fix to this never made it to Domoticz main line.
I was referring to the high resolution temperature measurements - I'm still receiving temperatures in high resolution on the V1 API while you were suggesting that was gone.
The new API key is already in watchforstock's python binding. He got it from Joe Zwack who also submitted the necessary changes to correct for the renamed fields and values. As I was to receive my own API key I did not copy it at the time and kept using the one that watchforstock used before that time as well. I never did receive that key though and as communicating with the Domoticz project owner was already troublesome I decided to leave it as is because it actually works for most but somehow it is starting to block new users more frequently and consistently.
Comment
-
-
Originally posted by DBMandrake View PostI was referring to the high resolution temperature measurements - I'm still receiving temperatures in high resolution on the V1 API while you were suggesting that was gone.
I should also mention that I had this stored incorrectly in memory. The change from March 2020 does not result in the v1 session validation routine in Domoticz to always return True, it always returns False and as a result it does a new login at every poll and you do hit the rate limit that they installed I think in 2018 or so.
Originally posted by DBMandrake View PostAhh ok. I thought this was a new change. I knew about the one a year or so ago that had been incorporated into watchforstock's evohomeclient2. What I didn't know was that this change has apparently not gone into domoticz. (I wouldn't have noticed as I don't use it anymore)
Comment
-
-
I think we're talking at cross purposes here. I don't use Domoticz. I was referring to the over the air API's only.
I was just trying to point out that the V1 API does still report high resolution temperatures through the evohomeclient library, because my own graphing solution does still record high res values.
Whether domoticz does or doesn't is none of my concern
Comment
-
-
Originally posted by DBMandrake View PostI think we're talking at cross purposes here. I don't use Domoticz. I was referring to the over the air API's only.
I was just trying to point out that the V1 API does still report high resolution temperatures through the evohomeclient library, because my own graphing solution does still record high res values.
Whether domoticz does or doesn't is none of my concern
@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.
Comment
-
-
Originally posted by gordonb3I 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.
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!
Comment
-
-
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.
Comment
-
-
Originally posted by gordonb3 View PostThat 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.
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.
Comment
-
-
Originally posted by philchillbill View Post@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.
Comment
-
-
Originally posted by bruce_miranda View PostBoth 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.
Comment
-
-
Originally posted by bruce_miranda View PostBoth 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.
Comment
-
-
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.
Comment
-
-
Originally posted by philchillbill View PostI 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.
Comment
-
-
Originally posted by gordonb3In 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.
Comment
-
Comment