homekit_controller: Add support for ecobee vendor extensions for presets

[InstigatorX]

Home Assistant release with the issue: 103.4

Last working Home Assistant release (if known): n/a

Operating environment (Hass.io/Docker/Windows/etc.): hass.io

Integration: homekit controller

Description of problem: set_preset_mode doesn't work (enabled) for Homekit Thermostats (Ecobee).

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant): homekit_controller/climate.py doesn't contain necessary options. Sorry not a developer, but can tell it doesn't have same options as the Ecobee climate.py

Additional information:

[probot-home-assistant[bot]]

Hey there @Jc2k, mind taking a look at this issue as its been labeled with a integration (homekit_controller) you are listed as a codeowner for? Thanks!

[Jc2k]

The homekit protocol doesn’t support presets afaik, so no way to do this. Or are you able to set presets through the official iOS home app on an iPhone or iPad?

[InstigatorX]

The homekit protocol doesn’t support presets afaik, so no way to do this. Or are you able to set presets through the official iOS home app on an iPhone or iPad?

I haven't tried as I would have to re-pair Homekit with Home app. However, the Ecobee support page implies this is possible. See https://support.ecobee.com/hc/en-us/articles/115004905767-ecobee-and-HomeKit-Set-up-Scenes-and-Troubleshooting

---

HomeKit scenes are a way to adjust your thermostat and other HomeKit accessories using a voice command. For example, telling Siri “I’m leaving” will set your thermostat to your Away Comfort setting.

You can set up any number of HomeKit enabled devices to work together and respond to a single command. For example, with your "Goodnight" scene, your ecobee thermostat can run your Sleep comfort setting and your Switch+ can turn off the lights. Now there's even less things to do before bed time!

Automations are the ways that your smart device control itself. For example, switching to your Away Comfort setting once you leave your location or geofence. Automations allow your thermostat to be even smarter as they are able to trigger actions without a voice command. Basically, they allow you to control your home in a way where you don't even have to think about doing anything!

If you have iOS9+, ecobee will have the following default scenes:

"Good morning" sets your thermostat to your Home comfort setting. "Good night" sets your thermostat to your Sleep comfort setting. "I’m home" sets your thermostat to your Home comfort setting. "I’m leaving" sets your thermostat to your Away comfort setting. "Resume schedule" resumes the programmed schedule if the thermostat was placed on hold or was in vacation mode. "

---

[Jc2k]

The scenes clue isn’t very helpful here unfortunately - scenes aren’t part of the protocol between an accessory and the controller it’s a concept that only exists within iOS.

What is probably happening here is that you would use a 3rd party ecobee app to setup the scenes, and they probably target unofficial and undocumented vendor specific “characteristics” (the name for a value on the accessory that we read or write) on the accessory.

We don’t currently have the ability to use unofficial characteristics. The underlying library doesn’t really have a way for us to do it, and we’ve avoided it because of the complexity of implementing n different and incompatible manufacturer specific characteristics. Even if we did we would need a developer with an Ecobee to reverse engineer the characteristic that’s involved here.

I’m the only homekit_controller contributor at the moment and so unfortunately we only have the man power (and barely) to support characteristics in the official public spec.

Sorry it’s not better news.

[InstigatorX]

Scenes are setup in ecobee app or on their portal. Nothing 3rd party. I would’ve thought since HA is essentially emulating the Home app it could make the same call.

On that note, it’s too bad there’s only one contributor given HK support could make HA more pervasive...IMO.

[Jc2k]

It is too bad IMO too :-) The HAP protocol is much nicer than relying on the cloud to control stuff on your own network. But I can't control what people volunteer their free time to work on :-(

You misunderstand what I mean by 3rd party. If you can't do it directly through the Home app on an iPhone (Apples official app, not ecobees) then its "3rd party" and potentially using vendor specific extensions.

RE: "the portal" - do you mean their website? - I don't have any ecobee hardware to play with.

Their manufacturer app is probably indeed using the homekit HAP protocol, so then its just a question of whether the "set preset mode" characteristic is official and documented or not. Note that setting up a scene with the ecobee app and then triggering it via the Home app doesn't count - you need to be able to trigger it directly in the Home app without a scene for it to be something we can emulate.

I'm sat in front of the spec now for a different climate ticket and V2 of the spec is 259 pages so it's indeed possible i've missed something, but there are no matches for "preset" and the climate service does not list anything that looks remotely preset-y.

