Enabling disabled sensor attributes causes "Debouncer call ignored as shutdown has been requested" message

[jeffgregx2]

There are a number of highly useful attributes associated with sensors such as humidity and battery level. For example, here is one of my devices as shown by Developer Tools:

hvac_modes:
  - 'off'
  - cool
  - dry
  - heat
  - fan_only
  - heat_cool
min_temp: 45
max_temp: 95
fan_modes:
  - superQuiet
  - quiet
  - low
  - powerful
  - superPowerful
  - auto
swing_modes:
  - horizontal
  - midhorizontal
  - midpoint
  - midvertical
  - vertical
  - auto
  - swing
current_temperature: 74
temperature: null
target_temp_high: null
target_temp_low: null
current_humidity: 65.289062
fan_mode: auto
hvac_action: 'off'
swing_mode: auto
battery_level: 84
filter_dirty: false
defrost: false
rssi: -60
sensor_rssi: -39
runstate: normal
friendly_name: Loft Bedroom
supported_features: 43

For example if I enable the battery attribute to be a new entity the new entity shows up correctly including value. However all of the hass-kumo Climate devices transition to an Unknown state and Developer Tools shows no attribute values any longer.

hvac_modes:
  - 'off'
  - cool
  - dry
  - heat
  - fan_only
  - heat_cool
min_temp: 45
max_temp: 95
fan_modes:
  - superQuiet
  - quiet
  - low
  - powerful
  - superPowerful
  - auto
swing_modes:
  - horizontal
  - midhorizontal
  - midpoint
  - midvertical
  - vertical
  - auto
  - swing
current_temperature: null
temperature: null
target_temp_high: null
target_temp_low: null
fan_mode: null
swing_mode: null
friendly_name: Loft Bedroom
supported_features: 43

Because the climate device is now Unknown there is no longer a convenient way to control the device. It may possible to use services to control them - not sure if that works at this point.

This is reproduced on HA V2023.8.2 using hass-kumo V0.3.7

Prior to enabling attribute:

After enabling attribute:

[dlarrick]

Hmm that's odd. This is working fine for me. You may be hitting the dreaded issues discussed in #105 . If you power-cycle your Kumo system (at the breaker is easiest; or unplug/re-plug the WiFi unit which is probably inadvisable), do things start working properly again?

[jeffgregx2]

So I tested it as follows:

1. Power cycled via breaker the split mini
2. Deleted the integration so I could start from scratch
3. Added a new Kumo integration verifying everything is shown correctly
4. Enabled the battery/humidity sensors for 1 zone
5. Waiting the 30 seconds for update and subsequent loss of all climate data (i.e., goes into Unknown state and developer->states show no associated data)
6. Power cycled via the breaker the split mini
7. Waited a few minutes to see if the data show up - no
8. Manually reloaded the Kumo integration to see if that fixed it - no
9. Deleted the integration and re-added it - verified everything is shown correctly
10. Used the integration to turn a zone on to verify local control is working

It's odd that I am the only one encountering this since I am able to reproduce it 100% of the time. I don't know if my environment is unique in some way. This is HASS OS based if that matters.

BTW - I am definitely hitting bug #105 - my zones do go offline, very annoying. Most of the time they come back on-line after a while (I assume they reboot). Occasionally they do not and I have to power cycle them. However for this testing I am pretty sure they are all on-line. The Kumo app on my phone connects to the zone immediately (I.e., no slash across the zone). If there are additional debug steps I am happy to take them.

Note that this is a vacation home so if I do debugging remotely I can't power cycle - at the mercy of the wifi module coming back up. That might make debugging take quite a while :-(

[dlarrick]

Anything different in the logs before/after enabling the additional sensors?

[jeffgregx2]

The normal logs don't have anything of note. I did the following test:

1. enable debug logging
2. Enabled one of the battery attributes
3. waited until the climate object became unknown
4. disabled debug logging - attached as home-assistant_kumo_2023-08-19T13-52-23.630Z-attr-enabled.log

Clearly this log shows there are #105 type issues happening. However I find it odd that by default it can use the cached state and does re-connect/load values over time. When I enable the attribute for some reason both the cached state and re-connect/load values doesn't seem to work.

I wanted to see if cycling the plugin would help so then did the following:

1. enabled debug logging
2. disabled the plugin
3. power cycled the mini-split system using the breaker
4. enabled the plugin
5. waited to see if the climate became known
6. disabled debug logging - attached as home-assistant_kumo_2023-08-19T14-00-11.439Z-restart.log

This log doesn't appear to say much. Please note that from the time I disabled the plugin went to the breaker panel flipped the breaker (counted to 10 and turned it back on) and then made it to my computer waited for the split unit to finish cycling it's fins then turned the plugin back on. The debounce messages are odd because a number of minutes had elapsed.

If there is anything else I can do to debug today I am totally wiling to try.

Thanks for your help! I really appreciate it.

[dlarrick]

I have seen those debouncer messages and couldn't figure out how to fix it. But they go away if you restart HA. Maybe that's your whole issue? If so we should leave this ticket open and I (or someone) can try harder to find it.

The only other thing I see in here is that your indoor units are pretty unhappy with the WiFi signal. When it's working, what's the WiFi RSSI value? My 3 units are -39, -48, and -46 respectively (higher values -- negative numbers closer to 0 -- are better). I've found reorienting the PAC module inside the indoor unit can affect this value.

[jeffgregx2]

Brilliant. I rebooted the HASS OS (be thorough) and sure enough everything came back on-line. Fortunately you only need to do that once. This implies there is some left over state conflicted on attribute add... hmmm.

As for WiFi - I definitely get what you're talking about. The thing is the Master Bedroom WiFi unit sits about 10 feet from an Ubiquiti Access Point. A computer in the same room can sustain video conferencing, etc. with zero issues. However to see if it will help, I flipped the WiFi module over and that reduced the rssi to -43. The loft WiFi will probably never be awesome because it's as far away as you can get - the solution for that is more involved (moving the access point to a more central location in a house that running wires is super difficult).

That said, I do have pretty reliable WiFi including the use of a site survey to map out the dead spots. All of my equipment is small business (Ubiquiti Unifi), VLAN, proxmox, etc.

[stormhagen]

FWIW I had the exact same problem on my installation. Debouncer errors even after restart of Mitsubishi units. A restart of Home Assistant also fixed it.