Decimals on set_circuit_dynamic_limit

[AMajland]

Feature request

According to https://developer.easee.cloud/reference/post_api-sites-siteid-circuits-circuitid-dynamiccurrent the phase1-3 are double but the implementation has as far as i can see currentP1-3 as integers.

For the purpose of matching car charging with the surplus power from solar panels it would be beneficial to have finer granularity than 1A - Especially when charging on 3 phases

(Yes in the end it is the car that decides what it wants, but it can be nudged to increase a bit in smaller steps than integers)

What version of the integration are you using?

0.9.48

Anything in the logs that might be useful for us?

No response

Additional information

No response

[olalid]

Actually, even if you call that API with a non-integer number, the setting will be converted to an integer before it is in the end output as a PWM signal to the car. You can try it yourself, if you use the link you sent above and set the value to some non-integer value, e.g. 15.2A, you will still get an integer number returned from the cloud and the Easee integration will display 15A in the dynamic circuit limit sensor. And as well in the output limit sensor. So the only thing that would change is if the value is rounded to an integer before or after it is sent to the API.

[AMajland]

Yes, then it won't make a difference :-(

But as i understand it the PWM signal in the standard is not limited to discrete values. I 've seen it described as duty cycle 0.6 resulting int the current limit in A (Between 10% and 85% ). That is a linear curve between 10%0.6 = 6A to 53%*0.6 = 32A (The limit of the easee charger)

My car ususally choose to draw 0.3 to 0.4 A less than the limit, so i had hoped to match the surpluss better by allowing it to draw a little more :-). At the moment i just add 1A to the limit and after truncating it gets the netto power pretty close to 0

[AMajland]

I'm also (beta) testing the solar charging with the equalizer but it seems to work at the phase level so I needs a surplus of 6A on each phase for it to start charging. It is stille to early in the season to have that for any prolonged periode of time since the house heatpump also uses a lot (temperatures below freezing outside).

My HA automation simple matches the netto available power to a dynamic current setting. Added the production to the aboce graph where drops due to clouds are very visible - but also the the electric water heater kicked in and the charging pause while it used the available power

[olalid]

In my personal setup I use single phase charging for "solar charging". I just do not feel it is worth switching to 3-phase charging since it a) requires at least 4.1kW surplus energy to be available which is just not that common in my case and b) the granularity of how I can control 3-phase charging is in 690W steps compared to 230W steps with single phase.

As you say the standard can be interpreted as it would be possible to control the PWM signal in a linear fashion between 10 to 85%, but on the other hand the standard also states that anything between 8 to 10% shall be interpreted as 6A, so that kind of indicates that the signal not necessarily is going to be interpreted as linear values by the charing vehicle and that some variation in PWM signal is expected and should be accounted for. My car also draws a little bit less than what is actually allowed and I think that is probably "standard" way to do things since being over the limit would be bad and they have to take tolerances in to account.

Seems pretty clear in any case that Easee has chosen to treat the current limits as integer values internally. If you want that to change I suggest you discuss that with Easee, we can not change it from our end.

[sla004]

@olalid I would like to implement also solar charging....Do you mind to share your code for this?

[olalid]

I use a couple of template sensors to calculate the limit I want to set:

      elbil_sol_begransning_1:
        friendly_name: "Elbil solladdning begränsning steg 1"
        value_template: "{{ (state_attr('sensor.j21_dynamic_circuit_limit', 'state_dynamicCircuitCurrentP3') - (states('sensor.elmatare_effekt') | float(0)/230)) | int(0) }}"
        unit_of_measurement: "A"
        device_class: current

Where state_attr('sensor.j21_dynamic_circuit_limit', 'state_dynamicCircuitCurrentP3') is the currently set limit for phase 3, and states('sensor.elmatare_effekt') is the current power consumption. The output is the new value of the current limit for phase 3.

      elbil_sol_begransning_2:
        friendly_name: "Elbil solladdning begränsning steg 2"
        value_template: "{% if (states('sensor.elbil_sol_begransning_1') | float(0)) < 5 %}5{% elif (states('sensor.elbil_sol_begransning_1') | float(0)) > 14%}14{% else %}{{ states('sensor.elbil_sol_begransning_1') }}{% \
endif %}"
        unit_of_measurement: "A"
        device_class: current

This is just limiting the value such that it stays between 5 and 14A.

Then I have an automation that runs every 20 seconds that sets the new calculated limit:

- id: elbil_solel_pa
  alias: Elbil solladdning på
  trigger:
  - platform: time_pattern
    seconds: "/20"
  condition:
    condition: and
    conditions:
    - condition: state
      entity_id: input_boolean.bastu_begard
      state: "off"
    - condition: state
      entity_id: input_boolean.billaddare_prioritet
      state: "off"
  action:
  - service: easee.set_circuit_dynamic_limit
    data:
      charger_id: xxxxxx
      currentP1: 0
      currentP2: 0
      currentP3: "{{ states('sensor.elbil_sol_begransning_2') }}"

As you can see I have a couple of conditions also which can override this automation, one is if I have turned on my sauna, and the second is if I have enabled the charging priority (i.e. charge full speed).

[olalid]

Closing this since at the moment we do not think the requested change is viable.