[InstigatorX]

Can you send/link me the spec? I’d be interested it perusing it.

On Dec 29, 2019, at 12:51 PM, Jc2k notifications@github.com wrote:

 It is too bad IMO too :-) The HAP protocol is much nicer than relying on the cloud to control stuff on your own network. But I can't control what people volunteer their free time to work on :-(

You misunderstand what I mean by 3rd party. If you can't do it directly through the Home app on an iPhone (Apples official app, not ecobees) then its "3rd party" and potentially using vendor specific extensions.

RE: "the portal" - do you mean their website? - I don't have any ecobee hardware to play with.

Their manufacturer app is probably indeed using the homekit HAP protocol, so then its just a question of whether the "set preset mode" characteristic is official and documented or not. Note that setting up a scene with the ecobee app and then triggering it via the Home app doesn't count - you need to be able to trigger it directly in the Home app without a scene for it to be something we can emulate.

I'm sat in front of the spec now for a different climate ticket and V2 of the spec is 259 pages so it's indeed possible i've missed something, but there are no matches for "preset" and the climate service does not list anything that looks remotely preset-y.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Jc2k]

https://developer.apple.com/homekit/specification/

[alistairg]

Interesting. They're creating custom HomeKit scenes using their native app which must be doing one of two things:

• Setting the temperature (a supported attribute) to something "special" (e.g. -1, -2, -99) OR
• Setting a custom characteristic to a specific value as part of a scene

Given that custom characteristics don't properly sync through iCloud, I'm guessing they're doing the former. The easiest way to tell will be to create a scene using their app, then run some custom swift code to output the characteristic values of the scenes.

I'm happy to take a quick look when I get home to see if I can discern which of the two approaches they're taking...

[alistairg]

So, Ecobee are using custom characteristics for this, and @Jc2k is correct - this is not imminently do-able using Home Assistant. For future reference, however:

Resume schedule: FA128DE6-9D7D-49A4-B6D8-4E4E234DEE38 to 1 Home Mode: 1B300BC2-CFFC-47FF-89F9-BD6CCF5F2853 to 0 Sleep Mode: 1B300BC2-CFFC-47FF-89F9-BD6CCF5F2853 to 1 Away Mode: 1B300BC2-CFFC-47FF-89F9-BD6CCF5F2853 to 2

[Jc2k]

Cheers @alistairg, this is very useful!

If you wrote an app to do this is it something you can share?

We could do with mapping out those characteristics (and heating-cooling.target and heating-cooling.current) and the interactions between them. E.g. if you write to any one of these characteristics, do the values of the other characteristics change?

I'm especially curious about:

• If you write 1 to AD803092-80E4-592D-9450-11106BB791CC and then 1 to heating-cooling.target, does the custom characteristic change back to 0? If thats the case then maybe this characteristic represents manual vs automatic and it would map to HVAC_MODE_AUTO?
• What happens to 42BF6B30-28E3-560B-82E7-31AD1AE66621 if you change the AD803 characteristic to 1 and to 0, and what happens to it if you step through all possible values of heating-cooling.target? Does it stay in its current state? In which case this characteristic on its own could be used to set preset_modes and preset_mode

This doesn't change that the code can't handle custom characteristics that aren't defined in homekit_python, of course. Will have to talk to upstream.

[alistairg]

Slight 'oops' with my code - corrected the UUIDs above. Also, @jc2k, I think I have a "cunning plan". Hacking some rough code together in a separate branch, will update this with my progress...

[alistairg]

OK. So, more progress.

1. These characteristics are "write only". They report null when you initially read them, and (obviously) don't change when Ecobee updates values.
2. I've hacked some, fairly gross, code together that:
   • Exposes unknown custom characteristics as attributes on Homekit Controller entities
   • Provides a service that takes entitity_id, characteristic_id, and value that writes the custom characteristic value to Homekit

In my initial testing I can do what we'd expect - "resume" program mode (Writing true to FA12.. using my service) and flip between Home, Sleep, Away modes by writing 0, 1, and 2 respectively using my service, e.g.:

call service homekit_controller.set_custom_characteristic with payload:

entity_id: "climate.main_floor"
char_name: "1B300BC2-CFFC-47FF-89F9-BD6CCF5F2853"
char_value: 2

