I run a number of standard repeating schedules that run overnight 7 days a week. Last night a charge schedule " Part 2 Charge" failed to execute @ 03:27 and it did not leave any reason or trace in the WW log files. I have had this happen once before and the next day it ran as normal without any modification. The schedule is a straight forward charge schedule to 100% with no conditions set. If you could take a look for me please circular- strategy

@"duplada"#p8625 Looks like the system data response from Giv was incomplete and we could not parse it due to the many null values, including things like SOC/percent. `Error parsing system data response: {"data":{"time":null,"status":"Unknown","solar":{"power":null,"arrays":[{"array":1,"voltage":null,"current":null,"power":null},{"array":2,"voltage":null,"current":null,"power":null}]},"grid":{"voltage":null,"current":null,"power":null,"frequency":null},"battery":{"percent":null,"power":null,"temperature":null},"inverter":{"temperature":null,"power":null,"output_voltage":null,"output_frequency":null,"eps_power":null},"consumption":null}}, txId: BGIrdHim` We will fix the bug and ensure this shows up in the activity log. And will be added to alerts.

That's a lot of Null's - Great Support Thank you

So because my SOC was around 17% this evening my export schedules Quick Discharge 1 - 4 didn't execute which is as expected. When WW executed "Quick Discharge 5" @ 22:50 which takes the battery down to 4% it errored out with the following. Looks as if the SOC % is missing. [URL=https://imgapi.wonderwatt.com/i/6wDSi27.png][IMG]https://imgapi.wonderwatt.com/i/6wDSi27h.png[/IMG][/URL] I will watch the system to see if my first Charge Schedule "Part 1 Charge" executes correctly @ 23:30 and report back. If you can take another look at it please.

