Update to pre-release givenergy-modbus

[cdpuk]

The current v0.x release contains a growing list of issues and is unsupported. There is a new version in the works, but it has not been released yet.

This integration could be updated to use the pre-release code.

Advantages:

• Improved reliability
• Compatibility with a wider range of inverters

Disadvantages:

• Interfaces may change
• Copying & pasting a library in to another codebase 🤮

[alfwro13]

will that address the upcoming givenergy breaking change firmware (that also affected GivTCP) ?

[cdpuk]

@alfwro13 If the fix worked for GivTCP, it would work here too

[cdpuk]

There is now a branch with WIP on this issue.

This takes the newer version of givenergy_modbus that was due to become v1.0 - more or less a complete rewrite compared to the original. Sadly it was never quite finished or released, but I've grabbed the source and attempted to fill some of the few remaining gaps to make it work with the integration.

I've included the CRC calculation fix for reading inverter data, but there's still a chance it won't be able to write new values - more work required there.

This successfully reads and writes values on my inverter with the old firmware. If someone could give this a run against some newer firmware, I'd be interested to hear whether it works at all. This is available through HACS by enabling beta releases on the download page. Look for v2.0.0-alpha1.

[andynash]

Great stuff, thanks got getting to work on this so quickly 👍

I'll try and install this tomorrow and let you know how I get on...

[andynash]

So I've upgraded the integration to the alpha version, and restarted, then reloaded the integration for good measure.

Unfortunately it seems we're not able to read from the inverter on the new firmware (at least in my case).

With debug logging turned on for the integration, these are the logs following a reload (of the integration):

tail -f /home/homeassistant/.homeassistant/home-assistant.log | grep givenergy

2023-12-14 11:54:04.710 INFO (SyncWorker_36) [custom_components.givenergy_local.coordinator] Fetching data from 10.0.0.27
2023-12-14 11:54:04.710 DEBUG (SyncWorker_36) [custom_components.givenergy_local.coordinator] Performing full refresh
2023-12-14 11:54:06.717 ERROR (SyncWorker_36) [givenergy_modbus] Transaction failed
2023-12-14 11:54:06.719 ERROR (SyncWorker_36) [givenergy_modbus] Modbus Error: [Input/Output] Modbus Error: [Invalid Message] No response received, expected at least 164 bytes (0 received)
2023-12-14 11:54:06.720 ERROR (SyncWorker_36) [givenergy_modbus] Did not receive expected response type: ReadInputRegistersResponse != ModbusIOException
2023-12-14 11:54:09.228 ERROR (SyncWorker_36) [givenergy_modbus] Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response
2023-12-14 11:54:09.228 ERROR (SyncWorker_36) [givenergy_modbus] Did not receive expected response type: ReadInputRegistersResponse != ModbusIOException
2023-12-14 11:54:11.736 ERROR (SyncWorker_36) [givenergy_modbus] Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response
2023-12-14 11:54:11.736 ERROR (SyncWorker_36) [givenergy_modbus] Did not receive expected response type: ReadHoldingRegistersResponse != ModbusIOException
2023-12-14 11:54:14.245 ERROR (SyncWorker_36) [givenergy_modbus] Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response
2023-12-14 11:54:14.245 ERROR (SyncWorker_36) [givenergy_modbus] Did not receive expected response type: ReadHoldingRegistersResponse != ModbusIOException
2023-12-14 11:54:14.711 ERROR (MainThread) [custom_components.givenergy_local.coordinator] Error fetching Inverter data: Error communicating with API: 
2023-12-14 11:54:14.711 DEBUG (MainThread) [custom_components.givenergy_local.coordinator] Finished fetching Inverter data in 10.002 seconds (success: False)
2023-12-14 11:54:16.755 ERROR (SyncWorker_36) [givenergy_modbus] Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response
2023-12-14 11:54:16.756 ERROR (SyncWorker_36) [givenergy_modbus] Did not receive expected response type: ReadHoldingRegistersResponse != ModbusIOException
2023-12-14 11:54:19.261 ERROR (SyncWorker_36) [givenergy_modbus] Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response
2023-12-14 11:54:19.262 ERROR (SyncWorker_36) [givenergy_modbus] Did not receive expected response type: ReadInputRegistersResponse != ModbusIOException

