Wallbox charger jumps to 32A after current adjustment

[taste66]

I have this strange bug for which I do not know if this is my Wallbox OCPP behavior of part of this integration.
I adjust the charge current regularly based of the total power entering my home. The charger can do 32A maximum, my main fuse is 35A so this is important. Initially I was updating the current every minute and ran into the problem it sometimes jumped to 32A current offered while maximum current was still set to a much lower value. Resending the same value did not fix the problem it needed to be something different.

I changed to only send a new value if it was at least 2A different than the old one which reduced the problem a lot but it is still there. I now added the Wallbox integration and are also sending the max charge current trough that control, 15s after I did send it through OCPP. It still happens but the high current is now limited to 20s so the Wallbox integration gets it right, as you can see on the graph below:

I do not like doing through a cloud connected service since it is an additional failuremode for it to not work. Is there a way to see in logging what OCPP is actually sending to the Walbox? If this is right I guess I need to file a bug at Wallbox but I would be surprised I am the only one suffering from it. I am running firmware 6.4.14 on a Wallbox Pulsar Plus

[lbbrhzn]

I believe the wallbox pulsar plus only supports specific values for the maximum current.

[taste66]

@lbbrhzn Thank you for responding. I am afraid the specific current is not the problem since it does work most of the time. When it goes wrong I send the same value trough the wallbox integration and that does work. Leave this work around in there for now and check after a Wallbox SW update.

[rbb-dev]

Without seeing the logs, no one can help you.
But from my experience, I have a charger that jumps to 32A if I set anything from 0 to 5A
It also faults and stops charging few seconds after I send it 7A.
It also goes to 32A if I send it any floating point value, 27.5 for example.
You just have to inspect the logs to see what is happening..

[taste66]

@rbb-dev Thank you, I double checked but I am only sending integer numbers. I can reproduce relative easy by using actions in the development menu. I did test with send the maximum current to 10 amps which shows up in the logs as 10.0
when I get the green check in the action GUI I press the button again after 3 times the current jumps to 32A
occp.log
In this logfile I set to 10A in line 30, 42, 48 and 54 I think the 23 inbetween is my normal automation getting in between

At line 56 you see the current offered is 32 A which is again updated to 23 A after 20s by my automation.
I know I am doing far to quickly but this also happens if I modify the current once per minute.

[rbb-dev]

in the space of 10 seconds, you send 4 csChargingProfiles to the charger.
After that, it reports that Current.Offered = 32A
i think you're confusing it.. its way to frequent
try reducing the frequency to 60 sends and see if it continues.

[taste66]

@rbb-dev I know I did it to fast, this was just a way to easy reproduce. In my standard automation I do it every 60s it still happens but far less frequent so more difficult the get the exact logging. The effect however is the same.
Why do you expect it goes wrong if I do it this frequent? It does acknowledge each current setting.

[rbb-dev]

on my charger its little linux SoC is jumping to 80% CPU for up to 10-15 seconds when its processing rate changes as it tries to connect to gpios and so some magic.
in your logs I didn't see you setting up the 32A but charger just goes to it automatically.
Its definitely an issue on the charger side, but workaround is simple.
1 - for the duration of the charge, set the sample period to 10 seconds (if your charger can handle it) (example below)
2 - Monitor sensor.charger_ac_current_import (or whatever your charger name is)
3 - If it is 32, set it to whatever your other automations determine is available power.
4 - set the sample rate back to 60
Basically you will force the charger to go down to right Amps when it decides to to go crazy.
It's not elegant, but it's a workaround. A 10-second breach on a phase limit should be okay unless you have a smart circuit breaker, which will see the overload and trip

alias: Chager AC - Set Metering to 10 seconds during Solar charging
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.charger_ac_status_connector
    from: Preparing
    to: Charging
conditions:
  - condition: and
    conditions:
      - condition: numeric_state
        entity_id: sensor.home_energy_gateway_solar_power
        above: 1
      - condition: time
        after: "08:00:00"
        before: "19:00:00"
        weekday:
          - sat
          - fri
          - thu
          - wed
          - tue
          - mon
          - sun
actions:
  - action: charger_ac.configure
    data:
      ocpp_key: MeterValueSampleInterval
      value: "10"
mode: single

[rbb-dev]

I noticed that you're using ChargePointMaxProfile to change the rate.
Not a good idea.
ChargePointMaxProfile will be written the charger nvram/flash to survive reboots.
you will wear out the flash.
switch to TxProfile, this is runtime only, just need to pass transaction id.
see example below:

alias: Charger AC - Set AC Charging Profile
description: Sets the charging profile based on AC sensor and input values
triggers:
  - entity_id:
      - sensor.charger_ac_transaction_id
      - input_number.penoda_ac_limit
    trigger: state
conditions:
  - condition: state
    entity_id: sensor.charger_ac_status_connector
    state: Charging
  - condition: time
    after: "08:00:00"
    before: "19:00:00"
    weekday:
      - sat
      - fri
      - thu
      - wed
      - tue
      - mon
      - sun
actions:
  - data:
      custom_profile: |
        {
          "transactionId": {{ states('sensor.charger_ac_transaction_id') | int }},
          "chargingProfileId": 1,
          "stackLevel": 0,
          "chargingProfilePurpose": "TxProfile",
          "chargingProfileKind": "Relative",
          "chargingSchedule": {
            "chargingRateUnit": "A",
            "chargingSchedulePeriod": [
              {"startPeriod": 0, "limit": {{ states('input_number.penoda_ac_limit') | int }}}
            ]
          }
        }
      conn_id: 1
    action: charger_ac.set_charge_rate
  - delay:
      hours: 0
      minutes: 0
      seconds: 15
      milliseconds: 0
mode: single

[taste66]

@rbb-dev Thank you, this could for sure be the cause of my problem. If it jumped to 32A it did not help to send the correct value again it had to be a different value. This probably means the charger received the right value but somehow got confused and did not write the correct value to VN-storage. It did detect there was no update if I resend the value and therefore did not write again. Still a bug but with you suggestion above easier to avoid and it avoids my charger gets broken. I will try and let you know the result!

[taste66]

@rbb-dev
my charger is named taste_wb so I changed your 'charger_ac' into 'taste_wb' However I get the error:
Error: Action taste_wb.set_charge_rate not found
This this mean my charger does not support this or is there another problem?

This is the output from the trace I fixed the current to 7 for my test it is set to 10 in the ChargePointMaxProfile

Executed: January 15, 2025 at 6:18:00 PM
Error: Action taste_wb.set_charge_rate not found
Result:
params:
  domain: taste_wb
  service: set_charge_rate
  service_data:
    custom_profile:
      transactionId: 1736960737
      chargingProfileId: 1
      stackLevel: 0
      chargingProfilePurpose: TxProfile
      chargingProfileKind: Relative
      chargingSchedule:
        chargingRateUnit: A
        chargingSchedulePeriod:
          - startPeriod: 0
            limit: 7
    conn_id: 1
  target: {}
running_script: false

[taste66]

I think I found the error. I had to use "ocpp.set_charge_rate" as action this works I get current offered as 7A while the max is 10A
For a test I left it running with a new value every 10s which did not cause any problem for 15 minutes. I think this solved it and indeed the Maximum current slider can be used as the upper limit more or less the same as the HW setting in the charger.
Really happy with your help @rbb-dev

For the record this is what I now have as action:

  actions:                  
    - data:
        custom_profile: |
          {
            "transactionId": {{ states('sensor.taste_wb_transaction_id') | int }},
            "chargingProfileId": 1,
            "stackLevel": 0,
            "chargingProfilePurpose": "TxProfile",
            "chargingProfileKind": "Relative",
            "chargingSchedule": {
              "chargingRateUnit": "A",
              "chargingSchedulePeriod": [
                {"startPeriod": 0, "limit": {{ final_amps | int }}}
              ]
            }
          }
        conn_id: 1
      action: ocpp.set_charge_rate

Where taste_wb is my charger ID and final_amps is my variable which contains the upper limit I calculated.

I do see many other users using the ChargePointMaxProfile setting e.g for solar charging. Mentioning this difference in the documentation and the warning about flash storage would be good I think. @rbb-dev although I have never done this I am willing to try to add this update if you are okay with it.

