Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set Program #51

Open
kut opened this issue Dec 6, 2024 · 3 comments
Open

Set Program #51

kut opened this issue Dec 6, 2024 · 3 comments

Comments

@kut
Copy link

kut commented Dec 6, 2024

Hey @dlarrick - per your comment here (dlarrick/hass-kumo#142) I wanted to understand what it would take to start to view and edit the Program via pykumo and eventually HA.

I'd love to learn (or have you point me in the right direction) as to how to pull Program information, and just anything you've discovered by tinkering with the local API as it relates to the Program. Just a place for me to start!

Mentioning @jacobmovingfwd who was on the original issue too.

@dlarrick
Copy link
Owner

dlarrick commented Dec 7, 2024

See comment here describing how to get/set schedules from the indoor unit:
#7 (comment)

I would accept PRs implementing schedule maintenance calls in pykumo. If it were me I think a nice implementation would have 2 classes, something like:

  • ScheduleEvent, representing the settings for a single schedule independent of what slot it's in, i.e. holding the "active" "inUse" "day" "time" and "settings" fields as shown in the comment linked above. This class would implement getter/setter for the fields, validation, and conversion to/from the JSON needed by the indoor unit
  • UnitSchedule, representing the actual state of the schedule on an indoor unit. This class would implement actually fetching the state of the indoor unit into an array of ScheduleEvents and being able to get the list and/or individual slots; and manipulating that state on the indoor unit by adding a ScheduleEvent in a specific slot (or clearing it), and maybe fancier stuff like eliminating duplicates, sorting into a canonical order, etc.

A good place to start would be a low-level function simply accept a JSON dict and send it to a specific slot on the indoor unit. This could be used as a proof-of-concept, and as a building block for the fancier implementation.

pykumo was written for (and as far as I can tell, primarily used with) Home Assistant. I don't think the Climate entities there currently support management of a schedule like this. But if I'm wrong and such functionality is available, it would be wise to understand how that looks so that it would be easy to hook up.

@kut
Copy link
Author

kut commented Dec 7, 2024

Great thanks @dlarrick. I think something like that should work.

Do you think there's a way to combine such a schedule feature in pykumo with the new Schedule helper in HA which (as of a recent update) allows you to add data attributes to each schedule block? I've never made a HA integration so am not sure if it's possible for integrations to interact in that way, but I do know that I currently use the Schedule integration in that way to set the temperatures of my units. (I have a Schedule helper for each unit, and each schedule block also defines "is_active, "temperature_if_winter" and "temperature_if_summer")

Perhaps if there were a way to manage (and sync) a single Schedule entity for each Kumo Device in HA with the corresponding unit's schedule?

Note that (currently) this advanced usage of Schedule is YAML-only, but I have to believe that it'll have a UI equivalent soon given it's fairly new and give HA wants to move more to UI config in general.

@dlarrick
Copy link
Owner

dlarrick commented Dec 8, 2024

All that functionality would be on the HomeAssistant side of things, with pykumo ability to view & manipulate the schedules as a prerequisite. There are plenty of other thermostatic systems that can or do keep their own schedules internally (in my own house I have Ecobee that certainly does). So hopefully such sync would not be specific to hass-kumo or any other climate integration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants