EvoControl - custom Alexa skill for Evohome

[zxdavb]

I use the _name during...

My official advice is to use name in params rather than _name in schema.

I see that when the _name in the schema is null then the corresponding climate.xxxxxx entity also has null in the attributes.params.name field.

If one is null, then so would the other be... But that value just shouldn't be null, and I'd like to know why. You should be able to work on the basis that - for the most part - it is not null (especially with the packet cache).

... However, attributes.friendly_name is correctly populated.

Beware - the default value for the friendly_name is the current zone name from the controller (and if the zone is later renamed at the controller, then that should be OK), but: if the user choses to rename the entity in HA (rather than at the controller), then they'll not match from that point on, unless the user renames either / both, so that they do match - you can't rely on that.

see: https://www.home-assistant.io/docs/c...izing-devices/
"You can use the UI to change the entity ID and friendly name of supported entities..."

I use the _name during what I call discovery which is where I find the correlation between the ramses_cc userdata and that in the TCC cloud.

Basically, I loop over all the known TCC zone names and look for a fuzzy-matched equivalent in the HA API data. Currently, I parse the binary_sensor.01_123456_schema and make sure all the TCC zone names also have an equivalent _name field somewhere in the schema. If there is a 1:1 match for all zones, the discovery succeeds and subsequently for determining state, I use the climate.xxxxxx entries returned by the API.

If you think it's safer, I can filter out all the climate entities that have a zone_idx (and as I now know, not a zone_id) and extract attributes.params.name as the name to check against TCC.

I have 'discovery' - it is deterministic. I also have eavesdropping, which is less reliable... For example, I use the current temperature of a zone to match to current temperatures of sensors - this is usually OK, as they have a precision of 0.01, but it is not deterministic.

Anyway, for the above: you should really rely upon the name params.name attr, rather than the friendly name, for reasons listed above.

If you think it's safer, I can filter out all the climate entities that have a zone_idx (and as I now know, not a zone_id) and extract attributes.params.name as the name to check against TCC.

I do - but appreciating that the value can be null, sometimes.

If it *is* null, you can ask ramses_rf to RQ|0004 to get the name - this will be much easier with the upcoming version of the library.

[philchillbill]

My official advice is to use name in params rather than _name in schema.

Thanks David. Then I'll use params.name and continue to ignore friendly_name . I already handle a potential null with an error message to the user and it's then game-over for the skill because it's the user's responsibility to get this stuff right IMHO.

[zxdavb]

... and I think I'll be working out a way to prevent people from changing the friendly names of climate entities.

[philchillbill]

v1.9 is now live

I've just pushed v1.9 live. It's mainly a bug-fix and inconsistency-correction release before v2 is unleashed. As always, you don't have to install or change anything as you automatically get the latest code when you run the skill.

• Header texts and button captions in all schedule views have been tweaked to provide more context information. There are also new hint-headers.
• Fixed a bug which left the selective-edit cell-dimming on after the back button was used.
• Fixed a bug where using the back button after editing a schedule but not saving/uploading it would show the aborted edit until the first TCC refresh. It now clears directly on 'back' selection.
• Merely saving a modified schedule no longer inadvertently uploads it as live.
• The Evotouch panel button in schedule-selection can now show captions where appropriate.
• Schedule comparison (tabular, not graphical) now prevents you from comparing known-equivalent schedules outright.
• The help text on the zone-order selection screen now correctly disappears if you revert all rows to the initial state.
• In schedule-related button rows, the cancel button now only appears when the nesting level is greater than 2. Otherwise, hitting the back button achieves the same outcome.
• When a cancel button is present in a button row, it returns to the initial screen for the function in question, so jumps back >1 screens.
• The 📝 indicator for a non-ABC schedule in the next-switchpoint appendage under the dashboard tiles now also has the same blue frame background/outline as ABC's get.
• The HA connector will now reject the non ramses_cc integration via the WebAPI (i.e. 'Evohome' integration).
• Fixed a bug whereby HA and Domoticz could get mixed up and cause immediate deletion of freshly-discovered HGI data.
• Trend graphs of HGI data should look smoother.

Enjoy!

[philchillbill]