[rbb-dev]

@taste66 Thanks for bringing this up, and apologies for the oversight. I forgot to mention that I moved ocpp.set_charge_rate to each charge point when they register, since I have 2 chargers and need separate control for both. Right now, this component can handle only a single charger at a time when it comes to setting the charge rate, which is why I had to make that change on my end.

Regarding ChargePointMaxProfile, it’s useful for chargers with multiple connections because it provides power sharing and an overall current limit at the charger’s hardware level. That functionality falls under the OCPP specs so it may be outside the scope of this specific project to implement or warn users about it. I’m not an official contributor here, just sharing what I know. You might want to reach out to @drc38 if you’re interested in contributing a fix , documentation or enhancement. :)

Hope this helps clarify things!

[drc38]

@taste66 sounds like a good idea, you could add a sub-section on solar charging with this detail under the User Guide section https://github.com/lbbrhzn/ocpp/blob/main/docs/user-guide.md

[taste66]

@taste66 sounds like a good idea, you could add a sub-section on solar charging with this detail under the User Guide section https://github.com/lbbrhzn/ocpp/blob/main/docs/user-guide.md

@drc38 Thank you, I will look into this this weekend

[rbb-dev]

If I may suggest, move the calculation of final_amps into a separate template sensor in Helpers. This way, the set_charge_rate automation only needs to track that sensor and the connector state, keeping it independent of the calculation. It also allows you to use a slider to adjust the charging rate whenever needed, which keeps the setup nice and clean.

[drc38]

@rbb-dev are you sure the profiles types are handled differently at a hardware level? As I assume if TXProfile is used you would still want it to persist say a reboot during a charging session.

[rbb-dev]

According to the OCPP specifications, a charging profile must be applied for as long as it remains valid.
It does not state what happens after reboot, its a grey area.
When ValidTo is not specified, the profile must remain in effect until its cleared.
ChargePointMaxProfile and TxDefaultProfile are not transaction-specific, so must be active even after reboot.
Reboot cancels any ongoing transaction, the TxProfile associated with that transaction also becomes invalid.
I tested it on my chargers.
1 - cleared all profiles.
2 - set ChargePointMaxProfile, reboot, power limit still there.

1 - cleared all profiles.
2 - started charging, set TxProfile, pulled the plug on the charger, limit was gone.

Maybe its just my chargers, but that is how it works for me.
Maybe someone can confirm with more brands of chargers?

[drc38]

Thanks, either way it's useful to show how TXProfile charging can be used in the solar automation. Personally I just set the maximum current slider which will use ChargePointMaxProfile

[taste66]

If I may suggest, move the calculation of final_amps into a separate template sensor in Helpers. This way, the set_charge_rate automation only needs to track that sensor and the connector state, keeping it independent of the calculation. It also allows you to use a slider to adjust the charging rate whenever needed, which keeps the setup nice and clean.

Thank you this is indeed a good tip, will also allow me to track the value of final amps. It is based upon the headroom I have on the total power to my house with a minim of 6A and a maximum of 30A and only integer numbers

[taste66]

According to the OCPP specifications, a charging profile must be applied for as long as it remains valid. It does not state what happens after reboot, its a grey area. When ValidTo is not specified, the profile must remain in effect until its cleared. ChargePointMaxProfile and TxDefaultProfile are not transaction-specific, so must be active even after reboot. Reboot cancels any ongoing transaction, the TxProfile associated with that transaction also becomes invalid. I tested it on my chargers. 1 - cleared all profiles. 2 - set ChargePointMaxProfile, reboot, power limit still there.

1 - cleared all profiles. 2 - started charging, set TxProfile, pulled the plug on the charger, limit was gone.

Maybe its just my chargers, but that is how it works for me. Maybe someone can confirm with more brands of chargers?

As a HW guy I think @rbb-dev is right especially because I fond that when the charger does not correct the faulty 32A when send the value again. At least in my Wallbox charger they seem to detect the there is no change and then do not set it again probably to avoid the Flash/I2C prom wear. By experience I now you can break these parts in weeks by writing to it every 30s.