Pulsar Plus: `SetChargingProfile` gets rejected [FW 5.17.87]

[dscho]

Describe the bug

EVCC was working correctly before I upgraded from v0.128.4 to v0.130.1. After upgrading, SetChargingProfile always gets rejected.

Steps to reproduce

1. Connect car to a Pulsar Plus charger
2. observe the log (and the errors in the UI)

Configuration details

log: debug
levels:
  cache: error
  ocpp: trace

meters:
- type: template
  template: senec-home
  usage: grid
  schema: https
  host: 192.168.178.84
  name: grid1
- type: template
  template: senec-home
  usage: pv
  schema: https
  host: 192.168.178.84
  name: bsh
- type: template
  template: senec-home
  usage: battery
  schema: https
  host: 192.168.178.84
  name: senec

chargers:
- type: template
  template: pulsarplus
  name: pulsar

vehicles:
- type: template
  name: id3
  title: id.3
  template: id
  [... login data ...]

loadpoints:
- title: Garage
  charger: pulsar
  mode: pv
  phases: 3
  mincurrent: 6
  maxcurrent: 16

site:
  title: [... title ...]
  meters:
    grid: grid1
    pv:
    - bsh
    battery:
    - senec
  residualPower: 300
  maxGridSupplyWhileBatteryCharging: 50

Log details

Successful SetChargingProfile before update

``` [...] Aug 19 12:06:52 raspberrypi evcc[528]: [site ] DEBUG 2024/08/19 12:06:52 ---- Aug 19 12:06:52 raspberrypi evcc[528]: [lp-1 ] DEBUG 2024/08/19 12:06:52 charge power: 4191W Aug 19 12:06:52 raspberrypi evcc[528]: [site ] DEBUG 2024/08/19 12:06:52 pv power: 4842W Aug 19 12:06:52 raspberrypi evcc[528]: [site ] DEBUG 2024/08/19 12:06:52 battery soc: 49% Aug 19 12:06:52 raspberrypi evcc[528]: [site ] DEBUG 2024/08/19 12:06:52 battery power: -93W Aug 19 12:06:52 raspberrypi evcc[528]: [site ] DEBUG 2024/08/19 12:06:52 grid meter: -139W Aug 19 12:06:52 raspberrypi evcc[528]: [site ] DEBUG 2024/08/19 12:06:52 site power: 68W Aug 19 12:06:52 raspberrypi evcc[528]: [lp-1 ] DEBUG 2024/08/19 12:06:52 !! active phases: 3p = min(0p measured 0p vehicle 3p physical 0p charger) Aug 19 12:06:52 raspberrypi evcc[528]: [lp-1 ] DEBUG 2024/08/19 12:06:52 !! session: chargeRater.chargedEnergy=4.1 - chargedAtStartup=0.0 Aug 19 12:06:52 raspberrypi evcc[528]: [lp-1 ] DEBUG 2024/08/19 12:06:52 charger status: C Aug 19 12:06:52 raspberrypi evcc[528]: [lp-1 ] DEBUG 2024/08/19 12:06:52 soc estimated: 78.28% (vehicle: 77.00%) Aug 19 12:06:52 raspberrypi evcc[528]: [lp-1 ] DEBUG 2024/08/19 12:06:52 vehicle soc: 78% Aug 19 12:06:52 raspberrypi evcc[528]: [lp-1 ] DEBUG 2024/08/19 12:06:52 vehicle soc limit: 80% Aug 19 12:06:52 raspberrypi evcc[528]: [lp-1 ] DEBUG 2024/08/19 12:06:52 vehicle range: 323km Aug 19 12:06:52 raspberrypi evcc[528]: [lp-1 ] DEBUG 2024/08/19 12:06:52 !! active phases: 3p = min(0p measured 0p vehicle 3p physical 0p charger) Aug 19 12:06:52 raspberrypi evcc[528]: [lp-1 ] DEBUG 2024/08/19 12:06:52 pv charge current: min 6A > 5.97A (68W @ 3p, battery: false) Aug 19 12:06:52 raspberrypi evcc[528]: [ocpp ] TRACE 2024/08/19 12:06:52 send evcc: [2,"316577498","SetChargingProfile",{"connectorId":1,"csChargingProfiles":{"chargingProfileId":1,"transactionId":2,"stackLevel":0,"chargingProfilePurpose":"TxProfile","chargingProfileKind":"Relative","chargingSchedule":{"chargingRateUnit":"A","chargingSchedulePeriod":[{"startPeriod":0,"limit":6}]}}}] Aug 19 12:06:52 raspberrypi evcc[528]: [ocpp ] TRACE 2024/08/19 12:06:52 recv evcc: [3,"316577498",{"status": "Accepted"}] Aug 19 12:06:52 raspberrypi evcc[528]: [lp-1 ] DEBUG 2024/08/19 12:06:52 max charge current: 6A Aug 19 12:06:52 raspberrypi evcc[528]: [lp-1 ] DEBUG 2024/08/19 12:06:52 !! active phases: 3p = min(0p measured 0p vehicle 3p physical 0p charger) Aug 19 12:07:22 raspberrypi evcc[528]: [site ] DEBUG 2024/08/19 12:07:22 ---- [...] ```

Restart after update

