True power measurement

[AndySchroder]

In various places throughout the code, an apparent power is computed using an assumed line voltage of 240V. Seems like line voltage is not always constant. Also, is there any evidence that the power factor of the onboard charger in the car maintains a power factor of 1.0 and that the sine wave does not have distortion?

I'm wondering if the RS-485 protocol supports providing the voltage in addition to amps? If that were the case, even if the sine wave isn't pure and the power factor is not exactly 1.0, it seems like it is still going to be an improvement to compute an apparent power using a measured voltage.

[ngardiner]

Hi @AndySchroder

We can't assume that the power factor for vehicle charging is 1.0 as it demonstrably is not so - there's just not 100% efficiency for vehicle charging. The problem being solved in this project is the control of input power to the wall charger through the specification of charging current, primarily to provide cost control or off-grid operation.

The wall charger then allocates this power to the vehicle onboard charger, which is where the efficiency is lost. The actual energy efficiency during conversion to battery charge, whilst we would prefer it to be as high efficiency as possible, won't be known or taken into account by querying the wall connector alone.

Other projects, which query the vehicle's charging parameters may report on this - projects such as TeslaFi or TeslaMate which query the Tesla Vehicle API and derive the efficiency of charges. If there were a particular reason to query this value (such as use in policy or automation to improve the efficiency of charges), we'd be able to do so (with some difficulty, due to the inability to directly identify vehicles connected to a TWC), but so far I haven't come across a use case for querying the vehicle charge efficiency and acting upon it. Interesting topic for consideration, though.

In terms of the voltage constants, these are for calculating the output power from the wall connector to the vehicle onboard charger. I'm not aware of any protocol output that specifies a measurement of this output value in real terms, however there would be ways to measure this (using a clamp or other measuring device) if someone were motivated to do so. This does impact the output to the user (ie it has a cosmetic impact) in that the real output voltage can be between 200-240v depending on wiring mechanism and yet our calculations are based on the constant, however as we can only specify input current, there's not a lot we could do to compensate for this.

I will tag this as discussion for now - we do have the ability to read grid voltage from green power system EMS modules where they are used and where the particular inverter/battery/meter supports it, and this would provide more accurate wattage calculations, however more consideration is needed as to how we would use this calculation, especially because EMS readings are single-phase, and due to the way that TWC is wired in 120v geographies, the conversion of single phase grid voltage to actual TWC differs depending on the wiring approach. It is not quite as simple as reading single phase EMS grid voltage and substituting this for the 240v constant.

[AndySchroder]

Hello,

I'm not talking about efficiency here, but instead true power. Please see the following link for a discussion of true power (Watts, W), reactive power (Volt Amps Reactive, VAR), and apparent power (Volt Amps, VA):

https://www.allaboutcircuits.com/textbook/alternating-current/chpt-11/true-reactive-and-apparent-power/

There are some notes in the code about how there is an RS-485 message that the slave may send that indicates the energy consumption in kWhours. If that is so, then that could be used to calculate true power (Watts) by a simple numerical differentiation scheme based on the time between the messages were sent. Any idea if this kWhour message is actually being sent on the RS-485 port and could be used? I would assume that tesla is properly integrating Volts and Amps to get kW*hours.

Here is the relevant portion of the code:

https://github.com/ngardiner/TWCManager/blob/v1.1.7/TWCManager.py#L653

https://github.com/ngardiner/TWCManager/blob/v1.1.7/TWCManager.py#L932

Thoughts?

[ngardiner]

Yes, there is the message that you've referenced above for those with a TWC that has a certain firmware version. My firmware version is 4.5.3 and it does support this command. Many units out there will not have support, unfortunately.

The response to the query gives me the following:

Lifetime kWh is hex 31 (decimal 49) and Phase 1 voltage is hex F9 (decimal 249v).

The lifetime kWh doesn't align with that reported by the Tesla API, however given it is a lifetime value, there is every chance that there were testing cycles run through the unit prior to my use. This is a testing unit I use only for debugging, so 49kWh is well above my actual utilisation to date (around 33 kWh).

Comparing the phase voltage reading against my solar inverter, they disagree (fronius inverter logged 244v at the exact moment TWC logged 251v).

