Thanks for sharing, nice to have some alternative insights!
I’m wondering what your reasoning is behind the 1 amp minimum. To me, it feels like kind of defeating the purpose of building a fully optimized smart grid (I know, it’s splitting hairs, but I’m the precise type )
Here’s my motivation why that’s of no use:
First, my home charging maximum power of 16 amps x 240 volts = 3.8kW compared to the supercharging limit of 624 amps x 400 volts = 250kW is kind of low-balling it when it comes to stressing the system…
Second, the initiation, switching and halting of the charge session is not something that physically stresses the system, as all energy flow is electronically regulated via a power protocol. This is especially true for ramping up the charging amps. I won’t deny that the internal relay switches more often when no restraint are implemented along the borders of the net grid production, but the power increase as regulated by the protocol still prevents it from being heavily loaded (e.g. it’s not switching the full 16 amps resistive load all at once, as it is regulated, and solar power increases don’t happen in that large of chunks anyway) It kind of depends on the quality of the components used, wether a lot of switching is a disadvantage or not.
If you do feel the need to take the no-risk approach to this downside, then I would recommend a principle a bit like you’ve already implemented. Immediately after the charger switches to the on-state, block it from switching off for about a minute to prevent every-power-update-oscillation. Still, I would want it to switch on without a delay when the first opportunity arises (net grid power production >= 240 watts), not to miss any sunshine for driving purposes!
@xdss I have been thinking about how to go about this for a couple of days, and I decided on going with this.
I’ve added a script to delay the switch.turn_off for the charger, that runs in single mode (it should finish it 2 minute delay without restarting or starting in parallel):
I’ve updated the automation that controls the charge current in two spots, first to call the script when needed, and second to stop the script when the updated_charging_amps evaluates to 1 or bigger. In this way, every re-calculation within the time frame of 2 minutes that allows for the charger to run cancels the script for switching off the charger:
This works great! So I’m keeping this construct. I’ll play around for a bit with the delay settings based on real-life oscillation. Will report on that and adjust accordingly.
Minor update. It seems there has been a change in the API, which caused the script to encounter an error if the requested charging amps (say 16A) is bigger than the car’s set maximum number of amps (say due to a cold battery).
To fix this, I chose to dynamically update the variable ‘max_charging_amps’ from the set 16 amps to the maximum that the car enforces. This limit is shown as the attribute ‘max’ in the number.charging_amps. So here’s the changed variable:
max_charging_amps: "{{ state_attr('number.charging_amps', 'max') | int }}"
Wow this looks great, I was looking for a solution as my energy monitor isn’t compatible with chargehq.net.
Thanks for sharing. I’ll let you know how it goes
I found out that the number.charging_amps accepts a setting of 0, which removes the need for the charger to switch off during smart charging. I’ve updated the script accordingly. The variable min_charging_amps now is set to a value of 0. This also removes the need for any anti-fluttering scripts, thus I’ve removed that as well.
I’ve also set the voltage variable to the actual phase voltage as reported by the DSMR sensor.
Here’s the full code for the revised script (tested and working correctly):
alias: "[Tesla] Charge on solar power"
description: ""
trigger:
- platform: state
entity_id: sensor.power_grid_usage
condition:
- condition: state
entity_id: binary_sensor.charger
state: "on"
- condition: state
entity_id: device_tracker.location_tracker
state: home
- condition: state
entity_id: input_boolean.smart_charge
state: "on"
action:
- variables:
grid_usage: "{{ states('sensor.power_grid_usage') | float }}"
max_charging_amps: "{{ state_attr('number.charging_amps', 'max') | int }}"
min_charging_amps: 0
grid_voltage: "{{ states('sensor.voltage_phase_l3') | float }}"
- choose:
- conditions:
- condition: template
value_template: "{{ grid_usage > 0 }}"
sequence:
- service: switch.turn_on
target:
entity_id: switch.charger
data: {}
- service: number.set_value
target:
entity_id: number.charging_amps
data:
value: >
{% set charger_power_draw = (states('number.charging_amps') |
int) * grid_voltage %} {% set charging_amps = ((grid_usage +
charger_power_draw) / grid_voltage) | round(0, 'floor') | int %}
{{ [max_charging_amps, charging_amps] | min }}
- conditions:
- condition: template
value_template: "{{ grid_usage <= 0 }}"
sequence:
- service: number.set_value
target:
entity_id: number.charging_amps
data:
value: >
{% set deficit_watts = -1 * grid_usage %} {% set
current_charging_amps = states('number.charging_amps') | int %}
{% set required_charging_amps = ((deficit_watts / grid_voltage)
| round(0, 'ceil')) | int %} {% set updated_charging_amps =
current_charging_amps - required_charging_amps %} {% if
updated_charging_amps < min_charging_amps %}
0
{% else %}
{{ [max_charging_amps, updated_charging_amps] | min }}
{% endif %}
mode: single
@dikkertjedap I have tried adding your code to my system and I have some functions working but the main charge on excess isn’t. Hoping you can help out as my templating skill is very average!
I’m not using the DSMR integration but I have the Iotawatt energy monitoring system and integration.
In your power grid usage template why do you have the "float * 1000? My solar and consumption numebrs are in watts are you using this to convert a number? What number should this template produce watts or KW? this is what I get:
The x1000 is because the state of the DSMR production and consumption sensors is shown in kilowatts. So to use this in watts, I multiply by 1000. I use the float because the kilowatts are returned as a float (say 1024 watts is 1,024 kW) so to avoid any rounding during conversion. In my script, power_production_w and power_consumption_w are used in watts. So you can leave the *1000 out in lines 1 and 2. That should work!
Good point. First of all: my wall box is from 2015 - before the IEC 61851 was conceived (I believe in 2017). That might be the reason it supports charge currents down to 0. Second: not all wallboxes are IEC 61851 compliant. As compliance is usually only implemented upon new product introduction and/or lifecycle changes, this might be a reason that a lot of chargers older than 2020 might still work with this script. Third: some chargers (like Alfen) only start charging with a 6A current but do allow for a current setting lower than that after initialization. I have no experience with this personally.
I’ve done some investigation as you suggested, and found out that through the API (so from Home Assistant) I can stop and start a charging setting with the current set to 0 amps, and the setting persists (so I can enforce a non-IEC compliant setting). I can set the amps to any number from 0 to 16 no matter the charging state.
If I start the session through the Tesla app, it quickly jumps to 6 amps and than drops to 5 amps, not allowing me to go any lower than that through the app. Nor does the app allow me to go any lower than 5 amps even if I can set it lower through the API by setting it through Home Assistant. The app only allows me to ramp up the amps (step = 1 amp) until it gets to 5, then from 6 I cannot go below 5. The number 5 seems odd from a compliance perspective, as the specifications demand a 6 amps minimum…
Although it seems to be a matter of compliance, I don’t expect any impact on the technical side. The testing that led to the spec states that the minimum should be enforced as lower charge currents might lead to relatively too high losses, although I find that quite patronizing - charging technology has vastly evolved, as the EVs used in the IEC test are Nissan Leaf (2015 model), Peugeot Ion (2011 model) and Renault Kangoo (2012 model). Which, too be honest, is not AT ALL what I would call representative for todays EV’s and charging technology (model Y losses at 240/16A are rated at 3,5% = 0,56A). So there you have it: my plea for updating the IEC charging spec.
Alternatively, you can refer back to the version of the automation that calls the script that switches off the charger below the minimum treshold and set the minimum to 6 amps (or if it does allow you to go any lower: calculate the value at what point you find the 0,5 amp loss relatively too high).
@dikkertjedap Thanks for confirming that… I did expect you were doing that but I now understand why you are using the multiplier.
So, update… I have had more success and I’m now using your latest automation but I’m experiencing strange behaviour which could be attributed to my power which is 3 phase but I’m not sure because the Tesla app still shows 0-16Amps for charging (eventhough thats across 3 phases e.g. if set to 16A it’s actually drawing 48Amps)
To test your automation I created a number helper to trigger the “charge on solar” automation and these are the values I got:
It seems to ramp up ok but not down? However I would need to divide the result by 3 in order to match the charger speed because of the 3 phase power
I’m not sure how to fix this so hoping you can help or maybe your seeing a similar thing?
I don’t understand exactly what I’m looking at here. Have you set the script variables according to your grid situation (correct voltage, min and max amperes?
Because I was testing the automation in the evening I was using a “dummy” power_grid_usage so I could test the automation, and the table in my previous response were the results.
I assume your feed in is single phase 240V? I have 3 Phase 240V.
This is my Automation:
alias: "[Tesla] Charge on solar power"
description: ""
trigger:
- platform: state
entity_id: input_number.power_grid_usage
condition:
- condition: state
entity_id: binary_sensor.tess_charger
state: "on"
- condition: state
entity_id: device_tracker.tess_location_tracker
state: home
- condition: state
entity_id: input_boolean.smart_charge
state: "on"
action:
- variables:
grid_usage: "{{ states('input_number.power_grid_usage') | float }}"
max_charging_amps: "{{ state_attr('number.tess_charging_amps', 'max') | int }}"
min_charging_amps: 0
grid_voltage: "{{ states('sensor.tesla_wall_connector_grid_voltage') | float }}"
- choose:
- conditions:
- condition: template
value_template: "{{ grid_usage > 0 }}"
sequence:
- service: switch.turn_on
target:
entity_id: switch.tess_charger
data: {}
- service: number.set_value
target:
entity_id: number.tess_charging_amps
data:
value: >
{% set charger_power_draw = (states('number.tess_charging_amps')
| int) * grid_voltage %} {% set charging_amps = ((grid_usage +
charger_power_draw) / grid_voltage) | round(0, 'floor') | int %}
{{ [max_charging_amps, charging_amps] | min }}
- conditions:
- condition: template
value_template: "{{ grid_usage <= 0 }}"
sequence:
- service: number.set_value
target:
entity_id: number.tess_charging_amps
data:
value: >
{% set deficit_watts = -1 * grid_usage %} {% set
current_charging_amps = states('number.tess_charging_amps') |
int %} {% set required_charging_amps = ((deficit_watts /
grid_voltage) | round(0, 'ceil')) | int %} {% set
updated_charging_amps = current_charging_amps -
required_charging_amps %} {% if updated_charging_amps <
min_charging_amps %}
0
{% else %}
{{ [max_charging_amps, updated_charging_amps] | min }}
{% endif %}
mode: single
Grat work, i was thinking doing something simmilar for myself.
Few questions :
As far as i understand you measure whether there is excess solar and if that changes you either stop charging or lower the amperage so you essentially keep the load as close to 0w as possible, correct ?
I have a smart meter in HA so i have the data. The problem i have seen previously is that controlling the amperage / start / stop charging from the Tesla API which essentialy what the addon does is very slow and not consistent like you have set the charge rate twice before it gets used. Do you experience that ?
Also how do you handle the mixture of the car beeing set to charge at a specific time or that the car should not charge when you plug it in and just wait till there is excess solar since Tesla does not have an option to manually control the charge, it’s either scheduled or by the SOC. How does that work for you ?
Also could you maybe share the full code now that you made some changes to it ?
What kind of EV charger do you have ? I have a Tesla Wall Charger.
This is exactly what the script does. For every 240 watts surplus available on the grid, I add another ampere to the charging power (which corresponds to 240 volts x 1 ampere = 240 watts) and as soon as the grid power drops below 0, I subtract an ampere for every 240 watts needed to get to or above 0 watts available on the grid.
I’m using the HACS Tesla custom integration, and I don’t experience any lag whatsoever.
I haven’t set any (non-)charging hours, so I’m not familiar with how thats handled. As you can see in the automation, as soon as the charger is connected during the day, at home, it immediately asks me if I want to use smart charging (using excess solar power production). If connected in any other setting (so after dawn or away from home), it just starts charging at regular (full) power setting. That works perfectly.
All full code is available! Final version of the automation is found in post 8 of this thread. The script for switching off the charger as suggested in post 4 can be discarded.
I have an older evbox.com charger (something like a single-charger wall-mounted version of the BusinessLine charger).
binary_sensor.charger is an entity from Tesla HACS add-on to check if the charger is connected ?
sensor.power_grid_usage Is this sensor a positive value in Watts when there is surplus e.g you are feeding to grid and negative when you pull energy from the grid ?
Generally spoken: yes, it shows the connection state of the charger (car side, so not the wall box!). It’s a little more comprehensive, because when you look at the sensor in the development tools section of Home Assistant, it shows some more detailed attributes like for instance the charging state (‘charging’, ‘complete’ etc.), the type of cable that’s connected to the plug, wether a fast charging point is connected and some more.
That’s absolutely correct. It shows the value of two separate sensors as one by subtracting the actual power consumption from the actual power production, which in my case are measured by separate sensors. It’s not a critical sensor and you can do this math inside the charger automation, but this just simplifies things a bit (and I have a nice needle sensor to show on my dashboard )
@dikkertjedap does your charger run 3 phases or 1 phase. I am just surprised that in you calculation you don’t multiply with 3 eg. V * A * 3. Also i guess if it should be totally right we need to do Power = Voltage (V) x Current (I) x Power Factor (PF) x square root of three if you meter provides the PF.
I use a 1 phase charger. I’m not familiar with the amp settings in a 3-phase situation. As I’m measuring the power surplus/deficit on the grid (so from outside the charger) and the charger power is set according to the actual grid situation, the power factor of the charger (the amount of power that can be transferred for useful work) doesn’t seem too important to me.
)