``` [...] Aug 20 11:59:59 raspberrypi systemd[1]: Stopping evcc... Aug 20 11:59:59 raspberrypi systemd[1]: evcc.service: Succeeded. Aug 20 11:59:59 raspberrypi systemd[1]: Stopped evcc. Aug 20 11:59:59 raspberrypi systemd[1]: evcc.service: Consumed 2h 18min 32.572s CPU time. Aug 20 12:00:35 raspberrypi systemd[1]: Started evcc. Aug 20 12:00:35 raspberrypi evcc[637]: [main ] INFO 2024/08/20 12:00:35 evcc 0.130.1 Aug 20 12:00:35 raspberrypi evcc[637]: [main ] INFO 2024/08/20 12:00:35 using config file: /etc/evcc.yaml Aug 20 12:00:35 raspberrypi evcc[637]: [db ] INFO 2024/08/20 12:00:35 using sqlite database: /var/lib/evcc/evcc.db Aug 20 12:00:35 raspberrypi evcc[637]: [main ] INFO 2024/08/20 12:00:35 listening at :7070 Aug 20 12:00:35 raspberrypi evcc[637]: [ocpp-1] DEBUG 2024/08/20 12:00:35 waiting for chargepoint: 5m0s Aug 20 12:00:56 raspberrypi evcc[637]: [ocpp ] INFO 2024/08/20 12:00:56 charge point connected, registering: evcc Aug 20 12:00:56 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:00:56 recv evcc: [2,"1299419085","StatusNotification",{"info": "","vendorId": "com.wallbox","vendorErrorCode": "","connectorId": 0,"errorCode": "NoError","status": "Available","timestamp": "2024-08-20T11:00:55Z"}] Aug 20 12:00:56 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:00:56 send evcc: [3,"1299419085",{}] Aug 20 12:00:56 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:00:56 recv evcc: [2,"1732414336","StatusNotification",{"info": "","vendorId": "com.wallbox","vendorErrorCode": "","connectorId": 1,"errorCode": "NoError","status": "Preparing","timestamp": "2024-08-20T11:00:55Z"}] Aug 20 12:00:56 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:00:56 send evcc: [3,"1732414336",{}] Aug 20 12:00:57 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:00:57 send evcc: [2,"1337973214","GetConfiguration",{}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"1337973214",{"unknownKey": [],"configurationKey": [{"readonly": false,"key": "AllowOfflineTxForUnknownId","value": "true"},{"readonly": false,"key": "AuthorizationCacheEnabled","value": "true"},{"readonly": false,"key": "AuthorizeRemoteTxRequests","value": "false"},{"readonly": false,"key": "BlinkRepeat","value": "10"},{"readonly": false,"key": "ClockAlignedDataInterval","value": "0"},{"readonly": false,"key": "ConnectionTimeOut","value": "120"},{"readonly": false,"key": "ConnectorPhaseRotation","value": "1.Unknown"},{"readonly": true,"key": "ConnectorPhaseRotationMaxLength","value": "1"},{"readonly": true,"key": "GetConfigurationMaxKeys","value": "50"},{"readonly": false,"key": "HeartbeatInterval","value": "60"},{"readonly": false,"key": "LightIntensity","value": "100"},{"readonly": false,"key": "LocalAuthorizeOffline","value": "true"},{"readonly": false,"key": "LocalPreAuthorize","value": "true"},{"readonly": false,"key": "MaxEnergyOnInvalidId","value": "5000"},{"readonly": false,"key": "MeterValuesAlignedData","value": "Energy.Active.Import.Register"},{"readonly": true,"key": "MeterValuesAlignedDataMaxLength","value": "10"},{"readonly": false,"key": "MeterValuesSampledData","value": "Energy.Active.Import.Register"},{"readonly": true,"key": "MeterValuesSampledDataMaxLength","value": "10"},{"readonly": false,"key": "MeterValueSampleInterval","value": "300"},{"readonly": false,"key": "MinimumStatusDuration","value": "1"},{"readonly": true,"key": "NumberOfConnectors","value": "1"},{"readonly": false,"key": "ResetRetries","value": "0"},{"readonly": false,"key": "StopTransactionOnEVSideDisconnect","value": "true"},{"readonly": false,"key": "StopTransactionOnInvalidId","value": "true"},{"readonly": false,"key": "StopTxnAlignedData","value": ""},{"readonly": true,"key": "StopTxnAlignedDataMaxLength","value": "0"},{"readonly": false,"key": "StopTxnSampledData","value": ""},{"readonly": true,"key": "StopTxnSampledDataMaxLength","value": "0"},{"readonly": true,"key": "SupportedFileTransferProtocols","value": ""},{"readonly": true,"key": "SupportedFeatureProfiles","value": "Core,FirmwareManagement,LocalAuthListManagement,Reservation,SmartCharging,RemoteTrigger"},{"readonly": true,"key": "SupportedFeatureProfilesMaxLength","value": "6"},{"readonly": false,"key": "TransactionMessageAttempts","value": "3"},{"readonly": false,"key": "TransactionMessageRetryInterval","value": "60"},{"readonly": false,"key": "UnlockConnectorOnEVSideDisconnect","value": "true"},{"readonly": false,"key": "WebSocketPingInterval","value": "50"},{"readonly": false,"key": "LocalAuthListEnabled","value": "true"},{"readonly": true,"key": "LocalAuthListMaxLength","value": "5000000"},{"readonly": true,"key": "SendLocalListMaxLength","value": "450"},{"readonly": true,"key": "ReserveConnectorZeroSupported","value": "false"},{"readonly": true,"key": "ChargeProfileMaxStackLevel","value": "1"},{"readonly": true,"key": "ChargingScheduleAllowedChargingRateUnit","value": "Current"},{"readonly": true,"key": "ChargingScheduleMaxPeriods","value": "100"},{"readonly": true,"key": "ConnectorSwitch3to1PhaseSupported","value": "false"},{"readonly": true,"key": "MaxChargingProfilesInstalled","value": "1"},{"readonly": false,"key": "WebSocketUrl","value": "ws://192.168.178.86:8887/evcc"},{"readonly": false,"key": "chargingALimitConn1","value": "16"},{"readonly": false,"key": "AuthEnabled","value": "true"},{"readonly": false,"key": "AuthEnabledOffline","value": "true"},{"readonly": false,"key": "AuthDisabledIdTag","value": "NoAuthorization"},{"readonly": false,"key": "minSoC","value": "9"},{"readonly": false,"key": "maxSoC","value": "97"},{"readonly": true,"key": "SSID","value": "VerticalInfinity"},{"readonly": true,"key": "WiFiSignalStrength","value": "64"},{"readonly": true,"key": "SerialNumber","value": "[number]"},{"readonly": true,"key": "PUK","value": "[number]"},{"readonly": true,"key": "WebSocketUrl","value": "ws://192.168.178.86:8887"},{"readonly": true,"key": "WebSocketUser","value": "evcc"},{"readonly": true,"key": "WebSocketPassword","value": ""} ]}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [2,"3528416686","TriggerMessage",{"requestedMessage":"BootNotification"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"3528416686",{"status": "Accepted"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [2,"1027082133","BootNotification",{"chargePointSerialNumber": "121196","chargePointVendor": "Wall Box Chargers","meterType": "Internal NON compliant","meterSerialNumber": "","chargePointModel": "PLP1-M-2-4","iccid": "","chargeBoxSerialNumber": "121196","firmwareVersion": "5.17.87","imsi": ""}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [3,"1027082133",{"currentTime":"2024-08-20T11:01:01Z","interval":60,"status":"Accepted"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [2,"1795859669","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Active.Import"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"1795859669",{"status": "Accepted"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [2,"2123168264","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Active.Import.Register"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"2123168264",{"status": "Accepted"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [2,"1337052265","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"SoC"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"1337052265",{"status": "Accepted"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [2,"2128483411","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Offered"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"2128483411",{"status": "Accepted"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [2,"1414498378","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Offered"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"1414498378",{"status": "Accepted"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [2,"3531551551","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Import"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"3531551551",{"status": "Accepted"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [2,"968119474","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Voltage"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"968119474",{"status": "Accepted"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [2,"2952143827","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Active.Import,Energy.Active.Import.Register,SoC,Current.Offered,Power.Offered,Current.Import,Voltage"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"2952143827",{"status": "Accepted"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [2,"744373274","TriggerMessage",{"requestedMessage":"MeterValues","connectorId":1}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"744373274",{"status": "Accepted"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [2,"1742209402","MeterValues",{"meterValue": [{"timestamp": "2024-08-20T11:01:01Z","sampledValue": [{"format": "Raw","location": "Outlet","context": "Trigger","measurand": "Power.Active.Import","unit": "W","value": "0.0"},{"format": "Raw","location": "Outlet","context": "Trigger","measurand": "Energy.Active.Import.Register","unit": "Wh","value": "4882904.0"},{"format": "Raw","location": "Outlet","context": "Trigger","measurand": "Current.Offered","unit": "A","value": "16"},{"format": "Raw","location": "Outlet","context": "Trigger","measurand": "Power.Offered","unit": "W","value": "11085"},{"format": "Raw","location": "Outlet","context": "Trigger","phase": "L1","measurand": "Current.Import","unit": "A","value": "0.0"},{"format": "Raw","location": "Outlet","context": "Trigger","phase": "L2","measurand": "Current.Import","unit": "A","value": "0.0"},{"format": "Raw","location": "Outlet","context": "Trigger","phase": "L3","measurand": "Current.Import","unit": "A","value": "0.0"},{"format": "Raw","location": "Outlet","context": "Trigger","phase": "L1-N","measurand": "Voltage","unit": "V","value": "237.0"},{"format": "Raw","location": "Outlet","context": "Trigger","phase": "L2-N","measurand": "Voltage","unit": "V","value": "230.0"} ]} ],"connectorId": 1}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [3,"1742209402",{}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [2,"2636720771","ChangeConfiguration",{"key":"MeterValueSampleInterval","value":"10"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"2636720771",{"status": "Accepted"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 send evcc: [2,"3173741355","ChangeConfiguration",{"key":"WebSocketPingInterval","value":"30"}] Aug 20 12:01:01 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:01 recv evcc: [3,"3173741355",{"status": "Accepted"}] Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] WARN 2024/08/20 12:01:05 deprecated: mincurrent setting is ignored, please remove Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] WARN 2024/08/20 12:01:05 deprecated: maxcurrent setting is ignored, please remove Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] WARN 2024/08/20 12:01:05 deprecated: phases setting is ignored, please remove Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:05 charge total import: 4882.904kWh Aug 20 12:01:05 raspberrypi evcc[637]: [site ] INFO 2024/08/20 12:01:05 site config: Aug 20 12:01:05 raspberrypi evcc[637]: [site ] INFO 2024/08/20 12:01:05 meters: grid ✓ pv ✓ battery ✓ Aug 20 12:01:05 raspberrypi evcc[637]: [site ] INFO 2024/08/20 12:01:05 grid: power ✓ energy ✗ currents ✗ Aug 20 12:01:05 raspberrypi evcc[637]: [site ] INFO 2024/08/20 12:01:05 pv 1: power ✓ energy ✗ currents ✗ Aug 20 12:01:05 raspberrypi evcc[637]: [site ] INFO 2024/08/20 12:01:05 battery 1: power ✓ energy ✗ currents ✗ soc ✓ capacity ✗ Aug 20 12:01:05 raspberrypi evcc[637]: [site ] INFO 2024/08/20 12:01:05 vehicles: Aug 20 12:01:05 raspberrypi evcc[637]: [site ] INFO 2024/08/20 12:01:05 vehicle 1: range ✓ finish ✓ status ✓ climate ✓ wakeup ✓ Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] INFO 2024/08/20 12:01:05 loadpoint 1: Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] INFO 2024/08/20 12:01:05 mode: pv Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] INFO 2024/08/20 12:01:05 charger: power ✓ energy ✓ currents ✓ phases ✗ wakeup ✗ Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] INFO 2024/08/20 12:01:05 meters: charge ✓ Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] INFO 2024/08/20 12:01:05 charge: power ✓ energy ✓ currents ✓ Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:05 phase timer inactive Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:05 pv timer inactive [...] ```

