Givenergy Local Control & Warranty

So this is a bit of a long read but is basically born from this post:

I've seen this banded about quite a bit BUT nothing officially from Givenergy what is approved (sorry @TheDragon (GivEnergy) I mean no malice in all this) but posts like this do add confusion & also risk stifling a growing community of apps & customizers before they start.

I want to be clear, at no point am I aware of anyone's system being damaged by any local control method to date at all

So why should I care? Well you may care about your warranty not being risked by the usage of certain new apps & tools coming out thick and fast now, so I think that does deserve some clarifications as -
1: how true this is?
2: what is/isn't approved for use (& how a mere mortal is to know)
3: If something goes wrong using an "approved" local control that GE would stand by it for warranty claims.
3: how you go about being approved and what is flat out a no no.

Full disclosure - I have little skin in the game beyond "being around" for the creation of GiVTCP and generally just being part of the group shaping/iterating it (risking my inverter I guess being about it, I don't think I've written a single line of code for it), re-testing it and so on.
I'm also under an NDA for that so the following is the best I can do to explain local control's history without breaking it. Please bear with me.

Some history - the most common local controller is GivTCP so lets start there.
This started as a community project with "some" input from GE to get it off the ground (hence why there's both a BritKat GivTCP repo & a Givenergy GivTCP on Github.)
It has been tirelessly updated by it's author (excellent work not detracting that AT ALL) HOWEVER this is technically still a community based code not written or "owned" by GE. So who's really liable should it do something it shouldn't?
To confuse matters, originally it talked direct to the inverter over modbus itself entirely, over time, more community developers came aboard and update speed was chosen as a key area to improve. So another user created another library called Givenergy Modbus. This made the update cycle far more robust and so it was adopted into givTCP and the older code retired. You can see this in the "requirements" files for GivTCP which links back to this modbus library (just so i'm not breaking NDA)
Still following? Great..

So hear in lies the crux of the issue - if GivTCP is "approved" (which I assume it is but is not officially documented as such although this post seems to contradict that with "As GivTCP is third party and not supported by GivEnergy..."

• then where is the line in the sand?

Underneath GivTCP it runs Givenergy Modbus - which is a far more powerful (read dangerous) tool if used incorrectly. Is that approved too? It comes with this warning:

Other libraries that now link to the Givenergy Modbus Library and bypass GivTCP such as CDPUK's Givenergy Local for Home Assistant direct integration - where do they stand in the order of things?

Going further, if you dig enough, Givenergy Modbus lists out what all the registers are for anyway. So now the genie is out the bottle with that. If you try hard enough (& your German is good enough) somebody leaked the entire modbus document for the inverters on a Smart Home forum way back in August 2020 so again, those determined enough have all the tools available should they wish. (For clarity this wasn't me, I hadn't even ordered the system then!)

I'm not entirely sure how to get around all this. At the time, the community method made sense as GE had enough on their plate. Now, if things are to be approved, I can't see a way out of this beyond GE taking it all back in house (and perhaps chucking the original GE Modbus & GivTCP authors a free battery or something for their efforts) and they can then "own" the problem. Anything not using their library & something goes wrong - your on your own.
The alternative being code has to be sent for review by GE which I think is going to be far to onerous on everyone.
This makes a bit more sense as more and more products get added to the stack something will need to give - the AIO for example - may or may not work the same as the other kit, is the author of GivTCP willing to support that if he doesn't have/get one?

None of this is something that can be solved overnight, but it is a complex problem that does need addressing one way or another - and some thought by GE.

Leigh

Just to add to this Leigh, again not pushing the bounds of our NDA.
The exposed library register list, was at that time. since then registers can and have changed use, moved or new ones added. The new beta FW for sure will use a few new ones.

So I hope, the underlying library is getting some TLC, I know the author of GivTCP is in liaison with GivEnergy, hence this has a blessing as ok for use (Despite being 3rd party). He likely has new register data and updates the underlying library.

But agree, it is a minefield, and it would be good to get a final definitive answer, what is and what isnt allowed.

My determination of reading is ok, and writing isnt, is purely based on liklyhood of incorrectly writing to the "BoomTime" register.
No write, no BOOM.

Just to be clear, I can confirm that the app I have published on the Google play store is a READ ONLY monitor. It has NO capability to change settings on the inverter.

My app does NOT use the GE modbus library nor any parts of the GivTCP code.

I am aware that there is documentation of the registers in the wild but that wasn't how this app came about. Initially I used the tPacketCapture android app to capture the packets from the official GivEnergy app. I observed that it repeatedly sent the same packet and received a 164 byte reply that varied. Then I wrote a java program to send that same packet and record the response. I converted the reply into a list of 60 16-bit integers and displayed them in my program. I ran the program 5 times at different times of day and transferred the information into a spreadsheet (5 columns of 60 rows). It was then quite easy to figure out which ones were changing and what values they related to.

Since then the only change I have made in the transmitted packet is the "slave address". I am using 48 (hex 30) for the slave address. Because that value is echoed by the inverter, it means my app can distinguish my packets from those of the official app. My app only transmits one packet each cycle and the content is fixed. The connection is set up and torn down each cycle to minimise the modbus overheads and remove the obligation for the inverter to copy every packet requested by all other slaves.

The general format of the modbus tcp packet is documented on wikipedia and elsewhere. The inverter uses the GivEnergy version of the Chinese version of the Schneider version of the Modicon version of the modbus protocol, but it isn't too hard to figure it out.