Please let me know if there is anything else that would help 👍

[cdpuk]

Ah, that would be because I messed up the release, so you were actually still running 1.9.0.

I've now published v2.0.0-alpha2.

[andynash]

Great! I've updated however I get a new error, perhaps just a typo?

Logger: homeassistant.setup
Source: setup.py:251
First occurred: 23:42:27 (1 occurrences)
Last logged: 23:42:27

Setup failed for custom integration 'givenergy_local': Unable to import component: No module named 'givenergy_modbus.client.client'; 'givenergy_modbus.client' is not a package
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.11/site-packages/homeassistant/setup.py", line 251, in _async_setup_component
    component = integration.get_component()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/srv/homeassistant/lib/python3.11/site-packages/homeassistant/loader.py", line 814, in get_component
    ComponentProtocol, importlib.import_module(self.pkg_path)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1206, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1178, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1149, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 940, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/home/homeassistant/.homeassistant/custom_components/givenergy_local/__init__.py", line 10, in <module>
    from .coordinator import GivEnergyUpdateCoordinator
  File "/home/homeassistant/.homeassistant/custom_components/givenergy_local/coordinator.py", line 8, in <module>
    from givenergy_modbus.client.client import Client
ModuleNotFoundError: No module named 'givenergy_modbus.client.client'; 'givenergy_modbus.client' is not a package

[cdpuk]

Not a typo as far as I can tell, but something to do with how Python dependencies are defined and downloaded.

I was able to reproduce this by having 1.9.0 installed, then upgrading to 2.0.0-alpha2 via HACS. Removing and re-adding the integration seems to clear things up, but this shouldn't be required and will need addressing.

If you're keen, you may want to try a completely separate HA instance and install the new version directly in that. I've just been running up a Docker container for it, installing HACS, then installing the integration to play around.

In the next version I'll change the approach to avoid this problem.

[andynash]

Thanks, I've tried removing the integration, but it wants the config deleted first. I've tried that, and confirmed the deletion, but then - nothing - the config doesn't appear to be deleted so I can't remove the integration. Any thoughts?

[cdpuk]

Assuming we're on alpha2 and it's not behaving, the least disruptive thing to do is perhaps to force it on to the correct version of givenergy_modbus. You can confirm the version with:

pip list installed | grep giv

I found that, after the upgrade, it was stuck on 0.10.1. To install the correct version for alpha2, run:

pip install givenergy-modbus@git+https://github.com/cdpuk/givenergy-modbus@aa5af8f8038408ebec07bfcea834b6b4a8493f25

Then restart HA.

It's odd how this works for fresh installs but not upgrades.

[andynash]

It's a (partial) Christmas miracle 😁🎄

That has worked and (almost) all entities appear to be as they should 👍

However, I'm seeing some issues relating to control - so far I have discovered that:

1. The charge and discharge power limits have been changed to 2600 and can't be set back to 3600. I guess the integration thinks the inverter is Gen 1 for some reason?
2. If I adjust the booleans (eco mode, ac charging, dc discharging), this fails and they revert to their original setting.
3. If I adjust them from givenergy.cloud, they update in HA, but still cannot be controlled.
4. Adjusting the booleans appears to also cause the integration to lose contact with the inverter, in fact the app and givenergy.cloud also appear to lose contact at the same time. I'm not sure how consistent this is yet.

I've also redownloaded the alpha-2, and restarted Home Assistant several times.