SetChargingProfile is getting rejected/waiting for local authentication (outdated)

``` [...] Aug 20 12:01:05 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:05 send evcc: [2,"557882437","SetChargingProfile",{"connectorId":1,"csChargingProfiles":{"chargingProfileId":1,"stackLevel":1,"chargingProfilePurpose":"TxDefaultProfile","chargingProfileKind":"Absolute","chargingSchedule":{"startSchedule":"2024-08-20T11:01:05Z","chargingRateUnit":"A","chargingSchedulePeriod":[{"startPeriod":0,"limit":6}]}}}] Aug 20 12:01:05 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:05 recv evcc: [3,"557882437",{"status": "Rejected"}] Aug 20 12:01:05 raspberrypi evcc[637]: [site ] DEBUG 2024/08/20 12:01:05 ---- Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:05 charge power: 0W Aug 20 12:01:05 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:05 charge currents: [0 0 0]A Aug 20 12:01:06 raspberrypi evcc[637]: [site ] DEBUG 2024/08/20 12:01:06 pv power: 4691W Aug 20 12:01:06 raspberrypi evcc[637]: [site ] DEBUG 2024/08/20 12:01:06 battery soc: 50% Aug 20 12:01:06 raspberrypi evcc[637]: [site ] DEBUG 2024/08/20 12:01:06 battery power: -1W Aug 20 12:01:07 raspberrypi evcc[637]: [site ] DEBUG 2024/08/20 12:01:07 grid meter: -4167W Aug 20 12:01:07 raspberrypi evcc[637]: [site ] DEBUG 2024/08/20 12:01:07 site power: -3868W Aug 20 12:01:07 raspberrypi evcc[637]: [lp-1 ] ERROR 2024/08/20 12:01:07 charge meter: not available Aug 20 12:01:07 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:07 charge total import: 4882.904kWh Aug 20 12:01:07 raspberrypi evcc[637]: [ocpp-1] WARN 2024/08/20 12:01:07 waiting for local authentication Aug 20 12:01:07 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:07 charger status: B Aug 20 12:01:07 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:07 charge start energy: 4.88e+03kWh Aug 20 12:01:07 raspberrypi evcc[637]: [lp-1 ] INFO 2024/08/20 12:01:07 car connected Aug 20 12:01:07 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:07 vehicle api refresh Aug 20 12:01:07 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:07 pv timer elapse Aug 20 12:01:07 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:07 pv timer inactive Aug 20 12:01:07 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:07 charge total import: 4882.904kWh Aug 20 12:01:12 raspberrypi evcc[637]: [main ] DEBUG 2024/08/20 12:01:12 vehicle status: B (id.3) Aug 20 12:01:12 raspberrypi evcc[637]: [lp-1 ] INFO 2024/08/20 12:01:12 vehicle updated: unknown -> id.3 Aug 20 12:01:12 raspberrypi evcc[637]: [ocpp-1] WARN 2024/08/20 12:01:12 waiting for local authentication Aug 20 12:01:12 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:12 vehicle status: B Aug 20 12:01:12 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:12 vehicle soc: 79% Aug 20 12:01:12 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:12 vehicle soc limit: 80% Aug 20 12:01:12 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:12 vehicle range: 327km Aug 20 12:01:12 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:12 pv charge current: 5.61A = 0A + 5.61A (-3868W @ 3p) Aug 20 12:01:12 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:12 pv disable timer reset Aug 20 12:01:12 raspberrypi evcc[637]: [lp-1 ] DEBUG 2024/08/20 12:01:12 pv timer inactive Aug 20 12:01:12 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:12 send evcc: [2,"2640631095","SetChargingProfile",{"connectorId":1,"csChargingProfiles":{"chargingProfileId":1,"stackLevel":1,"chargingProfilePurpose":"TxDefaultProfile","chargingProfileKind":"Absolute","chargingSchedule":{"startSchedule":"2024-08-20T11:01:12Z","chargingRateUnit":"A","chargingSchedulePeriod":[{"startPeriod":0,"limit":6}]}}}] Aug 20 12:01:12 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:12 recv evcc: [3,"2640631095",{"status": "Rejected"}] Aug 20 12:01:12 raspberrypi evcc[637]: [lp-1 ] ERROR 2024/08/20 12:01:12 max charge current 6A: set charging profile: Rejected Aug 20 12:01:35 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:35 recv evcc: [2,"1317886357","Heartbeat",{}] Aug 20 12:01:35 raspberrypi evcc[637]: [ocpp ] TRACE 2024/08/20 12:01:35 send evcc: [3,"1317886357",{"currentTime":"2024-08-20T11:01:35Z"}] Aug 20 12:01:35 raspberrypi evcc[637]: [site ] DEBUG 2024/08/20 12:01:35 ---- [...] ```

What type of operating system are you running?

Linux

Version

evcc version 0.130.1

[typxxi]

@dscho Also ich habe das Problem mit meiner Pulsar nicht, ein paar andere Themen - aber das nicht. Daher möchte ich anmerken, dass man im Log sieht, dass du Firmware Version 5.17.87 verwendest, ich habe schon Version 6.4.14. Das könnte ein entscheidender Unterschied sein.

Ich habe 5.17.87 und ich sehe kein Update, was ich durchführen kann, also bin ich auch abgeschnitten. Vielleicht auch noch mehr Nutzer, die sich alle hier finden.

Wenn ich sicher bin, dass die Sonne lange scheinen wird, dann probiere ich morgen erneut einen Rollout der 130.4 , wobei ich nur brauch, dass die wieder Überschussladen kann und nicht blind 11 kW verballert. Aktuell haben wir 0,5 kWh Bezug am Tag und der letzte Versuch war kein Zuckerschlecken, sondenr hat 3 h gedauert und endete im Schnellladen spät am Abend ohne Sonne.

[dscho]

Falls jemand compilieren kann würde es auch helfen, commits adf90ec, d0b58ba, 1515a67 und 568c564. Das sind jeweils die Commits vor/nach breaking Changes. Damit könnten wir die Ursache mal eingrenzen.

Ich habe das mal gemacht:

Leider ist EVCC damit immer noch kaputt:

If FW<6 = alteMetode else neu Metode

Das wäre verwandt mit der Best Practice, dass man so eine neue Methode erst mal hinter einem experimentellen Schalter versteckt, und dann abhängig von der Konfiguration Benutzer einlädt, das mal auszuprobieren. Mit so einem Schalter würde ich das wahrscheinlich auch mal wieder austesten, aber für's erste wurde ich etwas zu viel geschockt, als ich nach diversen manuellen Reverts und Re-applys folgenden Fehler bekam, wo mir nur ein Backup, was ich vor einiger Zeit mehr aus Versehen als absichtlich gemacht hatte, heraushalf:

Ich war ja vor dieser Regression sehr glücklich mit EVCC. Hoffentlich kann ich das auch wieder werden.

[dscho]

Vielleicht sollte dieses Issue wieder aufgemacht werden, der Fehler ist ja mitnichten behoben.

[MilkoKA]

Hiermal die Antwort meiner Anfrage bei Wallbox.com warum wir kein Update erhalten: Guten Tag,

vielen Dank, dass Sie sich an den Wallbox-Kundensupport gewandt haben. Wir schätzen Ihre Geduld, während wir Ihre Anfrage bezüglich des Updates auf Version 6.4.19 bearbeiten.

Wir können bestätigen, dass Version 6.4.19 tatsächlich verfügbar ist. Allerdings hängt die Verfügbarkeit dieses Updates vom Herstellungsdatum Ihrer Wallbox ab. Einheiten mit neueren Herstellungsdaten erhalten das Update zuerst. Seien Sie jedoch versichert, dass alle Wallbox-Einheiten letztendlich dieses Update erhalten werden, es kann jedoch etwas Zeit in Anspruch nehmen, je nach Herstellungsdatum Ihres Geräts.

Laut unseren Unterlagen wurde Ihre Wallbox am 19. Juli 2021 hergestellt. Das bedeutet, dass Ihr Gerät das Update erhalten wird, es jedoch etwas länger dauern kann.

