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

        This is my listing of my settings.... now I have managed to query them correctly

        And I realise that this is small fry to the likes of you @admin - but I am feeling rather pleased with myself this Friday evening...
        Updated via the API

          KristianS Very good! It’s nice to have a poke around. 🤩

          So, is there an issue with your Giv AIO & fw combo not using the global register on your set up?

            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?

            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

              Hmmmm, I will wait until after I have performed the now-present firmware upgrade....

              Post Firmware update....
              https://api.givenergy.cloud/v1/inverter/CH####G###/settings/17/read gave a value of "false"
              I then ran the command:
              https://api.givenergy.cloud/v1/inverter/CH####G###/settings/17/write?value=true&context="Via Postman by Kristian"
              which returned a "true"
              reran https://api.givenergy.cloud/v1/inverter/CH####G###/settings/17/read
              and now "value": true appears sticky....

              So, on the face of it, it appears that this setting was faulty on the old firmware and has been 'fixed'.
              I will test this tonight using the global values in my invertor settings and report back tomorrow.

              Good News item!
              As per the following images, you can see that my Global and Charge Window attributes were set as the following values in the settings....
              Global Values
              ID: 66; AC Charge Enable to ON
              ID: 72; Battery Charge Power set to 2067 (W)
              ID:17; Enable AC Charge Upper % Limit to ON
              ID: 77; AC Charge Upper % Limit set to 80%
              as per...

              and
              Charge 1 Settings
              ID: 64; AC Charge 1 Start Time to 23:35
              ID: 65; AC Charge 1 End Time to 05:25
              ID:101; AC Charge 1 Upper SOC % Limit to 100%

              And this was the resulting outcome

              Result!
              I am now confident that I can switch back to WW to control not only my charging, but also limiting the SoC to the value I set in the tool.
              Testing tonight and over the next few days different values to confirm.