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.

[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