Falls Sie weitere Fragen haben oder zusätzliche Unterstützung benötigen, lassen Sie es uns bitte wissen.

Mit freundlichen Grüßen

[dscho]

@MilkoKA danke für das Update. Schade, dass wir bis zu dem ungenannten Datum kein aktuelles EVCC verwenden können.

[typxxi]

Ich dachte nur, da die 128.4 funktioniert und die 129.0 nicht mehr. wurde denn auch in der 128.4 "SetChargingProfile" benutzt um von aus/pv/min+PV/schnell umzuschalten?

das bezweifel ich, denn ich habe auch die 5.17.87 und 129.0 läuft hier, aber alles von 130.* bis 130.6 machte nur Ärger.

[matti1993]

Ja so ist es bei mir auch 0.129.0 läuft alles Super

Wolf Gang @.***> schrieb am Di. 27. Aug. 2024 um 06:51:

Ich dachte nur, da die 128.4 funktioniert und die 129.0 nicht mehr. wurde denn auch in der 128.4 "SetChargingProfile" benutzt um von aus/pv/min+PV/schnell umzuschalten?

das bezweifel ich, denn ich habe auch die 5.17.87 und 129.0 läuft hier, aber alles von 130.* bis 130.6 machte nur Ärger.

— Reply to this email directly, view it on GitHub https://github.com/evcc-io/evcc/issues/15581#issuecomment-2311567263, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGDJPJZK3WCSCEUM2URN36TZTQAUXAVCNFSM6AAAAABM4P7ZR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJRGU3DOMRWGM . You are receiving this because you commented.Message ID: @.***>

[typxxi]

Macht ja keinen Sinn, hier bei EVCC den Druck, den wir haben, abzuladen, wenn am Ende der Hersteller genau wissen muss, was die Ursache ist, denn mit der neuen Firmware, die nur wenige haben dürften, soll der Fehler behoben sein laut @mrhund

@dscho Also ich habe das Problem mit meiner Pulsar nicht, ein paar andere Themen - aber das nicht. Daher möchte ich anmerken, dass man im Log sieht, dass du Firmware Version 5.17.87 verwendest, ich habe schon Version 6.4.14. Das könnte ein entscheidender Unterschied sein.

Daher BITTE das Kontaktformular der WALLBOX PULSAR PLUS GEPLAGTEN kurz mit copy & paste ausfüllen und zwar hier

Wenn wir uns nicht DORT BEI DENEN beschweren, passiert bei denen gar nix, sondern die kriechen in Barcelona langsam von 9 to 5 vor sich her - oder wer weiß, wohin die ihre Entwicklung mittlerweile ausgelagert haben.

Titel: WALLBOX PULSAR PLUS BRAUCHT Firmware 6.4.19

Dann einen Text, der besagt, dass die Pulsar Plus unbrauchbar ist und sich die Kundenbeschwerden auf evcc seit Tagen stapeln mit Verweis auf https://github.com/evcc-io/evcc/issues/15581#issuecomment-2304396454 bzw. https://github.com/evcc-io/evcc/issues/15581#issuecomment-2304396454.

Korrekt ausgefüllt und eingereicht sollte es dann diesen Hinweis geben

und damit wächst der Druck auf dem Kessel an der richtigen Stelle. Bis zur neuen Firmware können wir nur auf 129.x zurückgehen und dort bleiben. Ich habe nun 4 Versuche von 130.0 / 130.2 / 130.4 / 130.6 ERFOLGLOS hinter mich gebracht inkl. restore - und vielleicht war auch noch 130.5 um Mitternacht dabei, aber ohne Druck auf deren WALLBOX Kessel, da passiert bei denen rein gar nix.

Unsere Wallbox ist im Feb. 2023 im Sale bei Lichtblick und nicht bei WALLBOX selber für 250€ gekauft worden und ging Ende Juli 2024 ans Netz zum 2 phasigen e-GOLF laden.

[dscho]

Alles gute Punkte, insbesondere dass auch ich mit Wallbox zusammen arbeiten sollte, was ich bislang noch nicht gemacht habe. Das gebe ich zu, dass ich das hätte tun sollen.

Bevor ich das mache, möchte ich aber wissen, was hier genau seit 0.130 so schief läuft. Denn sonst würde ich selber, so ich denn in den Schuhen eines überarbeiteten Wallbox Support Engineers stünde, reflexartig sagen: wieso, ging doch vor dem Update, muss also ein Software-Fehler sein. Das ist eben auch weiterhin nicht auszuschließen.

wurde denn auch in der 128.4 "SetChargingProfile" benutzt um von aus/pv/min+PV/schnell umzuschalten?

Ja, in der Tat. Da gab es aber etliche Unterschiede in den Parametern, die da mitgegeben wurden (z.B. wurde TxProfile gesetzt anstatt TxDefaultProfile, und das ist nur eine von mehreren, grundsätzlichen Änderungen).

Ich muss mich mal in Go reinfuchsen und in Vite, damit ich da mal in meinem eigenen Fork Funktionen einbauen kann, mit denen diese geänderten Parameter hier zielgerichteter getestet werden können.

Um SetChargingProfile aufzurufen braucht es ja keine Sonne und nicht mal ein angestöpseltes Auto. Und es dauert auch unproduktiverweise jedes Mal ziemlich viel Zeit, wenn ich für jede Parameter -Änderung, egal wie minimal, den kompletten Code neu bauen muss und dann EVCC neu starten (denn da muss ich dann wieder minutenlang warten, bis der OCPP-Handschlag abgeschlossen ist).

Ich denke da z.B. an ein Eingabefeld, mit dem ich ein komplettes, JSON-formatiertes OCPP Kommando absetzen kann. Die Antwort kann ich ja im Log sehen, obwohl es auf lange Sicht noch viel schöner wäre, die Antwort im Web-Browser zu sehen (und das ganze als experimentelle Funktion mit ausreichenden Warnungen für alle Nutzer verfügbar zu machen, die solche Regressionen analysieren wollen, es wird ja erfahrungsgemäß nicht das letzte Mal sein, dass so etwas hilfreich wäre).

Falls jemand anderes hier schon an solcher Funktionalität gearbeitet hat, würde ich mir natürlich gerne die Zeit sparen, das noch einmal zu implementieren. Hat das schon jemand?

[typxxi]

Alles gute Punkte, insbesondere dass auch ich mit Wallbox zusammen arbeiten sollte, was ich bislang noch nicht gemacht habe. Das gebe ich zu, dass ich das hätte tun sollen.

nee, so war das ja an sich nicht gemeint, sondern nur das Zitat von mrhund.

Du hast ja Deinen Beitrag geleistet und das sauber dokumentiert, worauf mrhund uns ja die Hoffnung gab, dass die neue Firmware das Thema lösen würde, so dass nun jeder einfach die neue Firmware verlangen kann und sollte, weil die ein Problem löst.

Und wenn ich das recht verstand, geht es hier ja mal wieder um einen nicht eingehaltenen Standard, der nun in einer evcc Weiterentwicklung einen Fehler nur deshalb verursacht.
Der Fehler ist ja nicht der evcc Weiterentwicklung geschuldet ist, sondern mangelnder Einhaltung des Standards auf Wallbox Seite.

Da ja mrhund klar aufzeigen konnte, dass er nix von den bekannten / unseren Problemem an seiner Wallbox hat und er meinte, dass Du / wir eine veraltete Firmware hätten (sieht ja auch mega alt aus von 5.17.87 nicht zu 6.0 sondern 6.4.19)

liegt der Hund also auf der Wallbox Seite begraben, die ja zumindest die Fehler genau kennen müssen, die sie von 5.17.87 bis zu 6.4.19 behoben haben und dafür sorgen, dass evcc dann unsere Fehler nicht mehr hat.

Von daher geht es um alle Betroffenen Wallbox Pulsar Plus Besitzer, die das Problem für sich selber lösen können, indem sie zuerst per Formular ein Update verlangen wie beschrieben (und in der Zwischenzeit auf evcc 129.x zurückgehen und dort bleiben, denn ich glaub kaum, dass es von evcc eine Lösung geben wird, wenn wir wissen, dass es ein Hersteller Thema ist).

Ich fand es auch mal spannend, wie träge so ein Hersteller selbst als Sponsor sein kann, der die Sache an sich unterstützt, denn er ist ja Sponsor. Da hätte ich gedacht, dass die evcc Entwickler einen roten Teppich in das Entwicklungslabor von Wallbox bekämen, um genau solche Situationen wie jetzt zu vermeiden, denn je früher Fehler entdeckt und verfolgt werden, je besser das Produkt.

