barleybobs / homeassistant-ecowater-softener

A Homeassistant custom component to integrate Ecowater water softeners
https://github.com/barleybobs/homeassistant-ecowater-softener
MIT License
33 stars 10 forks source link

Log details - Offline Status #1

Closed mblauser closed 3 years ago

mblauser commented 3 years ago

HA-ecowater-softener component version: 1.0.1 HA version: 2021.9.5-ls36

I realize this project has not yet been released, but I noticed a potential issue and would like to assist with determining if the cause is code-related or a server-side problem. The logs available in HA are not detailed enough to point to a culprit.

I've only had this installed for the past few days. It worked very well upon the first installation attempt. However, the past two days have reported the device unavailable on two lengthy occasions. It has occurred this morning at 2:21am PT, and yesterday morning around 4:30am PT. The device appears and remains unavailable for 20+ hours before returning back to Available status on its own.

homeassistant-ecowater-softener-unavailable

Troubleshooting attempted during unavailable status:


HA Logs: [serial number intentionally masked] "Log Details (WARNING)"
`Logger: homeassistant.helpers.entity Source: helpers/entity.py:644 First occurred: September 10, 2021, 8:50:58 PM (27 occurrences) Last logged: 2:20:58 PM

Update of sensor.ecowater_ac000w003xxxxxx is taking over 10 seconds`


also appearing in the logs: "Log Details (ERROR)" `This error originated from a custom integration.

Logger: custom_components.ecowater_softener.sensor Source: custom_components/ecowater_softener/sensor.py:115 Integration: Ecowater Softener (documentation, issues) First occurred: September 10, 2021, 7:20:48 PM (35 occurrences) Last logged: 2:21:00 PM

Error: time data '01/31/2022' does not match format '%d/%m/%Y' Traceback (most recent call last): File "/config/custom_components/ecowater_softener/sensor.py", line 115, in async_update self._attrs[ATTR_OUT_OF_SALT_ON] = datetime.strptime(data_json['out_of_salt'], '%d/%m/%Y').strftime('%Y-%m-%d') File "/usr/lib/python3.8/_strptime.py", line 568, in _strptime_datetime tt, fraction, gmtoff_fraction = _strptime(data_string, format) File "/usr/lib/python3.8/_strptime.py", line 349, in _strptime raise ValueError("time data %r does not match format %r" % ValueError: time data '01/31/2022' does not match format '%d/%m/%Y' `


Is it possible to enable additional log details to help determine whether the trouble resides with server replies, component code, or perhaps unique to my HA instance itself? I do hope this information is valuable and look forward to assist with testing.

barleybobs commented 3 years ago

@mblauser I realize this project has not yet been released, but I noticed a potential issue and would like to assist with determining if the cause is code-related or a server-side problem.

Thanks for bringing this to my attention!

HA Logs: [serial number intentionally masked] "Log Details (WARNING)" `Logger: homeassistant.helpers.entity Source: helpers/entity.py:644 First occurred: September 10, 2021, 8:50:58 PM (27 occurrences) Last logged: 2:20:58 PM

Update of sensor.ecowater_ac000w003xxxxxx is taking over 10 seconds`

This should just be a warning and can be ignored. It is because it takes over 10 seconds to get the data from the ecowater servers.

"Log Details (ERROR)" `This error originated from a custom integration.

Logger: custom_components.ecowater_softener.sensor Source: custom_components/ecowater_softener/sensor.py:115 Integration: Ecowater Softener (documentation, issues) First occurred: September 10, 2021, 7:20:48 PM (35 occurrences) Last logged: 2:21:00 PM

Error: time data '01/31/2022' does not match format '%d/%m/%Y' Traceback (most recent call last): File "/config/custom_components/ecowater_softener/sensor.py", line 115, in async_update self._attrs[ATTR_OUT_OF_SALT_ON] = datetime.strptime(data_json['out_of_salt'], '%d/%m/%Y').strftime('%Y-%m-%d') File "/usr/lib/python3.8/_strptime.py", line 568, in _strptime_datetime tt, fraction, gmtoff_fraction = _strptime(data_string, format) File "/usr/lib/python3.8/_strptime.py", line 349, in _strptime raise ValueError("time data %r does not match format %r" % ValueError: time data '01/31/2022' does not match format '%d/%m/%Y'

This seems to be where the problem is. It appears that your ecowater device is returning a MDY date but the code expects a DMY date. To fix this during setup I have added a dropdown to pick the correct date format.

This is on the dev branch. If you could delete the integration from the integration tab. Then delete the ecowater_softener from your custom_components folder and then download the dev branch to test if that fixes the problem that would be appreciated!

Thanks 👍

mblauser commented 3 years ago

This is on the dev branch. If you could delete the integration from the integration tab. Then delete the ecowater_softener from your custom_components folder and then download the dev branch to test if that fixes the problem that would be appreciated!

I performed these steps while the integration was reporting as 'unavailable'. Upon adding the integration with updated dev code, it immediately began reporting as 'online' and has been so for the past 23 hours. Thank you! I'll certainly report back if the status changes.

ecowater-homeassistant-screenshot

Future enhancement consideration: It may be able to automatically select the user's date format with additional logic by comparing the result of a today() function with the value reported by the Ecowater server. It might then be possible to distinguish 09/10/2021 from 10/09/2021 based on today() during setup, and automatically set MM/DD or DD/MM accordingly. Very low-priority enhancement but worth considering.

barleybobs commented 3 years ago

@mblauser Future enhancement consideration: It may be able to automatically select the user's date format with additional logic by comparing the result of a today() function with the value reported by the Ecowater server. It might then be possible to distinguish 09/10/2021 from 10/09/2021 based on today() during setup, and automatically set MM/DD or DD/MM accordingly. Very low-priority enhancement but worth considering.

I had considered this but it has problems when it is for example 01/01/2021 or 08/08/2021. So I thought it would be easier for the user to determine and enter.

I'll close this issue in that case. Thanks for pointing this bug out!

If it goes offline again for a similar reason do not hesitate to comment on this issue and I can reopen it. Otherwise, create a new issue if you have further problems.

I will move the dev branch to the main in a day or two if no further problems are reported.

Thanks 👍

barleybobs commented 2 years ago

@mblauser This has now been added to the main branch.

Thanks for finding this issue and reporting it 👍