I wanted to announce a new custom integration for GivEnergy inverters, now available as a custom repository via HACS.
Last week I had a GivEnergy Hybrid inverter installed on my property. I’d already clocked the other thread on here, and while there seems to have been some success, I didn’t like the idea of having to use various additional components (MQTT, Node Red, giv_tcp, etc) to get this working.
Anyway, I had a bit of free time, and thought I’d take the opportunity to learn how to write a custom component. I’m using the same givenergy-modbus library to provide the underlying comms, but all wrapped up in a nice simple package. Just install via HACS and drop in your inverter address via config page.
The inverter provides dozens of possible sensors; I’ve exposed the ones that have been of most value to me, but happy to take feature requests for additions.
One major gap is battery compatibility. Due to global supply issues, my battery has not been fitted yet. Rather than blindly guess what a working battery looks like, the integration does not currently provide any battery sensors. I’ll get these added as soon as the battery arrives.
I also plan to add support for setting the charge/discharge configuration, probably via services. The dream is to be able to write automations that make clever use of half-hourly export pricing.
I have the Hybrid 5 Gen2 and a 5.2 battery and I’ve been looking forward to someone doing an integration for these. So many thanks for this.
I’ve installed the integration and put in what my router shows as the IP address for the wifi of the inverter. No devices show up. Am I right is thinking this is the correct IP address?
That’s right. Having just tested it again, it seems the library I’m using to connect to the inverter behaves differently when it gets a Connection Refused response - and behaves as if everything is fine! Might have to do more work to validate the connection properly.
Could you try restarting HA? I once loaded the integration and had to restart to get the devices and entities to show up. I put that down as a one off glitch, but perhaps there’s more to it.
The HA log almost certainly has something in it - have a look around the time of the attempted connection.
And of course perhaps the Gen 2 works differently.
Logger: homeassistant.components.sensor
Source: custom_components/givenergy_local/sensor.py:219
Integration: Sensor (documentation, issues)
First occurred: 22:17:36 (1 occurrences)
Last logged: 22:17:36
Error while setting up givenergy_local platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/givenergy_local/sensor.py", line 192, in async_setup_entry
PVEnergyTodaySensor(
File "/config/custom_components/givenergy_local/sensor.py", line 219, in __init__
self._attr_unique_id = f"{self.coordinator.data.inverter.inverter_serial_number}_{entity_description.key}"
File "/usr/local/lib/python3.9/site-packages/givenergy_modbus/model/plant.py", line 32, in inverter
return Inverter.from_orm(self.inverter_rc)
File "/usr/local/lib/python3.9/site-packages/pydantic/main.py", line 562, in from_orm
values, fields_set, validation_error = validate_model(cls, obj)
File "/usr/local/lib/python3.9/site-packages/pydantic/main.py", line 1048, in validate_model
values = validator(cls_, values)
File "/usr/local/lib/python3.9/site-packages/givenergy_modbus/model/inverter.py", line 212, in compute_model
values['inverter_model'] = Model.from_serial_number(values['inverter_serial_number'])
File "/usr/local/lib/python3.9/site-packages/givenergy_modbus/model/inverter.py", line 39, in from_serial_number
raise UnknownModelError(f"Cannot determine model number from serial number {serial_number}")
givenergy_modbus.model.inverter.UnknownModelError: Cannot determine model number from serial number
I’ve just written a tool that might help. Some basic command-line and Python needed to run it - let us know if anything is unclear.
I’m expecting the script to crash out with a similar error to above, but before that it should print out a load of low-level data that can be used to investigate further. It should look like:
I too have just had a GivEnergy system installed and am keen to be able to monitor all the parameters for HA. This looks to be ideal so many thanks @cdpuk for the work put in
The GivEnergy Local Repository has downloaded & is showing in HACS and in Configuration/Integrations/+ Add Integration, however setup throws up the following:-
Sounds different to the unknown serial number issue above (we’re working on that in the background for anyone interested).
Could you repeat adding the integration and grab the relevant section of the HA logs after that? Hopefully it can shed some light on what exactly is “undefined”
This is excellent - I have the NodeRed API version running but was struggling to get docker/GivTCP working. Will you be adding battery functions soon? Am very happy to test anything on my setup if you dont have your battery yet as my goal is to set battery charge % in my Octopus Go window based on next days solar forecast.
Thanks for doing the intergartion.
I’ve got it installed and working.
Is there any chance that you could prefix all the entities that is creates with something so that they are all grouped together and are easily identifiable?
Maybe something like “givenergy_local”
Geting this in the HA log:
Logger: homeassistant.components.sensor.recorder
Source: components/sensor/recorder.py:332
Integration: Sensor (documentation, issues)
First occurred: 18:35:10 (1 occurrences)
Last logged: 18:35:10
Entity sensor.consumption_today from integration givenergy_local has state class total_increasing, but its state is negative. Triggered by state -16.7 with last_updated set to 2022-04-23T17:30:22.140234+00:00. Please report it to the custom component author.
My battery is about a month away still. However since originally publishing I’ve received some sample battery data that would be enough to have a go. If I can find some time, I’ll give it a try.
Likewise I’m also hoping to make clever use of the battery based on forecasting and also the Octopus Agile Outgoing rates. Side note on that: There is another integration out there for Octopus Agile but it didn’t handle outgoing, so I made another for that purpose, though it’s not been published anywhere yet.
I did consider that exact point about entity name prefixes when making this. When taking a look at the core integrations I didn’t see a consistent approach with/without prefixes to decided not to. Personally I wanted to avoid long entity names, and figured if you need to see a grouping, you can do so via the Configuration pags. I’d be curious to hear what others think on this.
The consumption_today error is interesting. This should reflect your consumption value as seen in the GivEnergy portal. Clearly it should never be negative, but -16.7 sounds like a number with a different meaning. Here’s a week of my sensor data for reference - how does yours compare?
I’ve only just installed it today, so will give it a few days to see what happens
I’m also running GivTCP modbus, so I can compare it with that.
Thanks
Thanks for your reply @cdpuk.
Just to update. Today I went back and tried again and it has worked without any error messages.
Thanks again for your work on this
The poll time for things like power consumption seems to be around every 1-2 minutes. Is that correct? One of the nice things about local (through givtcp as an example and the GE app) is an update every few seconds. Could there be an option for poll rate?
Looks like its currently set to update every 60 seconds. (See custom_components/givenergy_local/__init__.py
class GivEnergyUpdateCoordinator(DataUpdateCoordinator[Plant]):
"""Update coordinator that enables efficient batched updates to all entities associated with an inverter."""
def __init__(self, hass: HomeAssistant, connection: GivEnergy) -> None:
"""Initialize my coordinator."""
super().__init__(
hass,
LOGGER,
name="Inverter",
update_interval=timedelta(seconds=60),
)
I’ve changed that last line in mine to be 5 seconds and it seems to be working fine, but I’d agree a config option to change the poll rate would be a great addition.
Thinking about it, its only the instantaneous power readings that need quick updates.
I’d personally be happy for the total usage values to only be updated every few minutes (or potentially less), but have the instantaneous ones updated every few seconds.
