Is the procedure with just renaming the version in the filename to a newer one working, or did you find another way?
Finally I found some time for testing.
As stated above, I have two TWC Gen3 which were until now not configured for power sharing and both are running on firmware v22.33.1
For the case that the master/slave configuration procedure is not known, here in short:
Activate the installation/service wireless access point on both TWCs
Login to the master and enter the SSID and password of the second one (which will be the slave)
Enter the maximum current for both TWCs (minimum is 2x 6 A ā 12 A)
Activate power sharing
Observed behavior after activating power sharing:
The normal API fo the master TWC is (after a short timeout) permanently available (ā¦/api/1/vitals|wifi_status|version|lifetime)
The same API is not available anymore for the slave TWC
For some minutes the installation/service AP is available for both TWCs
After around 5 minutes the installation/service AP of the slave is not visible/accessible
After around 10 minutes the installation/service AP of the master is not visible, but an existing connection is still alive and it is possible to change the current setting with the protocol buffer
After around 30 minutes the connection to the installation/service AP of the master is still alive, but changing the current setting results in an error (a normal āpingā is working)
Some additional notes:
It is not possible to add a not existing second TWC with some āfantasyā credentials (this process terminates with an error messageā¦ so you really need a second device for the configuration):
The master can display some fundamental data of the slave, but I am not sure if all data, that are normally available via the āmainā API, are visible or not:
After enabling power sharing the response contains a lot of āparticipant_dinsā in a a new entry called āload_sharing_configā, see the following two outputs (click on āBefore ā¦ā and āAfter ā¦ā):
Before enabling power sharing
$ ./set-charge-current.sh 6
* TCP_NODELAY set
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 192.168.92.1 (192.168.92.1) port 80 (#0)
> POST /tedapi/v1 HTTP/1.1
> Host: 192.168.92.1
> User-Agent: curl/7.52.1
> Accept: */*
> Content-Type: application/octet-stream
> Content-Length: 52
>
} [52 bytes data]
* upload completely sent off: 52 out of 52 bytes
< HTTP/1.1 200 OK
< Connection: keep-alive
< Transfer-Encoding: chunked
< Cache-Control: no-store, max-age=0
< Content-Type: application/octet-stream
<
{ [71 bytes data]
* Curl_http_done: called premature == 0
100 112 0 60 100 52 752 652 --:--:-- --:--:-- --:--:-- 769
* Connection #0 to host 192.168.92.1 left intact
payload {
delivery_channel: 1
sender {
din: "1529455-02-D--PGT21XXXXXXXXXX"
}
recipient {
local: 1
}
wc {
configure_settings_response {
settings {
max_output_current_amps: 6
gmi_mode: 3
country: "DE"
third_party_vehicle_mode: 1
}
}
}
}
external_auth {
type: 1
}
I was just looking at the json from the vitals API and see a session energy value. It seems totally off from what I would expect to see (energy delivered between contactor_closed==true to contactor_closed==false) which likely means I donāt understand what a session is in the context. My wild guess now is that is from connecting the charge cable to the port of the car (vehicle connected == true) to removing from the car (vehicle connected == false). I think this would be a helpful value to expose in the integration. Are there any plans for this? Can I help with that?
I do not have full decoding, but here are some states.
These are trivial:
1: Idle, not connected
11: Charging
7: Fault, recovery via unplugging
This is not so clear:
4: Charger ready car not charging due
9: Charger ready car not charging due to battery full (reached charge limit)
By not so clear I mean that there is really no way that the pilot signal could give this information, except for Tesla cars (they use proprietary protocol).
Other states I have not seen latelyā¦ Also fault, 7, is a new finding from last ~3 weeksā¦
I did have an additional look at the data and below are my findings though observation (Model Y and Kia Soul EV+). To calculate the charge rate the EVSE thinks is happening I used:
Charge rate = ((reported energy at the end of charging - reported energy at the beginning of charging) / charging time in min) * 60
1: Idle, not connected
4: Idle, connected
8: Charging stopped, connected (either set limit reached or manually stopped via Tesla app, this seems to be the normal state following 10)
9: Charging stopped, connected (I only see 11 ā 9 ā 4 as a sequence)
10: Charging (it seems at a rate less than 10.5 kW? )
11: Charging (it seems at a rate of more than 10.5 kW)
My TWC 3 always connect / disconnect, many times per minutes. The Wifi signal is 84% and rssi - 48 which seems to be very good.
2023-04-18 19:36:10.811 ERROR (MainThread) [backoff] Giving up async_request(...) after 3 tries (tesla_wall_connector.exceptions.WallConnectorConnectionTimeoutError: Timeout while connecting to Wall Connector at 192.168.1.70)
2023-04-18 19:36:10.817 ERROR (MainThread) [homeassistant.components.tesla_wall_connector] Error fetching tesla-wallconnector data: Could not fetch data from Tesla WallConnector at 192.168.1.70: Timeout
2023-04-18 19:36:40.370 INFO (MainThread) [homeassistant.components.tesla_wall_connector] Fetching tesla-wallconnector data recovered
2023-04-18 19:42:11.290 INFO (MainThread) [backoff] Backing off async_request(...) for 0.1s (tesla_wall_connector.exceptions.WallConnectorConnectionTimeoutError: Timeout while connecting to Wall Connector at 192.168.1.70)
2023-04-18 19:42:12.352 INFO (MainThread) [backoff] Backing off async_request(...) for 0.3s (tesla_wall_connector.exceptions.WallConnectorConnectionTimeoutError: Timeout while connecting to Wall Connector at 192.168.1.70)
2023-04-18 19:42:13.680 ERROR (MainThread) [backoff] Giving up async_request(...) after 3 tries (tesla_wall_connector.exceptions.WallConnectorConnectionTimeoutError: Timeout while connecting to Wall Connector at 192.168.1.70)
2023-04-18 19:42:13.684 ERROR (MainThread) [homeassistant.components.tesla_wall_connector] Error fetching tesla-wallconnector data: Could not fetch data from Tesla WallConnector at 192.168.1.70: Timeout
2023-04-18 19:42:43.440 INFO (MainThread) [homeassistant.components.tesla_wall_connector] Fetching tesla-wallconnector data recovered
I just installed two twc gen3 and i wanted to use the power sharing mode. I live in Sweden (230V and main 20A fuse for the house. Both twc on 3x16A each). One twc on each side of the house. Unfortunately the didnāt connect to each other because they were to far away. I assumed that they use my home wifi for power sharing, but i was wrongā¦
I called Tesla and they told me that I hade to put them closer and a wifi extender wonāt work.
But I bought a wifi extender anyways ans I got it working .
Maybe this will help someone else!
First I extended the āslaveā twc, and started the powersharing connection through the āmasterā twc. And when the start to communicate the āslaveā connects to the āmasterā twc. So I just extended the āmasterā twc afterwards. And it have been working since.
But whats already reported, the āslaveā disconnects frome my home wifi and I canāt get any data to Home Assistant. Maybe some of you find a solution that gets data from the main twc?
Hello,
I have 2 TWC3 setup with power sharing, I cannot find any solution to see the data of the second one, and display and use it in HA.
Does someone who alredy sucess ?
Tesla Wall Connectors Gen 3 are now accessible from the Tesla app. To do that, you need to open the Tesla app, add product and follow the process (scan QR code and connect to TWC wifi).
Iām wondering if this changes the apis, if we can now control the max amps (for load balancing with the house), and if you guys have any remarks about it.
I was also thinking, it would be nice to have a YouTube video from some of you who are doing power sharing, to see how it works.
I have the gen 3 TWC and configured to show in the app, note I donāt have the charge on solar feature (US/ Canada only ) I donāt see any additional API control functionality for the TWC.
I do however see new endpoints from the Tesla cloud API for the TWC, however at this stage they all look like monitoring points; power, handle temp and the like.
Iām interested in how the load balancing is achieved and can anything be utilised in HA, but havenāt seen anything yet.
I have 2 wc3 under powersharing. Both connected to the Tesla App.
The only thing I can do through the app is to create a charging schedule for the master wc3, and see some statistics. If I want to create a charging schedule for the slave wc3 the app tells me to press the cable button and connect to its own wifi. It works and then I can create a schedule. But if I want to remove it I have to do the same procedure again.
Hopefully they fix this or even better make it possible to change the amps during charging, through the app (and api). Then I can remove the powersharing network and do my own powetsharing in HA, integrate solar system and do powersharing measured from my house power meter.
I have a Gen3 charger and a M3, and State 9 also happens for 1 min when power consumption starts. My guess is that it indicates some pre-charging tests, or power ramp-up. And indeed, it lasts several minutes at the end of a charge.
And then, one doesnāt need to charge to obtain State 11. It also happens also when preheating the car while plugged (also preceded by State 9 for 1 min). So State 11 indicate power consumption in general, not necessarily charging. The charger has probably no idea what the car is doing with the power itās requesting. (On my MS 2013, heating was powered by the battery even when the car was plugged, but not charging.)
.
) I donāt see any additional API control functionality for the TWC.
.