Lifetime energy is no longer updating, while current day/month/year *are*

[wimvanhooff-mtv]

Describe the bug The lifetime energy is only updating at start-up time, while the other entities are updating every few minutes.

Debug information

• Are you using Kiosk or Northbound / OpenAPI mode?
  • [ ] Kiosk
  • [x] Northbound OpenAPI Since current day/month/year are working, credentials seem fine

To Reproduce Happens automatically

Expected behavior Based on previous observations, I expect the lifetime energy to be updated every few minutes.

Screenshots

Desktop (please complete the following information):

• OS: Docker on OpenMediaVault/Debian
• Browser: Firefox
• Version 121

Additional context Running HA 2024.1

[wimvanhooff-mtv]

I found a log which seems to point to the problem:

Logger: homeassistant Source: custom_components/fusion_solar/fusion_solar/energy_sensor.py:68 Integration: Fusion Solar (documentation, issues) First occurred: 3:30:09 PM (5 occurrences) Last logged: 4:10:09 PM

Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 243, in _handle_refresh_interval await self._async_refresh(log_failures=True, scheduled=True) File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 399, in _async_refresh self.async_update_listeners() File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 182, in async_update_listeners update_callback() File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 479, in _handle_coordinator_update self.async_write_ha_state() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 941, in async_write_ha_state self._async_write_ha_state() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1062, in _async_write_ha_state state, attr, capabilities, shadowed_attr = self.async_calculate_state() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 999, in async_calculate_state state = self._stringify_state(available) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 947, in _stringify_state if (state := self.state) is None: ^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/sensor/init.py", line 524, in state value = self.native_value ^^^^^^^^^^^^^^^^^ File "/config/custom_components/fusion_solar/fusion_solar/energy_sensor.py", line 68, in native_value if math.isclose(realtime_power, 0, abs_tol = 0.001): ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: must be real number, not str

[tijsverkoyen]

@AndersHoglund could you have a look?

[wimvanhooff-mtv]

Downgrading to version 3.0.0 seems to have fixed the issue. The logs point to energy_sensor.py being the culprit, which has this line 68 in version 3.0.0:

if realtime_power == '0.00':

... while in 3.0.1 this was changed to:

if math.isclose(realtime_power, 0, abs_tol = 0.001):

I'm guessing this should read:

if math.isclose(float(realtime_power), 0, abs_tol = 0.001):

[AndersHoglund]

Sorry, I can not duplicate this problem. Works fine here. Probably a Python version issue. Leaving out optional named arguments should be fine, as per examples in the school book: https://www.w3schools.com/python/ref_math_isclose.asp

You can try open file energy_sensors.py and change line 68 from: if math.isclose(realtime_power, 0, abs_tol = 0.001): to a variant with full set of optional argumentss: if math.isclose(realtime_power, 0, rel_tol = 0, abs_tol = 0.001): The later does not work here, the glitch reappears. I need to use something like this: if math.isclose(realtime_power, 0, rel_tol = 0.001, abs_tol = 0.001):

However, it seems from the posted log that the problem may be named args, as that Python version seems to expect a real number and not a str (arg name). If the above changes still does not work, try un-named args: if math.isclose(realtime_power, 0, 0.001, 0.001):

Or try a weird mix of un-named and named args: if math.isclose(realtime_power, 0, 0.001, abs_tol =0.001): But none of those work here. both optional params must be named. The W3School site says the same if you try it. TypeError: isclose() takes exactly 2 positional arguments (4 given)

All-in-all, I am lost. I am no Python coder, I give up.
So, the only thing I can think of is: Make sure that all your System components are up to date. I use whatever comes in the Pi4 image, continuously updated.

Also, the midnight glitch we are trying to filter out here is also visible in the one year and monthly energy data. This code only handles lifetime energy. Best solution is if Huawei could cleanup their act.

[AndersHoglund]

One more thought. I use the kiosk interface while this problem is reported using OpenAPI. What-if the realtime_power argument that is the culprit, not the tolerance args?? Log does not tell which arg has the str/real type mismatch. Are there some Python magic going on differently in the two Kiosk/OpenAPI branches, setting realtime_power to different types? Or maybe the Huawei responses look differently?

Please insert a debug log statement before line 68, after the assignment of realtime_power, like: realtime_power = self.coordinator.data[self._data_name][ATTR_REALTIME_POWER] _LOGGER.debug(type(realtime_power))

I can see that it is a float when data is coming from Kiosk: 2024-01-12 10:19:39.153 DEBUG (MainThread) [custom_components.fusion_solar.fusion_solar.energy_sensor] <class 'float'>

And the fact it is a float was the root problem I tried to fix by using isclose(), the original code was comparing floats for equality and that is a major nono. If it turns out to be a string when using OpenAPI, that should be fixed elsewhere. Making sure both branches behave the same in this code common for both. Or a hard type cast here, like: realtime_power = float(self.coordinator.data[self._data_name][ATTR_REALTIME_POWER])

[AndersHoglund]

@wimvanhooff-mtv I am so sorry, I did not read all your posts properly. You are probably correct in this part:

I'm guessing this should read: if math.isclose(float(realtime_power), 0, abs_tol = 0.001):