Schauen wir mal, wann eine inhaltliche Antwort kommt. Am Freitag ruf ich dann mal an, wenn nix kommen sollte.

[premultiply]

wie träge so ein Hersteller selbst als Sponsor sein kann, der die Sache an sich unterstützt, denn er ist ja Sponsor.

Wallbox.com ist leider kein Sponsor.

Da hätte ich gedacht, dass die evcc Entwickler einen roten Teppich in das Entwicklungslabor von Wallbox bekämen, um genau solche Situationen wie jetzt zu vermeiden, denn je früher Fehler entdeckt und verfolgt werden, je besser das Produkt.

Wir freuen uns aber u. a. genau aus diesem Grund immer über Sponsoren und Unterstützer des Projekts.

[mrhund]

Macht ja keinen Sinn, hier bei EVCC den Druck, den wir haben, abzuladen, wenn am Ende der Hersteller genau wissen muss, was die Ursache ist, denn mit der neuen Firmware, die nur wenige haben dürften, soll der Fehler behoben sein laut @mrhund

@typxxi Ja, es ist korrekt, dass ich diesen Fehler nicht habe, meine Box lädt und lässt sich durch EVCC starten und stoppen. ABER ich habe folgendes Problem mit der der 6.4.14: #15490 Das ist auch nicht viel besser, weil er bei PV bzw. MIN+PV auf 16A springt, egal wieviel Solarstrom da ist und mit voller Leistung lädt. Auch hier kein Fehler von EVCC, sondern der Firmware des Geräts. Ich hab mir dafür einen Workaroound gebaut https://github.com/mrhund/Wallbox_Pulsar-OCPP-Charge_Current-Fix und damit ist das OK für mich - aber Lösung ist es auch keine.