I will shortly run a charging test where I will measure the lifetime kWh at intervals and compare it to the vehicle charging stats, however with the delivered power precision being to the nearest kWh, it is much less precise than the Tesla API reading from the onboard charger (which provides actual amps and volts with 2 decimal place precision plus the charge_energy_added field which is a calculation in watts to 2 decimal places of the charge added to the battery by the charger):

https://tesla-api.timdorr.com/vehicle/state/chargestate

So ultimately whilst we could poll this value on an interval, I don't think we would get any value from it other than a more universal phase voltage reading than the 240v constant - but only for chargers which support this command. If the TWC reports it delivered 1 kWh lifetime over a period of 20 minutes, would that be any more precise data than the current V x A apparent calculation, which could be improved by polling green energy sources but with the caveat that I mentioned regarding different wiring approaches, which does add more configuration complexity than the current 240v constant (but could be overriden by those who wanted higher precision output).

We could read this value from the vehicle API, but we are getting closer and closer to the role of a data logger with a significant drawback to our approach (we are controlling a wall charger, not a vehicle, so we have to make inferences about which vehicle is at that wall charger at any one time). I personally run data loggers for my vehicle to get information on charging sessions, as the only detail I have come across so far that we have more insight into than the vehicle itself is the amount of time we are charging under green power vs from the grid.

