Hy5 Gen3 incorrectly importing from grid

Since the summer sun got intense enough I have had my HY5-Gen3 on a 'do not import from grid' setting, relying on the batteries. Nevertheless it does import small amounts - a few 10s or 100s of watts. However recently I have discovered it importing all energy from the grid even when the battery is full. or nearly so.

This happened about a week ago (3rd Jul) and then just now (8th) - I noticed I had used 1.5KWh from grid when I would expect approx 0. It was behaving as expected until exactly midnight, and then all of a sudden flipped to importing from grid. Battery was at 84%, so no reason not to use it.

The logs show no change of settings (at all). I went into the Settings page and disabled, then re-enabled Eco mode, and then all was well again, discharging from battery and not importing from grid.

How can I stop this?

1.5kWh is annoying but in the grand scheme of things isn’t a lot of money. It unfortunately sounds like a random corruption of the inverter settings which can happen. I don’t think there is anything you can “do” to stop it, as its a random act.

Usually a ‘reset to defaults’ or turn Eco on and off can cure most such ‘inverter stopped working’ behaviours.

I had a couple of incidents like this before I setup a firewall. The portal sends various commands to my inverter at apparently random times but commonly just after midnight. I presume it does the same to everyone's inverters.

Whilst the commands are intended (I think) to be beneficial, there is a risk of corruption. When a command gets corrupted it often turns eco mode on or off or starts a calibration.

This is the latest times from my firewall log of commands that have been blocked:

2024-06-25T00:00:06.436158+01:00
2024-06-25T00:00:07.108064+01:00
2024-06-25T00:00:08.450843+01:00
2024-06-25T00:00:11.298946+01:00
2024-06-25T00:00:16.675046+01:00
2024-06-25T00:00:27.426864+01:00
2024-06-25T00:00:50.466926+01:00
2024-06-25T00:01:33.475296+01:00
2024-06-25T00:02:59.491140+01:00
2024-06-26T00:02:06.949815+01:00
2024-06-26T00:02:07.296377+01:00
2024-06-26T00:02:07.968835+01:00
2024-06-26T00:02:09.312870+01:00
2024-06-26T00:02:12.128625+01:00
2024-06-26T00:02:17.505010+01:00
2024-06-26T00:02:28.257014+01:00
2024-06-26T00:02:50.276559+01:00
2024-06-26T00:03:33.284270+01:00
2024-06-26T00:04:59.300170+01:00
2024-06-26T00:05:35.124564+01:00
2024-06-26T23:17:52.120673+01:00
2024-06-26T23:17:54.598474+01:00
2024-06-26T23:17:59.715040+01:00
2024-06-26T23:18:09.700443+01:00
2024-06-26T23:18:30.946705+01:00
2024-06-26T23:19:11.911022+01:00
2024-06-26T23:20:31.780508+01:00
2024-06-26T23:22:32.610582+01:00
2024-06-26T23:22:53.138159+01:00
2024-07-02T04:39:10.076294+01:00
2024-07-02T04:39:16.258663+01:00
2024-07-02T04:39:28.548571+01:00
2024-07-02T04:39:53.890792+01:00
2024-07-02T04:40:43.043327+01:00
2024-07-02T04:42:21.346781+01:00
2024-07-02T04:44:22.183302+01:00
2024-07-02T04:46:23.027989+01:00
2024-07-02T04:48:05.544049+01:00
2024-07-07T21:29:53.122354+01:00
2024-07-07T21:29:53.412552+01:00
2024-07-07T21:29:53.956176+01:00
2024-07-07T21:29:57.292157+01:00
2024-07-07T21:30:01.636513+01:00
2024-07-07T21:30:10.088241+01:00
2024-07-07T21:30:28.000858+01:00
2024-07-07T21:31:02.817338+01:00
2024-07-07T21:32:10.404249+01:00
2024-07-07T21:34:11.232639+01:00
2024-07-07T21:34:54.065937+01:00
2024-07-08T00:02:32.228061+01:00
2024-07-08T00:02:32.584044+01:00
2024-07-08T00:02:33.288086+01:00
2024-07-08T00:02:34.664193+01:00
2024-07-08T00:02:37.480145+01:00
2024-07-08T00:02:43.112143+01:00
2024-07-08T00:02:54.120099+01:00
2024-07-08T00:03:16.921465+01:00
2024-07-08T00:04:01.961413+01:00
2024-07-08T00:05:30.024173+01:00
2024-07-08T00:06:53.256072+01:00

I think they are in blocks due to retries rather than multiple commands being sent.

Hmm... because I'm currently working on modbus library, I've been recording lots of modbus traffic. I wouldn't see the actual requests, but I should get a copy of all the replies. I'll have a trawl through and see if I've captured anything interesting.

DD I can't see any pattern. It's not every day. These are the days this year that I have been hit by portal commands just after midnight:

