In my original TellusPower integration guide, I connected the charger supplied with my Chery to Home Assistant using OCPP. That gave me a way to monitor charging and control the charger locally.
The next question was how to make that control useful every day. Could I adjust the charging current while the car was charging? Could Home Assistant stop a session and start it again? And could I use solar power for the car while still leaving enough energy to charge the batteries that run my house?
On 21 September, I worked through the next stage: testing current control and restarting a charging session, then designing the automations to manage solar charging around the house battery.
Current status: the current-control and short stop/restart tests worked on my setup. The complete solar controller described below is still a work in progress, with thresholds to validate through real charging sessions.
Changing the charging current from Home Assistant
One of the most useful results was confirming that I could change the charging current. Moving to 16 A and 20 A worked during testing.
That matters because solar output and household demand change during the day. A fixed charging rate can be too high when a cloud passes or a large appliance starts, even if it was suitable a few minutes earlier.
My setup uses an input_number.ev_charge_current helper to hold the requested current. An automation sends that value to the charger through ocpp.set_charge_rate using a custom charging profile.
For readers comparing their own OCPP configuration, the profile used in these tests had these settings:
| Setting | Value used in my tests |
|---|---|
| Connector | 1 |
| Profile ID | 2001 |
| Stack level | 14 |
| Profile purpose | TxDefaultProfile |
| Profile kind | Relative |
| Charging rate unit | A |
| Schedule | One period starting at 0, with the requested current limit |
These are the settings that worked with my charger and configuration, rather than a universal recipe for every OCPP charger. The original guide records the TellusPower firmware as 001238.
The important check is the charger’s measured current after a change. An accepted OCPP command is useful feedback, but I also want to see the actual charging behaviour follow the request. The vehicle can draw less than the available limit.
For the solar automation, I have chosen a working range of 6–24 A, instead of allowing it to request up to 32 A. This is my chosen software limit; the charger’s installation limits still need to be respected.
For a single-phase example at approximately 230 V, the power levels are:
| Current | Approximate power |
|---|---|
| 6 A | 1.38 kW |
| 12 A | 2.76 kW |
| 16 A | 3.68 kW |
| 20 A | 4.60 kW |
| 24 A | 5.52 kW |
These are calculated examples, not measured results or three-phase figures. They show why even the minimum charging rate needs a meaningful amount of available power.
Can the charger restart after stopping?
I normally start charging manually using switch.charger_charge_control, and initially need the vehicle unlocked to begin charging. That raised a practical question: if a solar automation stopped the session, would I have to go back outside and unlock the car again?
I tested stopping charging, waiting just over 30 seconds, and starting it again. The charger accepted RemoteStartTransaction, changed from Preparing to Charging about five seconds later, and opened a new transaction.
That is encouraging evidence for automatic resuming after a solar interruption. It confirms that a short stop/restart worked in that session. Longer pauses and the vehicle’s sleep behaviour still need testing before I can call unattended restarting reliable.
Charger behaviour also varies between models and integration versions. The OCPP integration user guide is a useful reference for understanding the available controls and status entities; my restart result above describes what I observed on this TellusPower setup.
Why my house battery needs a say
Simply increasing EV charging whenever solar production is high would miss an important part of my home: the batteries also need to charge for later use.
I want the controller to consider the whole system:
- How much power the house is importing from the grid.
- Whether the house battery is charging or discharging.
- The house battery’s state of charge.
- The EV’s current charging rate and measured power.
- Whether the charger and the required sensors are available.
The battery power sensor was particularly useful. On my inverter integration, negative power means the battery is charging, while positive power means it is discharging. Anyone adapting this approach needs to check their own sensor’s sign convention first.
For example, suppose the house battery is at 82% and charging at 2,200 W. If I want to preserve 1,000 W of battery charging, there is approximately 1,200 W that could be redirected towards the EV, assuming the other power flows remain stable.
At 230 V, that corresponds to roughly 5.2 A of additional current. It is an estimate of possible extra charging capacity, not an instruction to jump straight to a higher rate.
The battery priority settings I am starting with
The proposed controller reserves more charging power for the house battery when its state of charge is low, then gradually releases that priority as it fills.
| House battery state of charge | Proposed battery charging target |
|---|---|
| Below 70% | 3,000 W |
| 70% to below 80% | 2,000 W |
| 80% to below 90% | 1,000 W |
| 90% to below 95% | 500 W |
| 95% and above | 0 W reserved by this rule |
These are initial tuning values. They express how much charging power I would like to keep for the house battery; they do not force the battery to accept that power.
There is also a limitation to using battery charging power as the main signal: when the battery is full, it may accept very little power even if more solar is available. Export, solar production and household load may need to be considered to handle that situation properly. Any calculation must also account for whether the house-load reading already includes the EV.
Keeping the automations calm
I do not want the charging rate changing every few seconds. The design separates ordinary adjustments from conditions that should stop or reduce charging sooner.
| Situation | Proposed response |
|---|---|
| Normal adjustment | Review approximately every five minutes |
| More power available | Increase by no more than 2 A per normal review |
| Grid import above 200 W for 20 seconds | Stop EV charging |
| House battery discharge above 300 W for 60 seconds | Reduce current; stop if already at the 6 A minimum |
| Insufficient power to maintain 6 A | Stop charging and wait |
| Conditions recover | Require five continuous minutes of suitable conditions before attempting a restart |
The grid threshold allows for small fluctuations and measurement noise. It is intended to prevent sustained grid-powered EV charging; it cannot promise absolutely zero grid import during every transition.
The restart check should leave enough headroom for the minimum charging rate, rather than restarting as soon as a small surplus appears. The initial proposal uses approximately 1,600 W of available headroom, after the battery reservation, with grid import below 100 W.
These settings still need testing together. A passing cloud should not produce a repeated cycle of stopping, starting and immediately stopping again.
How the pieces fit together
The planned arrangement has a master EV Solar Charging toggle. When enabled, the solar controller decides whether charging is appropriate and adjusts the current helper within the 6–24 A range.
The existing OCPP current-control automation applies the requested current. Separate checks handle sustained grid import and house-battery discharge. Restart logic waits for stable conditions and verifies that the charger is ready before trying to resume.
Manual control also needs to remain clear. If I deliberately stop charging, the controller should recognise that intention rather than turning it back on at the next review.
I am keeping the complete solar YAML out of this update until the combined behaviour is verified. The useful result so far is that the core controls work; the next step is proving that the decisions around those controls behave consistently.
What I will be checking next
The next tests will cover cloudy periods, a large household load starting, and the house battery approaching full charge. I also want to check what happens after Home Assistant or the charger reconnects, including whether the intended current limit is applied again.
For each test, I will compare requested current with measured charging power, grid import, battery power and the charger’s status. Missing sensor readings need to prevent an automatic start, rather than being treated as zero consumption.
Once those checks are complete, I can share the tested automation package and real session graphs showing how the charger responds.
If you are starting with the same charger, begin with the TellusPower OCPP setup guide. For vehicle information alongside charger data, see my Chery Tiggo and Jaecoo Home Assistant guide.
Are you using a TellusPower charger with Home Assistant? I would be interested to hear which firmware you have and whether charging resumes successfully after a longer pause.
Leave a Reply