Tesla Gen 3 Wall Connector (WiFi)

[darkmatter08]

Is there anyone interested in adding support for the Tesla Gen 3 Wall Connector (WiFi), released in Jan 2020? I see two steps:
First, the API would have to be reversed -- possibly some kind of web endpoint accessible via simple GET/POST requests, given the browser based breaker/amp selection. Or perhaps there is telnet/ssh access. Currently, there is no power sharing logic enabled, so there is no device to device traffic to watch over the network with Wireshark.
Second, the core logic for green charging from this repo should be ported over to use the new API.

Currently I don't have access to the Gen3, otherwise I'd give this a shot.

[darkmatter08]

Looking at the TeslaMotorsClub forum, the author of this repo (WinterDragoness) has a Gen 3 unit and is investigating. However, there's no obvious solution so far...

I will confirm the rs485 ports on gen3 do not output anything during normal operation or respond to anything I've tried sending. I don't know why the ports are even there though I theorize they want the option to do something with them in the future, if they ever get around to it.

The manual does not say anything about the rs485 ports but it does say there will be wifi power sharing available "in a future firmware update". No idea when.

Since you can change circuit breaker size over wifi, I tried doing that while it was charging in order to get some control over charge rate, but it seems to turn the wifi off after it's been on for 5+ mins. So wifi config can only be used for provisioning, not during operation.

Internal components of gen2 TWCs were made by Delta, but gen3 internals are all stamped Tesla. CPU is different, there is no obvious JTAG connector, and so the firmware must be a complete rewrite for the new hardware. My best guess is that Tesla is trying to build a walled garden where their products talk to each other over Wifi but they don't want anyone else intruding on the conversation. I'm not sure how difficult that might be to break into but I can tell you that I won't be able to help with the process due to agreements I have with the company I now work for. I'm also concerned that even if someone breaks into the conversation, Tesla may release firmware updates that lock people out again.

Bottom line, TWCManager will likely not get updated to support gen 3 TWCs unless someone else can figure out how to do it. Until Tesla releases a firmware update, even power sharing between two stock gen3 TWCs is not currently possible.

Copied from the TMC forum.

[ms100austria]

Please add V3 Support.

You can access the data via the API:

http://"ipaddress"/api/1/vitals

{„contactor_closed“:false „vehicle_connected“:false „session_s“:0 „grid_v“:230.1 „grid_hz“:49.928 „vehicle_current_a“:0.1 „currentA_a“:0.0 „currentB_a“:0.1 „currentC_a“:0.0 „currentN_a“:0.0 „voltageA_v“:0.0 „voltageB_v“:0.0 „voltageC_v“:0.0 „relay_coil_v“:11.8 „pcba_temp_c“:19.2 „handle_temp_c“:15.3 „mcu_temp_c“:25.1 „uptime_s“:831580 „input_thermopile_uv“:-233 „prox_v“:0.0 „pilot_high_v“:11.9 „pilot_low_v“:11.9 „session_energy_wh“:22864.699 „config_status“:5 „evse_state“:1 „current_alerts“:[]}

http://"ipaddress"/api/1/wifi_status