cut -c-13 /var/log/firewall | grep 2024 | grep 00$ | uniq
2024-01-06T00
2024-01-09T00
2024-01-12T00
2024-01-14T00
2024-01-17T00
2024-01-22T00
2024-01-28T00
2024-02-01T00
2024-02-06T00
2024-02-09T00
2024-02-12T00
2024-02-13T00
2024-02-21T00
2024-02-25T00
2024-02-29T00
2024-03-26T00
2024-03-31T00
2024-04-12T00
2024-04-17T00
2024-04-19T00
2024-04-22T00
2024-05-01T00
2024-05-05T00
2024-05-12T00
2024-05-21T00
2024-05-23T00
2024-05-28T00
2024-05-29T00
2024-06-02T00
2024-06-06T00
2024-06-07T00
2024-06-08T00
2024-06-09T00
2024-06-13T00
2024-06-15T00
2024-06-16T00
2024-06-22T00
2024-06-25T00
2024-06-26T00
2024-07-08T00

Blocking them doesn't seem to have any harmful effect except that I have to change the time myself in March and October.

My house's firewall is incoming and outgoing, but I have obviously needed to allow the GE port access... can you let me know what your network filter looks like for those you mention?

I wish the software was more predictable!

geoffreycoan The 1.5KWh was simply what I noticed that night not the total that could have been used... my house runs at a minimum load of about 700W at present, so 1.5KWh that's about 2h of the 7h that could have been used that night, and I didn't notice the issue the first night it happened.

What I find particularly confusing is that to fix you need to disable Eco and then re-enable it, as if there is a setting that is hidden or gets corrupted somehow. Some additional bug-hunting in the software would seem necessary!

rivimey I know, it is frustrating when the inverters stop behaving.

I had one of my inverters just stop talking to GivTCP (in Home Assistant) in the week. It was on the network, it was sending data back to the portal, but it just wasn’t accepting any local interrogation or control.
Rebooting GivTCP and Home Assistant didn’t work, restarting the inverter from the portal didn’t, turning the wifi off and on again didn’t, powering the inverter down and restarting it didn’t. Eventually doing a ‘reset to defaults’ in the portal cured the problem and the inverter started talking to GivTCP again.
Why, I have no idea.

One theory is that if multiple devices try to talk to the inverter at the same time, e.g. the GivEnergy app on two devices, or GivEnergy app and GivTCP, then occasionally two devices sending commands to the inverter at the same time clash and results in a corrupted state on the inverter. I don’t know, it can work reliably for several months and then seemingly just not do what you want it to do. Annoying

geoffreycoan It was on the network, it was sending data back to the portal, but it just wasn’t accepting any local interrogation or control.
Rebooting GivTCP and Home Assistant didn’t work, restarting the inverter from the portal didn’t, turning the wifi off and on again didn’t, powering the inverter down and restarting it didn’t. Eventually doing a ‘reset to defaults’ in the portal cured the problem and the inverter started talking to GivTCP again.

One thing you don't list trying (in case it happens again): if you connect to the http interface offered by the dongle, it offers a means to restart the dongle. That might also be worth a try. (Though you'd think a power-cycle would fix it - assuming you did remove all possible sources of power ?)

@DD I'm connecting to the inverter using ethernet cable, so I don't think there is a dongle to reset. I didn't need to power cycle anything, just to re-re-enable Eco mode.

@geoffreycoan You might be quite correct about the 'clash' -- if both the app and something else is relying on sending discrete commands in sequence without something in the middle changing, then there is indeed a chance for untoward results when they interleave. The API would ideally include a 'start / end transaction' mode to signal to the inverter that the commands should be executed as an indivisible group.

DD thanks, didn’t try that. It would be less impactful than powering off the inverter which takes a number of circuits in the house out as I have them wired to the inverter EPS output (there’s no risk of high loads).

Presumably connect to the dongle SSID and access the config page used to setup the wifi details. That would also work for forcing a reconnection to the wifi when it decides it doesn’t want to join in for random reasons, despite the inverter sitting next to it being quite happy with the wifi.

geoffreycoan Presumably connect to the dongle SSID and access the config page used to setup the wifi details. That would also work for forcing a reconnection to the wifi when it decides it doesn’t want to join in for random reasons, despite the inverter sitting next to it being quite happy with the wifi.

If it was connected to the portal, the wifi must be working. For it not to be accepting connections, I guess the listening tcp port has got closed. But you may still be able to connect to the http port 80 through the wifi.

rivimey A standard port-blocking firewall that you might find on a home router or windows computer is not up to the job. You need a more advanced packet filtering firewall using something like netfilter.

I have posted about it before but didn't seem to get much interest at the time.
https://community.givenergy.cloud/d/1403-restricting-remote-control

I use a Linux netfilter firewall which controls both incoming (as usual) and outgoing (not usual) traffic, and have configured it to work with GE kit adequately. I use "shorewall" to configure linux, via an 'ansible' config, which I find useful. I define these two shorewall macros:

  - name: GIVPLUG
    desc: GivEnergy SmartPlug
    rules:
      - { proto: tcp, dest_ports: ["8886"] }

  - name: GIVENG
    desc: GivEnergy Solar Controller & /Plugs
    rules:
      - { proto: "udp,tcp", dest_ports: ["7654"] }

... and then allow traffic from the source zone to the internet for both of them.

I personally find their use of the network rather irritating - (it should have internal storage to buffer data if/when the interenet is not accessible, it should be contactable on the local network if the internet is down, the TCP/UDP ports required should be specified in the manual, the smartplugs should be accessible by other kit, and more...)