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.yamlfile 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:
- The Template tester within the Developer Tools that lets you write and see the results / errors of template code realtime.
- 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
sensors:
model_3_power:
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}}"
model_s_power:
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.