Zum Wallbox.com Support: Ich habe dort schon 2 Mal einen Case deswegen aufgemacht und wurde jedes Mal wieder zugemacht mit dem Kommentar, dass sie über ihr Remote Tool sehen, dass meine Box ja laden würde und was denn mein Problem sei - obwohl ich ihnen die Tracelogs von EVCC geschickt habe. Beim letzten Mal habe ich dann gesagt, ich will mit einem Manager sprechen, seither keine Antwort mehr. Schade, ich hab die Box und die Vorgängerversion schon länger und war total zufrieden, aber OCPP haben sie nicht im Griff :(

[dscho]

Ich hab mir dafür einen Workaroound gebaut https://github.com/mrhund/Wallbox_Pulsar-OCPP-Charge_Current-Fix

@mrhund Das ist interessant, danke, dass Du das geteilt hast. Damit kann ich ja eigentlich auch Workarounds in EVCC selber einbauen, diese Schleife muss ja gar nicht unbedingt in einem externen C# Projekt ausgeführt werden.

[mrhund]

Damit kann ich ja eigentlich auch Workarounds in EVCC selber einbauen, diese Schleife muss ja gar nicht unbedingt in einem externen C# Projekt ausgeführt werden.

Klar, kannst du - andig meinte nur:

Ein Mischmasch aus Hersteller-Api und Ocpp können/wollen wir nicht unterstützen. Eine gute Ocpp Lösung wollen wir aber!

Daher ist es ein externes Programm...und ich kann C# besser als Go ;)

[typxxi]

Keine neuen Erkenntnisse. Die WB mag SetChargingProfile nicht. Es ist unklar, was genau sie daran nicht mag. Entweder:

• findet jemand raus welche Änderung genau die Box nicht mag
• gelingt das FW-Update von dem wir wissen, dass es funktioniert
• oder bewegt den Hersteller dazu eine Aussage zu treffen

Für uns gibts hier grad nix zu tun. Ich würde das Issue mangels neuer Erkenntnisse dann schließen.

Jein, ich stehe im Kontakt mit Wallbox und es geht nun hin und her, wieso es deren Problem ist. EVCC ignorieren die zuerst und teilen nur mit, dass es keine neuere FIrmware gäbe as die 5.17.87.

So, wie ich das bisher verstanden habe, benutzt und folgt ihr den Standards, an die sich wallbox nicht zu halten scheint, zumal ja die letzte Firmware eine Korrektur enthalten muss, dass es sehr wohl laufen kann mit evcc.

Um welchen Standard geht es da nun, den OCPP , oder ?

Die wollen von mir sozusagen den Nachweis, dass der schwarze Peter auf deren Seite liegt und ich kann nur sagen, dass ihre OCPP Umsetzung beim PUnkt SetChargingProfile nicht gemäß dem Standard erfolgt.

Oder wie muss das richtig lauten, dass der Hersteller in Zugzwang gerät, endlich mehr zu tun als das aktuell Erkennbare ?

Wenn ich die richtige Anspruchsgrundlage habe, die nur von Euch kommen bzw. beschrieben werden kann, dann kann ich auch den Druck machen als Kunde, der ja nur abraten kann vom aktuellen Service "Mangel".

Danke

[typxxi]

Zum Wallbox.com Support: Ich habe dort schon 2 Mal einen Case deswegen aufgemacht und wurde jedes Mal wieder zugemacht mit dem Kommentar, dass sie über ihr Remote Tool sehen, dass meine Box ja laden würde und was denn mein Problem sei - obwohl ich ihnen die Tracelogs von EVCC geschickt habe. Beim letzten Mal habe ich dann gesagt, ich will mit einem Manager sprechen, seither keine Antwort mehr. Schade, ich hab die Box und die Vorgängerversion schon länger und war total zufrieden, aber OCPP haben sie nicht im Griff :(

Danke, dass Du Dich so fix gemeldet hast, denn ich habe Deinen Hinweis als Beleg angenommen, dass deren Firmware die Ursache für die Fehlfunktion an der Stelle ist.

Für mich ist das schwer nachzuvollziehen, was da überhaupt Sache ist und abgeht, da ich erst seit 1 Monat die Box im Einsatz habe, aber seit 2 Jahren mitgelesen habe, bevor ich die im Sale 2023 für 250€ bei Lichtblick kriegen konnte - oder fürs gleiche Geld eine Heidelberg schlag mich tot.

Sinngemäß schreibst auch Du, dass die Wallbox an einer schlampigen OCPP Umsetzung krankt und die dies Problem verantwortet und dann bei Dir mit der neuen Firmware ein Folgeproblem auslöst.

Also sind wir nach dem Problem von jetzt noch nicht durch - und ich kann mich auch an Dich oder einen Thread von Pulsar / Plus / Commander Beschwerden erinnern, wo sinngemäß ein Vollgasladen aus dem Netz statt PV Überschuss beklagt worden war. Das hatte ich nicht.

Aber wenn ich Dich richtig verstehe - und das ist jetzt der Kernpunkt - sind die Unzulänglichkeiten in der OCPP Implementierung zu suchen, die einem weltweiten Standard folgen müssen, die Wallbox aber zu ignorieren scheint, bis einer in den Allerwertesten tritt.

Entscheidend ist der Punkt, dass Wallbox behauptete, dass die Pulsar Plus Standard den OCPP erfülle. Irgendwo stand mal was von der Version 1.6 oder sogar 1.6j , wenn ich mich nicht irre.

Und das ist der kriegsentscheidende Punkt, dass sie diesen Mangel dann abstellen müssen und auch haften. Zumindest 1 Jahr und danach müssen wir beweisen, dass es deren Fehler war und ist.

Hat mir jedenfalls sehr geholfen, den ganzen Murks zu verstehen, der auch noch vor mir liegen mag, denn ich bin mit Vollgas und voller Zufriedenheit in die 4 Nutzungswoche gegangen, als ich einen Frontalzusammenstoß mit 1.30.0 erlitt, wo nix ging oder aber nur Vollgas.

Hat gedauert, bis ich geblickt habe, wie simpel es ist, zurück in den sicheren Hafen von 1.29 via dem BACKUP & Restore des Addon 1.29 zu kommen. Jetzt weiß ich auch, wofür die wichtig sind, denn bisher hatte ich die kleinen Dinger immer wieder mal fix gelöscht, weil ich viele Backups bei HA fahre (tgl. 1 oder 2 volle, einmal regelmäßig 22 Uhr und dann nach Entwicklungsmeilensteinen bei HA).

Und seit dem 130.0 hab ich 4 oder 5 Versionen bis 130.6 heut morgen getestet und bin gescheitert, wobei ich als HA user nur bedingt an die Fehlerreports komme bzw. diese generieren kann, weil mir ja die evcc start commands fehlen.

Ich hoffe, Wallbox reagiert. Meine Empfehlung an unsere amerikanischen Freunde für Überschuss Laden mit evcc und Pulsar Plus von vorletzter Woche habe ich widerrufen. Denn das tut ja gar nicht mehr.

In den USA gab und gibt es die Box von FISKER mit Fisker Logo aus der Insovenz für 250$. Daher die Fragen, ob man die empfehlen kann.

Dann lass uns mal gemeinsam schauen, wie wir das Ding flott bekommen mit anderen evcc WALLBOX Nutzern.

Wie hast Du dort denn einen CASE eröffnen können ? Per Kontaktformular oder ist das eine andere Prozedur ?

[dscho]

Wie hast Du dort denn einen CASE eröffnen können ?

Wenn man auf der my.wallbox.com Website links unten auf diesen Knopf drückt:

und dann immer weiter macht, bis die Standard-Anworten ausgeschöpft sind, dann kommt irgendwann diese Meldung:

Wenn man das gleiche in englischer Sprache macht, dann kommt dies hier:

Dieser "SUBMIT CASE" Link geht im Englischen hierher und im Deutschen zu dem hier, also zu dem Kontaktformular, das Du schon hattest. Das ist also so ein "Case".

[typxxi]

FEEDBACK WALLBOX VON HEUTE FRÜH:

1. ihre Wallbox ist toll, sie hat die "letzte" verfügbare Firmware - aber mein evcc funktioniert nicht und juckt sie kaum
2. immerhin ein kleines Einlenken, denn nun hat die elendige Anweiserei mit den Schritten, die ich in App / Cloud und Wallbox durchführen und mit Screenshot belegen soll, ein Ende, wo alle wissen, dass die Pulsar Plus in App & Cloud glänzen wird, aber bei OCPP Integration Probleme haben muss, wenn evcc set charge profile anfasst. Ich hatte genug vom Kabel reinstecken und Screenshot schicken.
3. Das ist aber erst passiert nach der letzten Mail nun mit Screenshots vom Forum, wonach in der Firmware 6.4x ein WALLBOX Fehler behoben worden sein muss, so dass EVCC dort diesen Fehler nicht mehr hat, aber alle 5.X Kunden im Dunkeln sitzen. Auf keinen Link wurde zuvor eingegangen, auf kein Zitat, erst mit dem SCREENSHOT von hier kam es zum Einlenken.
4. RESULTATE "sinngemäß":
   • wird es für die 5.x Kunden auch eine neue Firmware für die Pulsar Plus geben, aber ohne Auskunft wann.
   • wurde jetzt mein Vorgang "weitergeleitet"

Natürlich ohne die Antworten auf "an wen" und "bis wann" es ein Feedback oder Lösung geben soll.

Ich kann nur jedem Pulsar Plus Besitzer mit Firmware 5.X raten, diesen Screenshot einzufügen

und Druck zu machen, dass mit der 6.4* Firmware der besagte OCPP Fehler zu SetChargingPoint Profile nicht mehr auftritt und es damit einen Fehler auf Seiten von Wallbox gibt, den OCPP Standard nicht eingehalten zu haben, weil evcc mit dem Rest der Welt der Wallboxhersteller, der sich an den OCPP Standard, keine Probleme an der Stelle hat.

Jede weitere Mail wird helfen, das Thema zu eskalieren. Und ich habe meine Kaufempfehlung in den USA zurückgezogen unter Verweis auf die Probleme hier, denn in den USA wird Pulsar Plus zur Zeit für 250$ verramscht u.a. von vormals Fisker.

Es ist aber besser, jeder schickt seinen eigenen Screenshot von diesem ANDIG Kommentar hier

Ich hoffe, hier finden sich die Pulsar Plus Betroffenen = Geschädigten und erheben ihre Stimme, damit es voran geht. Ansonsten warten wir halt länger, also alle vor 2023 gebauten Pulsar Plus Besitzer (was eine Menge sein dürften, wenn die seit 2017 auf dem Markt ist)

[typxxi]

Wenn man auf der my.wallbox.com Website links unten auf diesen Knopf drückt:

Ok, genau das Kontaktformular hatte ich am Ende auch, dachte aber, Du hättest so etwas wie einen Datenbanklink , wo der Bearbeitungsstatus für alle ersichtlich wäre, was im Falle von 5.X Firmware mit evcc Problem SetchargeProfile dann auch ersichtlich wäre.

So hilft nur, dass sich viele hier zum Erstellen von einem Fall bei Wallbox aufraffen und den Sachverhalt per Screenshot so eintüten, dass Wallbox inhaltlich reagieren muss a la: ja , da wird was mit Firmware 6.x kommen und ggf. "Weiterleiten"

Das ist dann ein Eingeständnis von seiten Wallbox, dass dort Handlungsbedarf besteht.

DUMMERWEISE ist das aber nur die 1. Hürde, denn @mrhund hat ja schon die nächste Hürde ausgemacht, dass bei seiner Pulsar Plus mit 6.4 sinngemäß keine Überschussladen mehr stattfindet sondern ich meine Vollgasladen.

Aber wir 5.7x er Firmware Kunden müssen erst einmal die Hürde 6.4 nehmen und können dann erst auf gleichem Wege mit Fällen das Vollgasladen beklagen.

[stm9x9]

ob das mit dem Druck machen so klappt? Ich hoffe, da passiert intern was bei denen. Meine aktuell erhaltene Antwort:

vielen Dank, dass Sie sich an den Wallbox-Kundensupport gewandt haben. Wir schätzen Ihre Geduld, während wir daran arbeiten, Ihre Anfrage zu lösen.

Ich möchte Ihnen mitteilen, dass ich Ihre Anliegen mit unserem Produktteam besprochen habe und sie bestätigt haben, dass ein Update (Version 6.4.19) bald veröffentlicht wird. Allerdings haben wir derzeit noch kein genaues Veröffentlichungsdatum oder einen Zeitrahmen.

Sollten Sie weiterhin Probleme mit Ihrer aktuellen Version haben, können Sie vorübergehend zur vorherigen Version im EVCC (0.129x) zurückkehren.

Wir danken Ihnen für Ihr Verständnis und stehen Ihnen weiterhin zur Verfügung, um Sie bei diesem Prozess zu unterstützen.

[typxxi]

ob das mit dem Druck machen so klappt? Ist ganz simpel: Entwicklungkapazität ist immer limitiert und die Fraktion an Kunden wie hier die Pulsar Plus EVCC Nutzer, die am lautesten schreien und Stress machen kriegen die Priorität für eine Lösung immer dann, wenn ein Hinauszögern zu Produkt- und Imageschaden führen kann.

Wallbox hat lange Produktzyklen wie bei der Pulsar, also müssen die sehr darauf bedacht sein, dass alles in der Balance bleibt.

Hast Du Deine Antwort genau ein 2. Mal gelesen ?

Du hast etwas, was kein anderer hatte: "6.14.19 bald veröffentlicht wird" Bald hatte noch kein anderer Supporter so an uns Kunden mitgeteilt , denn die haben das generell offen gehalten. Jedenfalls wenn wir nicht unseren Arsch hoch kriegen, dann kann uns niemand helfen, sondern wir werden wie Lämmer zur Schlachtbank geführt, die sich halt nicht wehren.

Wenn jede Woche nur 1 Beschwerde wegen OCPP und offensichtlichen Wallbox Entwicklungsfehler eintrudelt , dann hat der Punkt niedrige Prio. Wenn aber 5 oder 10 in einer Woche x und noch dazu aus einem Spezialisten Forum kommen, dann wird es Zeit an der Prio zu schrauben.

War selbst bei Daimler und bei Audi so, wer wem wie auf die Zehenspitzen trat oder gar einen Vorstand kannte und so am Sonntagabend beim Golfen ein Thema unterschob, was Montag früh höchste Prio bekam und am Freitag noch unter "im neuen Jahr vielleicht einmal " gelaufen war.

Von daher, alle anstoßen, die hier sind und früher oder später von diesem oder einem anderen Problem wieder eingeholt werden. Wer heute 6 was auch immer hat, wird sich ja auch freuen, wenn wir 5er beim 6er Club eintrudeln , um Druck zu machen bei dem Problem, unter dem die 6er Kunden leiden wie "Vollgas Laden" statt Überschuss.

[Frintrop]

Also ich bin auch mit dem Wallbox Support im Kontakt...

Erste Antwort:

_Bitte beachten Sie, dass Sie ein Rollback auf die vorherige Softwareversion von Evcc durchführen müssen. Dies wird Ihnen helfen, das Problem zu lösen, bis Sie das letzte Update erhalten haben, was hoffentlich gut funktioniert.

Sollte das Problem weiterhin bestehen, können wir Ihnen gerne weiterhelfen._

Bin auf die zweite Antwort gespannt..

[stm9x9]

Ist das hier eigentlich auch ein bekanntes Problem mit der alten Firmware? Meine Pulsar sperrt sich immer wieder selbstständig (oder evcc macht da doch was in die Richtung, was aber hier immer als nicht möglich bezeichnet wurde) und ich muß die Wallbox komplett aus der OCPP-Steuerung rausnehmen, dann manuell entsperren in der App und dann wieder unter OCPP-Kontrolle bringen. Was also zwei Neustarts bedeutet, massig Zeit kostet und immer wieder das Risiko mit der aktuellen evcc-Version, daß die Verbindung zwischen evcc und Wallbox nicht zustande kommt ... :-/ Im Log sieht das so aus:

[ocpp-1] WARN 2024/08/29 22:22:25 failed to start remote transaction: Rejected

[mfuchs1984]

In der nächsten Nightly gibt es eine neue Option stacklevelzero: true, diese führt bei der ABB TerraAC dazu, dass das Charging profile akzeptiert wird, vllt. hilft's ja auch bei der Pulsar.

[mrhund]

Ich habs zum 2nd Level Support geschafft. Man hat meine Firmware von 6.4.14 auf 5.5.11 downgegraded und ich soll testen. Überraschung: Jetzt hab ich das "SetChargingProfile rejected" problem. Ich hab ziemlich direkt und energisch zurgeschrieben, dass sie das ja schon lange wissen müssen und endlich die Logfiles anschauen sollen.. mal schauen.

[andig]

Bei der ABB hat ja stacklevelzero geholfen. Hast Du das mal ausprobiert?

[typxxi]

Ich habs zum 2nd Level Support geschafft. Man hat meine Firmware von 6.4.14 auf 5.5.11 downgegraded und ich soll testen. Überraschung: Jetzt hab ich das "SetChargingProfile rejected" problem. Ich hab ziemlich direkt und energisch zurgeschrieben, dass sie das ja schon lange wissen müssen und endlich die Logfiles anschauen sollen.. mal schauen.

Wenn es nicht beim Lachen auch noch so weh täte, aber willkommen im Club (zurück der 5 er Firmware Freunde). Ich dachte, Du kämpfst schon für uns den Weg zur 6.5 frei und zwar mit richtigem Überschuss Laden statt dem von Dir beschriebenen Vollgas Laden.

Bin gespannt, wann Du wieder zufrieden sein wirst, bin jetzt auf 1.29 und sehe zu , dass ich dort bleibe, außer jemand gibt Entwarnung, nur dann würde ich auf Deinem Stand landen und wäre auch nicht glücklich.

DANKE fürs Update

[typxxi]

Ich habs zum 2nd Level Support geschafft. Man hat meine Firmware von 6.4.14 auf 5.5.11 downgegraded und ich soll testen. Überraschung: Jetzt hab ich das "SetChargingProfile rejected" problem. Ich hab ziemlich direkt und energisch zurgeschrieben, dass sie das ja schon lange wissen müssen und endlich die Logfiles anschauen sollen.. mal schauen.

Hast Du mal Andigs Rat von hier getestet? Vielleicht hilft das ja.

[mrhund]

Hast Du mal Andigs Rat von hier getestet? Vielleicht hilft das ja.

Bring ich leider mit 130.7 nicht zum Laufen: FATAL 2024/09/02 14:37:17 cannot create charger 'pulsarplus-1': cannot create charger type 'template': invalid key: stacklevelzero

Vielleicht sieht wer den Fehler:

chargers:
- type: template
  template: pulsarplus 
  name: pulsarplus-1
  stacklevelzero: true
  remotestart: true

[mfuchs1984]

Schon mit dem allgemeinen OCPP Templates versucht? Oder falls das nicht geht, mit dem ocpp-abb Template?

[andig]

@mrhund stacklevel is not exposed via templates. Try:

chargers:
- type: ocpp
  name: pulsarplus-1
  stacklevelzero: true
  remotestart: true

If that works we can add a template.

[Frintrop]

@andig @mrhund

also der SetTransaction Fehler scheint weg zu sein... OutOfSync wäre neu.

Mit @andig ´s config Vorschlag / evcc 0.130.7

chargers:

• name: WallboxLinks

  type: template

  template: pulsarplus

  type: ocpp

  timeout: 1m

  stationid: 102249 remotestart: true stacklevelzero: true

• name: WallboxRechts

  type: template

  template: pulsarplus

  type: ocpp

  timeout: 1m

  stationid: 65065 remotestart: true stacklevelzero: true

lp-2 ] DEBUG 2024/09/03 11:32:11 charge total import: 4327.592kWh [lp-2 ] DEBUG 2024/09/03 11:32:11 charger status: A [lp-2 ] WARN 2024/09/03 11:32:11 charger out of sync: expected disabled, got enabled [lp-2 ] DEBUG 2024/09/03 11:32:11 charger enable [ocpp ] TRACE 2024/09/03 11:32:11 send 65065: [2,"2138047065","SetChargingProfile",{"connectorId":1,"csChargingProfiles":{"chargingProfileId":1,"stackLevel":0,"chargingProfilePurpose":"TxDefaultProfile","chargingProfileKind":"Absolute","chargingSchedule":{"startSchedule":"2024-09-03T09:32:11Z","chargingRateUnit":"A","chargingSchedulePeriod":[{"startPeriod":0,"limit":0}]}}}] [ocpp ] TRACE 2024/09/03 11:32:11 recv 65065: [3,"2138047065",{"status": "Accepted"}] [lp-2 ] DEBUG 2024/09/03 11:32:11 charger disable [lp-2 ] DEBUG 2024/09/03 11:32:11 wake-up timer: stop [ocpp ] TRACE 2024/09/03 11:32:13 recv 65065: [2,"1461082220","Heartbeat",{}] [ocpp ] TRACE 2024/09/03 11:32:13 send 65065: [3,"1461082220",{"currentTime":"2024-09-03T09:32:13Z"}] [ocpp ] TRACE 2024/09/03 11:32:17 send 65065: [2,"3034079935","TriggerMessage",{"requestedMessage":"MeterValues","connectorId":1}] [ocpp ] TRACE 2024/09/03 11:32:17 recv 65065: [3,"3034079935",{"status": "Accepted"}] [ocpp ] TRACE 2024/09/03 11:32:17 recv 65065: [2,"1473968383","MeterValues",{"meterValue": [{"timestam

[andig]

Vollständiges Log?

[Frintrop]

Vollständiges Log?

evcc-20240903-142716-debug.log

[mfuchs1984]

Im Log fehlt der Start von evcc und die ocpp traces. Ansonsten scheint lp-1 zu funktionieren und ein Fahrzeug zu laden ohne Fehlermeldung. Lp-2 meldet expected disabled got enabled. Was ist denn der Unterschied zwischen den beiden?

[typxxi]

@mrhund stacklevel is not exposed via templates. Try:

chargers:
- type: ocpp
  name: pulsarplus-1
  stacklevelzero: true
  remotestart: true

If that works we can add a template.

off topic: ich wollte wissen, wieso Dein code bunt ist und der von anderen nicht. Hab es Dank des Zitats eben gesehen:

wenn man die Zeilen in CODE Marken setzt und mit einer '''yaml beginnt, dann sollte es bunt werden, von daher hat es sich erledigt, wenn das Beispiel hier funktioniert

chargers:
- type: ocpp
  name: pulsarplus-1
  stacklevelzero: true
  remotestart: true

und hier dann ohne Farbe

- type: ocpp
  name: pulsarplus-1
  stacklevelzero: true
  remotestart: true

Da es für andere auch hilfreich sein kann, lass ich das mal stehen. Wer mehr sehen will, der kann ja hier zitieren und sieht dann, wie es geht.

[mrhund]

@mrhund stacklevel is not exposed via templates. Try:

chargers:
- type: ocpp
  name: pulsarplus-1
  stacklevelzero: true
  remotestart: true

If that works we can add a template.

Config funktioniert - aber leider nein, ändert nix am Verhalten der Box.

[andig]

Schaffen wir das konkreter? Mit den üblichen Logfile? Von aussen ist nicht zu sehen, ob das Problem noch das gleiche ist...

[Frintrop]

Im Log fehlt der Start von evcc und die ocpp traces. Ansonsten scheint lp-1 zu funktionieren und ein Fahrzeug zu laden ohne Fehlermeldung. Lp-2 meldet expected disabled got enabled. Was ist denn der Unterschied zwischen den beiden?

lp-1 meldet das auch ab und zu ...

[lp-1 ] WARN 2024/09/06 14:13:48 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:13:48 charger disable [lp-1 ] WARN 2024/09/06 14:15:08 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:15:08 charger disable [lp-1 ] WARN 2024/09/06 14:16:43 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:16:43 charger disable [lp-1 ] WARN 2024/09/06 14:17:50 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:17:50 charger disable [lp-1 ] WARN 2024/09/06 14:20:07 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:20:07 charger disable [lp-1 ] WARN 2024/09/06 14:22:08 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:22:08 charger disable [lp-1 ] WARN 2024/09/06 14:23:57 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:23:57 charger disable [lp-1 ] WARN 2024/09/06 14:25:53 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:25:53 charger disable [lp-1 ] WARN 2024/09/06 14:27:41 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:27:41 charger disable [lp-1 ] WARN 2024/09/06 14:29:09 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:29:09 charger disable [lp-1 ] WARN 2024/09/06 14:30:39 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:30:39 charger disable [lp-1 ] WARN 2024/09/06 14:31:39 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:31:39 charger disable [lp-1 ] WARN 2024/09/06 14:32:40 charger out of sync: expected disabled, got enabled [lp-1 ] DEBUG 2024/09/06 14:32:40 charger disable

[Frintrop]

PS: Ich habe übrigens zwei identische Wallbox Commander 2.

[andig]

Schaffen wir das konkreter? Mit den üblichen Logfile?

Sieht nicht so aus :(

[cdyna43]

Ladesteuerung scheint grundsätzlich zu funktionieren. Allerdings habe ich jetzt den bisher noch nicht aufgetretenen Fehler "cannot create vehicle", obwohl ich daran in der evcc.yaml nichts geändert habe.

Logs (hoffentlich die richtigen):

evcc-20240908-092644-debug.log evcc-20240908-092715-trace.log

[mfuchs1984]

Es sieht so aus, als hätte evcc keinen Internetzugriff. Sowohl der Zugriff auf die BMW und VW API als auch auf den evcc update server schlagen im log fehl.

[cdyna43]

Hm, ich habe ja über Online-Zugriff die Logs runtergeladen. Internet funktioniert also grundsätzlich....

Wollte zum Testen zurück zur 129.0. Jetzt kommt dieser Fehler: ERROR 2024/09/08 10:18:55 version check failed: GET https://api.github.com/repos/evcc-io/evcc/releases/latest: 403 API rate limit exceeded for 176.198.247.222. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.) [rate reset in 17m33s] (installed: 0.129.0) Was ist nun?

Edit: Funktioniert aber trotzdem (die 0.129.0).

[cdyna43]

So, noch einmal Update auf die 0.130,7 und dann alles neu gestartet.

Es hat lange gedauert aber ES SCHEINT JETZT ALLES ZU FUNKTIONIEREN!

(Leider scheint aber gerade nicht die Sonne, ich habe also manuell zwischen "aus", "PV" und "schnell" umgeschaltet, um verschiedene Ladeleistungen zu erhalten. Das hat aber funktioniert.)

[typxxi]

Bei mir ist auch die 5.17.87 die aktuellste. damit begann Deine Geschichte und jetzt mit 130.7 ist nun alles gelöst - oder wie ist das heute zu verstehen?

Was hast Du alles geändert seit 129 nun geändert?

remotestart: true

und noch mehr ?

Ich hab die letzten WOchenenden jeweils fleißig installiert und jedesmal mich auf 129 zurückziehen dürfen, so dass ich jetzt keine Lust mehr hatte. Und im RElease Log von heut früh stand auch nix drin, dass WALLBOX Wallboxen nun wieder happy seien und set charging profile kein Problem mehr sei.

Wäre gut, wenn ich von Dir die Details kriege, dann kann ich unsere 5.17er auch auf 130.7 hochziehen.

DANKE

[cdyna43]

So sieht es in der evcc.yaml jetzt aus:

chargers:
- type: ocpp
  stationid: abc000
  connector: 1  
  name: wallbox4
  stacklevelzero: true 
  remotestart: true

Alles andere ist unverändert geblieben.

[mrhund]

Schaffen wir das konkreter? Mit den üblichen Logfile?

Sieht nicht so aus :(

@andig Sorry für die späte Antwort. Ich hab die Logs selbst gelesen und keinen Unterschied feststellen können. Inzwischen bin ich auf 130.8 + Firmware 6.4.14, gleiche Config wie oben (remotestart + stacklevelzero) da verhält es sich folgermaßen:

Start EVCC -> Auto nicht angesteckt -> "charger out of sync: expected disabled, got enabled", in einer Schleife. Rest geht. charger out of sync.log

ABER: Ich lade jetzt schon 1 Stunde mit MIN+PV bei Regenwetter und er ist noch nicht auf 16A gesprungen :o Ich bleib dran.

P.S. Manuelles hin + herschalten zwischen "Schnell" und "MIN+PV" funktionert auch, aber mit seltsamen Zwischenschritten, die wohl von EVCC angefordert werden: 16A -> 6A -> 12.3A -> 6A manual_switch.log

PPS. Leider zu früh gefreut. Nach Stop + Start mit MIN+PV nach einiger Zeit, startet er gleich mit 16A und bleibt dabei. Stop_Start_16A.log

[typxxi]

So sieht es in der evcc.yaml jetzt aus:

chargers:
- type: ocpp
  stationid: abc000
  connector: 1  
  name: wallbox4
  stacklevelzero: true 
  remotestart: true

Alles andere ist unverändert geblieben.

Leider hab ich noch type: pulsar

Von daher die Frage, diese 3 Zeilen bedeuten

stationid: abc000
connector: 1
stacklevelzero: true 

Von "remotestart: true" weiß ich nur, dass das mit 0.130 erforderlich wurde für die Pulsar Plus Besitzer. Ist das bei "stacklevelzero: true" auch der Fall ?

Danke

[andig]

Problem is that charger claims 11A offered although it has set profile to 0A:

[2,"3240992666","SetChargingProfile",{"connectorId":1,"csChargingProfiles":{"chargingProfileId":10,"stackLevel":0,"chargingProfilePurpose":"TxDefaultProfile","chargingProfileKind":"Absolute","chargingSchedule":{"startSchedule":"2024-09-09T07:03:18Z","chargingRateUnit":"A","chargingSchedulePeriod":[{"startPeriod":0,"limit":0}]}}}]
[3,"3240992666",{"status": "Accepted"}]
[2,"473676276","MeterValues",{"meterValue": [{"timestamp": "2024-09-09T07:05:10Z","sampledValue": [{"format": "Raw","location": "Outlet","context": "Trigger","measurand": "Power.Active.Import","unit": "W","value": "0.0"},{"format": "Raw","location": "Outlet","context": "Trigger","measurand": "Energy.Active.Import.Register","unit": "Wh","value": "63950.7"},{"format": "Raw","location": "Outlet","context": "Trigger","phase": "L1","measurand": "Current.Import","unit": "A","value": "0.0"},{"format": "Raw","location": "Outlet","context": "Trigger","phase": "L2","measurand": "Current.Import","unit": "A","value": "0.0"},{"format": "Raw","location": "Outlet","context": "Trigger","phase": "L3","measurand": "Current.Import","unit": "A","value": "0.0"},{"format": "Raw","location": "Outlet","context": "Trigger","phase": "L1-N","measurand": "Voltage","unit": "V","value": "234.0"},{"format": "Raw","location": "Outlet","context": "Trigger","phase": "L2-N","measurand": "Voltage","unit": "V","value": "0.0"},{"format": "Raw","location": "Outlet","context": "Trigger","phase": "L3-N","measurand": "Voltage","unit": "V","value": "0.0"},{"format": "Raw","location": "Outlet","context": "Trigger","measurand": "Current.Offered","unit": "A","value": "11"},{"format": "Raw","location": "Outlet","context": "Trigger","measurand": "Power.Offered","unit": "W","value": "7621"} ]} ],"connectorId": 1}]

As workaround get rid of the rogue measurement by adding:

metervalues: Power.Active.Import,Energy.Active.Import.Register,Current.Import,Voltage