-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature request: kWhDelivered/kWhCounter in WebUI, HASS status and MQTT #88
Comments
This is an interesting use-case. I don't see any reason why we couldn't query the Slave TWCs and record the lifetime kWh value, and ultimately make this available through the status interfaces. I'll take a look at this. |
I have just committed (in commit 83bd6ff) some new code that will:
Let me know if it does what you need in your environment |
As an update to the above, 8c37568 introduces detection of the polling not running (for fakeMaster = 1 users) and restarts polling if this is the case. This should mean reliable reporting of lifetime kWh and voltage per phase values for TWCs in both fakeMaster = 1 and fakeMaster = 2 modes, as long as they have the newer firmware that supports it. If not, it will just be reported as 0. |
hi, awesome, thanks for picking up and implementing that rocket fast! I switched to 1.20 brunch and will help with testing. Apr 26 12:55:49 TWCManager python3[1050]: 12:55:49 TeslaAPI 6 Car API disabled for 569 more seconds due to recent error.
Apr 26 12:55:49 TWCManager python3[1050]: ----------------------------------------
Apr 26 12:55:49 TWCManager python3[1050]: Exception happened during processing of request from ('192.168.1.51', 65338)
Apr 26 12:55:49 TWCManager python3[1050]: Traceback (most recent call last):
Apr 26 12:55:49 TWCManager python3[1050]: File "/usr/lib/python3.7/socketserver.py", line 650, in process_request_thread
Apr 26 12:55:49 TWCManager python3[1050]: self.finish_request(request, client_address)
Apr 26 12:55:49 TWCManager python3[1050]: File "/usr/lib/python3.7/socketserver.py", line 360, in finish_request
Apr 26 12:55:49 TWCManager python3[1050]: self.RequestHandlerClass(request, client_address, self)
Apr 26 12:55:49 TWCManager python3[1050]: File "/usr/lib/python3.7/socketserver.py", line 720, in __init__
Apr 26 12:55:49 TWCManager python3[1050]: self.handle()
Apr 26 12:55:49 TWCManager python3[1050]: File "/usr/lib/python3.7/http/server.py", line 426, in handle
Apr 26 12:55:49 TWCManager python3[1050]: self.handle_one_request()
Apr 26 12:55:49 TWCManager python3[1050]: File "/usr/lib/python3.7/http/server.py", line 414, in handle_one_request
Apr 26 12:55:49 TWCManager python3[1050]: method()
Apr 26 12:55:49 TWCManager python3[1050]: File "/home/pi/TWCManager/lib/TWCManager/Control/HTTPControl.py", line 337, in do_GET
Apr 26 12:55:49 TWCManager python3[1050]: page += self.show_status()
Apr 26 12:55:49 TWCManager python3[1050]: File "/home/pi/TWCManager/lib/TWCManager/Control/HTTPControl.py", line 525, in show_status
Apr 26 12:55:49 TWCManager python3[1050]: if (self.server.master.getModuleByName("Policy").policyIsGreen()):
Apr 26 12:55:49 TWCManager python3[1050]: File "/home/pi/TWCManager/lib/TWCManager/Policy/Policy.py", line 260, in policyIsGreen
Apr 26 12:55:49 TWCManager python3[1050]: for policy in self.charge_policy
Apr 26 12:55:49 TWCManager python3[1050]: StopIteration
Apr 26 12:55:49 TWCManager python3[1050]: ---------------------------------------- |
IIRC, there's code to handle the report from the slave of the car's VIN, but nothing is done with it and we never ask the slave for this data. |
ad. kwh counter
Regarding the VIN, only available above certain FW version: Potentially useful commands in firmware 4.5.3 are: FB EE SS SS RR RR
FB EF SS SS RR RR
FB F1 SS SS RR RR
|
Yes, we could certainly add this functionality alongside the lifetime kWh, @MikeBishop, is the output above regarding the green policy check anything obvious to you? From a cursory examination it seems it iterates through all policies and does not find one which matches the active policy name. I've been unable to replicate it, but it seems a potential code path if that is what has happened. |
Yes that's as expected. Only fakeMaster = 1 requires it to be requested (and it should only happen in that case also) - we as a TWC should not send out any requests for this when fakeMaster = 2. For the VIN however I'm not sure if you see requests for VIN parts in fakeMaster = 2? Given this is actual TWC driven, if it doesn't request it, you wouldn't see it. |
Are there recommended policy settings for |
|
doesn't seem to work, don't see meaningful values either in the webUI nor in HASS nor in MQTT broker.
Homeassistant States
|
@nean-and-i: Could you please grab the following entry from the log for me: 23:45:42 Policy 1 New policy selected; changing to Non Scheduled Charging (yours may differ) Also, with the above, we do not publish the value to HASS or MQTT until we see it from the Slaves. Are you seeing the lifetime kWh and volts per phase in the log? If not, given you're in fakeMaster = 2 mode, it means the real TWC master has not yet probed the Slave TWCs for their lifetime kWh and volts per phase data. |
ad policy: ad lifetime kWh :
|
Great, thank you for that. I can now see the cause of the exception you were getting (no policy selection for fakeMaster = 2). I'll keep that in mind going forward. I'm investigating the missing HASS/MQTT/Web values now. |
Unfortunately I was missing a rather important line for fakeMaster = 2 logging of the lifetime kWh value @nean-and-i. My apologies. I have updated this in 4749212. |
With 6365098 we add VIN polling for TWCs which support this in their firmware. When a vehicle is detected charging on a Slave TWC, we will send the command to prompt the TWC to send the first 7 bytes of the attached vehicle. If it responds, we then go on to request the next 7 bytes and finally the last 3 bytes. This is stored as current VIN and last VIN for each Slave TWC. This is now visible in the built-in web interface, and is published via MQTT and HASS:
I am going to use this opportunity to do some work on the two Status module docs pages now to reflect all of the various published values. They are: |
thanks a lot! Shall I already see lifetimekwh on the webui (as with the current last commit it doesn't) or do I miss something, it shows up in the logs but nowhere else? looks like master.updateSlaveLifetime need some love ? Apr 28 17:27:09 TWCManager python3[11455]: Traceback (most recent call last):
Apr 28 17:27:09 TWCManager python3[11455]: File "/home/pi/TWCManager/TWCManager.py", line 1290, in <module>
Apr 28 17:27:09 TWCManager python3[11455]: master.updateSlaveLifetime(senderID[0], senderID[1], kWhCounter, voltsPhaseA, voltsPhaseB, voltsPhaseC)
Apr 28 17:27:09 TWCManager python3[11455]: TypeError: updateSlaveLifetime() takes 6 positional arguments but 7 were given
Do you think we'd need it that perfect, wouldn't be just the last 7 bytes sufficient? |
Thanks @nean-and-i - I changed the function arguments between 1.1.8 and 1.2.0 so while it should have been working for 1.1.8, it wasn't for 1.2.0 which I have fixed with e8d3780. The main problem with partial VIN is that none of the segments of the VIN alone seem very useful. You can get the first 7 bytes, the middle 7 bytes or the last 3 bytes. Arguably the last 3 are most significant in identifying any individual vehicle however you could have a situation where 2 vehicles with the last 3 VIN digits existed. That said, we could make this an option - users could select full or partial VIN collection and skip the two extra VIN steps. The way this is implemented now it would just be a matter of skipping the first 2 VIN requests. It's hard to say whether this would be useful, I'm not entirely clear of the likely use cases for VIN details (outside of perhaps logging charge sessions or matching up vehicles to the API details) at this point. |
@nean-and-i, to your last question, if a non-Tesla car is charging the result will be all zeros. |
thanks, pls. let me know when I can/should test the lifetimekwh to be in webUI/mqtt/hass. |
Hi,
|
sorry guys, I can't get that to work even with the latest commits and reinstall, but maybe there is a misunderstanding or a config issue on my end, can someone pls. comment on my findings? thanks, testsPassive Mode: FakeMaster: 2
Active Mode: FakeMaster: 1
config.jsonOne thing with the json file, can someone please remove the {
"config": {
"settingsPath": "/etc/twcmanager",
"wiringMaxAmpsAllTWCs": 16,
"wiringMaxAmpsPerTWC": 16,
"minAmpsPerTWC": 12,
"onlyChargeMultiCarsAtHome": true,
"greenEnergyAmpsOffset": 0,
"greenEnergyFlexAmps": 0,
"subtractChargerLoad": false,
"cloudUpdateInterval": 1800,
"nonScheduledAmpsMax": 16,
"nonScheduledLimit": -1,
"chargeNowLimit": -1,
"debugLevel": 10,
"displayMilliseconds": false,
"fakeMaster": 2
},
"interface": {
"Dummy": {
"enabled": false,
"twcID": 1234
},
"RS485": {
"enabled": true,
"baud": 9600,
"port": "/dev/ttyS0"
},
"TCP": {
"enabled": false
}
},
"control": {
"HTTP": {
"enabled": true,
"listenPort": 8080
},
"MQTT": {
"enabled": false,
"brokerIP": "192.168.1.XX",
"topicPrefix": "TWC",
"username": "mqtt",
"password": "XXXXXXXXXX"
}
},
"policy":{
"engine":{
"policyCheckInterval": 30
},
"extend":{
"emergency":[
],
"before":[
],
"after":[
],
"restrictions":{
}
},
"override": [
{ "name": "Non Scheduled Charging",
"match": [ "none" ],
"condition": [ "none" ],
"value": [ 16 ],
"charge_amps": "config.nonScheduledAmpsMax",
"charge_limit": "config.nonScheduledLimit" }
]
},
"logging":{
"Console": {
"enabled": true
},
"CSV": {
"enabled": true,
"path": "/home/pi/csv",
"mute":{
"ChargeSessions": false,
"GreenEnergy": false,
"SlavePower": true,
"SlaveStatus": true
}
},
"MySQL": {
"enabled": false,
"host": "1.2.3.4",
"database": "twcmanager",
"username": "twcmanager",
"password": "twcmanager"
},
"SQLite": {
"enabled": true,
"path": "/home/pi/twcmanager.sqlite"
}
},
"sources":{
"Fronius": {
"enabled": false,
"serverIP": "192.168.1.XX"
},
"HASS": {
"enabled": false,
"serverIP": "192.168.1.XX",
"serverPort": "8123",
"apiKey": "XXXXXXXXXXXXXXXXXXX",
"hassEntityConsumption": "sensor.meter_power_live",
"hassEntityGeneration": "sensor.inverter_power_live"
},
"MQTT": {
"enabled": false,
"debugLevel": 11,
"brokerIP": "192.168.1.XX",
"topicPrefix": "TWC",
"username": "mqtt",
"password": "XXXXXXXXXX"
},
"Powerwall2": {
"enabled": false,
"serverIP": "192.168.1.XX",
"password": "test123",
"minBatteryLevel": 90
},
"TED": {
"enabled": false,
"serverIP": "192.168.1.XX",
"serverPort": "8080"
}
},
"status": {
"HASS": {
"enabled": true,
"serverIP": "192.168.1.XX",
"serverPort": "8123",
"apiKey": "XXXXXXXXXXXXXXXXXXX"
},
"MQTT": {
"enabled": true,
"debugLevel": 11,
"brokerIP": "192.168.1.XX",
"topicPrefix": "TWC",
"username": "mqtt",
"password": "XXXXXXXXXX"
}
}
} |
FWIW, the Charge Now is probably your best bet to test. Alternatively, set Scheduled Charging to run all day using the web interface. |
@MikeBishop , thanks for your reply. reg. commenting, I think this is not a major thing, it only gets a bit ugly on my end when using an editor that does linter and syntax checks (sublimetext2/VSC/,...) but feel free to ignore! my attempt putting it manually in pseudo object is a bit time consuming: {
"config": {
"_comment_settingsPath" : [
" The settings path will store the dynamic settings which are defined via the web interface"
],
"settingsPath": "/etc/twcmanager",
"_comment_wiringMaxAmpsAllTWCs" : [
" Set wiringMaxAmpsAllTWCs to the maximum number of amps your charger wiring can handle.",
" I default this to a low 6A which should be safe with the minimum ",
" standard of wiring in the areas of the world that I'm aware of. ",
" Most U.S. chargers will be wired to handle at least 40A and sometimes 80A,",
" whereas EU chargers will handle at most 32A (using 3 AC lines instead of 2 so",
" the total power they deliver is similar).",
" Setting wiringMaxAmpsAllTWCs too high will trip the circuit breaker on your",
" charger at best or START A FIRE if the circuit breaker malfunctions.",
" Keep in mind that circuit breakers are designed to handle only 80% of their",
" max power rating continuously, so if your charger has a 50A circuit breaker,",
" put 50 * 0.8 = 40 here.",
" 40 amp breaker * 0.8 = 32 here.",
" 30 amp breaker * 0.8 = 24 here.",
" 100 amp breaker * 0.8 = 80 here.",
" IF YOU'RE NOT SURE WHAT TO PUT HERE, ASK THE ELECTRICIAN WHO INSTALLED YOUR CHARGER."
],
"wiringMaxAmpsAllTWCs": 6,
"_comment_wiringMaxAmpsPerTWC" : [
" If all your chargers share a single circuit breaker, set wiringMaxAmpsPerTWC",
" to the same value as wiringMaxAmpsAllTWCs.",
" Rarely, each TWC will be wired to its own circuit breaker. If you're",
" absolutely sure your chargers each have a separate breaker, put the value of",
" that breaker * 0.8 here, and put the sum of all breakers * 0.8 as the value of",
" wiringMaxAmpsAllTWCs.",
" For example, if you have two TWCs each with a 50A breaker, set",
" wiringMaxAmpsPerTWC = 50 * 0.8 = 40 and wiringMaxAmpsAllTWCs = 40 + 40 = 80."
],
"wiringMaxAmpsPerTWC": 6,
"_comment_minAmpsPerTWC" : [
" https://teslamotorsclub.com/tmc/threads/model-s-gen2-charger-efficiency-testing.78740/ post-1844789",
" says you're using 10.85% more power (91.75/82.77=1.1085) charging at 5A vs 40A,",
" 2.48% more power at 10A vs 40A, and 1.9% more power at 20A vs 40A. This is",
" using a car with 2nd generation onboard AC/DC converter (VINs ending in 20000",
" and higher).",
" https://teslamotorsclub.com/tmc/threads/higher-amp-charging-is-more-efficient.24972/",
" says that cars using a 1st generation charger may use up to 30% more power",
" at 6A vs 40A! However, the data refers to 120V 12A charging vs 240V 40A",
" charging. 120V 12A is technically the same power as 240V 6A, but the car",
" batteries need 400V DC to charge and a lot more power is wasted converting",
" 120V AC to 400V DC than 240V AC to 400V DC.",
"",
" The main point is 6A charging wastes a lot of power, so we default to charging",
" at a minimum of 12A by setting minAmpsPerTWC to 12. I picked 12A instead of 10A",
" because there is a theory that multiples of 3A are most efficient, though I",
" couldn't find any data showing that had been tested.",
"",
" Most EU chargers are connected to 230V, single-phase power which means 12A is",
" about the same power as in US chargers. If you have three-phase power, you can",
" lower minAmpsPerTWC to 6 and still be charging with more power than 12A on",
" single-phase. For example, 12A * 230V * 1 = 2760W for single-phase power, while",
" 6A * 230V * 3 = 4140W for three-phase power. Consult an electrician if this",
" doesn't make sense.",
"",
" https://forums.tesla.com/forum/forums/charging-lowest-amperage-purposely",
" says another reason to charge at higher power is to preserve battery life.",
" The best charge rate is the capacity of the battery pack / 2. Home chargers",
" can't reach that rate, so charging as fast as your wiring supports is best",
" from that standpoint. It's not clear how much damage charging at slower",
" rates really does."
],
"minAmpsPerTWC": 12,
"_comment_onlyChargeMultiCarsAtHome" : [
" When you have more than one vehicle associated with the Tesla car API and",
" onlyChargeMultiCarsAtHome = True, cars will only be controlled by the API when",
" parked at home. For example, when one vehicle is plugged in at home and",
" another is plugged in at a remote location and you've set TWCManager to stop",
" charging at the current time, only the one plugged in at home will be stopped",
" from charging using the car API.",
" Unfortunately, bugs in the car GPS system may cause a car to not be reported",
" as at home even if it is, in which case the car might not be charged when you",
" expect it to be. If you encounter that problem with multiple vehicles, you can",
" set onlyChargeMultiCarsAtHome = False, but you may encounter the problem of",
" a car not at home being stopped from charging by the API."
],
"onlyChargeMultiCarsAtHome": true,
"_commen_defaultVoltage" : [
" Newer TWCs can report actual voltages. ",
" For older TWCs, you can specify what voltage should be assumed and",
" whether the power is single (1) or 3-phase."
],
"defaultVoltage": 240,
"numberOfPhases": 1,
"_comment_greenEnergyAmpsOffset" : [
" When determining how much green energy is available for charging, we count",
" greenEnergyAmpsOffset as consumption. This is most often given a value",
" equal to the average amount of power consumed by everything other than car",
" charging. For example, if your house uses an average of 2.8A to power",
" computers, lights, etc while you expect the car to be charging, set",
" greenEnergyAmpsOffset = 2.8.",
"",
" If you have solar panels, look at your utility meter while your car charges.",
" If it says you're using 0.67kW, that means you should set",
" greenEnergyAmpsOffset = 0.67kW * 1000 / 240V = 2.79A assuming you're on the",
" North American 240V grid. In other words, during car charging, you want your",
" utility meter to show a value close to 0kW meaning no energy is being sent to",
" or from the grid.",
"",
" If you are able to obtain consumption details from an energy management system,",
" this value can be set to 0 unless you wish to manually adjust what it returns."
],
"greenEnergyAmpsOffset": 0,
"_comment_greenEnergyFlexAmps" : [
" If green energy dips below the target charge amount while already charging,",
" how much extra current should be drawn to keep charging? This avoids frequently",
" stopping and starting charging on a day with variable solar output, at the cost],",
" of drawing energy from sources other than solar."
],
"greenEnergyFlexAmps": 0, etc,... thanks! |
I haven't tried a setup with |
Hi, long time no see, after I while I'm back to the project and glad to see all the good progress. please check PR #469 "Status updates for MQTT/HASS in fakeMaster=2 mode ", it works now, but maybe some cleanup is required thanks |
I'm working on a solution for a simple view of the consumed/charged kwh, preferably recorded by car/model (M3 and non tesla), just to get an overview of how much kwh each of the cars consumed in a year.
I think this fork is the closest to beginn with and fits quite good, as my idea was to integrate it in HASS anyway and/or make it available via MQTT.
I use TWCManager in a passive way, in
fakemaster = 2
mode and like to capture the consumed kwh (on newer fw). As a second step I'm planing to readout part of the VIN to figure out if its a telsa or not to assign from-to charged kwh to the individual car.is it possible to integrate kWhDelivered/kWhCounter msgpart from debug output in HASS and MQTT the same was as "total_amps_in_use", "totalAmpsInUse" ?
The text was updated successfully, but these errors were encountered: