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
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.
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
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.
