GivTCP data Freezing

I have 1.1.7 installed as an add-on. Some time during each night the data freezes - the log says its reading the tags and the entities show live in the list but the data doesnt reflect the portal or the app which is reading data fine in local mode. The only way to unfreeze the data is to uninstall the addon, deleted the config directory and reinstall it - but it then freezes up again after several hours. Anyone any ideas what's happening? Installing docker on my other PI was a nightmare and I don't want to have to go back to that if at all possible.

Do you get any error messages when this occurs? It might be that the connection to the invertor has failed, or some other problem so it continues to publish the last known good data, which makes it appear "stuck".
Also, is it all data, or just some?

For me it freezes if I use the GE app at the same time in local mode. It was doing it regularly, but since I've trialled not useing the GE app for a few days I've had no more sticking data. Must be polling too frequently to cope. May not be your issue, but now I close down the GE app, rather than leaving it running in background after use. The behaviour was very repeatable and I could turn it on/off. Have noticed the occasional issue around midnight, where there appears to be a zero division calculation error (that sticks the data) but usually sorts itself out within 10 mins.

hmm - it started in the middle of the night so dont think it was the app - no errors - user opening and closing in the logs just the data frozen - have bitten the bullet, reformatted my other pi and about to install 2.0 in docker to see how that goes

ok am getting the same with docker but in docker I can see the following erros before the container exited
2022-09-10 14:22:13,006 - GivTCP_Read_1 [ERROR] Error collecting registers: (<class 'KeyError'>, KeyError(HR:013), <traceback object at 0x7fadfeb640>)
2022-09-10 14:22:13,008 - GivTCP_Read_1 [ERROR] Removing lock file due to read error
2022-09-10 14:22:56,263 - givenergy_modbus [ERROR] Did not receive expected response type: ReadHoldingRegistersResponse != ReadInputRegistersResponse
2022-09-10 14:22:56,771 - givenergy_modbus [ERROR] Returned base register (0) does not match that from request (60).
2022-09-10 14:22:57,280 - givenergy_modbus [ERROR] Did not receive expected response type: ReadHoldingRegistersResponse != ReadInputRegistersResponse
2022-09-10 14:22:57,788 - givenergy_modbus [ERROR] Did not receive expected response type: ReadInputRegistersResponse != ReadHoldingRegistersResponse
2022-09-10 14:22:58,296 - givenergy_modbus [ERROR] Did not receive expected response type: ReadInputRegistersResponse != ReadHoldingRegistersResponse
2022-09-10 14:22:58,798 - GivTCP_Read_1 [ERROR] Error collecting registers: (<class 'KeyError'>, KeyError(HR:013), <traceback object at 0x7fadf7ff00>)
2022-09-10 14:22:58,800 - GivTCP_Read_1 [ERROR] Removing lock file due to read error
2022-09-10 14:25:19,306 - givenergy_modbus [ERROR] Returned base register (0) does not match that from request (60).
2022-09-10 14:25:19,831 - GivTCP_Read_1 [ERROR] Error collecting registers: (<class 'KeyError'>, KeyError(IR:110), <traceback object at 0x7fae3914c0>)
2022-09-10 14:25:19,832 - GivTCP_Read_1 [ERROR] Removing lock file due to read error
2022-09-10 14:33:48,798 - givenergy_modbus [ERROR] Did not receive expected response type: ReadHoldingRegistersResponse != ReadInputRegistersResponse
2022-09-10 14:33:50,548 - givenergy_modbus [ERROR] Did not receive expected response type: ReadHoldingRegistersResponse != ReadInputRegistersResponse
2022-09-10 14:33:52,562 - GivTCP_Read_1 [ERROR] Error collecting registers: (<class 'KeyError'>, KeyError(HR:113), <traceback object at 0x7fae13d980>)

Any ideas whats going wrong?

Is this with 1.1.7?

Yes

I had similar. One night just stopped updating.

Stopped the GivTCP instance.
Deleted the 3 cache files in the \config folder.
Restarted GivTCP.
Been fine since

