I love smart home projects that feel a little ridiculous until they quietly become part of everyday life. This Mercedes E53 and Home Assistant integration started that way. On paper, it sounded simple enough: show me whether the car is charging, display the live power on my dashboard, and help me precondition the car at the right time without nagging me or firing at the wrong moment. In reality, it turned into one of those projects where every layer had a tiny lie hiding inside it.
I’m Wayne, a software engineer at eBay, and I’ve spent the last couple years wiring Home Assistant into the parts of life that matter enough to automate but annoying enough to do badly when left manual. My setup already tracks energy, presence, climate, lighting, cameras, and vehicle data. The Mercedes side should have been one of the easier integrations. Instead, it exposed a bunch of the usual smart-home nonsense: delayed cloud data, mismatched units, stale sensor values, and dashboards that technically render while still telling you the wrong story.
So I fixed it the same way I fix most Home Assistant problems now: stop trusting the first entity, stop trusting the first graph, and keep going until the system reflects the real world. What came out the other side is a setup that gives me live charging visibility, cleaner preconditioning logic, and a car dashboard in Home Assistant that is finally useful instead of decorative.
What I actually wanted from the Mercedes integration
I wasn’t trying to build some over-engineered sci-fi garage. I wanted a practical set of outcomes:
- See whether my Mercedes E53 is actively charging right now.
- Show charging power alongside the rest of the house energy view.
- Avoid stale or ghost readings that make it look like the car is still charging when it isn’t.
- Precondition the car based on real life — calendar, location, and travel context — instead of dumb fixed timers.
- Send notifications only to me, not every device or every person in the house.
That sounds basic, but that’s the trap with vehicle integrations: basic is where most of the pain lives. It’s easy to get some data. It’s harder to get data you can trust when you’re making decisions off it.
The first problem: the charging sensor technically existed, but it was not useful enough
The good news was that the core Mercedes charging entity existed in Home Assistant. The bad news was that it reported power in kilowatts, while the rest of my power dashboard was built around watts. That sounds minor until you graph everything together and the car either disappears into the scale or makes the graph misleading depending on how the card handles mixed units.
This is where a lot of people stop and accept a mediocre dashboard. I’ve done that before, and it always turns into future annoyance. If the graph lies, you eventually stop checking it.
So instead of splitting the Mercedes into a separate chart — which makes the overall energy story worse — I created a normalized watt-based sensor and kept the car in the same power context as the rest of the house. That matters more than it sounds. When I open the dashboard, I want one answer to the question what is drawing power right now? I do not want to mentally reconcile three cards and two unit systems while standing in the garage.
The fix: create a watt-normalized charging sensor
The simplest reliable move was to build a Home Assistant template sensor that converts the source value from kilowatts to watts. If the raw Mercedes entity says 1.2 kW, the dashboard should show 1200 W just like it shows the server rack, the grid import, or a high-load appliance.
Here’s the shape of the template logic:
template:
- sensor:
- name: Mercedes E53 Charging Power W
unique_id: mercedes_e53_charging_power_w
unit_of_measurement: W
device_class: power
state_class: measurement
state: >
{% set kw = states('sensor.w1klh6db5ta304630_charging_power') | float(0) %}
{{ (kw * 1000) | round(0) }}
That gets you the unit conversion, but it does not get you a trustworthy live sensor. And that’s where the second, nastier problem showed up.
The second problem: stale values pretending to be live values
This one was more annoying. The raw charging entity could hang onto a nonzero value even when it was no longer fresh enough to represent reality. So you’d open the dashboard later, see the car apparently still pulling power, and realize the embedded timestamp was old. That is poison for any operational dashboard.
A stale sensor is worse than a missing sensor because it gives you false confidence. If I’m deciding whether the car finished charging, whether a charging schedule actually started, or whether house load is spiking because of the vehicle, I need the number to mean now.
The fix was to add a freshness guard. In my case, I made the normalized Mercedes power sensor return watts only if the source timestamp was reasonably recent. Otherwise it returns zero instead of serving stale junk.
The logic looked like this in principle:
template:
- sensor:
- name: Mercedes E53 Charging Power W
unique_id: mercedes_e53_charging_power_w
unit_of_measurement: W
device_class: power
state_class: measurement
state: >
{% set source = states('sensor.w1klh6db5ta304630_charging_power') | float(0) %}
{% set updated = states.sensor.w1klh6db5ta304630_charging_power.last_updated %}
{% set age = (now() - updated).total_seconds() if updated else 999999 %}
{% if age < 7200 %}
{{ (source * 1000) | round(0) }}
{% else %}
0
{% endif %}
That one change made the graph dramatically more honest. The car shows up when it’s actually charging, disappears when the source goes stale, and stops muddying the house power picture with phantom load.
Why the dashboard mattered more than the sensor by itself
A lot of integrations die on the vine because the data exists but the presentation is bad. Once I had a clean watt-based Mercedes charging sensor, I dropped it into the same Home Assistant power trend card I use for the rest of the house.
That gave me something I actually wanted to look at:
- Grid import in watts
- Server rack usage in watts
- Mercedes E53 charging draw in watts
- Other live household loads in the same unit system
This sounds cosmetic until you’ve lived with it for a week. If the car starts charging and your house load jumps, you can immediately see whether that jump is the vehicle, the HVAC, or something else. If your energy numbers look weird, you can quickly rule the car in or out. And if you’re checking whether a scheduled charge actually kicked off, you don’t need to guess from a status badge. You can see the power draw in context.
For this kind of setup, I also like a wall or counter dashboard that is visible at a glance. A dedicated tablet helps a lot here. If you want a cheap dashboard panel, something like an Amazon Fire HD 10 works well for always-on Home Assistant dashboards without spending iPad money.
The preconditioning side: this is where most automations get dumb fast
Charging is the visible part. Preconditioning is where the automation earns its keep.
I didn’t want a brittle system that says “run climate at 7:15 every weekday” and calls it smart. That kind of automation works right up until the first day you’re not leaving at the same time, the first day the car isn’t home, or the first day a reminder fires after you’ve already left.
My rule for preconditioning is simple: if the automation ignores calendar context or location context, it’s not ready yet.
So the Home Assistant side was built around a few practical constraints:
- Use the Erikson calendar only for Mercedes reminders.
- Require a real location signal before acting.
- Prefer event-driven timing over fixed clock schedules whenever the data is reliable enough.
- Send notices only through
notify.wayne.
That means the automation is less flashy, but it behaves more like an adult. If the car isn’t where it should be, or the trip context doesn’t line up, it should not fire just because the clock says so.
How I think about the actual preconditioning logic
The automation design is less about a single YAML block and more about guardrails:
- Look for a relevant calendar event.
- Make sure the vehicle is actually in the right place to precondition.
- Check travel timing, not just current time.
- Trigger the reminder or action close enough to departure to be useful.
- Notify only me.
In Home Assistant terms, that often ends up looking like a mix of calendar entities, presence or zone checks, and a notification action that is intentionally narrow. I’d rather miss one edge case than build a spam machine that everyone in the house starts ignoring.
This is also where Home Assistant’s flexibility beats the car app alone. The Mercedes app can precondition the car. Great. Home Assistant can answer the smarter question: should I precondition the car right now, given the actual context of my day?
The energy angle is underrated
One reason I cared so much about getting live Mercedes charging into the same dashboard as the rest of the house is that vehicle charging changes how you interpret everything else. If you’ve ever looked at your house energy graph and thought, “why did load jump by over a kilowatt?” you already know the problem.
For anyone doing serious Home Assistant energy work, I still think a whole-home monitor is worth it. I’ve had good results with the Emporia Vue Gen 2 Energy Monitor because it gives you the broader context around what the car is doing. The Mercedes charging sensor tells you what the car is pulling. The panel monitor tells you what that means for the house.
And for smaller supporting loads or quick validation, a plug-level monitor like the TP-Link Kasa KP125 smart plug is still one of the best cheap tools in a Home Assistant setup. I use those all over the place when I want to know whether something is truly idle or just pretending to be.
If you like local-friendly gear and a little more flexibility, the Shelly Plus Plug S is another solid option for device-level monitoring and automation triggers.
What went wrong along the way
I think it’s worth spelling this out because most polished tutorials skip the actual frustration:
- The first graph looked clean but hid the Mercedes line because the units were mismatched.
- A separate graph solved the visibility problem but made the dashboard worse, not better.
- The raw charging entity looked live until I checked its timestamp and realized it was carrying stale data.
- A lot of the vehicle automation ideas sounded smart before location and timing reality made them obviously weak.
That’s the real Home Assistant workflow, by the way. Not “paste this YAML and enjoy your futuristic life.” It’s usually a loop of: observe the lie, tighten the model, test again, remove more dumb assumptions, and keep going until the system behaves like the world actually behaves.
What I’d recommend if you’re building a Mercedes + Home Assistant setup right now
If you’re starting fresh, here’s the short version of what I’d do:
- Normalize your units immediately. Don’t mix kW and W in the same operational chart and hope the card will save you.
- Add a freshness guard. Vehicle cloud data gets stale. Plan for that, don’t apologize for it later.
- Keep the car in the main house power story. Charging is part of home energy, not a separate novelty graph.
- Use calendar + location + delivery targeting for preconditioning reminders. Fixed timers are lazy.
- Send fewer, better notifications. A useful automation is one you don’t start muting.
And if you’re building a wall dashboard for this stuff, make sure it answers one obvious question at a glance: what is the car doing right now, and does it make sense? If it doesn’t answer that in two seconds, keep refining.
The end result
Right now, my Mercedes E53 integration does what I wanted it to do in the first place. When the car is charging, I can see the live watt draw on the same chart as the rest of the house. When the source data gets stale, the dashboard stops pretending it’s still live. When I think about preconditioning, I’m working with calendar and location context instead of a dumb recurring timer.
That may not sound revolutionary, but honestly, that’s most of good home automation. Not flashy. Just honest. Clean data, useful context, and fewer moments where you look at your own dashboard and think, “yeah, that’s technically a chart, but I still don’t trust it.”
If you’re already deep into Home Assistant, this is one of those projects that pays off because your car stops being an isolated app and becomes part of the house logic. And once that happens, you start making better decisions with charging, notifications, and timing without having to think nearly as much about any of it.
Related reads
- Smart Climate Control Automation with Home Assistant
- Energy Monitoring and Optimization with Home Assistant
- Home Assistant Backups and Disaster Recovery
If you build a version of this for your own garage, make the dashboard tell the truth first. Everything else gets easier after that.