{„wifi_ssid“:„RlJJVFoh4565464IEZvbiBXTE456IDczOTA=“ „wifi_signal_strength“:100 „wifi_rssi“:-35 „wifi_snr“:62 „wifi_connected“:true „wifi_infra_ip“:„192.168.178.149“ „internet“:true „wifi_mac“:"98:ED:5C:8C:77:21“}

http://"ipaddress"/api/1/lifetime

{"contactor_cycles":32 "contactor_cycles_loaded":0 "alert_count":5 "thermal_foldbacks":0 "avg_startup_temp":5199147.0 "charge_starts":32 "energy_wh":89012 "connector_cycles":5 "uptime_s":1297280 "charging_time_s":33152}

http://"ipaddress"/api/1/version

{„firmware_version“:„21.8.5+g51eba2369815d7“ „part_number“:„1529455-02-D“ „serial_number“:"PGT21106012345“}

Sure will be your first beta tester.

[deece]

I'm not convinced there's a big value add to support logging data without being able to control the charging.

Since you already have a nice REST interface, I'd just push that directly into OpenEnergyMonitor/HomeAssistant/whatever and call it job done, at least until we have some way to control the charging.

[joriws]

At least a new firmware upgrade to 21.29.1 has power sharing api calls. So maybe twc manager could use that to control gene live.

But first api should be traced for handshakes and messages and then twc gen3 emulator could be build.

[Darosnl]

Just got an gen3.
Looks like it got 2 wifi bands, it can connect to your home network and still send out the Tesla network.
So looks like the dedicated tesla "network" is for load balacing.

Also i would like to mange the gen3 you must connect to the "private" tesla network. In your own network you see an /public page (and can access the api).

[bgrigoriu]

@Darosnl Can you give more details on what is accesible on each chanel ?

[Darosnl]

Could you explain what you need or what i can do?

[bgrigoriu]

Hi,
For the need , as most of us, I would like to be able to modulate the charging curent intensity depending on an external parameter ( for me is the output of my enphase solar system) . But this can be extended and used for load shedding. For the moment I could not found any doc on how to communicate with the Gen 3TWC. Only some reading is documented. Did you found anything else ?

[Darosnl]

I'm happy to help but if you can point me to some tooling i can use.
Or maybe we can do it together?

[bgrigoriu]

Hi,
I am happy to work with you but I really dont have the expertise to look/search what a gen3 is sending/expecting in order to modulate the charging curent.
I think it will need that someone has two Gen3 TWC configured as "master" and "slave" and see what is transmited over the wifi connection between the two ( I do not know even if that is possible or the degree of security involved here).
My Gen3 TWC connects as a station over the wifi to the house network and then to ionternet (TESLA server I suppose). The trafic is rather important: 56Mb uplink and "é MB downlink in two days including here a firmware upgrade.
The four requests Vitals, Wifi Status, lifetilme and version work very well but I am not aware of any other way to interact with the TWC.
The TWC also broadcasts an Wifi AccesPoint . You can change here the charge setiings. But I saw no doc over internet about it on how to interfere with this.
If you have infos or ideas how to get it I am open

[r151809]

Would the TWC access point stay up, if you connected and kept the connection alive forever? I.e. connect to TWC SSID, and send a get request for the config page once per minute or so.
Of course the api would be better, but it's still a mystery..

[mjkapkan]

Hi, Good discussion you have going on here. I recently bought gen3 as well. My initial idea was to use an openwrt wifi router with 2 bands that would forward the requests to the dedicated wifi network, that way the public part of API would be always accessible. Of course, one needs to first reverse engineer the load balancing protocol to control the charger ;).

[petekelly]

This is really interesting. I have a gen3 and we’re looking to have an enphase solar system installed. Ideally I’d monitor the enphase via API calls and enable 6A charging to the car if the correct amount of excess solar is detected.

@bgrigoriu did you have any luck or success with anything? My initial train of thought is a device which is connected to the wall charger Wi-Fi hotspot and just posts charging rate updates as the solar capacity becomes available.

I guess there is also the issue of telling the car to stop/start charging too but 1 hurdle at a time!

[bgrigoriu]

@petekelly
Hi,
the short answer is no, I could not do anything more. It is so far to my job today and i had no time to spar for this project. My enphase system is running and I managed to write the routine to get all the data from the Envoy metered. It is rather simple. I did it on a ESP8266 in C++. I had no time and experience to access the Tesla API to see if I can modulate charge intensity. The API comands for starting charging and modifyng the charging current have been published but since I am a newbee everything takes an enourmous time.

[mattiasottosson]

@petekelly, if you have a tesla only, you can set the amperage via the vehicle api. I installed a twc3 in my cabin yesterday and made a really ugly python test script in home assistant in order to set the charging rate based on whats available on each phase. Tends to work fairly well, but don't know the rate limits on the api. Would be better to do it to the twc directly though since it would work with all vehicles and less things that could break along the way.

https://gist.github.com/mattiasottosson/7deb5db74d561dcaee7ec331679922e7

[bgrigoriu]

Hi,
These is very good news. I read about the api commands but never never used them.
What is the minimal hardware that can log onto the tesla site and then send the commands ? (for which the suitable libraries exists/are published) .
I implemented the read of the excess solar production on a ESP8266 ( ESP32 also works). So i would like to put all this people in a small din unit that can be integrated in the electrical distribution panel.
Do you know if an ESP8266.ESP32 can connect or we nees a respberu pi ? à à zero or a zero 2 would work ?)