Ultimately this project is a bit of a blunt instrument in that through the reverse engineering of a load sharing protocol for the TWC, we are able to specifiy a rounded decimal number of amps to supply to the vehicle for charging. In the future when API commands exist to control this from the vehicle side, there will really be no need for this project anymore (except perhaps for non-Tesla vehicles which is fairly ironic as it's a Tesla wall charger based solution). It will always suffer from a precision problem given the space that it occupies (as it neither provides detailed metering nor does it do the actual charging which is an on-board process on the vehicle, so our observation of utilization is limited).

[AndySchroder]

You have a lot of valid points.

I am curious though, what did you use to issue the command and receive the response? Are you saying they are decimal integers?

Are you saying that the Amps you tell TWC to allow the car to use are rounded to the nearest integer, or to 1 or 2 decimal places?

How do you tell the firmware version, and is it ever updated?

[ngardiner]

The command can be issued using the debug web interface at:

http://<TWC IP>/index.php?debugTWC=1

Are you saying they are decimal integers?

Yes, this is correct. The commands we send to the TWC control charging by decimal integer, the responses we recieve report in decimal integers as well.

Are you saying that the Amps you tell TWC to allow the car to use are rounded to the nearest integer, or to 1 or 2 decimal places?

The nearest integer.

How do you tell the firmware version, and is it ever updated?

The firmware version can be fetched with:

http://<TWC IP>/index.php?sendTWCMsg=FB1B&submit=1

There is some discussion that it may have been updated in the past, although there is really no confirmation of this that I have seen. You can see some discussion here:

https://teslamotorsclub.com/tmc/threads/charge-connector-update-in-progress.112886/

Either way, nobody has seen such an update in the wild for at least 18 months, and the new TWC devices just released by Tesla include wifi connectivity for the TWC, so more than likely the answer is no for legacy TWC devices and yes for the new form factor devices:

https://electrek.co/2020/01/15/tesla-home-charging-station-wifi-connection-design/

[AndySchroder]

According to

https://github.com/ngardiner/TWCManager/blob/v1.1.7/docs/SlaveProtocol.md

the amps are accurate to 10 milliamps. Also,

https://github.com/ngardiner/TWCManager/blob/v1.1.7/lib/TWCManager/TWCSlave.py#L758

and

https://github.com/ngardiner/TWCManager/blob/v1.1.7/lib/TWCManager/TWCSlave.py#L58

indicates the same thing. If you go through the code and replace some int with float in various places, a non-integer amp setting will be applied.

However, I'm not sure what the real amps are that are being used. Set point and actual seem to be off by 0.2 to 0.7 amps often times, the actual being higher than the set point, it seems. I tried measuring with a multi-meter and the actual seems to be lower than the set point, but not sure how accurate the multi-meter is.

Also, with the same multi-meter, it indicates a power factor of 0.999, so my question about real power vs apparent power may not be as big of a deal if the actual amps being reported by the TWC is actually correct. I may try to get a better multi-meter or the Tesla API (phone app only reports integers, and I'm not sure if it's rounding them correctly) to get to the bottom of the amps accuracy issue.

Regarding voltage, also probably will be better to compare to the Tesla API, but when comparing the phone app to the value received via RS-485, the phone app reports a value that is about 1-3 volts lower. This could make sense because 1-3 volts drop could occur through the cabling possibly?

[ngardiner]

According to

https://github.com/ngardiner/TWCManager/blob/v1.1.7/docs/SlaveProtocol.md

the amps are accurate to 10 milliamps. Also,

https://github.com/ngardiner/TWCManager/blob/v1.1.7/lib/TWCManager/TWCSlave.py#L758

and

https://github.com/ngardiner/TWCManager/blob/v1.1.7/lib/TWCManager/TWCSlave.py#L58

Yes you are right, we instruct the TWC to charge the vehicle with 10 ma precision, that was a mistake on my part. We do not however see any more than integer level detail for the lifetime kWh value that we have been discussing in this thread.

[AndySchroder]

Okay, well, if the power factor is indeed 0.999, then apparent power is only off from true power by 0.1%, so it's close enough. Since Volts has 3 significant figures and amps has 3 significant figures below 10 amps and 4 significant figures above 10 amps, we have a decent amount of precision on the power measurement, and therefor can have a fairly accurate energy measurement. I will do further testing to confirm the power factor is really 0.999 and the current and voltage values coming from the RS-485 port are accurate.

[AndySchroder]

By the way, the voltage/kW response coming from the slave over RS-485 has more bytes than the example ones shown in the code where I linked above. Most are zeros, but a few are values that change sometimes, and I'm not sure why because they go up and down.

[ngardiner]

Is it the CRC byte at the end that you are seeing vary, or other positions in the output? We could certainly note and observe any other relevant information that seems to change in the output, however there is no documentation to refer to so it is purely observational/reverse engineering to identify the significance of the data.

[dschuesae]

I added two factors for min and maxAmps. It works like a charm. I added this in the following branch: https://github.com/dschuesae/TWCManager/tree/v1.2.0-betterCalculationOfChargeLoadAndTrackGreenEnergy

[ccutrer]

Comparing the phase voltage reading against my solar inverter, they disagree (fronius inverter logged 244v at the exact moment TWC logged 251v).

Note that this is not at all unusual. I have 6(!) IoTaWatt's installed at my house, across 5 sub-panels. And 1 TWC that reports voltage. And 3 solar inverters. Of all of these readings, only 2 are matching exactly. Between slight miscalibrations (two IoTaWatts are literally powered off the same outlet, and are showing 0.1-0.2V differences), and actual differences caused by varying loads and the distance of the measurement to the load, you shouldn't expect them to be the same. Large loads (and measurements near them) like a TWC will cause local voltage sags, while solar locally raises the voltage to "push back" against the grid. I routinely see my voltage go up during the day during solar production. I am a bit surprised at as large of a difference between your inverter and your wall connector (7V!), and that the inverter was lower of the two. Right now I'm within 2V across all of my readings.

[RichieB2B]

Are you saying that the Amps you tell TWC to allow the car to use are rounded to the nearest integer, or to 1 or 2 decimal places?

The nearest integer.

This is not actually true. The decimal part is just chopped off using int():

TWCManager/lib/TWCManager/TWCSlave.py

Line 843 in 23eaea2

desiredAmpsOffered = int(desiredAmpsOffered)

I found that replacing this with round() works much better. With round() I stay within 0.5A of the target. With 3-phases 240V that is a maximum inaccuracy of 360W instead of 720W when using int(). With single phase 120V it is 60W vs 120W so it doesn't matter as much.

[MikeBishop]

Note that the general goal is to stay below the amount of available solar, so the truncation is deliberate. If 9.6A is available, it might be better to export 0.6A to the grid than to pull 0.4A from the grid. And depending on the tariff, it might not be. I can see a reasonable argument for making this a switch, but I'd be hesitant about simply replacing it for everyone.