Schedule "Part Charge 1" executed correctly @ 23:30 [URL=https://imgapi.wonderwatt.com/i/mPs88UF.png][IMG]https://imgapi.wonderwatt.com/i/mPs88UFh.png[/IMG][/URL]

I will see if "Part 1 Discharge" schedule executes @ 01:40 and let you know

@"duplada"#p8628 Yep, same issue, null values returned from Giv API, which we cannot do anything with. We need SOC. At least we now know the log fix is working!

So have GE updated their API and have an issue with it? It seems rather strange it has happened twice in 24 hours to me but not to other users. This has to be some sort of intermittent problem as the charge schedule which errored when I first reported the problem ran fine last night, but an export schedule that worked fine the day before errored last night, Neither have been amended. The three schedules that have run since the last error have all succeeded When that type of error is received, would it not be possible to retry the execution again? What is the way forward here, Do you have contacts at GE to explore this further as a consistently reliable system is essential for user confidence. Keep me updated and I will let you know if I see further instances of this issue. Thanks for looking at this on a weekend.

So I had another parsing failure in the early hours today [URL=https://imgapi.wonderwatt.com/i/AU4USzy.png][IMG]https://imgapi.wonderwatt.com/i/AU4USzy.png[/IMG][/URL] Can you give me some insight into the operation of WW as I have been trawling through my data logs to see if I can identify any communication problems or missing data in my GE logs. My dual AIO system records data about every 60 seconds and not the usual 5 minutes. In the past occasionally I have seen odd instances where some field data has been missing from a record in the GE logs. Is the error happening as a result of querying the GE data to see if the Schedule should be executed? or Is the error the result of actually trying to set up the schedule on the GE server.? what time window before a schedule time should I be looking for missing SOC data 2 of 3 minutes? Any information that you can provide would be useful as I am determined to get things operating successfully Would it be possible where you get a failure like the parsing error for general schedules to perform a retry a few minutes later? Retry on Failure Y/N?

@"duplada"#p8639 Sure, the API call is basically: HTTP GET: https://api.givenergy.cloud/v1/inverter/:serial/system-data/latest Where :serial param is your GW serial number. And you will need to sent your API token as a Bearer authentication header. You can try this with various tools like Postman. This seems to occasionally result in a bunch of null values. But because it's a valid JSON document and we get a valid HTTP status (200 OK) back, we don't retry these. This is ultimately something that Giv will need to sort out on why their dual AIO GW sometimes responds with all null values for that specific API call (`system-data/latest`). Hope that makes sense!

@"admin"#p8640 Well it sort of made sense. Both you and in particular me both know that GE is not going to sort anything out, as they just cannot cope, they won't even answer the phones these days. I have multiple open support tickets going all the way back to March. There is one person who knows and understands the dual AIO's and that is it at GE period. I fully realise that you have a system that supports multiple inverter manufacturers and you trying to make your system as flexible and reliable as possible. I have had 4 of these show stopping errors now. 1 was an Inverter Timeout and the other 3 have been the parsing errors where the SOC is missing. What I was suggesting with the retry option is since the WW system knows that there is a parsing error and is about to send a WhatsApp message, could it not execute a retry also a few minutes later. Also the timeout error in the log text also says "try again" so why can't the system try again automatically? It just makes sense to me. Thanks again for replying on a weekend.

Failed Execution of Standard Schedule Not Recorded in WW Logs

duplada

I contacted GE again today about this error, no replies so far. I will keep trying.

admin

duplada We'll have a bit of think of a quick win.

duplada

admin We'll have a bit of think of a quick win

OK I will leave it with you. No issues overnight

duplada

Failed execution @ 20:49 Null Values again I guess.

Here we go again

duplada

Null Error tonight again.

duplada

And again Just now

duplada

Had another Go at them today I got to talk to the Support Manager waiting for a reply on a number of topics this error being one of them.

admin

duplada We’ll investigate a different/additional retry mechanism, 5 mins apart or so, up to 3 times. But needs a few DB changes too.

duplada

admin We’ll investigate a different/additional retry mechanism, 5 mins apart or so, up to 3 times. But needs a few DB changes too.

admin We’ll investigate a different/additional retry mechanism, 5 mins apart or so, up to 3 times. But needs a few DB changes too.

Have you had any further thoughts on the alternate Retry? I had another GE parsing error overnight. Despite my recent successes at speedily responding to the WW WhatsApp error alert messages, and subsequently being able to rectify the situation with a manual Quick Schedule. Sadly (for my wallet) today's GE induced error, was not caught by my inhouse monitoring solution (me). Leaving my sleep deprivation issues to one side, If you can find a timely solution to this problem, it will be much appreciated by all GE Dual AIO users who are affected by it.

I will of course be "rattling" the GE cage once again today, as always. Though, as you well know, GE cannot even find the time to interact with its customers, let alone actual fix something. Once again another instance of a small third system (WW) having to provide fixes for the shortcomings (apathy unlimited) of the 1st party Global system of (GE). I know who I would rather support and spend my money with going forward. 😠

duplada

OK I will leave it with you, you would need to knock 5 minutes off the length though right? When you get to altering all these bits and bobs, a lot of which revolve around the Scheduler and you have to restructure your database. Could you add a Comment field to Remind yourself why you have something set or whatever?
To Do
Pause Schedules
Discharge Rates
I am sure there is something else but cannot remember what it is at the moment
No I remember Comment Field

duplada

And again this evening

admin

duplada Yep - we'll be rolling something out later this evening.

duplada

admin once again you ride to our rescue, truly amazing, thank you so much.

duplada

admin Yep - we'll be rolling something out later this evening.

Well I can confirm the retry feature works. I will provide the evidence for others to view tomorrow. Thanks again for this very timely fix., Outstanding work. 🥳

admin

duplada Thanks, you may have also noticed that we catch 'Inverter Offline' messages as a 'retryable' error (benefitting any GivEnergy user), hence your schedule at 22:30 got retried successfully too.

johalareewi

admin you may have also noticed that we catch 'Inverter Offline' messages as a 'retryable' error

I got one of those the other night. Very handy because I only lost 1 Agile slot rather than 7.

duplada

admin I certainly did notice that. In fact I got that excited that I didn't even notice that WW saved the day again by retrying in 5 with a parsing error @03:25. The first error, Invertor Timeout / Offline (below) was the internet dropping 2 minutes before my 23:30 charge schedule. It was if you had engineered a test to show off the new feature of WW. So far the new retry has saved the day 3 times in the last 2 days which is fantastic.

I did however have some events were I didn't receive a WhatsApp and one that I did, if you can let me know why please?

The WW system just gets better and better thank you so much. 🥳

Steve1

admin Hi, I have just added a 2nd GE AiO and are now getting similar error messages from WW, see below;

2025-10-18 05:30:06 N/A %
Error parsing system data response after 3 attempts, txId: Ek8UKk08
2025-10-18 05:03:06 80 %
Error setting discharge-rate schedule: There was no response from comms. Please try again [bk1NRGP1]

This has happened a few times in the last week or so

WindyMiller

Super. The 4,10,10 second retry took me from 1 in 5 command sequences failing to 1 in 50. I can see this taking me to 1 in 500. Brilliant. If only my fingers were as reliable!

WindyMiller

WindyMiller Here's proof the 5 minute retry is working. End of hold at 4pm met with lots of Comms failures but the retry at 4.07pm got through. Nothing in the WW log though.

WindyMiller

WindyMiller A rather unscientific estimate of my error rate is showing just 2 command sequences of 300 have failed in the last 17 days. Both of them were 'Inverter Offline' messages. That's pretty impressive.

duplada

WindyMiller Nothing in the WW log though.

So it worked, but the WW log didn't specifically say it was retrying in 5 minutes? It would be better if it did let you know, an alert would stop you trying to correct manually if you caught that it hadn't executed.

« Previous Page Next Page »