Just for “fun” I spun the exact same compose file up on my Rpi4 and behaviour was identical unfortunately.
Sorry - have to reply here because I hit a limit…
No problem at all - I saw new dev and test versions earlier today but figured best to let you let me know when it was ready to try again. I’m over the moon to report that after a key error message, an F5 in the browser brought back all the values (I think).
This is what I get in the browser when it fails:
{“result”: “Error collecting registers: (, KeyError(HR:120), )”}
This is an example from the log:
[2022-02-25 18:41:56 +0000] [12] [INFO] Booting worker with pid: 12
ERROR:givenergy_modbus:Did not receive expected response type: ReadHoldingRegistersResponse != ReadInputRegistersResponse
ERROR:GivTCP:Error collecting registers: (<class ‘KeyError’>, KeyError(IR:183), <traceback object at 0x7f99b39e5900>)
ERROR:givenergy_modbus:Returned base register (60) does not match that from request (120).
Seems to happen occasionally but it’s looking very good now, thank you so much!
Tomorrow with a clear head I will try and get it into HA so I can start to make real use of it.
Sorry for delay, didn’t get notification of reply. I have a new “test” version on dockerhub which should fix this. Can you try it for me and then I can push to “latest” if it resolves the issue
James, there isn’t currently a simpler way than running the docker container… There is a custom_component in the works by others but it’s not yet available.
I’m working on the next version of the GivTCP which works with MQTT to integrate nicely with HA. But this will still need a docker container running somewhere on your network.
Test image isn’t working for me either, I get the same error. The 22 Dec version works OK.
I also can’t control my givenergy inverter - I’ve tried using a rest command and switch via HA, as below, but neither works. Trying to POST either of these commands in the terminal gives me a “method not allowed” error. Grateful for help!
All,
Perhaps you might want to try out the dev version, which utilises HA MQTT auto discovery for read and control. It will create devices and entities and (in theory) should work much more seamlessly. Docker Hub (using “dev” tag)
Got it connecting and givtcp things have appeared in HA. Which is great. It’s only got sensors at the mo, I can’t yet find a switch/state for anything. project for later.
Using the wrong container! Was using dev, not dev2. Now it’s giving reasonably reliable readings though they did disappear from HA for a while last night. However, no controls in the mqtt discovered entities.
Thanks for your help and hard work on this! I really think GE and Zappi should collaborate and make their kit play together
“Dev” is the right container to use, but there was a bug! I’ve fixed it and uploaded a new dev image.
Try it out and you should get switch etc for control
My preferred usage is to have the container “self_run” and populate the local cache (and optionally MQTT) and then call “/readData” using REST if desired (rather than “/runAll”. this will ensure any failed readings are transparent to the user.
I have pushed a new update to GivTCP to both Dockerhub (“latest” or “2022.03.11” tags) and Github (1.1.0):
One major change is local caching of data and as such I now recommend running setting the container to “self-run” then either use mqtt to extract data or when using REST use the call “/readData”. This will mask any missing data and provide the most recent valid data.
New Features:
MQTT Control
Home Assistant AutoDiscovery (MQTT)
Local caching to “hide” failed read calls
Multi-stage read calls (REST now provides “/getData”, “/readData” and “runAll”)
Breaking Changes:
Returned data objects have the whitespaces of names replaced by “_”
Happy to help anyone who has problems getting this running/modifying their current set-up to accomodate
BOOM! Total success, thanks. Works perfectly and I’ve set up an automation to enable and disable battery discharge to help by Zappi ECO+ mode work. Thanks for your work on this!
I’ve just set up GivTCP (britkat/giv_tcp-ma:latest) in docket and was so pleased to see all the elements flowing through to Home Assistant once I’d figured out the MQTT side of things.
However, I’ve found that since running it I’m getting intermittent poor performance on the battery. It’s not always reacting to export and charging the battery like it normally would. I sat and watched it for a good 10 mins today with a large 6kw export and no battery charge kicking in. Later in the day it did work, with no settings changes, so it does seem intermittent. I’m guessing that i’m overloading the Giv inverter perhaps. Some things that point me towards this assumption are:
The previously mentioned intermittent charging
Occasional errors in the GivTCP logs in docker/portainer
ERROR:givenergy_modbus:Did not receive expected response type: ReadHoldingRegistersResponse != ModbusIOException
ERROR:givenergy_modbus:Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response
NoneType: None
In the GivEnergy portal, under Inverter Data / System Data - the “Status” is showing WAITING a lot more often than previously, when it’s mostly “NORMAL”. No clue if this has anything to do with it though.
The website has occasionally given timeout errors when attempting to change the battery charge status.
I initially tried disabling a large number of the MQTT topics / sensors in HA to see if that would help, but it doesn’t appear to have made a difference.
So I guess my questions are, has anyone else had this? Does it seem feasable or do you think something else is going on? Is there a polling rate I can adjust? In general… Help please
Unrelated to my post above, I thought I’d post my experience with installing the docker file in case it helps someone else. As a warning, I’m a novice with this stuff so my choice of words may well be inaccurate, but is an attempt at explaining it as I understand it for others who are new to it.
GivTCP is best used with docker I have read. Docker is a program which virtualises software, similar to how you might virtualise hardware with HyperV or VMWare. It (usually) makes life much easier to install some software without worrying about OS or other compatibility issues. You download the program you want to run, such as GivTCP as a “container” image.
I’ve had portainer installed for some time. Portainer is an app which gives a nice GUI for managing docker, rather than having to use command line to manager your docker containers. Once you have portainer installed you can just click “Add Container” and then fill in the address of the container, in this case “britkat/giv_tcp-ma:latest”. Give it a name and then hit “Deploy Container”. Once it’s deployed I then went into the container and clicked “Duplicate/Edit”.
From the edit screen you can change the required settnigs, these are under the ENV tab half way down the page. Make the changes you need and then click “Deploy the container”. My belief is that every time you deploy the container, it also downloads/updates your container, which is one of the advantages of using docker, that it should be easy to upgrade.
One confusion I did have is when it came to the MQTT settings. I initially thought that in the ENV tab you had to make up a MQTT username and password and somehow get this into Home assistant, and possibly even publish some ports for home assistant to connect to. I had this totally wrong and backards. In the ENV tab you put in the MQTT username and password of your MQTT broker in HomeAssistant. So in HA go to your Integrations page, find MQTT, click CONFIGURE, then RE-CONFIGURE. And you’ll find your brokers username and password in there. I found I also had to change the MQTT_ADDRESS from 127.0.0.1 (which is local host) to the IP address of my HomeAssistant installation which in my case was 192.168.1.200. They are both on the same physical machine, but I believe because both HA and GivTCP run in docker, docker isolates them which is why the 127.0.0.1 address didn’t work.
Once I did this, a few minutes later everything populated into home assistant and I was overjoyed
