Battery not discharging

Been having an issue since about 2 a.m Tuesday, battery is set to charge between 00:30 and 04:30 and only charged up to 63% overnight by 2 a.m. and then stopped. Didn't discharge at all from 04:30, then charged up with solar and got 10 100% where it has stayed since. Is there a breaker or something I need to check? The solar is working fine and running the house during the day. I've tried changing the settings for the battery between scheduled discharge etc. Initially I noticed this morning that the app was showing the battery reserve set at 100% which I thought was the problem but changing that to 10% has had no effect.

Fixed it by changing the discharge power for the battery from the displayed 2600 to 500 and forced discharge and it started outputting power, put it back to on demand and 2600 and seems to be working as normal. I assume a 0 discharge power had been written somewhere and app not displaying actual set value?

gaggers1 Might be worth reporting this as a bug as it would be helpful if the portal displayed the settings on the inverter rather than the settings held in browser cache (if that's what it was).

Tim .
Is that why the Remote Control page for My Inverter has buttons for 'READ ALL UNREAD REGISTERS' as well as 'READ CATEGORY' adjacent to each setting?
Certainly in my line of work it is recommended to configure a web browser to clear all cached data on closing when connecting to PLC web servers so that you are not looking at out of date info when you connect in a following session.

Simon_C Certainly a button to send a Givtcp-type read-all would refresh the data displayed. There have been reports of people configuring their inverter via app but it not appearing to commit those changes at the inverter and vice versa. I think that if you have hardware that can be configured from a number of points (App or browser via web and app via local as well as Givenergy developers/staff by whatever means they have access to) then automatically re-reading the inverter registers each time you open the page, or commit changes would provide more confidence that the changes had been committed to the inverter registers.

This may be the design intent on the developer's behalf but perhaps if the link between the web server which is presenting the option displayed on your app or browser is unable to communicate to the actual inverter, you may be looking at the required settings rather than those actually held in the inverter's registers.

Anyway, a way to indicate that comms between the web server and the inverter is good or bad might help.

The read all registers thing was handy when running with the old APIs as none of that updated the portal side of things - so it went out of sync real quick.
Now everything (App, Portal and API) is talking together using the same unified API it (in theory) should now only be needed if you run GivTCP, as that would obviously not filter up to the portal.

Note: even the app in local is just read only, you can't change settings locally, they still use the cloud for that. (Checked by disabling Internet access but keeping the router up and the app just times out on setting changes)

hoggy Thanks for the clarification on how access (at least for customer) is all completed using the same set of APIs. Whether you are looking at your device app or a web browser or pulling it into a home automation system, it's the same calls that are being made, just the visual presentation that can differ.

hoggy .
If the app in local is read only, what happens if you make an intended temporary change to the inverter operating mode then lose the internet connection before managing to revert back to normal auto operation? Is there no way to recover that situation for normal non-programmer users until the internet connection is re-established?

Or is there a default mode that is reverted to after the inverter is put through a controlled shutdown and power up?

I imagine that your stuck with whatever you told it to do before you lost the Internet. If say you temporary use the pause function on the app then lose network then it'll stay paused. Even with a power off and on of the inverter. Under no network conditions the inverter just carries out its last instruction (I've had mine off and on a bunch of times and the internal registers don't reset or anything).
This may also be an issue for those on Agile if the network drops off - the inverter would carry out the same instruction beyond the anticipated half hour block. It has no inbuilt scheduler or queue or anything, settings are just pushed from GE side to either charge or discharge for Agile.
Only way around that is to use GivTCP. I wasn't going to bother updating my own app thing that used the old API to do things like pause & adjust power levels (which the new app can now do) but i might look at making it run on GivTCP instead as a last gasp fix should GE servers be down for a while.

hoggy .
Thanks for the clarifications.
It does seem to be a glaring omission by GivEnergy to not have a simple user process to recover the inverter to a known state in the event of loss of the internet connection, rather than just continuing with the last known command for ever more.

Some interesting points. I've had the system since November and this is the first time I've had this sort of problem. I've seen plenty of issues with the app with data display etc but this is the first time that there has been an actual impact on the performance of the system. The other possible cause for me could be an issue with my internet. I have recently switched to fibre to the house and we are having a number of dropouts, I think I have traced an issue to near this time so perhaps this caused an issue if a remote update was happening.

For some reason my battery stopped discharging for around the last day or two. It’s been on dynamic all the time and no manual charge cycles recently. Only noticed because I saw I imported more today and yesterday and saw that the battery had discharged 0kWh for the last 48 hours or so.

Tested by turning on the over and kettle to generate load for a few minutes and sure enough the battery wouldn’t discharge. Gave it a kick in the app by changing its mode to force discharge and then back to resume/normal and seems to be ok now.