I'll push my code to the branch "homekit-custom-chars" on my fork https://github.com/alistairg/home-assistant.

I'm not in love with the fact that people will need to know what custom characteristics are, but maybe we could hide this behind an "advanced" option? Start a UUID registry for 'known' variants?...

I do like the fact, however, that we could use attributes as parameters for templates - for example, the Ecobee exposes another one, 1B1515F2_CC45_409F_991F_C480987F92C3 which provides service messages:

Time To Have Your Heating AC System Serviced, it was last inspected on Apr 1, 2019

[Jc2k]

I think something like that could be a last resort. Would definitely want it all to be behind a config entry option.

Would much prefer to be able to do this "right", though, as its better than each user having to implement a bunch of services and awkward templates themselves.

I've been slowly refactoring in the background and recently added a helper for reading a characteristic that uses the UUID rather than the char name (see here) , this was mostly so that flake/pylint would spot typos but it should mean eventually let us use custom characteristics in HA as well.

I'm thinking something like supporting subclassing the homekit entities, maybe something like:

ECOBEE_PRESETS_TO_HK = {
    "home": 0,
    "sleep": 1,
    "away": 2,
}

ECOBEE_PRESETS_FROM_HK = {value: key for (key, value) in ECOBEE_PRESETS_TO_HK.items()}

class EcobeeTypes:
    PRESET_MODE = "1B300BC2-CFFC-47FF-89F9-BD6CCF5F2853"
    DISPLAY_TEXT = "1B1515F2_CC45_409F_991F_C480987F92C3"

class EcobeeClimate(HomeKitClimateDevice):

    def get_characteristic_types(self):
        return super().get_characteristic_types() + [EcobeeTypes.PRESET_MODE]

    def preset_modes(self):
        return ECOBEE_PRESETS_TO_HK.keys()

    @property
    def preset_mode(self):
        return ECOBEE_PRESETS_FROM_HK.get(self.get_hk_char_value(EcobeeTypes.PRESET_MODE))

    def async_set_preset_mode(self, value):
        .. snip ..

The bit i'm not sure on is how async_add_service will change. I'm thinking of either using a homeassistant.util.decorator.Registry to map these overrides to UUID's - maybe like this:

@OVERRIDES.register(EcobeeTypes.PRESET_MODE)
class EcobeeClimate(HomeKitClimateDevice):
     pass

Or using a @classmethod sniffer maybe:

class HomeKitEntity(...):

    @classmethod
    def is_override_for(class, service):
        for char in service["characteristics"]:
            if Characteristics.get_type(char["type"]):
                # built-in char is boring
                continue
            if char["type"] not in class.get_override_characteristic_types():
                continue
            return True
        return False

class EcobeeClimate(HomeKitClimateDevice):

    @classmethod
    def get_override_characteristic_types(self):
        return [EcobeeTypes.PRESET_MODE]

In this case EcobeeClimate wouldn't override get_characteristic_types itself any more. The 2nd approach is more DRY, but i got flagged in review last time i made these classmethods.

With both of these we'd change async_add_service to try and find a matching override, and then fall back to the default HA type.

What i'd really like to know is if there is a way to tell if the Ecobee is following a schedule or not.

[alistairg]

Won't the icky part come when you need to define a manufacturer/model set of overrides to determine which [sub]class to instantiate?

I'll poke around at the read / event characteristics and see if there's any pattern to them. You'd think that Ecobee would have made them "read/write" so that homekit users could see the scenes "activating", but they must just be relying on Apple's HomeKit cache.

[Jc2k]

Did i miss something with picking which subclass to instantiate? We should be able to key it off characteristic UUID's - so if we spot 1B300BC2-CFFC-47FF-89F9-BD6CCF5F2853 load the Ecobee driver. If they reuse UUID's between models and change the behaviour we might be out of luck I guess. At that point we might have to rely on other grim heuristics but i'll worry about it when it happens I guess.

Cheers it would be a big help if you could poke around the r/o characteristics. The ones i know of are:

B7DDB9A3-54BB-4572-91D2-F1F5B0510F8C - r/o, uint8 - an enum? range unknown
E4489BBC-5227-4569-93E5-B345E3E5508F - r/w, temperature between 7.2 and 26.1
7D381BAA-20F9-40E5-9BE9-AEB92D4BECEF - r/w, temperature between 18.3 and 33.3
73AAB542-892A-4439-879A-D2A883724B69 - r/w, temperature between 7.2 and 26.1
5DA985F0-898A-4850-B987-B76C6C78D670 - r/w, temperature between 18.3 and 33.3
05B97374-6DC0-439B-A0FA-CA33F612D425 - r/w, temp between 7.2 and 26.1
A251F6E7-AC46-4190-9C5D-3D06277BDF9F - r/w, temp between 18.3 and 33.3
1B300BC2-CFFC-47FF-89F9-BD6CCF5F2853 - w/o, uint8 between 0 and 3 - home/away/sleep
1621F556-1367-443C-AF19-82AF018E99DE - r/w, a string. in the sample i have its a time stamp from 2014.
FA128DE6-9D7D-49A4-B6D8-4E4E234DEE38 - w/o, bool - resume schedule
4A6AE4F6-036C-495D-87CC-B3702B437741 - r/o, uint8, range unknown
DB7BF261-7042-4194-8BD1-3AA22830AEDD - r/o, uint8, range unknown
41935E3E-B54D-42E9-B8B9-D33C6319F0AF - r/o, bool
C35DA3C0-E004-40E3-B153-46655CDD9214 - r/w percentage
48F62AEC-4171-4B4A-8F0E-1EEB6708B3FB - r/o uint8, observed a value of 100 - so maybe percentage?
1B1515F2-CC45-409F-991F-C480987F92C3 - r/o text status from device

Does that match what you can see?

I wonder if the 3 pairs of temperature characteristic are the upper and lower thresholds for away, home and sleep mode?

41935E3E-B54D-42E9-B8B9-D33C6319F0AF is interesting because its the only readable bool and resume schedule is a writeable bool. Sure they won't make it that easy though!

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[InstigatorX]

👎

[stcbus]

Hey all - just adding another note of interest to this for my ecobee. It would be nice to go back to using preset modes instead of hard setting temps. Could this work on the characteristics maybe also allow controlling the fan with the native homekit controller pairing?

[Jc2k]

Can you use scenes to define presets on the HA side? From what I’ve seen the HK preset implementation will be a bit crap even if we get it to work (not clear we can read the state back out so the UI HA has for presets wouldn’t work).

RE fan, If you can determine the characteristic uuid and the values it takes we may be able to do something. But I’m not confident they have exposed it.

[stcbus]

@Jc2k Forgive me, but I am new to all of this - how would I go about determining or searching for those characteristics?

[Jc2k]

We are talking about reverse engineering here so it won’t be easy. But there are 2 approaches.

We talked above about writing iOS code to inspect them. In other words, writing your own app using the iOS HomeKit API. This is not something I could help with. This has the advantage that you can perform an action in iOS and observe the state of the readable characteristics.

The other is to use a standalone client (like homekit_python). It has a command line utility to read all the readable characteristics, even if it doesn’t understand them. With that you can make a change in the official app (not the homekit app) and then see if any of the characteristics changed state in the command line app.

You can also poke values into the characteristics and see if anything happens. This is mildly risky as you have no idea what the action is you are triggering.

[stcbus]

@Jc2k Ok, so the fan appears to be controlled by 1.52, but 1.53 seems to mirror the status?:

  1.52: () >Unknown Characteristic C35DA3C0-E004-40E3-B153-46655CDD9214< [pr,pw,ev]
    Value: 100
  1.53: () >Unknown Characteristic 48F62AEC-4171-4B4A-8F0E-1EEB6708B3FB< [pr,ev]
    Value: 100

Setting 1.52 to "100" activates the fan and 0 turns it off/auto.

python3 -m homekit.put_characteristic -f pairing.json -a ecobee -c 1.52 100

[Jc2k]

And what about values in between? It seems like it’s going to be a speed percentage, where 100 is fully on. Would be good to confirm if there are actually different speeds.

[Jc2k]

Also wonder if 1.52 is the "target" state, and 1.53 is the actual state. Like if the ecobee switches the fan on by itself in auto mode, maybe that would be relected by 0 in 1.52 and 100 in 1.53. If the fan is on auto what makes the ecobee switch it on? Could you make that happen to test the theory?

[stcbus]

There may be speeds for different devices? But I'm hesitant to try here especially since the Ecobee itself only gives me auto/on as options.

Like if the ecobee switches the fan on by itself in auto mode, maybe that would be relected by 0 in 1.52 and 100 in 1.53.

