Reporting GivTCP issues?

Anyone point me in the right direction to report issues with GivTCP? I can't see any comment or issues option on the github page. This is for the HA Add on but may also affect the main fork.

Yes, I'm getting issues with 'unknown' values having worked for a day or two.

GitHub doesn't seem to have a location to raise issues.

I have a crash that should be dead easy to fix but I'm not a coder so can't suggest a pull request. At least I think that how it's done if you know what you are doing . . .

Yeah, there's normally an 'issues' tab in github that you can raise things under.

Not sure why it's been switched off for GivTCP...?

To be fair I'm not sure that its 'fully' supported any more - at least by GivEnergy. So it's pobably just one or two hardy volunteers that may not wish to be committed to responding to too many questions/issues/suggestions. I find it very useful and am grateful to anyone that has got it to where it is. My crash only happens every few days and just requires me to create a dummy pk1 file and restart. It would be nice, though, not to have to manually intervene.

GivTCP isn't something that GE have developed, it was @Britkat

Hopefully this has tagged them to have a look, I know they've been working on v2.0 recently

V2.01 is out already. I think as an addon but I use it via node red.

I can't resist trying to help...

I'm not a python coder but am familiar enough with other languages to have a looksee and work a few things out.

I think my issue would be resolved if the following in GivLUT.py:

...
if oldDataCount>10:
#5 error in a row so delete regCache data
logger.critical("10 failed invertor reads in a row so removing regCache to force update...")
os.remove(GivLUT.regcache)
os.remove(GivLUT.batterypkl)
os.remove(GivLUT.oldDataCount)
...

was changed to:

...
if oldDataCount>10:
#5 error in a row so delete regCache data
logger.critical("10 failed invertor reads in a row so removing regCache to force update...")
if exists(GivLUT.regcache):
os.remove(GivLUT.regcache)
os.remove(GivLUT.batterypkl)
os.remove(GivLUT.oldDataCount)
...

As it's a crash from trying to remove the regCache_1.pk1 file when it doesn't exist. Perhaps check if the other two exist as well?

More than happy to be corrected, though. Sorry of I overstepped...

having this issue as well, its reported no values since abut 2pm today

dm0806 Are you using it as an addin? I don't an have no issue, unless I cock something up. Mines been running in a docker with no issues for over 11 days,

anglefire yeah add in on ha running on a Ras Pi, have tried multiple resets but nothing seems to work.

Just for info, I think my issues are that my network link between my house and detached garage is not 100% reliable. So when GivTCP fails to get data from the dongle more than 10 times in a row it tries to sort itself out by effectively restarting. This triggers the attampt to remove the non existant regCache_1.pk1 file.

I get it every couple of days or so and I simply manually create the file (using terminal in HA) and then manually restart GivTCP through settings | Add-ons | GivTCP | Restart

Hence my stab at the code change required to mitigiate this issue.

Mark has gone quiet on this recently, wonder if he is busy with his real job.

Ok, lets try another tack, then. Python is interpretive so I may be able to just add my edit to the installed file.

I'm using the HA Add-on and I'm not a linux fan (at least from an administrative point of view that is - too much gobbledegook only meaningful to the super clever).

Anyone point me to where I would find the python file GivLUT.py on the HA os installed Raspberry PI? If I can find it I'll maybe give it a go and report back.

Not sure if the pi runs the app in a container. On the docker container it's in /app/GivTCP

chickengeorge I run GivTCP in a docker container in a separate vm to Ha. I’ve run it that way as it wasn’t available as an addon initially.

I’ve got mqtt turned on but don’t currently use that data in ha, but use nodered to get the data. Mostly because my names don’t match the ones that will come out of mqtt so will mess up my historical data 🤣

Does anyone have any pointers for automating GivTCP to restart if it goes into an error state?

ispookie666 I've just been playing with node red, you can watch the lastUpdate.pkl file to see if it doesn't update after a set time, you can restart the GivTCP add-on.

Although the only way i've tested this is to manually stop it.

ispookie666 My container Restart policy is set to "Unless stopped", which I presume means it automatically restarts on error, unless stopped (manually).

Apologies should have been clear. I'm running GivTCP in Home Assistant, in Oracle VM Virtual Box. A lot of this is above my head!
I have a sort of work around. I'm using the change in SOC(from Victron) as trigger, then added a condition for "last update time" with time stamp of 5 min. This followed by actions involving stopping and starting Giv TCP.

All this is still an automation in beta phase. I have a feeling, I have done this the long way.

ispookie666 Seems to me that the Addon way is not as good as running a separate docker - mine has run for weeks in the past with no issues - I only restarted it on Friday night because I wanted to experiment with MQTT into HA so turned on the autofind function (Which worked stunningly well - as Paul Hibbert irritatingly says "It just works" )

anglefire I've ran it in both and they perform about the same for me, so I'd rather have it in HA, I get the same class Key Errors in both.

ispookie666 It looks like you're doing the same thing I am but natively in HA. You can run Node-RED as an add-on. You can throw some node's on a page and can make some really good automations. I don't use the HA automations, I create a new 'flow' for each area/integration. There are some really good guides on youtube.

dm0806

Hi, I'm getting similar issues to you also, it can work for a bit but then stops working after a while.

I've found using using the older v1.1.7 docker container instead of v2.x is more stable for me.

However even on v1.1.7 I've found it can stop working, even after restarting the docker container.

If I use the 'recreate' option in portainer, it seems to fix things and it works well for a while.

@Britkat

Is there a way we can allow the SoC and voltage values to adjust in jumps? With the new self calibrating Battery firmware, the battery SoC can jump 10% in one go, if its found to be wrong when checked at Idle. However its not shown, as the filter gets rid of it. Needing a restart of GivTCP
Previously it was to stops the odd 0 value results. But is also filtering put genuine jumps.
Eg One of my batteries, 6,6,6,26,26,26,25,24,23. The 6 to 26 jump on self calibrate was lost. needed reboot to show