Smart Charging - Switched to Use Fixed Charge to X % being ignored
- 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
This is my listing of my settings.... now I have managed to query them correctly
- Edited
Let me run some tests on each of the settings in the global registers and show you the inputs and outputs.
Interesting -
Commands:
https://api.givenergy.cloud/v1/inverter/CH####G4##/settings/17/write?value=true&context="Via Postman by Kristian"
https://api.givenergy.cloud/v1/inverter/CH####G4##/settings/77/write?value=85&context="Via Postman by Kristian"
And yet this is the current state......
So for reasons unknown. Enable AC Charge Upper % Limit is not staying as toggled to ON
https://api.givenergy.cloud/v1/inverter/CH####G4##/settings/17/read
Have I just found out why your setting is not having the desired effect on my system?
Rerun the command:
https://api.givenergy.cloud/v1/inverter/CH####G4##/settings/17/write?value=true&context="Via Postman by Kristian"
Same outcome
KristianS It does look like when you read it through the portal it returns false even though it's true.
Although when you then query it via the API it also returns false? Even though you've just set it to True?
You could be onto something here. Just condense this down for Giv into the smallest reproducible example for your AIO and FW combo and let them know the details. Looks like a bug at their end for sure.
Final screenshot of the outcome from setting the three slots via the API and the resulting actions on my AIO
Charge / Discharge settings that were configured
What we really want is to be able to manage the SoC via the global values, but if the Enable AC Charge Upper % Limit is not staying to True, no matter what value we set AC Charge Upper % Limit to, it will be ignored and the system will continue to charge until it is full...... ignoring the value as set by WW, which is not what I wanted it to do.
Simple submission to GivE on its way shortly
- Edited
Hmmmm, I will wait until after I have performed the now-present firmware upgrade....
