[v1.80] Heat pump intermittently showing as "unavailable" after latest update

[Mirodrag]

Hello, since updating to 1.80, the heat pump regularly shows up as 'unavailable'. This didn't happen prior to the update. I've already tried reconfiguring the integration and re-linking my account. Interestingly, the connection seems to recover on its own intermittently, as the sensors temporarily become available again. Thank you very much for help!

[frytaman]

remove your device and add it again. Had the same issue.

[hannuterasloihde]

Im seeing the same issue. Deleting the device and re-adding it didn't help for me.
Logs just show timeouts:
Logger: custom_components.myuplink
Source: helpers/update_coordinator.py:439
Integration: myUplink (documentation, issues)
First occurred: 13:45:35 (6 occurrences)
Last logged: 14:57:17

Timeout fetching myUplink data

I downgraded to 1.7.3, which is working fine

[Ounakas]

After the update the integration repeatedly disconnects. All my Nibe entities become unavailable at the same time, then recover automatically later. Looking at the history, the connection stays up for about 5-6 minutes, then remains unavailable for about 15-17 minutes before reconnecting again. This cycle repeats continuously.

[maheibert]

After the update the integration repeatedly disconnects. All my Nibe entities become unavailable at the same time, then recover automatically later. Looking at the history, the connection stays up for about 5-6 minutes, then remains unavailable for about 15-17 minutes before reconnecting again. This cycle repeats continuously.

I have the same issue... it repeatedly disconnects...

[MaikSunny]

Same issue, how to downgrade?

[jaroschek]

Hello, this all seems kind of weird, as I have no such issues... or at least not as often as described here.

But to clarify: If a device is becoming "unavailable", in most cases it means that you get no answer or your request is rejected from the myUplink API. And this is very often directly connected to their rate limit for using the API.

Public API clients: 25 requests per minute.
These limits may be adjusted at any time without prior notice if deemed necessary.

This seems to be kind of new, as previously it was only allowed one request every 4 seconds. Now we are allowed to make one request every 2.4 seconds.

To comply with this rate limit the API implementation in this integration uses throttling to postpone requests. And now with the raised limit this should not happen at all.

BUT: I have observed that this is not how it works in reality. Sometimes (really not often) the API becomes unavailable although I did not query the API as often as allowed. This is kind of weird, but I got used to it.

On the other hand... If you compare the version 1.8.0 to previous versions. One thing that was added was the support for smart home zones through addition API requests. And this adds up to already many API requests that are done for different purposes:

• Get all available systems from API systems/me?page=1&itemsPerPage=99

And per system call the API for the following features:

• For each System check, if a premium subscription is available systems/{system.id}/subscriptions (multiply with system number)
• If the smart home mode is enabled (configurable), one additional request per system systems/{system.id}/smart-home-mode (multiply with system number)
• If notifications from myUplink should be fetched, this is another request per system systems/{system.id}/notifications/active?page=1&itemsPerPage=99 (multiply with system number)

As every system can have multiple devices for each device in each system further API calls are made:

• The main feature to display the entities is to fetch all available devices parameters devices/{device.id}/points (multiply with system number and multiply with device number)
• If the feature to fetch firmware update information is enabled another API request is made per device devices/{device.id}/firmware-info (multiply with system number and multiply with device number)
• If the (newest) feature of the smart home zones is enabled another API request is made per device devices/{device.id}/smart-home-zones (multiply with system number and multiply with device number)

All these API request add up. So even for a single system with a single device this can be up to 7 requests for one update run. But if you disable all the optional features this can be reduced to 3 (systems, subscriptions, parameters). Or if you have multiple systems and/or multiple devices this can add up to a lot of requests.

