I noted that my battery stopped discharging resulting in us using grid power during peak time.
Looking at the inverter log its 03/08/25 DC discharge Previous:2600 New:0 source was 'Server' and the notes said External Change Detected (so not the app or WebUI) anyone else seen this? Are Giv secretly in league with Octopus??? seriously though I'm going to have to set up a monitor alert vi HA for all settings?
What kit have you got
What tariff are you on
Have you setup the Smart Tariff dashboard - that takes control
zerotosixty2 external change detected is typically when it has detected that a change has been made locally (such as via HA) and it is bringing the portal cache in line.
zerotosixty2 First, well done for checking the log and fixing the problem yourself.
Now the question is why did this happen?
External Change Detected means that either a command was sent locally and then the portal picked up the change OR the portal sent a command but it got corrupted and changed the wrong thing and then the portal picked up that something changed that shouldn't have.
Was there a previous entry in the log to set something to zero (maybe turn ECO off?) that could have changed the wrong register? Did the change occur shortly after midnight? Occasionally the portal sends some maintenance commands shortly after midnight which are not recorded in the log, but can get corrupted.
I am also getting External Change Detected events for the last 2 days.
I am using WonderWatt and overnight, the battery discharge rate is set to around 700W.
At 7:30am, WW sends a command to set the battery discharge rate back to 2600W.
This has been working for a long time but the last 2 days, after WW has done its change, GE change it back. I have checked with WW and they get a confirmation from the GE API that their change was made ok so not sure why GE think that an external change happened.
Any ideas why this is now happeneing and how to stop it?
2025-08-19 07:32:44 Server Battery Discharge Power Read Successfully 2600 655 External Change Detected
2025-08-19 07:32:43 You AC Charge 1 End Time Written Successfully 05:00 00:00 00:00 API - Inverter Settings - Wonder Watt - IsGUoFeY
2025-08-19 07:32:42 You AC Charge 1 Start Time Written Successfully 03:30 00:00 00:00 API - Inverter Settings - Wonder Watt - IsGUoFeY
2025-08-19 07:32:41 You AC Charge Enable Written Successfully true false false API - Inverter Settings - Wonder Watt - IsGUoFeY
2025-08-19 07:32:40 You Battery Discharge Power Written Successfully 655 2600 2600 API - Inverter Settings - Wonder Watt - IsGUoFeY
alan_johnston Any ideas why this is now happeneing and how to stop it?
My GUESS is Portal Latency. I think the portal is becoming more overloaded.
When a setting is changed the inverter has to send a "44 packet" to the portal and receive back an acknowledgement. In theory that should take a fraction of a second, but if the portal is heavily loaded it may take longer.
Although the portal may appear to be one big computer, it is in fact a cluster of many computers in a datacentre somewhere. I don't know how many systems GE have installed, but I will take a guess at 40,000. I don't know how many computers comprise the portal (back end), it could be 10 with 4000 customers each, 20 with 2000 customers each, or 40 with 1000 customers each. The point is whenever your system reconnects to the portal it will be randomly allocated to a computer. How many customers you are sharing that computer with (and hence how fast it can respond) is beyond your control.
I think WW is very brave to be sending commands 1 second apart. GivTCP users have reported issues in the past and generally recommend allowing 10 seconds between each command. I think sending the commands 10 seconds apart would resolve the issue, but may be difficult for WW to implement.
alan_johnston A short term fix might be to "Restart Inverter" using the portal. This causes a reconnection which will probably get around the problem for a while.
Rubikcube think WW is very brave to be sending commands 1 second apart. GivTCP users have reported issues in the past and generally recommend allowing 10 seconds between each command.
Givtcp works locally over modbus, and could be sending commands without waiting for a reply. IF the API waits for a response for one command before sending the next, then firing them continuously might be fine?
Rubikcube When a setting is changed the inverter has to send a "44 packet" to the portal and receive back an acknowledgement. In theory that should take a fraction of a second, but if the portal is heavily loaded it may take longer.
Ah. That could be the issue.
The past couple of days I have been uploading lots of data to the cloud overnight and it will have been running at 7:30am and could easily have delayed the GE 44 packet on its round trip.