All sensors are "unavailable" since last update

[devfaz]

Hi,

i updated to 1.0.9 (I think from 1.0.7), but now all my sensors are behaving a bit strange. They seem to be updated (irregularly) but most of the time marked as "unavailable".

May this be related to recent changes in the code?

[devfaz]

found this in the output of home-assistant

2023-10-24 16:40:24.805 ERROR (MainThread) [custom_components.waterkotte_heatpump] Unexpected error fetching waterkotte_heatpump data: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 290, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/waterkotte_heatpump/__init__.py", line 217, in _async_update_data
    result = await self.api.async_get_data()
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/waterkotte_heatpump/api.py", line 72, in async_get_data
    res = await self._client.read_values(self.tags)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/waterkotte_heatpump/pywaterkotte_ha/ecotouch.py", line 1321, in read_values
    "value": a_eco_tag.read_function(a_eco_tag, str_vals),
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/waterkotte_heatpump/pywaterkotte_ha/ecotouch.py", line 56, in _parse_value_default
    return (int(first_val) & (1 << self.bit)) > 0
            ^^^^^^^^^^^^^^
TypeError: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'

[devfaz]

Downgraded to 1.0.7 and after some time of "TOO MANY USERS", the sensors are working again. Will upgrade back to 1.0.9 to see if its also able to recover from this.

[devfaz]

Ok, currently also 1.0.9 is working again. Maybe somehow to many user-sessions got initiated. Feel free to close, if you dont see any further issue.

[marq24]

Thank you so much for your feedback Fabian!

In the past vew days I have started to refactor the complete integration - I have started with removing a lot of stuff and also changed the internal reading (of the tags) in order to support the new Energy fields (I hope you have found them already)...

Even if I did not came accross the error you have posted here (HA log) - it's worth to 'catch' it and to continue... instead of just cancel the complete reading process - I will create a new release (with plenty of additional internal refactoring) this evening... I hope this time the update will work for you much smoother!

[devfaz]

Updated to 1.0.10.

Not absolutly sure, but I think in the previous version (1.0.9) i was able to reproduce the issue by changing settings of the WK with HA and VNC (more or less) at the same time.

Now (1.0.10) this no longer seems to cause issues :+1: Sadly all just subjective feelings :)

[devfaz]

ok, after playing a bit with "number of tags to fetch" and "interval" I was able to get again the "TOO MANY USERS"-error int he logs.

2023-10-25 10:16:19.413 INFO (MainThread) [custom_components.waterkotte_heatpump.pywaterkotte_ha] LOGIN status:200 content: -37
#E_TOO_MANY_USERS
2023-10-25 10:16:19.414 ERROR (MainThread) [custom_components.waterkotte_heatpump] Unexpected error fetching waterkotte_heatpump data: Error while LOGIN: status:E_TOO_MANY_USERS
Traceback (most recent call last):
  File "/config/custom_components/waterkotte_heatpump/api.py", line 58, in login
    await self._client.login(self._username, self._password)
  File "/config/custom_components/waterkotte_heatpump/pywaterkotte_ha/ecotouch.py", line 349, in login
    raise StatusException(f"Error while LOGIN: status:{self.get_status_response(content)}")
custom_components.waterkotte_heatpump.pywaterkotte_ha.ecotouch.StatusException: Error while LOGIN: status:E_TOO_MANY_USERS

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 290, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/waterkotte_heatpump/__init__.py", line 194, in _async_update_data
    await self.api.login()
  File "/config/custom_components/waterkotte_heatpump/api.py", line 63, in login
    await self._client.login(self._username, self._password)
  File "/config/custom_components/waterkotte_heatpump/pywaterkotte_ha/ecotouch.py", line 349, in login
    raise StatusException(f"Error while LOGIN: status:{self.get_status_response(content)}")
custom_components.waterkotte_heatpump.pywaterkotte_ha.ecotouch.StatusException: Error while LOGIN: status:E_TOO_MANY_USERS

so seems the integration is currently not correctly closing a session during reload/reconfigure.

[devfaz]

and it seems to ignore the "number of tags to fetch" and "interval" completly

changed them to "10", but log still tells me:

2023-10-25 10:19:03.553 INFO (MainThread) [custom_components.waterkotte_heatpump] number of tags to query: 60
2023-10-25 10:19:03.642 INFO (MainThread) [custom_components.waterkotte_heatpump] number of tag-values read: 60

just FYI - not a real issue :-)

[marq24]

changed them to "10", but log still tells me:

2023-10-25 10:19:03.553 INFO (MainThread) [custom_components.waterkotte_heatpump] number of tags to query: 60
2023-10-25 10:19:03.642 INFO (MainThread) [custom_components.waterkotte_heatpump] number of tag-values read: 60

just FYI - not a real issue :-)

ok - the log output is probably misleading - that's the total number of entities that are enabled/active - the code will then later split the this total number (in your case 60) to the number of TagsPerRequest and then send multiple requests to your waterkotte and then combine the responses (of this 6 requests) to a single result set, that then will be processed - with the next update I will also add a log output that will log every single request...

ok, after playing a bit with "number of tags to fetch" and "interval" I was able to get again the "TOO MANY USERS"-error int he logs.

2023-10-25 10:16:19.413 INFO (MainThread) [custom_components.waterkotte_heatpump.pywaterkotte_ha] LOGIN status:200 content: -37
#E_TOO_MANY_USERS
...

so seems the integration is currently not correctly closing a session during reload/reconfigure.

The problem is, that the waterkotte webserver does not have a "logout" functionality (or I did not found any yet) - when you use the original GUI of the waterkotte, there is no logout button either - this is the root of the problem and I do not have a single clue how to get around this... sorry

[marq24]

hopefully with the release of https://github.com/marq24/ha-waterkotte/releases/tag/1.0.11 you will find "all infos" in den debug log...

[der-berni]

Hi, just FYI. When I delete the cookie, I am logged out of the web ui. You could try to set a Cookie with expires tag.

Set-Cookie: =; Expires=Thu, Jan 01 1970 00:00:00 UTC;

[marq24]

@der-berni I am not sure, if I understood, how "keeping the existing cookie 'forever'" would could solve the situation - since IMHO as long as the server does not activity destroy his internal session (for an (previously) existing connection) we will hit the too many concurrent users barrier?!

When I would keep the cookie (even over HA restarts) for long time, then I would assume that it will be removed (at least on Waterkotte hardware restart) and then the communication will be broken...

But my thoughts could be totally wrong?!

[devfaz]

@der-berni dont think its something you can control on client side.

May I ask you to try the following

• create 2 sessions (maybe one normal and one in a private browser window)
• try to create another session while the other 2 are still valid => this should fail
• try to expire one of the first 2 sessions
• retry to create another session => now this new session should work.

[marq24]

I hope t's fine, when I "close" this issue here - since the initial cause is solved... of course we can continue to discuss here (if and when how we could terminate active backend sessions)...