An additional configuration parameter that is used here is the polling interval. Per default this is set to 300 seconds (5 minutes). (I never got any more frequently changed parameter values from the API for my Nibe heatpump so I decided to make the 300 seconds the default polling interval. Even with a lower polling interval of e.g. 60 seconds, the values delivered from the API did not change more often than every 5 minutes.

But it should be obvious that disabling features to limit requests should be unnecessary as the throttling implementation in the API client should handle this to avoid to often made requests. BUT the rate limiting does happen even with the throttling. This lead me to the conclusion, that the rate limiting of the public myUplink API is not working in the right way. And even if the rate limit is respected the API will not allow requests from time to time of just give no answer.

A suggestion for everybody having these issues here is to check and increase the polling interval to the highest reasonable value. And may be check, if you need all the optional features (linke smart home mode, smart home zone, notification, firmware info) and disable unnecessary features thorough the configuration:

One thing I just learned from the updated API documentation is that the updated response headers now include information regarding the API limits. So I will enhance the logging and the throttling to apply current rate limit windows. Another thing would be to (optionally) post a (warning) notification to Home Assistant if a rate limit is reached.

[jaroschek]

Hello, I have now rewritten the throttling mechanism to work with the (new?) rate limit header values.

Please feel free to try the latest pre-release version 1.8.1-rc1.

[ceesgeert]

I also have the same problems. I would like to try the pre-release. Please provide a few hints how to install this prerelease.

[jaroschek]

@ceesgeert Assuming that you already used HACS to install this integration, you can use HACS to obtain other versions too: https://www.hacs.xyz/docs/use/repositories/dashboard/#downloading-a-specific-version-of-a-repository

[ceesgeert]

I installed 1.8.1-rc1 some 15 minutes ago. It came up perfectly. Let;s wait if this version behaves stable now.

1 hour later: all working fine seems stable. If no new messages assume it keep running in my situation. Thanks for the work.

[jaroschek]

Hello, I monitored the integration too with enabled debug logs in my own production environment.

And I have to admit that I logged some "unavailable" entities too. But in the logs all requests were successful and the rate limit header values did not show any rate limit in effect. So it did not happen because of failed or rejected requests.

In fact not all entities became "unavailable". The entity für the connection status just got the state "disconnected". This state is read from the device data that is obtained from the systems request. This means that myUplink temporarily has no connection to the device and declares it as "disconnected".

And as a matter of integration design I originally defined in the integration, that a disconnected device should cause the entities to become unavailable. This was already an issue for some people and "solved" in #96 by adding a configuration option to avoid "unavailable" entities if a device get's disconnected from myUplink.

So I assume this is all just related to a temporary connection status issue in myUplink itself. The servers at myUplink seem to loose connection to devices from time to time and declare the devices as "disconnected".

Interesting: In the myUplink app on my smartphone the device was not disconnected at the time it was declared disconnected from the API.

But as a solution just enable the config option "Keep disconnected parameters available". With this option the entities stay available although the device is disconnected from myUplink.

[ceesgeert]

I installed 1.8.1-rc1 some 15 minutes ago. It came up perfectly. Let;s wait if this version behaves stable now.

1 hour later: all working fine seems stable. If no new messages assume it keep running in my situation. Thanks for the work.

Version 1.8.1-rc1 now runs for over 24 hours. The conclusion is that the situation improved a lot andMyUplink recovers after a while.

Unfortunately there are still timeouts which cause gaps in graphs, no visible monitoring during which no (automated) control is possible from home assistant. See details in the pictures.

In the mean time I now enabled the config option "Keep disconnected parameters available" in order to remain visibility during disconnection.

[thirst4truth]

Hi All, I have had the same issue with unavailable episodes lasting from 3-12 minutes. I had assumed up to v 1.8.1 this was because I was sending commands to my SMO40 and it was getting confused in some way. There was a close association with when I was sending commands. However after I installed 1.8.1 the frequency increased to about 8-10 per day and occurred independently of my commands (I understand from what jaroschek has written this is coincidence). The MyUplink app on my phone showed I could still access my SMO40 when I could not from HA.
Having installed the latest version 1.8.2 yesterday I had no "unavailables" for 28 hours, but unfortunately have just had one:

This error originated from a custom integration.
Logger: custom_components.myuplink
Source: helpers/update_coordinator.py:440
Integration: myUplink (documentation, issues)
First occurred: 18:03:08 (1 occurrence)
Last logged: 18:03:08
Timeout fetching myUplink data

This is for information only. Thank you jaroschek for letting us know about the config option "Keep disconnected parameters available". I was getting to about the half way stage in creating action templates for all the sensors when I read this so this will save me a bit of work! And thanks in general for the add-on. It has been essential in creating some level of order coordinating my ashp, my solar, my battery, and the 3 stretches of cheap electricity I have on my tariff.

[thirst4truth]

An update. There is a persisting issue although this may be an issue with myUplink and therefore not remediable at the HA end. When I send a command from HA to myUplink, for example to change the state of switch.smo_40_temporary_lux_50004 from off to on, or select.smo_40_op_mode_47137 from manual to auto, all states deriving from the SMO40 become unavailable for about 5 minutes. In the case of the command to change the state of switch.smo_40_temporary_lux_50004 myUplink did not carry through the command.