When you unlink the skill and re-link it, the oauth authorization which was refreshed multiply since your original linking dies together with all the skill's data in DynamoDB. Pulling the original oauth tokens from your account won't work because your subsequent refreshes invalidate them. I've just changed the skill-disable behaviour so the most recent oauth refresh token is snatched in the skill's dying throes and stored back into your account dashboard to overwrite the original oauth, so if you re-link the skill within 6 months then re-auth should no longer be necessary. Hope that makes sense.

[philchillbill]

I've added several new error messages that will show if there are issues with your HA Connector when you tap the red HA icon in the top right corner. This feature now also works when the Domoticz Connector icon is red.

[philchillbill]

When you refresh your configuration, if TCC is reporting one or more faults with your panel (e.g. BoilerCommunicationLost) then you will be told so in order to draw your attention to it.

[jweaver]

As we are heading towards the end of the year, it will be time to turn the heating back on soon.. Is the charging model for Evocontrol ready yet? When will we have to start paying??

[philchillbill]

As we are heading towards the end of the year, it will be time to turn the heating back on soon.. Is the charging model for Evocontrol ready yet? When will we have to start paying??

The EvoControl website says it'll be from Sept 1st and that should be fairly on the mark. I've asked some people at Honeywell if they want to sponsor it so I can keep it free for end-users but no response at all, I'm afraid.

[bruce_miranda]

I wouldn't be surprised if Resideo decides.to simply shuts off the free TCC service one day. People have no idea how much a cloud service costs to run and maintain.

[philchillbill]

I wouldn't be surprised if Resideo decides.to simply shuts off the free TCC service one day. People have no idea how much a cloud service costs to run and maintain.

[bruce_miranda]

I am wondering if Resideo have completely forgotten about Evohome. It's services like EvoControl that have really increased its usefulness far longer than Honeywell ever envisaged. I am hopeful that if/when TCC does get shut down EvoControl+HA+ramses_cc+evofw3+SSM-D2 continues to provide a smart local control option

[philchillbill]

I am wondering if Resideo have completely forgotten about Evohome. It's services like EvoControl that have really increased its usefulness far longer than Honeywell ever envisaged. I am hopeful that if/when TCC does get shut down EvoControl+HA+ramses_cc+evofw3+SSM-D2 continues to provide a smart local control option

EvoControl is used by non-nerds and nerds alike, in about a 14:1 ratio (around 7% of users of the skill have activated either the HA or Domoticz Connector). The problem with the "HA+ramses_cc+evofw3+SSM-D2" part of your equation is that it is decidedly nerd-only territory. So in the case of a TCC demise, the masses will just switch to the likes of Drayton, Netatmo, Tado, etc. Or else just continue to use Evohome standalone without the app/skill in set-and-forget mode.

Methinks the real problem with Evohome is that Resideo sees it as a B2B rather than B2C product. They market it to installers. Your local friendly installer is supposed to not just install it for you (yikes!) but make you aware of Evohome's existence in the first place (even bigger yikes). My regular boiler serviceman Jos told me he recently went through a full heat-pump certification so he is still capable of learning new stuff at his age. But he freely admits to despising anything to do with (smart) thermostats and runs a mile when consumers ask him.

One of the most popular webshops in NL (Coolblue) doesn't even have Evohome as an option in the category Smart Thermostats (see the list of supported brands on the left in the screenshot: Bosch, EVE, Hama, Nest, Netatmo, Somfy, Tado).

Screenshot 2023-08-21 162441.jpg

Why? Because Resideo doesn't see retail customers as a target market for Evohome...

[bruce_miranda]

I'll stand united with the nerds.

[s.w.webb1]

Your comment around marketing is spot on. I wouldn't have gone evohome if it wasn't for someone recommending it & subsequently diving into it.

Looking at alternatives, I haven't seen anything surpass functionality/flexibility of evohome yet, despite its age.

I've seen a number of friends get a "smart heating" system installed, only to realise it's basically what they had before except just they can view the temperature remotely & switch on/off from an app, offering no more granular control..

Evocontrol is a very refreshing extension to the functionality & I'll certainly will be in line to cough up when the time comes.