In the logs I've seen the following:

Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:238
Integration: Home Assistant WebSocket API ([documentation](https://www.home-assistant.io/integrations/websocket_api), [issues](https://github.com/home-assistant/core/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+websocket_api%22))
First occurred: 11:06:40 (4 occurrences)
Last logged: 11:08:42

[140516901194560] Value 3600.0 for number.battery_charge_power_limit is outside valid range 0.0 - 2600
[140516901194560] Value 3000.0 for number.battery_charge_power_limit is outside valid range 0.0 - 2600
[140516901194560] Value 3600.0 for number.battery_discharge_power_limit is outside valid range 0.0 - 2600
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.11/site-packages/homeassistant/components/websocket_api/commands.py", line 238, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/srv/homeassistant/lib/python3.11/site-packages/homeassistant/core.py", line 2067, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/srv/homeassistant/lib/python3.11/site-packages/homeassistant/core.py", line 2104, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/srv/homeassistant/lib/python3.11/site-packages/homeassistant/helpers/entity_component.py", line 272, in handle_service
    return await service.entity_service_call(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/srv/homeassistant/lib/python3.11/site-packages/homeassistant/helpers/service.py", line 878, in entity_service_call
    single_response = await _handle_entity_call(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/srv/homeassistant/lib/python3.11/site-packages/homeassistant/helpers/service.py", line 948, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/srv/homeassistant/lib/python3.11/site-packages/homeassistant/components/number/__init__.py", line 96, in async_set_value
    raise ValueError(
ValueError: Value 3600.0 for number.battery_charge_power_limit is outside valid range 0.0 - 2600

The following errors both appear to occur on integration reload:

Logger: givenergy_modbus.client.client
Source: runner.py:188
First occurred: 11:02:29 (2 occurrences)
Last logged: 11:03:56

network_consumer reader at EOF, cannot continue

Logger: custom_components.givenergy_local.coordinator
Source: helpers/update_coordinator.py:332
Integration: GivEnergy Local ([documentation](https://github.com/cdpuk/givenergy-local), [issues](https://github.com/cdpuk/givenergy-local/issues))
First occurred: 11:02:29 (2 occurrences)
Last logged: 11:03:56

Error fetching Inverter data: Error communicating with inverter:

Not sure about the following, perhaps related to the controls not functioning?

Error doing job: _GatheringFuture exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/asyncio/tasks.py", line 490, in wait_for
    return fut.result()
           ^^^^^^^^^^^^
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.11/site-packages/givenergy_modbus/client/client.py", line 207, in send_request_and_await_response
    await asyncio.wait_for(response_future, timeout=timeout)
  File "/usr/local/lib/python3.11/asyncio/tasks.py", line 492, in wait_for
    raise exceptions.TimeoutError() from exc
TimeoutError

Logger: homeassistant
Source: custom_components/givenergy_local/coordinator.py:37
Integration: GivEnergy Local ([documentation](https://github.com/cdpuk/givenergy-local), [issues](https://github.com/cdpuk/givenergy-local/issues))
First occurred: 10:02:12 (2 occurrences)
Last logged: 10:05:36

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/home/homeassistant/.homeassistant/custom_components/givenergy_local/coordinator.py", line 37, in async_shutdown
    await self.client.close()
  File "/srv/homeassistant/lib/python3.11/site-packages/givenergy_modbus/client/client.py", line 68, in close
    await self.writer.wait_closed()
  File "/usr/local/lib/python3.11/asyncio/streams.py", line 350, in wait_closed
    await self._protocol._get_close_waiter(self)
  File "/usr/local/lib/python3.11/asyncio/selector_events.py", line 995, in _read_ready__data_received
    data = self._sock.recv(self.max_size)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ConnectionResetError: [Errno 104] Connection reset by peer

[andynash]

A further update, delayed by festivities and travel: as well as not being able to perform any control functions as described above, the read functionality doesn't last long, and the integration fails again completely, though clearly we're on the right track...

[cdpuk]

Thanks for the update. I too haven't had much time to make any further changes over the festive period.

1. Power limits - probably easy to fix. I'm not too worried about this.
2. Changing booleans - I didn't get around to implementing the CRC correction code for write operations, so I expect that's why.
3. Updates via the app - good, glad to hear they're being reflected in HA.
4. Probably related to 2.

I've noticed that modbus, or this specific modbus implementation, is pretty dumb. There doesn't appear to be any isolation between clients when multiple connections are established with an inverter. e.g. while running my development HA, the modbus connection on that receives responses to requests made from my live HA instance. This appears to cause the givenergy_modbus library to get out of sync (receiving a response for a request it never made) and future comms fail. I wouldn't be surprised if failure to write values correctly causes the same thing and also interrupts cloud comms temporarily.

Regardless, the fact you can read data again is a massive step forwards. Next up I'll sort out the CRCs for control operations. Thanks again for your help testing this.

[andynash]

No problem, and can totally understand not having much time recently 😁

Happy to help further if I can 👍

[comm]

Hi, Just checking in - is there any update on this please? I failed to check outstanding issues before upgrading my firmware last night and would be super keen to get this back up and running! Happy to help out with testing if I can - I am running Hy-5-G2 inverter and 9.5-G2 battery. Thanks in advance!

[cdpuk]

No updates yet, but I'm keen to upgrade my own firmware so this is very much on the list of things to sort out as soon as I've got time to do so.

[cdpuk]

I've just published v2.0.0-alpha3.

• givenergy_modbus has crudely been copied in to the codebase to avoid the dependency issues we saw in alpha2.
• A possible fix for write operations has been added. A test would be appreciated to see if values can now be updated.

I've not yet looked at the instability over time, or the issue with the power limits.

[comm]

Sensors now visible! And only after simple upgrade through HACS, no additional commands required.

Am getting regular error though: ERROR (MainThread) [custom_components.givenergy_local.coordinator] Error fetching Inverter data: Error communicating with inverter:

I will have a look through the entities and services in the morning to see if there is anything awry there.

Thanks for the step in the right direction!

[comm]

Hmm, sensors died overnight, with the following debug errors occurring every 30 seconds: 2024-01-21 06:13:02.364 DEBUG (MainThread) [custom_components.givenergy_local.givenergy_modbus.client.client] Cancelling existing in-flight request and replacing: 2:4/ReadInputRegistersRequest(slave_address=0x32 base_register=0) 2024-01-21 06:13:02.364 DEBUG (MainThread) [custom_components.givenergy_local.givenergy_modbus.client.client] Cancelling existing in-flight request and replacing: 2:4/ReadInputRegistersRequest(slave_address=0x32 base_register=180) 2024-01-21 06:13:02.365 DEBUG (MainThread) [custom_components.givenergy_local.givenergy_modbus.client.client] Cancelling existing in-flight request and replacing: 2:3/ReadHoldingRegistersRequest(slave_address=0x32 base_register=0) 2024-01-21 06:13:02.365 DEBUG (MainThread) [custom_components.givenergy_local.givenergy_modbus.client.client] Cancelling existing in-flight request and replacing: 2:3/ReadHoldingRegistersRequest(slave_address=0x32 base_register=60) 2024-01-21 06:13:02.366 DEBUG (MainThread) [custom_components.givenergy_local.givenergy_modbus.client.client] Cancelling existing in-flight request and replacing: 2:3/ReadHoldingRegistersRequest(slave_address=0x32 base_register=120) 2024-01-21 06:13:02.366 DEBUG (MainThread) [custom_components.givenergy_local.givenergy_modbus.client.client] Cancelling existing in-flight request and replacing: 2:4/ReadInputRegistersRequest(slave_address=0x32 base_register=120) 2024-01-21 06:13:02.367 DEBUG (MainThread) [custom_components.givenergy_local.givenergy_modbus.client.client] Cancelling existing in-flight request and replacing: 2:4/ReadInputRegistersRequest(slave_address=0x32 base_register=60) 2024-01-21 06:13:02.367 DEBUG (MainThread) [custom_components.givenergy_local.givenergy_modbus.client.client] Cancelling existing in-flight request and replacing: 2:4/ReadInputRegistersRequest(slave_address=0x33 base_register=60) 2024-01-21 06:13:02.368 DEBUG (MainThread) [custom_components.givenergy_local.givenergy_modbus.client.client] Cancelling existing in-flight request and replacing: 2:4/ReadInputRegistersRequest(slave_address=0x34 base_register=60) 2024-01-21 06:13:02.368 DEBUG (MainThread) [custom_components.givenergy_local.givenergy_modbus.client.client] Cancelling existing in-flight request and replacing: 2:4/ReadInputRegistersRequest(slave_address=0x35 base_register=60) 2024-01-21 06:13:02.372 DEBUG (MainThread) [custom_components.givenergy_local.givenergy_modbus.client.client] Cancelling existing in-flight request and replacing: 2:4/ReadInputRegistersRequest(slave_address=0x36 base_register=60) 2024-01-21 06:13:12.361 DEBUG (MainThread) [custom_components.givenergy_local.coordinator] Finished fetching Inverter data in 10.002 seconds (success: False)

Looking further back, the following critical occurred on boot: 2024-01-20 21:35:46.743 CRITICAL (MainThread) [custom_components.givenergy_local.givenergy_modbus.client.client] network_consumer reader at EOF, cannot continue

I reloaded the integration - debug log attached, if that helps! 2024-01-21-06-21-GivEnergy_Debug.log

Will report back later on any further status - let me know if you want me to try/lookout for anything else.

[comm]

Connection now failed, with same issue from last night: 2024-01-21 07:44:27.259 INFO (MainThread) [custom_components.givenergy_local.coordinator] Fetching data from 192.168.1.12 2024-01-21 07:44:28.279 ERROR (MainThread) [custom_components.givenergy_local.coordinator] Error fetching Inverter data: Error communicating with inverter: 2024-01-21 07:44:28.280 DEBUG (MainThread) [custom_components.givenergy_local.coordinator] Finished fetching Inverter data in 1.021 seconds (success: False)

and continues with this every 30 seconds: 2024-01-21 07:45:29.272 INFO (MainThread) [custom_components.givenergy_local.coordinator] Fetching data from 192.168.1.12 2024-01-21 07:45:30.302 DEBUG (MainThread) [custom_components.givenergy_local.coordinator] Finished fetching Inverter data in 1.029 seconds (success: False)

Wifi is fine, I've monitored on my router and can connect to the inverter using GivEnergy App. Reloading the service restores connection... lets see for how long...

[comm]

So last few hours have been on and off - big gap in connectivity for about an hour and Error communicating with inverter every 2-10 minutes...

I've not yet tried any service calls, but noticed that the Charge and Discharge limits are set to 2600, when they should be (and were previously) 3600 as per the Gen2 capability.

[cdpuk]

The poor reliability is still an issue that needs looking at. The alpha3 release should enable settings to be written from HA. It'd be useful for someone to test this, but it needs doing during what might be a brief window when data is actually being read successfully.

alpha4, just published, attempts to restore the inverter model identification, which should correctly identify things like power limits.

The device info should display some of this info:

[andynash]

The poor reliability is still an issue that needs looking at. The alpha3 release should enable settings to be written from HA. It'd be useful for someone to test this, but it needs doing during what might be a brief window when data is actually being read successfully.

alpha4, just published, attempts to restore the inverter model identification, which should correctly identify things like power limits.

The device info should display some of this info:

Can confirm the ID of the inverter amd this the power limits is now correct 👍

As you say no change on the reliability side, and I'm away so have not got time to check the write access properly I'm afraid - doesn't appear to work but I've not looked at logs and I have other things set up that maybe interfering.

Thanks for your continued work on this!

[comm]

I can also confirm the device info and power limits are now correct, another step forward! Thank you.

I have tried adjusting the charge/discharge limits and toggling the Charge/Discharge/Eco switches and these appear to work. second step forward! Thank you!

However, connection stability is still low.

[comm]

I have setup an Automation to re-load the integration if it's down for more than 2 minutes, to try and capture more data.

I've noticed random spikes in "Grid Power" (00:57:23 to 00:57:56 and 01:49:29 to 01:50:02): If it helps at all, I've attached the DEBUG logs for the timeframe 00:57:22 to 00:57:56 and 01:49:28 to 01:50:03 2024-01-25-08-25-GivEnergy_Debug.log (the timeframes of the spikes)

This also shows as massive spikes in a number of other sensors and the daily cumulative/totals

[andynash]

I've now had time to check the write actions, and can also confirm those I have tested (forcing a charge, forcing an export, returning to auto/dynamic/eco mode) work fine 👍

I'm assuming for now that they all do.

Stability is indeed still a significant issue, so I will also try setting up an automation to Reload periodically if the integration has been unavailable for a while.

I'll look out for the peaks mentioned above too.

Happy to help test anything to help with that - pretty busy at the moment though I'll do my best!

[cdpuk]

v2.0.0-alpha5 is now ready for testing. This completely clears up the stability issues for me - keen to hear whether this works for other too.

The spikes may be due to the fact I removed some error checking code that attempts to identify improbable values. Do other entities also report garbage at exactly the same time? The checks used to look for things like:

• Inverter temperature == 0
• Battery temperature == 0
• Inverter total output < 0

It would be simple enough to reinstate such checks. I'll try to run mine for a bit longer to capture some data.

[comm]

Great news, I will install now and let you know how it goes.

And yes, multiple givenergy_local entities report garbage/spikes at the same time - suggest the error checking is needed, but I'll report back tomorrow to confirm still an issue in alpha5.

[comm]

Quick report on first 8 hours, still poor stability, sorry it's not quite going to plan:

1. Initial warnings on boot: 2024-01-26 06:04:31.513 WARNING (MainThread) [py.warnings] /config/custom_components/givenergy_local/switch.py:69: RuntimeWarning: coroutine 'GivEnergyUpdateCoordinator.execute' was never awaited 2024-01-26 06:04:31.695 WARNING (MainThread) [py.warnings] /config/custom_components/givenergy_local/switch.py:103: RuntimeWarning: coroutine 'GivEnergyUpdateCoordinator.execute' was never awaited 2024-01-26 06:05:31.119 WARNING (MainThread) [py.warnings] /config/custom_components/givenergy_local/switch.py:65: RuntimeWarning: coroutine 'GivEnergyUpdateCoordinator.execute' was never awaited
2. None of the switches are working - coinciding with a fresh log entry as above: 2024-01-26 06:45:47.991 WARNING (MainThread) [py.warnings] /config/custom_components/givenergy_local/switch.py:137: RuntimeWarning: coroutine 'GivEnergyUpdateCoordinator.execute' was never awaited
3. Changing variables (charge/discharge rate etc) appears to work - although the exact figure does "stick". If I put 2000, it returns 1999, if I put 1800, it returns 1714, 1000 returns 952...
4. Attempting to change variables and toggle switches occasionally causes things to become unavailable, but return within 10 seconds
5. A number of deprecated unit types are used (POWER_WATT, ELECTRIC_POTENTIAL_VOLT, ENERGY_KILO_WATT_HOUR, FREQUENCY_HERTZ, TEMP_CELCIUS) will be removed from HA in 2025.1 - I will raise another ticket for these as it's not critical to the modbus issue.

Hopefully easy to identify!

[andynash]

I can also confirm that stability is still poor, I'm afraid I am super-busy and will be for at least the next week, so cannot spare time to dig into logs etc, sorry!

[cdpuk]

Another day, another attempt: v2.0.0-alpha6

I'm surprised how unstable alpha5 has been for others, given the difference it made for me, but I've been able to address a few more reliability issues after throwing more abuse at my test instance, e.g. delaying responses, breaking the connection unexpectedly. Perhaps these will help things, but it'll be interesting to see logs from any further stability problems.

On the points from @comm:

1. My bad, missed some awaits. Now fixed.
2. Probably due to the above - should be fine now.
3. This should't have changed as part of this v2.0.0 series. It's a "feature" of the API: the power limits can only be represented by numbers 0-100, and IIRC, only 0-50 is actually used. An increment of this number corresponds to a much larger incremet in terms of watts. When setting the value in HA, the nearest 0-50 value gets picked and converted back for display in the UI.
4. Works for me, which isn't helpful, but let's see whether alpha6 improves anything for you.
5. Fixed on master and ported forward to v2.0.0-alpha6 to cut down on errors/warnings.

[comm]

Thanks for persisting! Stability now appears good, although not perfect (5 disconnects over 8 hours rather than every 10/15 minutes) - see how it goes. Logs for disconnects, FYI: 2024-01-27-18-01-GivEnergy_Debug.log

Other feedback:

1. No worries, things will always slip through when you're trying to solve another issue - glad we could sort them - all gone now.
2. Switches now working again - thanks!
3. My bad, maybe I just didn't notice it before, I don't really use it to be fair.
4. This appears to be fixed.
5. Thanks for the quick implementation!

Still seeing the random spikes in some entities: Logs attached for the 4 events this afternoon. (2024-01-27-17-51-GivEnergy_Debug.log)

Side note: Interesting entity labelling I just noticed though - why is it called "Grid Export Power" when its Positive for Export and Negative for Import? Where is the "Grid Import Power"? Should this not simply be called "Grid Power"? Anyway...

[andynash]

Yes, thanks for getting this up and running again 👍

Stability with alpha6 is much, much better 👏 As at 08.22 today my automation to restart the integration if unavailable for 2.minutes has only been triggered 5 tines since 23:14 last night rather than around every 10 minutes (plus when switches were used).

Regarding spikes, I've only looked at sensor.grid_power so far, but this does spike frequently to the same figure each time: 23,583 W.

![Uploading Screenshot_20240128_082019_Home Assistant.jpg …]()

[cdpuk]

This all sounds fairly promising 😄

I updated my firmware last night, which in the end I think was only a battery firmware update, but everything continues to work smoothly after doing that.

We're past getting the basic comms right, and now just dealing with data quality issues. Missing responses and bad values seem far too common. The ideal solution would be for GivEnergy to spend a bit of effort resolving these in firmware, but I think we've just got to handle those as transparently as possible for now.

v2.0.0-alpha7 is now available, which expands data quality checks to cover the examples seen further up this thread. It will also reattempt any requests that resulted in bad data, up to 3 times. After that you'll still see unavailable entities in HA, though hopefully only for a short period until the next refresh (~10s).

If you're still having to automate reconnections at this point, some logs would be handy (ideally without the automation running) to understand why it gets stuck.

@comm on the Grid Export Power sensor - this is just one of those things where different people have different opinions on how it should work. At the moment it does the simplest thing possible: takes the value straight from the inverter with no transformation and sticks it in a sensor. Some people think it should never go negative, some people would prefer the +/- reversed, some want an import sensor and an export sensor, and some want a combination of all of that. My normal response is that you can do all of that using template sensors, and the integration isn't the right place to be transforming values. Hope that makes sense.

[cdpuk]

One further observation to mention: I've noticed the odd glitch I do get often coincides with something else reading data from the inverter (e.g. 2 HA instances, or perhaps GivTCP running if anyone is trying that). Just thought I'd mention in case that's what's causing a larger number of glitches for others.