GivTcp vs GivEnergy Local

For those users that have Home Assistant I'm wondering what, if any, are the pros and cons of using GivEnergy Local versus GivTcp in terms of functionality, reliability or user experience?

Rahul I use neither. I think perhaps predbat requires GivTCP, but I don't know that for sure. (Predbat is quite popular on here - even if you don't need it now, might be worth keeping the option open ?)

They both use an underlying modbus access library. Unfortunately, use of that has fragmented rather badly, and now both projects have their own copy. The GivTCP people probably have closer links to GE, and have better access to information about registers. GivTCP was the first to get support for a recent change (addition of CRCs).

A few of us are currently working to try to get the modbus bit separated out and maintained independently, so that it can be shared (or just used standalone, which is where my interests lie).

Agree with the comments from @DD. GivEnergy Local is I believe simpler to use, with more straight forward commands to start discharging, charging, etc, whereas GivTCP is closer to the native inverter controls so if you are writing your own scripts you may have to set a few controls to get the required activity, but once you have those scripts done (or borrow someone else’s), its easy enough to use.

GivEnergy Local hadn’t been updated for the newer firmware (gen 2+) that includes CRC and as DD says, it had fallen behind GivTCP so you could only use it on the older Gen 1 inverters. I think this may be resolved.

Predbat does work with GivTCP, it can use the GivEnergy cloud connection as an alternative. Not heard that anyone has used GivEnergy local with Predbat. GivTCP includes support for the GivEnergy EV charger and 3-phase inverters is in development.

I started with GivTCP because that’s what Oli “speak to the geek” recommended in his video. It works fine for me and is in active development.

geoffreycoan GivEnergy Local hadn’t been updated for the newer firmware (gen 2+) that includes CRC and as DD says, it had fallen behind GivTCP so you could only use it on the older Gen 1 inverters. I think this may be resolved.

Yes, they merged in a newer copy of the modbus library and added CRC support.

GivTCP is an add-on, so probably tricky to install if you're not running HA OS. (I'm running HAOS on an RPi with GivTCP)

As an aside, the need for another CRC on data that's already has checksums at both the Wifi frame and TCP frame level is a pretty good indication that something is inherently broken with the protocol 🙁

rjp As an aside, the need for another CRC on data that's already has checksums at both the Wifi frame and TCP frame level is a pretty good indication that something is inherently broken with the protocol

Not entirely - it's TCP as far as the dongle, but then I believe it has to go over a serial link to speak to the actual inverter firmware. But arguably they could have added the CRC for just that step, rather than requiring end-to-end CRC.

DD You're right, the serial link is where things go wrong 🙂
I suspect the system was never designed to work with more than one incoming connection at a time (the portal). As soon as you use the app 'home' mode or GivTCP, stuff starts getting flaky.

The serial link itself really shouldn't be an issue. I've worked on endless RS232/422 systems since the 80's and actual comms errors over a short internal link like that are effectively zero.

DD I think GivTCP is the only one to get support from GE. I don't seem to have much joy lately! Albeit I've not had the time lately to do anything I am starting to think we may just be stuck following GivTCP register lists as they come out.