Smart Charging - Switched to Use Fixed Charge to X % being ignored
- Edited
This is the value that the App has changed:
which is the AC Charge 1 Upper SOC % Limit, but that is not the value that is set by WW, normally. This is AC Charge Upper % Limit instead.
So, looking through the logs, WW alters these registers:
Enable AC Charge Upper % Limit
AC Charge Upper % Limit
AC Charge 1 Start Time
AC Charge 1 End Time
So, I guess this is by design, but in the AIO we appear to be getting different outcomes.
I will report back tomorrow AM - work allowing
- Edited
As expected. Charged at ~ 800W until SoC = 90% and then maintained that SoC
- Edited
MrMessy I presume this is likely to do with firmware version etc.
How on earth are we supposed to know what to use? It's bizarre that Giv don't have a consistent implementation and inverter and FW differences effectively bleed out into the public API, which then makes it hard for any and all consuming services/apps that are using the Giv API.
@KristianS Could you see what Giv suggest here? They really should make sure there's a much more consistent implementation, ie. for your flavour of AIO and fw version, setting the main AC Charge Upper % Limit should simply result in setting the underlying AC Charge 1 Upper % Limit register (if that's the only one that seems to have an effect). The mapping should happen on their side, rather than push this upstream.
MrMessy So there are two types of registers.
Global ones, as per your image:
and then Charge / Discharge Schedule Settings - which I suspect you have also.
The GivEnergy Mobile app alters Slot 1 = Charge 1 Settings, Slot 2 = Charge 2 Settings and so on....
I concur, you would think that by setting the Global this would take precendent. It would appear not.....
admin I am happy to raise a case with GivEnergy as to what they suggest is the best way forward on this. As per my previous response to Mr Messy, you would think that setting the Global values, this would supercede any setting set on the charge schedules..... but on the face of it, that appears not to be the case. I will also review the online API documentation - but nothing has been udpated on the portal for a while at GivEnergy in their 'What's New' section..... so whether this has been documented for the different firmwares..... Anyones guess.
- Edited
I am also now temtped to set a Charge 1, Charge 2 and Charge 3 settings and see if I can control the SoC using these registers and timings manually. @MrMessy I wonder if you too wouldn't mind delving into your GivEnergy Charge/Discharge schecdules and see if you can also 'control' your system the same as I think I can. You up for that?
BTW - I have done a 'Reset to Defaults' in the app before making any alterations to clear any anomoly entries first
KristianS and then Charge / Discharge Schedule Settings - which I suspect you have also.
I don't have those, as you can see, which is why I was a little confused...
KristianS I am also now temtped to set a Charge 1, Charge 2 and Charge 3 settings and see if I can control the SoC using these registers and timings manually. @MrMessy I wonder if you too wouldn't mind delving into your GivEnergy Charge/Discharge schecdules and see if you can also 'control' your system the same as I think I can. You up for that?
...... which is going to be tricky, obviously.
I think it was added for Gen2 briefly, about a year ago, but was rather hastily withdrawn, reasons unknown. I believe Gen3 may also have the 10 charge/discharge slots available, presumably also with the additional SoC % registers.
admin How on earth are we supposed to know what to use? It's bizarre that Giv don't have a consistent implementation and inverter and FW differences effectively bleed out into the public API, which then makes it hard for any and all consuming services/apps that are using the Giv API.
I agree. It seem very poor implementation that a) it's inconsistent across different FW and b) there are duplicate/conflicting registers at all.
Interestingly.... Reset to Defaults, doesn't actually reset everything to default values.... Seriously....
As you can see, Charge 1 Settings have been reset from a time values, but the AC Charge 1 upper SOC limit is stuck at 80%..... Weird
MrMessy
So, whilst I agree the implementation is a challenge, the ability to have flexibility of the differing Slots makes sense from a manual perspective. Which is exactly what I am going to enact this evening...
But to my point earlier, if a Charge / Discharge slot 1- 10 [for each] is set, then the Global values should take precedent, IMO
- Edited
Mobile APP:
Web Portal:
Let's see how this runs tonight
Bah humbug. I didn't quite guestimate the charge rate correctly to hit the glass ceiling of each charge window. Just shy in each case. I will up the charge rate for tonight's run to ensure we hit each block's artificial limit. Doh
KristianS So, whilst I agree the implementation is a challenge, the ability to have flexibility of the differing Slots makes sense from a manual perspective. Which is exactly what I am going to enact this evening...
Other than the current experiment, curious as to why one would want multiple slots charging to differing % ?
If you were on Cosy, for example, wouldn't you just want to charge to 100% in each period?
Besides, there's a Smart Tariff (Beta) card you could utilise to charge below £x.xx, so even multiple slots aren't required.
On a sidenote, a question was asked yesterday on the GivFB page:
"I have a 13.5 battery and solar, can someone tell me how to set up that the solar charges the battery to 100 percent but I want the electric to charge to say 80 percent overnight. If I set it to charge to say 80 percent from the electric the solar only charges to the same. Any ideas"
The answer seems obvious, just set AC Charge Upper % to 80, but where?
However, my next question would have been "how do I control AC and DC charge rates independently?". Something that would be useful for clipping but, I can't see a way of achieving this.
MrMessy In the most part, I concur. But then, thinking about 'Battery Care' then I have to say, if you don't need to charge to 100% each time, then being able to determine the SoC of your choosing is better for the battery longevity. My EV actually complains at me if I choose a value over 80% SoC, so I guess this was my thinking. I do know as lithium-ion batteries get closer to 100% full it can be a challenge for the ions to find homes in the lattices, and therefore, it can increase the resistance to charge. This produces more effort, i.e., it consumes more power and increases the heating rate as a result.
To your example above, if the global value was to charge to 100% using 'any' charge method, but that the grid charge slot was set to charge to only 80% then, for me, the Enable / Disable settings would appear to be the way to set global maximums, with the Charge / Discharge schedule settings being subservient - but still manageable for controlling specific charge requests. However, clearly, the implementation of these two schemas is not consistent across the ecosystem and so renders the said response 'it depends' - which everyone hates. Especially when writing apps to control said environments..... go figure.
- Edited
OK. An update. And remember why we are doing this. To confirm that by using the App/Portal we can achieve our objective of controlling the time windows of charge/discharge and also the value of the SoC at the same time using the registers that are available in Charge/Discharge section. !! for the AIO at least !!
Success [the previous time 23:30 - 00:00 is there, I just haven't screenshotted it - but it is as expected]
Slot 1: Charge: 23:30 - 01:30 to 70% SoC
Slot 2: Charge 01:30 - 03:30 to 80% SoC
Slot 3: Charge 03:30 - 05:30 to 90% SoC
Portal: AIO FW version: D0.613-A0.613
API: AIO FW version:
},
"firmware_version":
"ARM": 613,
"DSP": 613
},
My first thought is - does it matter if the fields are not exposed in the web portal and would any GivEnergy system respond accordingly.....
I also see this returned: "model": "All-In-One", and so maybe there is an option to test for this and return the value for each GivEnergy connected to WW and adapt accordingly.... That might be too risky a way forward
Thought this may be of interest too....
https://community.givenergy.cloud/d/251-official-givenergy-api-v1-released/149
