Pulling Tesla Power Data From Home Assistant

Home Assistant (HA), and associated integrations with Sense, Tesla and Ecobee, has been really helpful for me in pulling together all my energy usage data into one place. Home Assistant also has its limitations as well, mostly due to how it samples and collects data, but understanding these shortcomings pave the way to better usage. I’m going to share my ongoing work to try to better integrate data between HA and Sense, especially for the case of EV charging.

As some of you know, I had spent a lot of time trying to assemble and blend my EV charging usage into my Sense data so I can fill in the blanks on my home energy usage, even as Sense has continued to refine their EV detection. I’m at a place today where I can overlay Sense EV native detection, with Sense EV detection from DCM (Flex sensors) in Home Asssistant. And I have been close to overlaying the actual Tesla charger data with these other two sources, but limited for two reasons:

  • Tesla Integration - The HA Tesla integration is great - it brings tons of “sensor” data from the car into HA, but only a small portion of that data is recorded as “state” data, that can be graphed automatically. Unfortunately, though you can tell when the doors and frunk are locked or whether a SW update is available, etc., when it comes to power / energy usage, the nearest state information are the following 3 entities. But precisely none of those are good for overlay charting because of the 2nd HA shortcoming.
sensor.tesla_energy_added_sensor (kWh)
sensor.tesla_charging_rate_sensor (mi/hr)
sensor.tesla_battery_sensor (%)
  • Home Assistant only charts like units on the same history graph, and as you can see, none of the above are in Watts (W), the units the Sense integration uses for detections.

The charge rate is a nice proxy for power usage during charging, but isn’t quite the same as having that data on the same chart.

The crazy thing is that the Tesla integration does pull current, voltage and even real power usage into HA as an attribute associated with the charging rate entity, but never creates a stored ‘state’ value for those values.

HA does forward all the attributes onto InfluxDB if one has that option configured, and InfluxDB and Grafana are more capable when it comes to graphing and calculating. Lots of details here, but this shows how I was able to overlay all three power data sources, Sense native, Sense DCM and Tesla charger power (voltage * current), in Grafana. You’ll notice how the part of the data query in orange does the multiplication to convert the saved charging_rate_sensor attributes into Watts.

But I wanted to do this in native HA, which meant learning a little more about HA Templates, to do the same math built into HA, fro graphing in HA. After a little trial an error, I took the following steps.

  • Created and and included a new sensor.yaml file in HA for developing what I would call “derived sensors”, sensors that use logic and math on incoming sensor data to create a more digestible, usable set of states.
  • After a bunch of fumbling around with syntax, based on template examples in the HA community forum, I discovers the wonders of two capabilities inside HA:
  1. The Template tester within the Developer Tools that lets you write and see the results / errors of template code realtime.
  2. The YAML reloading tool in the Configuration > Server Controls section that enabled me to quickly reload a new Template, to see the results in HA itself, once I had worked through the basic issues.
  • I eventually developed the following chunk of code that did what I think I needed for converting mi/hr charging rate attributes into Watt-level power. Not the friendliest syntax, but the Template tester was a total boon in making it easier.
platform: template
        friendly_name: Model 3 Charging Power
        unit_of_measurement: 'W'
        value_template: "{{ state_attr('sensor.blue_comet_charging_rate_sensor', 'charger_actual_current') | float * state_attr('sensor.blue_comet_charging_rate_sensor', 'charger_voltage') | float}}"
        friendly_name: Model S Charging Power
        unit_of_measurement: 'W'
        value_template: "{{ state_attr('sensor.white_lightning_charging_rate_sensor', 'charger_actual_current') | float * state_attr('sensor.white_lightning_charging_rate_sensor', 'charger_voltage') | float}}"
  • Finally I tested the results by doing a couple of short charging sessions on my Model 3, then charting the new states in Watts against the Sense data. I kept around the charging rate data in mi/hr, just for a reference since it should somewhat mirror the power waveform. What I discovered is that my calculation was right, almost …

The bottom chart is Watts, with the Sense native detection in orange, the Sense DCM data in light blue and the Tesla charger derived calculation in dark blue. Topline values, and start and finish times match up, but there are major differences in waveforms, especially the charging notch indicated by the red arrow. But why ? It all comes down to sampling. The Sense integration samples data to HA every 60 seconds for waveforms (and every 5 minutes for Trend data). The default sampling for the Tesla integration is every 660 sec (11 min) in order to keep the car from waking up too often. I suspect that the Tesla sampling is also a little event driven - it takes a sample right when the car wakes up at the start of the charge cycle. That’s why the first datapoint was mid-power ramp at about 7200 Watts. 11 min later, the HA integration caught the full 11,600W (48A). Not completely sure why some of the 1 min samples of the Sense native detection caught much lower values, but the 1 minute sampling is clear to see, as well.

So for now, I’m going to try this out for a week or so before looking at my next enhancements:

  • Add presence detection to the templates so that HA only provides power numbers for when I charge at my primary residence. When I charge at other 240V or 120V locations, I want HA to report to a different set of state values - right now it all goes in one bucket. FYI - Supercharging is NOT registered by the car charger because that charging is managed by the Supercharger, not the car.
  • Potentially feed back to Sense via HA SenseLink. The problem is that I don’t want to Sense to double count EV charging. Right now I prevent double counting by doing my DCM measurements on a second Sense monitor.

First test - Both EVs charged last night and new HA states detected the charging within the previous constraints.

  • Sense detected the Model S charge cycle using native detection. The charger power calculation is very close, though it missies a bit at the start due to the 11 min sampling period.

  • Sense did not detect the Model 3 charge cycle using native detection, but did pick it up through my DCM CT. The charger power calculation is very close in peak usage, but is offset at the start by quite a bit due to the 11 min sampling period. The off transition is very close though.


I still have not pursued adding a conditional to test whether my Tesla is at home before evaluating / using the power info from the Tesla Integration with HA. Remember - Because the reporting Tesla charger is actually in the car, it could be charging almost anyplace, so I can’t rely on the calculated power number being only at home, with out the location check. I have the following snippet of code working, but figuring out how to integrate the conditional into the value_template has me thrown (any HA experts, feel free to give me hint !)

          message: >
            {% if is_state('device_tracker.tesla_blue_comet', 'home') %}
               Blue Comet is home! 
            {% else %}
              Blue Comet is away.
            {% endif %}

I have also discovered one more wrinkle that might be problematic in correlating EV power usage between various data sources, since I have 2 EVs and 2 high-power wall connectors (HPWCs) at home. The HA Tesla Integration data is tied to the car, Sense native detections are tied to the car, but DCM detections are tied to the HPWC, so if I swap charging slots in the garage, I’ll get incorrect DCM results like happened yesterday.

In the chart below, the Model 3 Usage (DCM) suddenly lines up with the native detection of my Model S and the charging data of the Model S (center spike on bottom). One more thing to worry about when trying to correlate.