Intermittently stuck in heat_8_15

[jhellstein]

Checklist

• [x] I have verified that the account and device works in the Comfort Cloud App.
• [x] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• [x] This issue is not a duplicate issue of currently previous issues..

What version of Home Assistant Core?

core-2025.1.3

Describe the issue

This might be related to the previous preset bug, but not entirely since the symptoms differ slightly.

The problem is that I can't exit the heat_8_15 preset after it's been active for some time (hours-days). If I try changing preset back immediately after enabling heat_8_15 it works, but every other day I discover that it's stuck in this mode. (I have an automation that switches preset between heat_8_15 and none-preset, as well as set temperature, since I'm on hourly energy rate)

Exiting the preset back to normal (none) isn't working neither through the climate card nor programatically through automations. In automations, I've tried both: - device_id: xxxx domain: climate entity_id: xxxx type: set_preset_mode preset_mode: none and - action: climate.set_preset_mode metadata: {} data: preset_mode: none target: device_id: xxxx

I've seen the following error thrown in the logs intermittently, "Error in get_status Expected status code '200' but received '500' Response body: {"code":5001,"message":"DB system error due to db system"}"

A workaround is to toggle the unit off-on, then the preset change works again. But I feel like that increases wear on the unit. Rebooting HA doesn't have any effect.

Error/Debug Logs

I don't know how related this is:
File "/usr/local/lib/python3.13/site-packages/aio_panasonic_comfort_cloud/panasonicsession.py", line 145, in execute_get
  File "/usr/local/lib/python3.13/site-packages/aio_panasonic_comfort_cloud/helpers.py", line 32, in check_response
aio_panasonic_comfort_cloud.exceptions.ResponseError: (get_status: Expected status code 200, received: 502: {"message": "Internal server error"}

2025-01-21 09:19:06.618 ERROR (MainThread) [aio_panasonic_comfort_cloud.helpers] Error in get_status
2025-01-21 09:19:06.619 WARNING (MainThread) [aio_panasonic_comfort_cloud.apiclient] Failed to get live status for device CS-HZ25ZKE+E098812651 switching to cached data.
2025-01-21 09:33:37.257 ERROR (MainThread) [aio_panasonic_comfort_cloud.helpers] Error in get_status
2025-01-21 09:33:37.257 WARNING (MainThread) [aio_panasonic_comfort_cloud.apiclient] Failed to get live status for device CS-HZ25ZKE+E098812651 switching to cached data.

[AnonymousRetard]

I'm experiencing the same issue here, running a bit older version of home assistant: 2024.11.1 and an older version of panasonic_cc: 2025.1.0. (Later versions of panasonic_cc don't seem to be compatible with this version of home assistant)

I think the issue started appearing after upgrading from homeassistant 2024.10.4 together with an even older version of panasonic_cc (because higher versions where again, not compatible).

Since I upgraded this issue has occured twice so far. I also have an automation that changes between preset modes "+8/15" and "none" and every now and then after switching from "+8/15" back to "none" it doesn't stick and reverts back to "+8/15" and doesn't accept the temperature I set in a later step which is above 15.

Automation then gives error: "Error: Provided temperature 18.0 is not valid. Accepted range is 8 to 15"

Using the climate card doesn't work either, it still reverts back to "+8/15", but other changes can still be made. So far I have solved it by opening the offical app and changing heating mode from there, and after that point I can control the heat pump normally from home assistant again.

[AnonymousRetard]

I have updated to a newer version of homeassistant and with this the latest version of panasonic_cc (2025.5.0) and I am still experiencing this issue.

I have tried to update my automation to turn the pump OFF if it's in preset mode +8/15 and then put it in heating mode in order to get it unstuck but it's not working.

Now i have started reading through the code a bit and I suspect that maybe the issue is triggered by calling "set preset mode" to "heat_8_15" more than once (while pump already is in this mode)?

Then it looks like _async_enter_summer_house_mode could be called while pump already is in this mode which then overwrites all the stored_data variables with values only valid for summer_house_mode, which means that next time exit_summer_house_mode is called it fails to leave this mode?

For now I have manually patched my code so it never uses the stored_data variables and after restarting homeassistant I was immediately able to leave preset mode +8/15, although that might not have been because of my change (perhaps restarting homeassistant by itself also clears the stored_data values?).

I will report back once I have tested this a bit more, but perhaps @sockless-coding who knows this codebase and how to build homeassistant integrations much better than me could chime in here already?

I don't really know if async_set_preset_mode gets called if an automation tries to change preset to the same one the pump already has, but if it does I think problems will happen. Because enter_summer_house mode has no guard to do nothing if we already are in summer_house_mode while exit_summer_house_mode does have this guard.

[AnonymousRetard]

I have now run with my patch for almost two weeks where the "stored_data" variables are not used at all anymore and this issue seems to be completely gone for me. So currently it looks like my theory holds. Probably these values (which are supposed to hold the settings from before we entered summer_house_mode) get overwritten with settings from summer_house_mode if preset mode is set to heat_8_15 while preset mode is already heat_8_15 and after this we can no longer exit summer_house_mode.

My current patch to not use "stored_data" works perfectly fine for me but it means that when I leave heat_8_15 mode the temperature, fan and eco settings go back to their defaults instead of their previous values which is not something I personally care about (my automation already control all of those things anyway).

Maybe when I have some more time I will try to improve my patch so it fixes the issue without this side-effect and once that is well tested I might make a proper pull request.

Another workaround that should work (but I have not yet tested) is that if there's an automation that sets preset to heat_8_15 this automation must have a condition to never set preset to heat_8_15 again if preset is already heat_8_15, because if it does that's probably the point were we get stuck in this mode.