I've just noticed some errors in my GivTCP logs, could anyone advise what might be wrong please?
client.subscribe(MQTT_Topic+"/control/"+GiV_Settings.serial_number+"/#")
AttributeError: type object 'GiV_Settings' has no attribute 'serial_number'
2024-06-15 09:00:55,430 - Inv1 - read - [ERROR ] - 10 failed inverter reads in a row so removing regCache to force update...
2024-06-15 09:03:46,895 - Inv1 - read - [ERROR ] - 10 failed inverter reads in a row so removing regCache to force update...
2024-06-15 09:06:47,287 - Inv1 - read - [ERROR ] - 10 failed inverter reads in a row so removing regCache to force update...
G
#2geoffreycoan
J1m On your other thread you mention that you have a Gen 1 inverter which is the same as I have.
I have seen this problem before myself, sometimes it starts appearing when GivTCP has been running fine for months. I’ve logged it as an error on GivTCP before now.
If you keep seeing the errors then this something that needs to be addressed, its basically GivTCP saying that it can’t read from your inverter, and that the Home Assistant entities for the inverter will either be stale (contain old data) or empty.
When this first happened to me I found that the only fix was to revert the GivTCP add-on to an older version. This however is only an option if you have a backup from an old version as there’s no way in HA to install a specific add-on version.
More recently I found another fix which was to do a ‘reset to defaults’ of the inverter in the GivEnergy portal. You might need to manually force a read of all the inverter settings in the portal before you do this to ensure the reset fully works. I think it is caused by a corruption/confusion in the inverter as to what its settings are. It can work perfectly normally but GivTCP comes up with the serial number error, basically saying that it can’t read the inverter serial number information. Resetting to default settings cured the problem for me
J
#3J1m
geoffreycoan
Thanks very much for that advice. I will have a try at restoring to defaults as you suggest. I do wonder if this also has something to do with my timed discharge issues as per the other thread.
Thanks again..
J
#4J1m
geoffreycoan
I'm assuming it's settings/reset to default on the inverter portal? I did the 'read all registers first' a few times but it kept coming up with an error - Reading DC Discharge 1 Lower SOC % Limit failed with message Inverter Timeout Please try again.. After the reset to defaults I'm still getting the same GivTCP errors unfortunately even after restarting GivTCP
G
#5geoffreycoan
Reset to defaults fixed it for me.
Another idea, and try this first, delete the PKL files from /config/GivTCP. I think these are cache files that GivTCP uses. This was raised as a fix to the github ticket I raised about 2.4.3 not working on gen 1 https://github.com/britkat1980/giv_tcp/issues/153
Final idea: try installing the beta version of the GivTCP add-on. You need to add https://github.com/britkat1980/ha-addons to the add-on store 'custom repositories' list.
See this Github ticket https://github.com/britkat1980/giv_tcp/issues/145 which was when the issue was first raised, fixed in 2.4.2 and was then recently experiencing the issue on an AIO. Fix was to install the beta
J
#6J1m
geoffreycoan
I tried deleting the PKL files (there were three) but no difference.
Regarding installing the Beta version of GivTCP, do I need to uninstall the original version first, or would it install over the top without the need to reconfigure?
I've added the repository and found it (I think) in the GivTCP Test section, version 2.4.324 is that correct please? (Not installed it yet).
Incidentally, those PKL files haven't been recreated yet...
D
#7DD
J1m Reading DC Discharge 1 Lower SOC % Limit failed with message Inverter Timeout
I don't think gen-1 has that register, and modbus simply doesn't respond when you try to read a non-existent register (which would manifest as a timeout).
Gen-1 doesn't implement CRC, which can lead to register corruption. Maybe that's why reset-to-defaults helps?
S
#8SteveCook
What is CRC?
Mine stopped working when I read about this a few months back and I seem to remember reinstalling GivTCP and it all worked again. Dont take that as gospel as I just tried things and dont really know what I was doing
EDIT just read all about CRC on Wiki, but not sure how it applies to my inverter
D
#9DD
SteveCook CRC (cyclic redundancy check) is a method of detecting transmission errors in a protocol. Parity is a very simple example for a serial port. You construct the message you want to send, then compute some function of the bytes. (Simple sum, for example.) Then append that to the message. THe recipient does the same computation, and if the answer is different from the one in the message, something has been corrupted.
GE have recently enabled CRC checks in the modbus comms, so it can detect if a request to change a register got mangled during transmission, and so reject the request. This broke the GivTCP, which is why you had to reinstall to get a version that calculated the CRC correctly.
But gen-1 doesn't do the crc check, and so doesn't detect if a request got corrupted in transmission.
G
#10geoffreycoan
J1m Regarding installing the Beta version of GivTCP, do I need to uninstall the original version first, or would it install over the top without the need to reconfigure?
I've added the repository and found it (I think) in the GivTCP Test section, version 2.4.324 is that correct please? (Not installed it yet).
I assume you restarted GivTCP after deleting the PKL files?
You should be OK to install the GivTCP-beta alongside your existing GivTCP, just don't have both add-ons running at the same time. The GivTCP test repository has 3 different test versions of GivTCP, I believe the beta one is the more stable. You will obviously need to configure it for your inverter IP etc
CRC is Cyclic Redundancy Check. Its basically error checking that no data has been lost in transmission. The Gen 1 inverters didn't have CRC whereas the Gen 2, 3 and AIO do, which is why you have to set the 'old firmware' switch in GivTCP for Gen 1's, If you are on the beta version of the Gen 1 firmware (191/193) then it does have CRC
S
#11SteveCook
geoffreycoan CRC is Cyclic Redundancy Check. Its basically error checking that no data has been lost in transmission. The Gen 1 inverters didn't have CRC whereas the Gen 2, 3 and AIO do, which is why you have to set the 'old firmware' switch in GivTCP for Gen 1's, If you are on the beta version of the Gen 1 firmware (191/193) then it does have CRC
so if i get the supposed new firmware (191/193) soon, will it kill my system?
G
#12geoffreycoan
SteveCook so if i get the supposed new firmware (191/193) soon, will it kill my system?
I installed the Beta version as you suggested Geoffrey. I left solar and tariff settings disabled and only had to input the inverter ip address. The log showed no serial no. error, the only error showing was '2:3/ReadHoldingRegistersResponse(slave_address=0x31 base_register=360) after 4 tries at 3s, giving up'...and I've no idea if that is anything important!
The best thing was that I let my discharge/export automation (as per my other post) run to conclusion and lo and behold the battery wasn't in pause mode when it completed!
Thank you sincerely Geoffrey for your help and suggestions! I'm just wondering now whether I should try reinstalling the original GivTCP or stick with the Beta version?
While posting this could I please ask another question, relating to Predbat (re the other thread, rather than starting a new one)? I installed Predbat (via the Predbat add-on option) and have it running okay, but can't find the folder 'addon_configs/6adb4f0d_predbat'. I can't get my head around how to use file editor in HA so have installed Studio Code Server as at least it has an 'Explorer' like Windows and you can see the file/folder structure. But I can only see the root folders Config, Outline, Timeline and MDI, and if I do a search for Predbat or apps.yaml nothing is found. Could I trouble you for some more advice please?
D
#16DD
J1m '2:3/ReadHoldingRegistersResponse(slave_address=0x31 base_register=360) after 4 tries at 3s, giving up'...and I've no idea if that is anything important!
ReadHoldingRegisters is the modbus protocol message to read configuration registers. It tried 4 times, retrying every 3 seconds, but got no response.
Registers have been added incrementally over firmware releases. 360 is quite high, and possibly doesn't exist on gen-1. For example the discharge limits, relatively new features, are probably up in that vicinity.
Is this during startup?
G
#17geoffreycoan
J1m I can't advise about the ReadHoldingRegistersResponse error, I'm not using the Beta, sorry. If it is otherwise working fine then I'd suggest you stick to the Beta.
For interest though, it might be worth shutting the Beta down and restarting the original GivTCP (assuming you have it installed still) and see if it now works. Would be useful info for others that have experienced the random serial number error.
r/e predbat folders. The folder you need is actually /addon_configs/6adb4f0d_predbat - the leading slash is significant as it means start from the root directory.
File editor works OK but you must make sure you turn off 'enforce basepath'.
Personally I use Studio code server all the time. I think your problem is that you are only seeing the files in the /config directory, you need to tell it to look in the whole file system
Actually, I can't see a definition for any registers up in the vicinity of 360. I can see some code that mentions register 360, but that's basically just the startup code that probes the inverter to see what registers are available. In which case you can probably ignore it.
As you suggested Geoffrey I tried shutting down the Beta version today and re-running the original GivTCP. The same serial number errors immediately came back so I've gone back to the Beta!
J
#22J1m
J1m
Since I changed to GivTCP beta I had an issue where despite the timed battery charge being set around 50% the batteries charged to 100% on Saturday and Sunday night. I emailed GivEnergy support yesterday and they replied that they had 'reset my batteries', and to see if it fixed it last night. Last night the batteries didn't charge at all! GivEnergy support are now suggesting that it's a firmware issue 'that's being investigated' (the batteries are still charging from solar).
Is there any possibility Geoffrey that GivTCP is somehow causing this? It just seems strange that I've had no issues at all with overnight battery charging previously!
D
#23DD
J1m Since I changed to GivTCP beta I had an issue where despite the timed battery charge being set around 50% the batteries charged to 100% on Saturday and Sunday night.
I don't know anything about GivTCP, but one thing I encountered when playing with api scripts to control charging: there are two different registers that configure the charge limit. (Depending on which version of the inverter you have.)
In the API list, there's
77 AC Charge Upper % Limit : Value must be between 0 and 100
83 Restart Inverter : Value can only be 100
96 Pause Battery : Value must be one of: 0, 1, 2, 3 (Not Paused, Pause Charge, Pause Discharge, Pause Charge & Discharge)
101 AC Charge 1 Upper SOC % Limit : Value must be between 0 and 100
According to my notes, the app/portal set #77, but my gen-3 inverter actually uses #101. So my script copies the value from #77 to #101 (since it's convenient to use the app).