I have the same on 1.1.7. Runs fine until
`2022-09-11 21:52:02,392 - GivTCP_Read_1 [ERROR] Error processing registers: (<class 'KeyError'>, KeyError('BG2112G123'), <traceback object at 0xb5d44da8>)

2022-09-11 21:52:10,024 - GivTCP_Read_1 [ERROR] Error processing registers: (<class 'KeyError'>, KeyError('BG2112G123'), <traceback object at 0xb5b3c408>)

2022-09-11 21:52:26,572 - GivTCP_Read_1 [ERROR] Error processing registers: (<class 'KeyError'>, KeyError('BG2112G123'), <traceback object at 0xb5aae6c8>)

2022-09-11 21:52:43,068 - GivTCP_Read_1 [ERROR] Error processing registers: (<class 'KeyError'>, KeyError('BG2112G123'), <traceback object at 0xb5b3c408>)

2022-09-11 21:52:59,520 - GivTCP_Read_1 [ERROR] Error processing registers: (<class 'KeyError'>, KeyError('BG2112G123'), <traceback object at 0xb5b3c408>)

2022-09-11 21:53:16,060 - GivTCP_Read_1 [ERROR] Error processing registers: (<class 'KeyError'>, KeyError('BG2112G123'), <traceback object at 0xb5d44de8>)
`

I delete the container and rebuild and its fine.

If I knew where the config folder was I'd try that.

dbt85 inside the container it’s at /config/GivTCP and you can delete any “pkl” files.
I Recco mend mapping that folder to a persistent volume, then you don’t have to console inside the container, you can also get easy access to the log files.

I have been having this issue for a few weeks. Sometimes lasts a couple of days before freezing, sometimes a couple of hours.
Only fix I have found is as said to uninstall add-on, delete GivTCP folder and reinstall. This is running on a mini PC running HAos.
Whilst frozen, Giv app and portal are fine. Having the PC reboot at midnight every night doesn't appear to have improved things either.
Simon

@ Simkna do you have more than one battery?

Yes, I do. 2 x 8.2

Interesting. So do I. I'll try it on one of the inverters that only has 1. Mine died again yesterday.

EDIT: So its now been running over 12 hours with no major issues. There are some errors in the log every 4 mins or so about modbus and response type but its working at least. I think those kids of errors have always been there for everyone?

There's a link to the full log since I fired it up in case you want to see.

https://ln5.sync.com/dl/c28c79190/rmpuipw5-cb26ygb4-d545vvfp-eyp577hq

On mine its the second battery that throws it - after anything from a few hours to over 24 hours it refuses to read the second battery. @Britkat is looking into it. The latest dev release (yesterday) has a fix which seems to keep the rest running - might be worth seeing if you see the same - today when mine failed everything kept running but I lost updates on the second battery SOC and a few other variables on the 2nd battery.

I can try running the new dev back on the 2 battery inverter and see what occurs. If I'm honest I don;t think I've ever actually noticed a second SOC but then a whole ton of sensors appear in HA so its likely I've missed it.

There's an SOC that the inverter reports (what you see in the Givenergy app) and then an SOC for each battery.

Just pushed a dev:dev image with a second level fix to the second battery issues. In short it seems that sometimes the invertor doesn't return data for the invertor and the data-smoothing functions gets confused as the data cache doesn't match, so in this instance we now throw away the cache when this happens for 10 consecutive reads. this should then kick it back to life.
Keen for as much feedback as possible.

dev:dev being

image: britkat/giv_tcp-dev:dev

yes?

I've just fired it up and the second battery has gone. It appears if I do a 6345/runall but in HA it's not showing up.

Log file here

Nothing specific in the logs that’s helpful, could you log it at info level and resend the log. It’s odd that the data is there in REST but not showing in HA

Ok so I have run dev:dev it again today using your 2.0 compose template and it seems to be ticking along fine with both batteries. I'm not sure what might have been the issue before with my other template but still using the dev:dev image (apologies, despite having your template in my compose file commented out, I completely forgot about it when fiddling with this yesterday so should have used it then.

Heres the info log in case you want to see it doing its thing
https://ln5.sync.com/dl/f4e033060/bee52hud-tbm3u7ks-zd69tb4v-66h3fx72

I'll give it till tomorrow and then I might see if I can add the other inverters back in and see if it plays ball. Would Info level still be best for any logs of that?

dbt85 Info is best log level if we expect problems