Have you tried it? Did it work?? I have added this and it does not seem to do any harm, but I will see in an hour or so when the sun has set and power is zero if the statement works fully. I'll be back....

So the core problem is most likely that OpenAPI returns strings while Kiosk returns floats. Not too good, needs fixing. @tijsverkoyen where can this be corrected? Can you fix it, please. Quick-fix is a type cast here, but a proper fix would be nice.

Sorry for all my rantings in prev. posts, it was too late at night (or rather too early in the morning) for reading and debugging. /A

[AndersHoglund]

The float type cast does no harm to the Kiosk data, and the fix for the midnight glitch also works as usual.

2024-01-12 15:33:18.664 DEBUG (MainThread) [custom_components.fusion_solar.fusion_solar.kiosk.kiosk] calculated API base url for JrlNJcLJ3daMl24aN4F45PIiLxw36xax: https://uni002eu5.fusionsolar.huawei.com 2024-01-12 15:33:18.664 DEBUG (MainThread) [custom_components.fusion_solar.sensor] fusion_solar 2024-01-12 15:33:18.665 DEBUG (MainThread) [custom_components.fusion_solar.sensor] JrlNJcLJ3daMl24aN4F45PIiLxw36xax 2024-01-12 15:33:18.956 DEBUG (SyncWorker_4) [custom_components.fusion_solar.fusion_solar.kiosk.kiosk_api] Received data for JrlNJcLJ3daMl24aN4F45PIiLxw36xax: 2024-01-12 15:33:18.956 DEBUG (SyncWorker_4) [custom_components.fusion_solar.fusion_solar.kiosk.kiosk_api] {'realTimePower': 0.048, 'cumulativeEnergy': 24661.57, 'monthEnergy': 16.02, 'dailyEnergy': 2.29, 'yearEnergy': 16.02} 2024-01-12 15:33:18.962 DEBUG (MainThread) [custom_components.fusion_solar.sensor] Finished fetching FusionSolarKiosk data in 0.298 seconds (success: True) 2024-01-12 15:43:18.663 DEBUG (MainThread) [custom_components.fusion_solar.fusion_solar.kiosk.kiosk] calculated API base url for JrlNJcLJ3daMl24aN4F45PIiLxw36xax: https://uni002eu5.fusionsolar.huawei.com 2024-01-12 15:43:18.664 DEBUG (MainThread) [custom_components.fusion_solar.sensor] fusion_solar 2024-01-12 15:43:18.664 DEBUG (MainThread) [custom_components.fusion_solar.sensor] JrlNJcLJ3daMl24aN4F45PIiLxw36xax 2024-01-12 15:43:18.971 DEBUG (SyncWorker_5) [custom_components.fusion_solar.fusion_solar.kiosk.kiosk_api] Received data for JrlNJcLJ3daMl24aN4F45PIiLxw36xax: 2024-01-12 15:43:18.971 DEBUG (SyncWorker_5) [custom_components.fusion_solar.fusion_solar.kiosk.kiosk_api] {'realTimePower': 0.0, 'cumulativeEnergy': 24661.579999999998, 'monthEnergy': 16.03, 'dailyEnergy': 2.3, 'yearEnergy': 16.03} 2024-01-12 15:43:18.977 DEBUG (MainThread) [custom_components.fusion_solar.sensor] Finished fetching FusionSolarKiosk data in 0.313 seconds (success: True) 2024-01-12 15:43:18.978 INFO (MainThread) [custom_components.fusion_solar.fusion_solar.energy_sensor] sensor.kronkarrs_huawei_vr_jrlnjclj3daml24an4f45piilxw36xax_total_lifetime_energy: not producing any power, so no energy update to prevent glitches.

Will PR this. Needs to be tested by some OpenAPI user.

[tijsverkoyen]

Released https://github.com/tijsverkoyen/HomeAssistant-FusionSolar/releases/tag/v3.0.2, containing the quick fix.

[wimvanhooff-mtv]

Thanks for the help team! Love the integration 🙂

Kind Regards, Vriendelijke Groeten,

Wim @.***> | Montova platform expert | p: +32 (0)2 711 41 30 | [MONTOVA] https://www.montova.com/ , Belgicastraat 11 bus 4, BE-1930 Zaventem

---

From: Tijs Verkoyen @.> Sent: Monday, January 15, 2024 16:36 To: tijsverkoyen/HomeAssistant-FusionSolar @.> Cc: Wim Vanhooff @.>; Mention @.> Subject: Re: [tijsverkoyen/HomeAssistant-FusionSolar] Lifetime energy is no longer updating, while current day/month/year are (Issue #132)

Released https://github.com/tijsverkoyen/HomeAssistant-FusionSolar/releases/tag/v3.0.2, containing the quick fix.

— Reply to this email directly, view it on GitHubhttps://github.com/tijsverkoyen/HomeAssistant-FusionSolar/issues/132#issuecomment-1892395282, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BEXRTQMDMORSV5YXCNJNQCTYOVEJLAVCNFSM6AAAAABBWT6SM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJSGM4TKMRYGI. You are receiving this because you were mentioned.Message ID: @.***>