Closed BertilJ closed 3 years ago
Will look into this. How can i test it? is it sufficient to disconnect the charger and see if the old values still are used in HA?
Sorry for late response.
I don't exactly know what happens with the api call if the charger is completly disconnected. But I'm guessing for test purposes if you would send null as a an update for the sensor, the current behaviour would be to set the sensor to 0 and my proposed solution would be that if value is null, i.e not existing there shouldn't be an update to the sensor, the sensor should keep current value.
@BertilJ please check the master branch or version 0.12.0 via hacs solves this for you.
Will also test. @cathiele thank you so much for your great work!
Still happening for me - updated to 0.12.0, restarted my HA
ok, thank you for testing. I will try to reproduce it again
I get the same drops to 0 on all values. I assumed it is because of loosing wifi connection, maybe give that a try?
edit: my firmware version is 033
I get the same drops to 0 on all values. I assumed it is because of loosing wifi connection, maybe give that a try?
I'd suspect the same thing, since my Charger also drops off quite often unfortunately.
Finally i had time to check this issue again. Please update to version 0.14.0 and comment here if it is still a problem.
As the fix is already from October 2020 it was present in my last charging session when I already had updated via HACS. I had no drops to 0 in this session. Already wondered what was going on, as no such fix was announced ;-)
@cathiele thank you for still hanging on here, much appreciate your efforts!
Unfortunately, updating to 0.14.0 didn't help. I updated and restarted my HA instance (full restart), yet I still see 0-entries:
I looked at my core logs and saw timeouts that - yet that 21:21:36 exception didn't produce a 0-entry (with that exact timestamp, later new ones appeared @ 21:28).
2021-05-08 21:21:36 ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.goecharger_xxxxxx_charger_max_current fails Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 445, in _make_request six.raise_from(e, None) File "<string>", line 3, in raise_from File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 440, in _make_request httplib_response = conn.getresponse() File "/usr/local/lib/python3.8/http/client.py", line 1344, in getresponse response.begin() File "/usr/local/lib/python3.8/http/client.py", line 307, in begin version, status, reason = self._read_status() File "/usr/local/lib/python3.8/http/client.py", line 268, in _read_status line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1") File "/usr/local/lib/python3.8/socket.py", line 669, in readinto return self._sock.recv_into(b) socket.timeout: timed out During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/requests/adapters.py", line 439, in send resp = conn.urlopen( File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 755, in urlopen retries = retries.increment( File "/usr/local/lib/python3.8/site-packages/urllib3/util/retry.py", line 532, in increment raise six.reraise(type(error), error, _stacktrace) File "/usr/local/lib/python3.8/site-packages/urllib3/packages/six.py", line 735, in reraise raise value File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 699, in urlopen httplib_response = self._make_request( File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 447, in _make_request self._raise_timeout(err=e, url=url, timeout_value=read_timeout) File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 336, in _raise_timeout raise ReadTimeoutError( urllib3.exceptions.ReadTimeoutError: HTTPConnectionPool(host='192.168.0.193', port=80): Read timed out. (read timeout=5) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 316, in async_update_ha_state await self.async_device_update() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 524, in async_device_update raise exc File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/goecharger/sensor.py", line 113, in update fetchedStatus = self._goeCharger.requestStatus() File "/usr/local/lib/python3.8/site-packages/goecharger/goecharger.py", line 280, in requestStatus status = self.__queryStatusApi() File "/usr/local/lib/python3.8/site-packages/goecharger/goecharger.py", line 184, in __queryStatusApi statusRequest = requests.get("http://%s/status" % self.host, timeout=5) # TODO: Configurable Timeout File "/usr/local/lib/python3.8/site-packages/requests/api.py", line 76, in get return request('get', url, params=params, **kwargs) File "/usr/local/lib/python3.8/site-packages/requests/api.py", line 61, in request return session.request(method=method, url=url, **kwargs) File "/usr/local/lib/python3.8/site-packages/requests/sessions.py", line 542, in request resp = self.send(prep, **send_kwargs) File "/usr/local/lib/python3.8/site-packages/requests/sessions.py", line 655, in send r = adapter.send(request, **kwargs) File "/usr/local/lib/python3.8/site-packages/requests/adapters.py", line 529, in send raise ReadTimeout(e, request=request) requests.exceptions.ReadTimeout: HTTPConnectionPool(host='192.168.0.193', port=80): Read timed out. (read timeout=5)
If I can support with full logs or anything else, please let me know - and thank you again for your hard work!
I now found a way to reproduce it here with adding a firewall DROP-rule to my raspberry with homeassistant:
iptables -A OUTPUT -p tcp --dport 80 -d <chargerip> -j DROP
and deleting it with:
iptables -D OUTPUT -p tcp --dport 80 -d <chargerip> -j DROP
so i hope i can debug this now more easily.
Please test Version 0.15.0
First 12 hours after updating to 0.15.0 look flawless!
Still great after (nearly) 24h. For me this is solved :-) Thank you!
Gut Ding will Weile haben ¯_(ツ)_/¯
I am having challenges with using utility meters together with the kwh sensors. Does not matter which I am using, both gives 0 values on and off probably due to the api not responding fast enough. This is causing the utility meters to go crazy, eg reading from current session charged is 10.3 kwh, but the utility meter that is consuming that value gives 255 kwh.
Proposal is to not have the sensors to report 0 when not getting a new update, but rather stay on current value until new actual value is received.
I have set up some rest sensors to test this and the box does not seem to report 0 on and off, but sometimes the api does not report all values.