[mjkapkan]

I use a cheap wifi router with custom OpenWrt firmware.

[petekelly]

@petekelly, if you have a tesla only, you can set the amperage via the vehicle api. I installed a twc3 in my cabin yesterday and made a really ugly python test script in home assistant in order to set the charging rate based on whats available on each phase. Tends to work fairly well, but don't know the rate limits on the api. Would be better to do it to the twc directly though since it would work with all vehicles and less things that could break along the way.

https://gist.github.com/mattiasottosson/7deb5db74d561dcaee7ec331679922e7

Yes Tesla only (albeit it's not arriving until Saturday...). This was my plan actually, to

1. Connect to the solar Enphase API to determine the current excess generation
2. If excess >6 amps (1.4KW @ 240V), instruct the car to begin charging at 6amps
3. If excess <6 amps, instruct the car to stop charging.

[robot256]

Yes Tesla only (albeit it's not arriving until Saturday...). This was my plan actually, to

1. Connect to the solar Enphase API to determine the current excess generation
2. If excess >6 amps (1.4KW @ 240V), instruct the car to begin charging at 6amps
3. If excess <6 amps, instruct the car to stop charging.

I tried this a few years ago. I found that the car stopped responding to on-off commands after only a handful per day. It might be different now, and I don't know if the same limit is applied to the new API for setting Tesla charge current. If I were to do it over again I would use the car's schedule to enable charging during typical solar hours and modulate the charge current with the TWC signal (I still have Gen2).

[bgrigoriu]

@mjkapkan: that is a lot in term of size. I would like to put it on avery small hardware so this can be included in an distribution panel. However I am not able to find a tesla V3 authorisazation library.
@robot256 could you describe your hard/software more in detail

[robot256]

I forget exactly what my setup was. I think it was OpenHab using the Tesla API to control the car's on-off, and TWCManager on a Pi Zero controlling the Gen2 TWC amps setting, and OpenHab using HTTP calls to TWCManager. I have a Brultech GEM power monitor feeding OpenHab with the solar and house consumption data, which is why OpenHab needed to be the center of the system.

[mattiasottosson]

Yes Tesla only (albeit it's not arriving until Saturday...). This was my plan actually, to

1. Connect to the solar Enphase API to determine the current excess generation
2. If excess >6 amps (1.4KW @ 240V), instruct the car to begin charging at 6amps
3. If excess <6 amps, instruct the car to stop charging.

I ran it for one night now and it seemed to be working just fine. You can actually set the amps to lower than 6 through the api. It even seems to accept 0 as a value and pauses the charging (but the actual charging session is still active).

[KastB]

@petekelly It looks like you would use homeassistant.
I had pv excess charging (hopefully it is called that way in English) running for ~3 months with a python script that controls the charge speed via the tesla api and gets its information via mqtt (teslamate streaming api to reduce the api calls, vzlogger for the grid consumption from the smart-meter).
Maybe you want to have a look at here:
https://github.com/KastB/addon-tesla-pv-charging

Nevertheless I would like on "offline" version with limit imposed by the TWC better: we could have a higher rate of control and easier support of multiple cars or other brands. However, the minimal charge rate will probably be limited to 6A.

[realdadfish]

@KastB Based on your work I hacked together a version without MQTT / HomeAssistant support (neither of which I have in my setup) here: https://github.com/realdadfish/addon-tesla-pv-charging - it's not final yet and not tested, just work-in-progress.

The plan is to have this running standalone on my home server. The problematic part will probably be that the vehicle is woken up each time I need to query the state of charge to determine whether or not to charge it and if so at what amperage. At night the whole process can be stopped (when plugged in) because solar_power is zero, but at day time this means the car never really gets to sleep, especially when it's not charging, and this will likely draw power.

I don't know how Teslamate gathers the current data, but I'd guess it uses the Tesla API internally as well to query it, so I don't actually know how big of a problem this becomes.

[KastB]

@realdafish Probably there is a difference. There is some logic which decides when to stop polling/use the streaming api so that as little data as possible is lost while sleep mode is not prevented. Simply polling is probably not the best solution (probably ~300W higher consumption during the times sleep is prevented) https://docs.teslamate.org/docs/faq/

[jonasman]

Btw gen3 also supports rs485 power sharing . Maybe this could be adapted for that bus?

[KastB]

@jonasman are you sure there is full rs485 support for v3? I only read about V2 - do you have a link to detailed information?

My solution to control the charge current on the vehicle side broke due to restrictions on the API for Tesla cars.

Does anybody have any experience with this API and it's capabilities/limitations?
https://github.com/jeremyvisser/wc3magic
Cheers

[jonasman]

@KastB that’s how neurio is connected to the wc3:

https://service.tesla.com/docs/Public/Energy/Charging/Wall-Connector-Device-Setup-in-Tesla-Pros-EN/GUID-8CD32F0F-C5BA-43D9-951A-EB3E17043427.html

[deece]

Nice, if someone can track down the meter model, that should lead to the protocol specs (probably Modbus), and then the meter can be faked.

Looks like this is the unit:
https://www.ebay.com.au/itm/296252870455
Part number is W1-MODBUS-TESLA

[frizzby]

I would appreciate it if someone else could take a look at the data.
Clearly, the load values are being transmitted. There must be at least 4 floats or ints (if milliwatts are used). And I don't think the data is encrypted – it wouldn't make sense.

[r151809]

Exellent job @frizzby :)

Serial number and such are probably read by WC3 when provisioned. So we should record the data from the installaion phase. I assume that the WC3 will not just blindly ask the data - it first reads the model and serial to verify it really is Neurio.

Not really done decoding yet, but the first hunch is that it could be RTU Framing. Three ones at the begining looks like 3.5 character start, the rest would be missing from capture.. Some documentation here:
https://www.modbustools.com/modbus.html

[KastB]

I didn't have time to dig into it today.
The sequences without meter are interesting. I would guess those are requests to the meter and we see the response data from the meter in the "normal" data. Thus we might be able factorize and only deal with those smaller chunks between those requests.

[KastB]

@frizzby Great work, thank you! I had a second look into it and wondered if we really can expect so little data:
There is about 48bit, sometimes only 40bit of data. If I'm not wrong, the 7 digits of power from your screenshot need 32bits twice already. I'm wondering if the baudrate was higher / changed during your recording.
Did you try other baudrates / how did you determine it?

[frizzby]

Thanks everyone for taking time to look at it!

@KastB, aaah, yes, I think you're right – I'm not using the right baud rate.

For some reason I assumed (incorrectly) that since I'm getting any data it means the baud rate is right. Now that I think about it that assumption makes no sense.

I don't have an oscilloscope, but I do have a logic analyzer. Can it be used to determine the baud rate? In my understanding it should be possible if used with rs485-TTL converter, not directly from rs485 line. Can someone confirm?

Meanwhile, I'm going to just try different baudrates to see what results it will give.

[frizzby]

Disconnected and reconnected the meter. 115200 baud rate.

0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111
0000000100000011000000001000100000000000000010100100010111100111000000010000001100010100010001000100001010001110011001100100010010001000100111001101111010111101000000010110111100100101101111100010001000110100101011111100001101110010111000110100100000001101111100000000000100000011000000001111010000000000000010000000010111111110000000010000001100010000010000001101110100000101000010100100000100011011110111111110110000111100110000110101001111111000001111001100101110100011000001100010100000011100
0000000100000011000000001000100000000000000010100100010111100111000000010000001100010100010001000100001100010001000000000100010010001010001010110110010110111101000000010110111100100101101111010000000111000011101111111100001101110011000100111110000100100111011010000000000100000011000000001111010000000000000010000000010111111110000000010000001100010000010000001101101110111000100011010100000100011100100001001011001100111100101110110101011100110010001111001110001011110011100001011111111111111100
0000000100000011000000001000100000000000000010100100010111100111000000010000001100010100010001000100010010101001000001000100010010001000110110100010010010111101000000010110111100100101001111010000000111000011101111111100001101110011000000111010111101111111101111010000000100000011000000001111010000000000000010000000010111111110000000010000001100010000010000001101111011011011011001000100000100011100100111000111000000111100110011100011100001001011001111001100101110100011000001101110001010000101
0000000100000011000000001000100000000000000010100100010111100111000000010000001100010100010001000100001001100001110110100100010010001000101100110010011010111101000000010110111100100101101111011000000111000011101111111100001101110010110100110001010100011010110000010000000100000011000000001111010000000000000010000000010111111110000000010000001100010000010000001101110001000000110010100100000100011011101010001111111000111100110001111010111101001101001111001011110111001011001111011001100000100110

[frizzby]

This is how it looks with 115200 with low vs high load https://docs.google.com/spreadsheets/d/1KzO4i0zNmd9PlaaSO53OKI9kKUAVvXDLb3r9rOAyFCA/edit?usp=sharing

[frankenbubble]

looks like modbus RTU, but all the responses have an extra 107 bytes after the frame

convert to hex and use a tool like https://npulse.net/en/online-modbus (enter hex into Hexadecimal Translate, hit enter etc)

request as hex 01030088000A45E7
a response as hex (first 25 bytes, removing the 107 extra bytes) 010314444261DA4488B326BD016F25BD81C3BFC372D3151AC1

CRCs seem to check out , not sure what the extra 107 bytes are, not timestamps that I can see

First few bytes of each extra data portion:
Response 1: 01006f25be2234afc372
Response 2: 01006f25be4038efc373
Response 3: 01006f254f4038efc373
Response 4: 01006f25be6038efc372

[frankenbubble]

here is some python that reads your binary and decodes it. seems they are 32bit floats, and match your readings ?

https://gist.github.com/frankenbubble/33d14a01c65c80f42e0f92a09127a888

using the raw data in your sheet, putting it data.txt for the script I get this output

Line 1:
Request:
Raw Hex: 01030088000a45e7
Address: 1
Function Code: 03
Data: 0088000a

CRC (received): E745
CRC (calculated): E745
CRC Match: True

Response:
Raw Hex: 01031442ab3a1643c200c9bd016f253d81c3bfc233b4bcef3a
Address: 1
Function Code: 03
Number of bytes: 20
Register Data: 42ab3a1643c200c9bd016f253d81c3bfc233b4bc
Interpreted Data:
16-bit Registers: [17067, 14870, 17346, 201, 48385, 28453, 15745, 50111, 49715, 46268]
32-bit Floats: [85.61344909667969, 388.0061340332031, -0.03160013630986214, 0.06336163729429245, -44.92649841308594]
CRC (received): 3AEF
CRC (calculated): 3AEF
CRC Match: True

---

your sheet indicates its for reading 86W and 380W, which looks like a close match to the first 2 32-bit floats in the response

for the page indicating 2000KW , script says

32-bit Floats: [1985.830322265625, 2206.439697265625, -0.03160013630986214, -0.1267232745885849, -52.32987594604492]

[KastB]

Nice script.
I just made a small extension to parse the second request/response for each timeslot
So now we have the power as well as the current readings:
https://github.com/KastB/twc_meter_communication/blob/master/modbus_test.py

The current guess is: the 32-bit floats are Power/Current with clamp 1,2,3,4.
I don't know what the 5th value is for.

[KastB]

This script give as csv to show the Power/Current values:
https://github.com/KastB/twc_meter_communication/blob/master/modbus_read_data.py
My guess would be, that the 5th Power value is not a flat, but some other data

[KastB]

@frizzby I guess your goal should already be achieved. For us/me there are still 2 or 3 open points:

1. What are the last 32-bits in the power message for (maybe frequency/crc/voltage?)
2. How does the initial commissioning look like so that we can emulate a meter. (Could you maybe do a recording of that as well?)
3. Does the TWC completely shut off, if the reported currents limits are reached?

[frankenbubble]

re 1. The doc for the meter say it has measurements for Real Power, Reactive Power, Energy, Imported/Exported, RMS Current,
RMS Voltage, Line Frequency , so maybe it's one of those , I would assume voltage must be there somewhere for it to know amps from the watts readings.
re 2. this for me is important as it means we could try fake a meter to control charge current
re 3. my understanding from https://teslamotorsclub.com/tmc/posts/8124883/ that it fails to 6A if it loses connectivity.

[KastB]

1. For information ab to each clamp, there probably is too little information. Additionally: when we calculate voltage from power and current, for the low power recording, the voltage seems to be too low. So either there is pretty bad fluctuation on the grid, or a scaling factor involved. Maybe a longer recording could help there.
2. Thats my motivation as well.
3. This would be bad news for me. I would like to do PV charging, and thus need the ability to completely stop charging by setting a high current, so that the limit seems reached for the charger.

@frizzby It would be great if you could 3 more tests:

1. A long recording, where different load scenarios happen, without interrupting the recording (I think we can find the transitions now), so that we maybe can decode the 5th power value, which might be a scaling factor
2. Do a recording of the initial setup, so that we could create a virtual meter
3. It would be great if you could verify the behavior of the charger, when the limit of the cabinet is reached => maybe configure a small current limit for the cabinet, create load so that the limit is reached, and check if charging stops, or if it is only reduced to 6A

[frizzby]

Thanks everyone for the help! Nicely done decoding it!

1. I'm not sure what are the last 32-bits in the power message. It usually sits at around -50. When I start EV charging it drops to -240 and doesn't react much when I increase the load even more (by turning on the oven). However, it jumps to 1200 when I start my AC. What could it be? Reactive power? See https://snapshots.raintank.io/dashboard/snapshot/WbI32Gl5jiOXmE464csvNzdyRwYjCfqQ
   I've added a few annotations on the charts to help understand what's going on.
2. There's no way in the app to unlink/remove the meter. I'm going to Factory Reset the wall connector and do recommissioning while recording the data from rs485 line. I will post the results separately.
3. The lowest limit I can set is 40A. The app doesn't allow lower values. Unfortunately the charging doesn't stop when limit is exceeded. It is only reduced to 6A. The same happens when I disconnect the meter.

Btw, my wall connector is Tesla Universal Wall Connector, not TWC3. But I think they are the same software-wise.

[KastB]

1. This could really speak for reactive power: Unaffected by the resistance load of the oven (if you don't have an induction stove), capacitors of the EV charging would be in-line with more negative reactive load, and the induction of the motors in the AC could be correct positive reactive power. From what we learned in theory, this could very well be reactive power and it would make sense to place it close to the loads for each clamp. I never had a look on real-world reactive power data, so I wouldn't know for sure, but it sounds plausible.
2. That would be great!
3. That really is a pity. Maybe there is a 2nd limit when we greatly exceed the limit, which we could reach with the virtual meter. Otherwise we need manual intervention to stop charging at least at night.

Thank you very much for your efforts doing those recordings!

[johado]

Is it clear whats needed on the network side towards the WC3 to enable and configure the load balancing without an actual Neurio meter?
(Protobuf messages mentioned)
Does the vitals or other REST endpoint on the WC3 show anything related to load balancing or is it all protobuf?
(I currently do my load balancing towards my car using the Tesla vehicle-command go program from an RPi using BLE so I don’t use the cloud API:s, but controlling the charger would be better.

[frizzby]

Unfortunately I didn't have time today to do the recommission, and tomorrow I leave for vacation for a few weeks. I have some vested interest myself in figuring out the rest of the modbus communication, so I will recommission and record the comms when I'm back home.

[frizzby]

Is it clear whats needed on the network side towards the WC3 to enable and configure the load balancing without an actual Neurio meter? (Protobuf messages mentioned) Does the vitals or other REST endpoint on the WC3 show anything related to load balancing or is it all protobuf? (I currently do my load balancing towards my car using the Tesla vehicle-command go program from an RPi using BLE so I don’t use the cloud API:s, but controlling the charger would be better.

Protobuf mentioned above is an excerpt from the communication between TWC and Tesla One app with the phone connected to the AP the TWC is broadcasting. Once we're able to emulate the meter TWC should automatically detect the meter and you would use Tesla One app to configure CTs as Conductor and set the current limit. You can see how that looks in the video and in the pdf.

I didn't see any changes in /api/1/vitals endpoint after configuring the meter.

[KastB]

@johado I only read about the tedapi which seems to exist for several products: PowerWall or TWC3
But I didn't test it by now as it seemed to me, that they are only used to configure (for TWC3), not during operation.
I didn't find resources about the load sharing protocol.

[KastB]

Here they have a reactive power for each clamp

[frankenbubble]

afaik, the wall chargers don't expose any data like this via the 'normal' internet wifi, although you can get some different data via the built in 'setup' wifi, but that still goes asleep after some minutes.
the powerwalls seem to have always on wifi that gives extend information, which i think is what they are looking at.

I suspect the 5th float is indeed (total) reactive power, as it make sense with the AC turning on it becomes a high positive value, otherwise a small negative value. I also suspect if we queried the meter at other addresses we would get more data, and we might see that happening in the setup communications.

it would be interesting to see what serial requests come from the TWC3 during setup as it looks for a meter (what address it queries and with what codes etc),

[frankenbubble]

I hooked up my twc for serial, and notice it regularly outputs a modbus request, adding here as information, i assume a probe for a meter.

Binary: 00000001 00000011 10011100 01000010 00000000 00000110 01001011 10001100
Hex: 01 03 9c 42 00 06 4b 8c
ASCII: �BK�
Received CRC: 0x8C4B
Calculated CRC: 0x8C4B
Message Length: 8
Address: 1
Function Code: 3
16-bit Registers: [40002, 6]
32-bit Floats: [-6.418924582637371e-22]

[johado]

I can confirm that I get exactly the same data. So getting a trace from power on from someone with a Neurio connected would help us get one step further hopefully.

[andreaconfa]

Hi, any news on this?

[frankenbubble]

Need @frizzby or someone with the hardware to post more serial data

[frizzby]

Attached are two files:

• I started the recording -> clicked factory reset on the TWC -> the TWC is now in waiting for commissioning state -> I stopped the recording: factory_reset.txt

• I started the recording -> I commissioned the TWC and configured the meter -> I stopped the recording: after_factory_reset.txt

[KastB]

@frizzby: welcome back, I hope you had nice holidays.

For the provisioning/resetting: Those seem to be ASCII Strings:
Registers: 9c420006 ASCII: ...BGenerac. Raw: 0001004247656E6572616300

To register this seems to be the register:
Registers: 00010037 ASCII: 0x000004714B056861..1.6.1-Tesla.........012.00020A.H....90954.VAH4810AB0231.................04:71:4B:05:68:61.

Raw:3078303030303034373134423035363836310000312E362E312D5465736C6100FFFFFFFFFFFFFFFF3031322E3030303230412E480000FFFF3930393534005641483438313041423032333100FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF30343A37313A34423A30353A36383A363100

Maybe/Probably 9c420006 is just a magic string.

00010037 holds different Blocks.
Notice how "." encodes different things in the ASCII representation:

• "2E" when there is a "." within a string
• "00" or "FF" to fill a block
  I'm not sure where the limits of those blocks exactly are and what they represent, and when to fill them with "00" and when with "FF" .
  The first block seems to be 20 chars long and a hex number.
  Second one the firmware version, then maybe a configuration.
  Then there is the serial number of the meter and at the end a mac address.
  What I miss is the number under the meter (52506).
  For the parts besides MAC, Serial Number, and Firmware version I have no idea what they represent.
  Probably we would only find out by trial and error. Maybe just copy and manipulate them to find out how the TWC behaves.

[frankenbubble]

The two files seem identical, but i think it's ok as it's probably the commissioning one.

I put a simple html page together that makes parsing the binary easier. https://frankenbubble.github.io/modbus_decoder/index.html ,

it looks like ~20 gets of data at 2 addresses, is probably the metrics. and 2 at 2 other addresses is the setup (I'm guessing). My TWC sends out the requests to address 0x9C42, and it looks like the response is the manufacturers name.

the requests to 0x0001 seem to have the firmware and other information like @KastB says. some of it looks different to your screenshots earlier such as VAH4810AB0231 looks like it previously in you data was VAH4770AB5642 . @KastB maybe the meter number 52506 is now 90954