Comments (15)
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.
from twcmanager.
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.
from twcmanager.
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):
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?
from twcmanager.
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).
from twcmanager.
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?
from twcmanager.
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/
from twcmanager.
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?
from twcmanager.
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.
from twcmanager.
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.
from twcmanager.
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.
from twcmanager.
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
from twcmanager.
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.
from twcmanager.
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
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.from twcmanager.
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.
from twcmanager.
That is a valid point I did not consider yet. I'll add a config switch to PR #515
from twcmanager.
Related Issues (20)
- Tesla API doesn´t work any more HOT 1
- External control / Start, Stop, Disable HOT 3
- Unable to start/access web interface after update. HOT 11
- Clean install error - TWC 1.3.1 stable version - urllib3 (2.2.0) or chardet (4.0.0) doesn't match a supported version! HOT 10
- MQTT - Unsupported callback API version: version 2.0 added a callback_api_version HOT 2
- Actual status of the new Tesla API integration - for noobs HOT 9
- Car API not available - can't stop charging HOT 52
- regular expression in line 1050 of Vehicle/TeslaAPI.py needs to be changed HOT 2
- car_api_charge() and enforcePolicy() prevent car from sleeping HOT 2
- Implement Fleet API vehicle_data rate limiting HOT 22
- A "disconnected" car is never charged when it is plugged in later HOT 2
- Charging at single phase on a 3 phase connection causes incorrect power consumption. HOT 12
- MySQL logging HOT 1
- "Tesla Vehicle Command Protocol required" HOT 19
- Exception in thread paho-mqtt-client-MQTT.EMS if mqtt
- POSTGRESQL DB
- Charge limit set to 60% instead of stop charging. Charging never starts again
- Incorporation of Teslemetry Authentication into TWCManager HOT 3
- When to reset stopAskingToStartCharging?
- Useless start-charge commands HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from twcmanager.