No data returned from HASS entity sensor.solax_house_load_today

[mergwyn]

Describe the bug I periodically get an error loading my consumption history. As far as I can see from the logs, the request is timing out after 10 seconds and the history is not loaded completely which means I don't get an optimal plan.

The visible symptom of this was that sometimes the pvopt status was stick in "loading tariffs", and other times it just failed silently. The workaround for this was to reduce the number of days of history.

The good news is that I've just upgraded to 3.9.3 and whilst the issue has not gone way (ie the timeout still occurs) this version seems to handle the error more gracefully. However, I'm not sure of the implications of failing to fully load the history.

It might be coincidence, but I first noticed this after I had an issue around Wednesday and I had to restore HA from a 4 hour old backup, so this may be an issue with my data set.

Logs appdameon_log.txt config_yaml.txt

Context pvopt version 3.9.3 Using HA container version 2024.2.2

[fboundy]

I think this is an issue with AppDaemon just not returning the requested data so I’ve tried, like you say, to get PV_Opt to handle it gracefully. At present it will just skip that optimisation. What I haven’t done yet if see if a simple re-try will work.

I’ll have a look at the logs and see if it helps diagnose what’s going on. On 25 Feb 2024 at 18:42 +0000, mergwyn @.***>, wrote:

Describe the bug I periodically get an error loading my consumption history. As far as I can see from the logs, the request is timing out after 10 seconds and the history is not loaded completely which means I don't get an optimal plan. The visible symptom of this was that sometimes the pvopt status was stick in "loading tariffs", and other times it just failed silently. The workaround for this was to reduce the number of days of history. The good news is that I've just upgraded to 3.9.3 and whilst the issue has not gone way (ie the timeout still occurs) this version seems to handle the error more gracefully. However, I'm not sure of the implications of failing to fully load the history. It might be coincidence, but I first noticed this after I had an issue around Wednesday and I had to restore HA from a 4 hour old backup, so this may be an issue with my data set. Logs appdameon_log.txt config_yaml.txt Context pvopt version 3.9.3 Using HA container version 2024.2.2 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[fboundy]

Added some extra checks in 3.9.,4

[mergwyn]

HI, thanks so much for responding so quickly.

Here is the latest log after the update. My config is set to 3 days history (which seems to consistently load without error), and then I changed it to 7 days which provokes the error. Both of these runs of the optimiser should be in the log.

appdameon_log.txt

[fboundy]

It looks to me as if AppDaemon is timing out at 10 seconds when you try to pull in 7 days of data hence:

Coroutine (<coroutine object Hass.get_history at 0x7f47de176f10>) took too long (10 seconds), cancelling the task...

You might be able to fix this by adding: thread_duration_warning_threshold: 00 to your appdaemon.yaml. See here

[mergwyn]

Hi Francis, many thanks for this. I've not seen the error for a few days now, so it may well be that server was just overloaded (it is a bit short of memory) and on a 'go-slow'. I'll close this issue for now, and try your workaround if it happens again.

Thanks again for your great work - I'm enjoying watching the discharge happened automatically when there is a saver session!