Interface Control Document for Inverter Modbus/GivTCP?

9 comments started 2023-11-09 last 2023-11-10
Home AutomationHome Assistant
R
#1 Ryggwelter

Hi,
Big appreciation to @Britkat, @hoggy and others in the community for their work and sharing their knowledge 👏

Now that the wet days are here, I've been able to play with my RPi and have Home Assistant up and running in Docker along with GivTCP, MQTT broker, Nginx etc.

I'm building my first dashboard and so am looking for documentation (ICD) describing what each of the control parameters do? Most are self explanatory but, for example, what does GivTCP Force Charge normal/running/cancel/2/15/30 etc do?
Have GivEnergy published anything? I've had a Google and a look in github etc but haven't found anything yet.
Thanks

#2 hoggy

Ryggwelter so the actual repo is here: https://github.com/britkat1980/giv_tcp
It has some of the detail but misses some parts along the way, although I see the EV charger has made it & you can glean a few other bits from the changelog:
https://github.com/britkat1980/giv_tcp/releases

It's community (britkat) driven so although Givenergy promote/support it, it's not actually theirs so the documentation aspect relies on either 'us' as a community writing it OR takes time away from coding for Britkat to write it.

Your specific query on Force charge - selecting 2/15/30 is how long in mins you want to it to force charge for. (Normal, running denote current state, Cancel stops the force charge and reverts to previous state)

R
#3 Ryggwelter

Hi @hoggy,
Thanks for your reply.
Yes - quite understand :-) Sorry I badly phrased the question. I was wondering if GivEnergy had documented the underlying Modbus parameter set which GivTCP is passing up?
Thanks for the info on Force Charge - I'll have a look at the code to better appreciate what functions, such as the timeout, the inverter is handling and which GivTCP is providing. (another winter project - learn Python - lol)

A
#4 anglefire

Ryggwelter the modbus commands and registers are a reasonably closely guarded secret of GE - based on the idea that incorrect setting of registers can cock it up so.
So you either use the published api calls or givTCP to control the system which does the necessary calls in modbus - sometimes to multiple registers in the correct order to carry out the required function.

But I do agree it would be nice to have a better understanding of what does what and what you need to do - as even with givTCP or the api calls, you sometimes have to do two things to get the system to do what you want. Such as set the discharge time and to then enable it.

A
#6 anglefire

naltsta hoggy’s pages are a wealth of information. I’ve posted some stuff on there in the past but may be out of date now. Really should have a look and update it.

#7 hoggy

anglefire

anglefire hoggy’s pages are a wealth of information

Wealth of (out of date) information. With the release of various new products & firmwares (sometimes FW even in the same inverter generation) that appear to either work slightly differently & sometimes the complete opposite it never really got off the ground.
It's very hard to write a page on something when you don't have it (coming from someone who is running first batch of Gen1 gear I've seen none of the newer features at all to ve able to write about them (which is sometimes a blessing in disguise as likewise I've never seen a show stopping bug either - looking at you SOC bug, Pause isn't Pause bug, 500V+ PV bug...)

And horror of horrors, I've actually switched to (my own fork) of Givenergy Local as opposed to GivTCP as it seemed to be getting a bit unwieldy with various bolt on bits I don't need. (I dont need MQTT, nor solar forecast, don't have the EV charger...)

#8 hoggy

Ryggwelter so GivTCP and others (like Givenergy Local) sit on top of another library that actually does the interfacing with the inverters themselves. This equally is community written.
The library is called 'Givenergy Modbus' but as things have evolved the need arose for Britkat to fork it so the version that GivTCP uses is now in the GivTCP repo.
Original Version: https://github.com/dewet22/givenergy-modbus
Britkat Version (updated for Gen3, AIO and EV charger registers)
https://github.com/britkat1980/giv_tcp/tree/main/givenergy_modbus

If you are that invested the actual registers it is interfacing with can be found in the code if you dig around as they are mapped to 'friendly names'
The actual FUNCTIONS (like what friendly names (underlying registers) it steps through to say 'set timed AC charge) can be found in Client.py:
https://github.com/britkat1980/giv_tcp/blob/main/givenergy_modbus/client.py

Obviously that means wider reaching compatibility with pretty much the entire Givenergy product range is achieved through GivTCP using his updated modbus library, whereas the likes of Givenergy Local are stuck on the original library that only really covers firmware and products upto about Gen 2.

R
#9 Ryggwelter

hoggy
Many thanks - that helps demystify the various repos. Thanks for the pointer too to Client.py :-)