Looks like you're right - this morning my fan was on (due to a setting I have that keeps the fan on at least 5 min/hour. i.e., the fan is still kept in auto.)

1.52 was "0" and 1.53 was "100".

[ntoto]

I just checked the other characteristics on an Ecobee 3 Lite and here is what I have:

B7DDB9A3-54BB-4572-91D2-F1F5B0510F8C - r/o, uint8 - current mode - home(0)/sleep(1)/away(2)/temp(3)
E4489BBC-5227-4569-93E5-B345E3E5508F - r/w, float - home heat temperature between 7.2 and 26.1
7D381BAA-20F9-40E5-9BE9-AEB92D4BECEF - r/w, float - home cool temperature between 18.3 and 33.3
73AAB542-892A-4439-879A-D2A883724B69 - r/w, float - sleep heat temperature between 7.2 and 26.1
5DA985F0-898A-4850-B987-B76C6C78D670 - r/w, float - sleep cool temperature between 18.3 and 33.3
05B97374-6DC0-439B-A0FA-CA33F612D425 - r/w, float - away heat temp between 7.2 and 26.1
A251F6E7-AC46-4190-9C5D-3D06277BDF9F - r/w, float - away cool temp between 18.3 and 33.3
1B300BC2-CFFC-47FF-89F9-BD6CCF5F2853 - w/o, uint8 - set hold schedule mode - home(0)/sleep(1)/away(2)
1621F556-1367-443C-AF19-82AF018E99DE - r/w, string - 2014-01-03T00:00:00-07:00T
FA128DE6-9D7D-49A4-B6D8-4E4E234DEE38 - w/o, bool - true to clear hold mode, false does nothing

Unfortunately there seems to be a bug with the homekit code in Ecobee. When using the characteristic 1B300BC2-CFFC-47FF-89F9-BD6CCF5F2853 to set the "Home/Sleep/Away and hold" mode the value in B7DDB9A3-54BB-4572-91D2-F1F5B0510F8C is not updated accordingly. You can see the hold mode active in the Ecobee UI though. The same thing is true when changing the target temperature (temp hold) through homekit. When changing the mode or temperature through the Ecobee UI the characteristic value is properly updated.

Also, as far as I can tell, there is no way to know if the Ecobee is in a regular schedule mode or in hold schedule mode.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[raccettura]

Still valid. Go away stale bot ;)

[bagobones]

Just flipped over to ecobee from a nest.. I was going to integrate via the API integration, but it seems that local control and faster updates of the occupancy sensors makes homekit a no brainer.

I hope work is still continuing on this path. Forcing away mode (2hrs is longer than nests 30-45min) would be very nice to have.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[bagobones]

stale bot go away come again some other day.

[juched78]

Having the service exposed to homekit_controller.set_custom_characteristic would be useful in the generic sense right? This way people could use it to set custom values in advanced mode... ie. to resume a program.

Could this part be merged from @alistairg branch until a fully generic method is available? Or does it break some rules?

[Jc2k]

The code appears simple but ultimately the support for a feature like that isn't. There's no such thing as "until", once it's in it's in. And while it's just me as maintainer, these 2 things together are just not appealing. Sorry.

[juched78]

Ok, I fully understand.

I am trying to make a quick python snippet using aiohomekit directly. I get the same error "Accessory received an invalid value in a write request".

asyncio.run(main(["put", "-f", "pairing.json", "-a", "LivingRoom", "-c", "1.48", "true"]))

Trying to simply try to resume. I can confirm 1.48 is the resume ID.

[Jc2k]

Some of these devices are really badly made and won't accept "true" but will accept "1". But I think aiohomekit should be making that translation for you automatically.

You could turn on debug logging and see if it is actually writing to the device?

[juched78]

Seems when you pass a "1" string it tries to pass a string and gives invalid value. If you pass in an int it fails in the argparse function since it cannot handle non-strings.

I think I am commenting in the wrong place, but was hoping to make it work with aiohomekit. I can use the command line via "homekit" but that doesn't come pre-installed with home assistant.

These all work: bash-5.0# python -m homekit.put_characteristic -f pairing.json -a LivingRoom -c 1.40 1 bash-5.0# python -m homekit.put_characteristic -f pairing.json -a LivingRoom -c 1.40 2 bash-5.0# python -m homekit.put_characteristic -f pairing.json -a LivingRoom -c 1.48 1

Any way to pass an integer into the main class cli for aiohomekit?

[Jc2k]

No idea. Aiohomekit only exists for HA, I don't really care about anything else. So CLI might well be broken for your use case. File a bug there so we aren't spamming everyone here.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[andrew-d]

Still not stale :smile: I'm going to be installing an ecobee 4 shortly, and would be happy to help out/debug at that point.

[kreene1987]

Just to confirm, this is why I don't have any preset_modes, fan_modes, or fan only status (shows idle) when comparing HomeKit vs Ecobee API integrations?

[Jc2k]

A HomeKit Thermostat profile looks like this:

This is from the offical spec. Nothing else is supported out of the box.

HomeKit does support custom characteristics, but these only work with the vendors app (not the homekit app), and they are completely undocumented. Not all vendors bother, and when they do they are often a bit crap. (Eve are the big exception here. Theirs are undocumented but well thought out and not buggy).

All we know about the Ecobee ones so far is listed here:

https://github.com/home-assistant/core/issues/30258#issuecomment-647160757

As you can see it doesn't really cover fan stuff at all. And while it gives some control over Home/Sleep/Away/Temp, its completely broken (we can't make a change and see that we made a change, it still shows the old change).

I would take a PR that added number entities for the 6 temperature values (see https://github.com/home-assistant/core/blob/dev/homeassistant/components/homekit_controller/number.py#L14) but that's realistically the best we are going to get. And we haven't really had anyone test those fully, they could be buggy too.

[Tuckie]

Just out of curiosity, has anyone messed with additional comfort settings to see how they are exposed via HomeKit? I've created a few others beyond Home/Away/Sleep.

[Jc2k]

There is no guarantee they even are exposed to homekit. Generally if it's not in the spec I posted it's not supported. Vendor extensions are rare and rarely implement the spec enough to do anything useful with.

We do know that home/sleep/away is quite broken as it's not designed to be used like we want to use it.

If they are supported and built on top of the existing ones we know about it's unlikely we can e.g. determine their names so it's going to be next to impossible to do anything useful with.

[Tuckie]

it's going to be next to impossible to do anything useful with.

Dang, that's too bad. I just switched over to homekit control and now I'm tempted to go back to the cloud-based integration. I know it will never happen, but man a alternative local interface for ecobee would be awesome.

[josephnad]

I am coming from SmartThings, and have many automations that depend on resuming program in ecobee, changing fan mode (on/auto). I would like to migrate to HomeAssistant and use HomeKit because it is local.

Is there a way to send these vendor extensions? What are my options to do this? Is forking the code the only way? Or could I for instance do this using python code?

[Jc2k]

Your options are very very limited. Vendor extensions do not support all features of your device. Vendor extensions (where they exist at all) are typically incomplete and of poor quality. For example, changing fan mode is not possible with them, either in Home Assistant or if you wrote a python script.

I do not have an Ecobee so i'm not familiar with its terminology so can't say for certain about "resuming program". Now that we have the button type it looks like we could conceivably add a button for what i believe is "Release Temperature Hold" or "Clear Hold Mode", if thats the same thing. The button platform is new, previously there was no entity that was usable for that endpoint.

https://github.com/home-assistant/core/issues/30258#issuecomment-647160757 documents the known extensions.

If you think "Clear Hold Mode" is what you need, take a look at this PR: https://github.com/home-assistant/core/pull/59750/files

It adds all the framework needed to support a Clear Hold Mode button. There is a bit like this:

BUTTON_ENTITIES: dict[str, HomeKitButtonEntityDescription] = {
    CharacteristicsTypes.Vendor.HAA_SETUP: HomeKitButtonEntityDescription(
        key=CharacteristicsTypes.Vendor.HAA_SETUP,
        name="Setup",
        icon="mdi:cog",
        entity_category=ENTITY_CATEGORY_CONFIG,
        write_value="#HAA@trcmd",
    ),
    CharacteristicsTypes.Vendor.HAA_UPDATE: HomeKitButtonEntityDescription(
        key=CharacteristicsTypes.Vendor.HAA_UPDATE,
        name="Update",
        icon="mdi:update",
        entity_category=ENTITY_CATEGORY_CONFIG,
        write_value="#HAA@trcmd",
    ),
}

You just need to add one of these entries for FA128DE6-9D7D-49A4-B6D8-4E4E234DEE38. write_value would be True. And add a constant for it in aiohomekit (like this https://github.com/Jc2k/aiohomekit/pull/48/files).

If someone is able to test this and submit a PR I would review it straight away.

But like i say, if its not in the list I linked to there is nothing you can do.

[josephnad]

Ecobee API has Resume Program function that restores the thermostat back to the scheduled program. It is probably the same as "Clear Hold Mode". Whenever the temperature or fan mode is overriden, it sets a hold with an end time (e.g. 2 hours, until next schedule, or indefinite). Setting temperature through homekit controller is an indefinite hold, so the thermostat will never switch to sleep or home preset based on schedule. So we need a way to cancel the hold so that the schedule/program resumes.

I will look into the PR you mentioned and try to test it out.

[stcbus]

I had mentioned before in my comment https://github.com/home-assistant/core/issues/30258#issuecomment-623767208 the characteristic that controls the fan. It would be nice to have that added as well.

On Wed, Dec 1, 2021 at 9:38 AM Jc2k @.***> wrote:

Your options are very very limited. Vendor extensions do not support all features of your device. Vendor extensions (where they exist at all) are typically incomplete and of poor quality. For example, changing fan mode is not possible with them, either in Home Assistant or if you wrote a python script.

I do not have an Ecobee so i'm not familiar with its terminology so can't say for certain about "resuming program". Now that we have the button type it looks like we could conceivably add a button for what i believe is "Release Temperature Hold" or "Clear Hold Mode", if thats the same thing. The button platform is new, previously there was no entity that was usable for that endpoint.

30258 (comment)

https://github.com/home-assistant/core/issues/30258#issuecomment-647160757 documents the known extensions.

If you think "Clear Hold Mode" is what you need, take a look at this PR: https://github.com/home-assistant/core/pull/59750/files

It adds all the framework needed to support a Clear Hold Mode button. There is a bit like this:

BUTTON_ENTITIES: dict[str, HomeKitButtonEntityDescription] = { CharacteristicsTypes.Vendor.HAA_SETUP: HomeKitButtonEntityDescription( key=CharacteristicsTypes.Vendor.HAA_SETUP, name="Setup", icon="mdi:cog", entity_category=ENTITY_CATEGORY_CONFIG, @.", ), CharacteristicsTypes.Vendor.HAA_UPDATE: HomeKitButtonEntityDescription( key=CharacteristicsTypes.Vendor.HAA_UPDATE, name="Update", icon="mdi:update", entity_category=ENTITY_CATEGORY_CONFIG, @.", ), }

You just need to add one of these entries for FA128DE6-9D7D-49A4-B6D8-4E4E234DEE38. And add a constant for it in aiohomekit (like this https://github.com/Jc2k/aiohomekit/pull/48/files).

But like i say, if its not in the list I linked to there is nothing you can do.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/30258#issuecomment-983704324, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5AKKQ63TAIDYIFHMH2EJLUOYXMVANCNFSM4KAO6GQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[Jc2k]

Ah, if its not in https://github.com/home-assistant/core/issues/30258#issuecomment-647160757 its dead to me.

Can you confirm that C35DA3C0-E004-40E3-B153-46655CDD9214 is indeed read and write? And that the read value is accurate. Specificaly, if you write to it, does it get updated when you read it. And if you change it on the Ecobee, does it get updated there.

(I ask that because this device has form for not always showing the latest value in the homekit API).

Since you posted that comment we've gotten the new number type in Home Assistant which makes it super easy to support those too: https://github.com/home-assistant/core/blob/dev/homeassistant/components/homekit_controller/number.py. As with button, you just need to update a mapping:

NUMBER_ENTITIES: dict[str, NumberEntityDescription] = {
    CharacteristicsTypes.Vendor.VOCOLINC_HUMIDIFIER_SPRAY_LEVEL: NumberEntityDescription(
        key=CharacteristicsTypes.Vendor.VOCOLINC_HUMIDIFIER_SPRAY_LEVEL,
        name="Spray Quantity",
        icon="mdi:water",
    ),
    CharacteristicsTypes.Vendor.EVE_DEGREE_ELEVATION: NumberEntityDescription(
        key=CharacteristicsTypes.Vendor.EVE_DEGREE_ELEVATION,
        name="Elevation",
        icon="mdi:elevation-rise",
    ),
}

in this file. You can see an example PR here.