Coffee Maker

[simbaja]

@alexanv1, I've started integrating the coffee maker support into the "dev" branch, please give it a shot and let me know what you think.

[alexanv1]

Wow, that was fast! Thanks! I've made a few fixes to get it to be somewhat functional: https://github.com/simbaja/ha_gehome/pull/63

Unfortunately, while it's functional, it ends up being clunky and borderline unusable (i.e. I don't think it will pass WAF :)) The problem is that setting either the temperature or changing the mode ends up turning the Coffee Maker on. Once it's on, changing the other value does not always have an effect since it seems that setting brew settings once the device is already brewing isn't really a supported scenario (not surprising since that functionality is not exposed in the app). Sometimes it works, sometimes it doesn't and I haven't been able to identify a real pattern here.

Ideally, the interface would be similar to the app where you can select the settings and then click a button to start brewing with those settings (and have another button for cancel). The new button entity that was introduced in HA 2112 gets us part of the way there I think.

The remaining challenge is exposing number\select entities (# of cups, strength, temperature) that don't actually impact the device state when they are modified. I think this can be handled by creating some new "virtual" entity types that don't directly map to an ERD. Instead, changing the values would call into the CoffeeMaker Appliance API which would just cache those values. Then, when a button is clicked, the Appliance API would construct the brew settings from cached values and set the ERD.

In other words, the entities exposed for the coffeemaker would be:

• ERD-backed sensors (# of cups, strength, current temperature, target temperature, is_brewing, etc)
• ERD-backed buttons (start brewing, cancel brewing, start descaling, cancel descaling)
• "virtual" number for selecting temperature
• "virtual" select for selecting brew strength
• "virtual" select for selecting # of cups

It would then be very simple to use conditional entity rows in Lovelace to only display those buttons that are applicable (e.g. only display Cancel Brewing when binary_sensor.is_brewing is True, etc). Granted it does involve a bit of manual effort to integrate into Lovelace but you can end up with an experience that very closely mimics what Smart HQ app provides.

The only caveat that I can see is that since the virtual entities aren't tied to an ERD, their initial values (on HA startup) would be static and they would only ever change as a result of user input. Also, whatever changes the user makes wouldn't persist across restarts. However, I think there may be a way to solve the persistence across restarts since HA saves the entity state and maybe that saved state can be used as initial state. Need to look into that aspect some more...

What do you think? I am more than happy to try and code this up and we can see what it looks like.

[simbaja]

Thanks for making those fixes :) One day I should make some unit tests to catch my coding errors :)

Yeah, I suspected that this might not be the best and something like what you describe is probably the next direction I would have gone down. With the button support of 2021.12, we can make it work (would have been a pain before, would have had to use service calls).

I might suggest that when these "virtual" entities are created, we can set the initial value for each of these would be based on the corresponding ERD values, that way we can at least set them to last used instead of resetting them when HA restarts. Perhaps it also makes sense to change them when the ERD value changes so that if you're operating from the machine itself, it's reflected in the HA UI? So, perhaps the "virtual" entities should be based on the ERD select/number, but override the set/state to enable this type of behavior?

I don't know how the buttons are called from a script, but we may also want to make some service calls as well to enhance automatability (have some timer related calls already that we can probably leverage as a guide).

[alexanv1]

I might suggest that when these "virtual" entities are created, we can set the initial value for each of these would be based on the corresponding ERD values, that way we can at least set them to last used instead of resetting them when HA restarts. Perhaps it also makes sense to change them when the ERD value changes so that if you're operating from the machine itself, it's reflected in the HA UI? So, perhaps the "virtual" entities should be based on the ERD select/number, but override the set/state to enable this type of behavior?

Yeah, at least hydrating the initial values from the actual device should definitely be straightforward. I will also experiment with dynamically updating when the ERD changes but there might be some caveats there with making sure not to override with values from the machine after they are explicitly changed in the UI but before they are "committed" by starting brewing.

[simbaja]

I will also experiment with dynamically updating when the ERD changes but there might be some caveats there with making sure not to override with values from the machine after they are explicitly changed in the UI but before they are "committed" by starting brewing.

Is there any way for those settings to change besides someone physically changing it on the device? If not, an on change approach should work (maintain last value and check new value if an update request comes in). If there is some way to change them outside of interacting with the device, probably just the initial hydration would be the best. Basically, I'm thinking you'd prioritize someone at the device over the remote user if possible.

[alexanv1]

Finally had time to implement this - PR is opened: #68

[kksligh]

I have a coffee maker and all that shows up in the entities is sabbath mode switch. I've installed the different Dev branches and don't see anything different...any ideas?

[alexanv1]

I have a coffee maker and all that shows up in the entities is sabbath mode switch. I've installed the different Dev branches and don't see anything different...any ideas?

Hmmm, that's interesting... What model is it? You can open an issue in the SDK repository (https://github.com/simbaja/gehome) and follow the websocket example there to collect the data that would be needed to support it properly.

[simbaja]

@kksligh, are you using HACS or manually installing from the "Dev" branch? I haven't created a pre-release yet that incorporates this functionality, but the "Dev" branch should have it. You'd just have to manually copy the files into the custom integration folder. That should also support the microwave as well.

[kksligh]

I'm struggling with knowing how to add the code manually. Where exactly to I get said code and how do I manually add into HA? Sorry if that's a trivial question

[kksligh]

@simbaja can you help with my challenge above?

[kksligh]

I think I've figured it out. I'll test this weekend and report back

[kksligh]

Following up here - the coffee maker works great! attached is a list of the functions and sensors that come through...