search

britkat1980 / giv_tcp

TCP connection (from inverter) and MQTT implementation
78 stars 37 forks source link

Connection to () failed: timed out #160

Open alfwro13 opened 9 months ago

alfwro13 commented 9 months ago

I am using GivTCP Home Assistant add-on version 2.4.3. Home assistant is setup to automatically update to the latest verstion. Since I have upgraded to version 2.4.3 (at some point last month) I've been having issues where the addon is failing to connect to my inverter with error: Connection to (INVERTER_IP, 8899) failed: timed out

Sometimes it recovers but most often it doesn't. To work around that problem I have a HA automation that restarts the add-on when the GE Last Updated Time time is greater than 3 minutes. I know that there are no communication issues with the Inverter as it consistently replies to pings with average time of 1ms and when the addon is restarted it resumes communication with the inverter without issues. Also I had no issues with the previous version

alfwro13 commented 9 months ago

I have managed to narrow down the issue - it would appear that when internet is down the GivTCP app stops talking to the inverter every 10 minutes (Connection to () failed: timed out) it will only resume when add-on is restarted but it will work for 10 minutes. It became apparent when my internet went down for a day. Now that internet is back I am able to reproduce that by blocking inverter's IP address on my router. Can that be changed so GivTCP is able to operate when internet is down? In the meantime I have automation that checks if internet is down and if it will restart GivTCP addon every 10 minutes and that works great but it would be even better if that wasn't necessary at all. Thanks

SheriffOfNotts commented 8 months ago

@alfwro13 Please can you share your automation - I have the same issue

gcoan commented 8 months ago

@alfwro13 Please can you share your automation - I have the same issue

This is not quite the same as @alfwro13 automation but here's one I've written to monitor that GivTCP is working and alert if it isn't

https://springfall2008.github.io/batpred/output-data/

SheriffOfNotts commented 8 months ago

Thank you - I added that a couple of days ago :) It worked perfectly as I saw the alert from 03:00 this morning lol.

I'd like to force a restart, I've written the enclosed, but not sure it will work? `` alias: "Monitor: GivTCP Force Restart" description: "" trigger:

gcoan commented 8 months ago

Glad you're getting the alerts at least!

Adding an auto-restart is a good idea. If ever I get the error, restarting givtcp is all I do anyway

I have never used the hassioo.addon_restart service, but assume if you run it manually it does what you'd expect, and restarts givtcp?

My only comment on the code above is that I think you have the trigger wrong. Its triggering on a change of state of last_update_time

think you need something like this:

trigger:
  - platform: state
    entity_id: sensor.g_xxx_last_updated_time
    to: null
    for:
      minutes: 30

so triggers when last update time doesn't change for 30 minutes

looking at my code it looks like I had also got triggers on xxxx_battery_cells going to unknown for the battery going offline and givtcp_xxx_status going from online for 30 minutes. Certainly I have seen (once I think) last update time being updated but the rest of givtcp not working. Having said that, it is the most likely predictor of it not communicating to the inverter

update: just looked at the code I had put in the predbat documentation and I had included all these 3 cases already

SheriffOfNotts commented 8 months ago

Thanks @gcoan. All seems to work.. I'll keep a eye on it - I've had quite a few instances where a restart alone hasn't fixed it. I've also had to delete the .PKL files to get it working..

alias: "Monitor: GivTCP Force Restart" description: "" trigger:

SheriffOfNotts commented 8 months ago

@gcoan Do you know how I can downgrade to 2.4.2? May be coincidence, but these problems seem to start after upgrading.

gcoan commented 8 months ago

@gcoan Do you know how I can downgrade to 2.4.2? May be coincidence, but these problems seem to start after upgrading.

Assuming you are using the add on (not docker), which from the automation looks like you are,

Go to system / backups and restore the add on backup before you upgraded.

I use Google drive add on to store most of my backups so you may need to upload the backup into HA if you do the same

gcoan commented 8 months ago

@SheriffOfNotts forgot to say, if you haven't got the partial backup before you upgraded GivTCP you can just do a partial restore of the GivTCP add on from the last full backup. That works too

SheriffOfNotts commented 8 months ago

Thanks @gcoan, I've a bit nervous about partial restoring from backup. Is there a way by uninstalling the current version and manually installing 2.4.2?

gcoan commented 8 months ago

Here's what I found when I went through same question

https://community.home-assistant.io/t/how-to-downgrade-addons/331223

It advised doing the partial restore of just the add on which is what I did and it worked fine. There's unfortunately no other home assistant way to do this

SheriffOfNotts commented 8 months ago

Thanks @gcoan, appreciate your help.

gcoan commented 8 months ago

Hi @SheriffOfNotts again, I was just looking at the givtcp activity automation and realised that I had missed out the choose: part of the action: to send different alert messages whether the inverter or battery was offline. Also per a suggestion from Hoggy on the GivEnergy forum, have added a check of inverter temperature as another way to detect the inverter is offline. This'll go in the next predbat doc update I push out, but here's my fork: https://github.com/gcoan/batpred/blob/main/docs/output-data.md

SheriffOfNotts commented 8 months ago

Thanks @gcoan, appreciate it. BTW the automation worked perfectly at 01:00 this morning :)

steveconrad commented 4 months ago

Can I add to this post my situation?

I too see plenty of log messages such as `2024-05-12 23:25:12,853 - Inv1 - sync - [ERROR ] - Connection to (192.168.0.104, 8899) failed: timed out

2024-05-12 23:25:15,356 - Inv1 - sync - [ERROR ] - Connection to (192.168.0.104, 8899) failed: timed out

2024-05-12 23:25:17,860 - Inv1 - sync - [ERROR ] - Connection to (192.168.0.104, 8899) failed: timed out`

Now when testing this, I cannot get my GivEnergy Interter to reply on this port 8899. It happily gives me a login prompt at the port 80 address though.

I think this is down to the mode the inverter is running in. STA mode, works for me in that the inverter talks back to GivEnergy without issue. However, port 8899 isn't there. In AP mode, I think 8899 is live, but then the inverter doesn't talk to GivEnergy.

Thus I run mine in STA mode. Interestingly, though the GivTCP does see the inverter, as I notice this line later:

`2024-05-13 03:03:30,100 - startup - [CRITICAL] - No inverters found...

2024-05-13 03:03:30,102 - startup - [CRITICAL] - Running Redis

2024-05-13 03:03:30,104 - startup - [CRITICAL] - Setting up invertor: 1 of 1

2024/05/13 03:03:30 [notice] 249#249: using the "epoll" event method

2024/05/13 03:03:30 [notice] 249#249: nginx/1.20.2`

Further, GivTCP does read and send info OK, as MQTT shows all the info and updates back seem to work too.

So is this something I need to fix or should I just ignore the 8899 messages?

TIA

thewookiewon commented 4 months ago

Just chiming in here to say I'm getting a similar experience. GivTCP is working fine using REST but periodically I can see in the logs

2024-05-31 05:30:09,659 - Inv1 - write       -  [INFO    ] - Setting Charge Slot 1 was a success
2024-05-31 10:18:28,851 - Inv1 - sync        -  [ERROR   ] - Connection to (<INVERTER IP, 8899) failed: timed out

Prob a simple code change to detect if port 8899 is working for the Inverter IP or not and alter the connection accordingly / stop pumping the error message to logging