Drawing power out of CCS port (V2x, inverse charging, bidirectional CCS)

[uhi22]

Well, if we strictly stick to the topic of the thread, I would even call this a full success
Summary: Tesla Model 3 2019 (EU) as "solar string" on Kostal Plenticore Plus (together with the amazon precharge converter) happily delivered 5kW for ~15 minutes.

[lewurm]

Let's make that ~70 minutes

The car sent a PowerDeliveryReq with "ReadyToChargeState": "0", and then a SessionStopReq, last lines of the log is attached.

Also the alerts in the service menu are very interesting. Seems to be the threshold is 15Ah of discharge.

Edit: Including BMS_a076 / BMS_a076_SW_Dch_While_Charging and BMS_a174 / BMS_a174_SW_Charge_Failure as text here, so it's searchable.

[johu]

Very nice! So that is 5 kWh roughly.
Just a random thought: if you command the inverter to actually charge the car for a few seconds maybe that resets something?

[lewurm]

Finally...

Convincing the Kostal inverter was trickier than expected. After some help by the Battery Emulator community I finally got it to work. There is also a ModBus register in the inverter where the current can be changed from -13A up to +13A. Both works

Just a random thought: if you command the inverter to actually charge the car for a few seconds maybe that resets something?

Yeah, I will conduct some tests in that area since I can finally control the (dis)charge rate. If that shouldn't work, another attempt would be to disconnect the CP line via a relay to simulate a unplug/plug and thus restart the charging session. But even those 5kWh are "workable"... that would get us through a summer night

What I also want to investigate is the handling of SessionStopReq. This should rather quickly communicate to the inverter to reduce the current to ~0A. I did it manually so far, but if the car for some reason (e.g. -15Ah threshold reached) requests it, pyPLC will just send "yeah, good bye", although there is still some load on the line...

[Skibbie]

Very nice! The Kostal is even a very good Tip, with it's combined PV/Batt Input this could even Work for my EV6 with Up to 825V.

Currently I've stopped my Tests, because of some "incident". A Capacitor is blown... Luckily nothing Else Happens. Bit Always remember: High DC voltage is Dangerous!

In my Tests I was Not able to Open Battery contacts, with EVSEMaximum = 1000V. IT was even worse, because the contactors Starter some flickering. Sounded Not very healthy for them...

Maybe there ist someone Out there WHO wants to try a Kostal with e-GMP 800V system? Currently I don't Like to spend 1200euro for playing...

Greetings from northern Germany,
Christian

[lewurm]

The Kostal is even a very good Tip

No no no... please don't get a Kostal. Basically every other inverter has a ModBus or CAN interface, except for the Kostal, they implement a custom (undocumented) protocol over RS485, which isn't fully understood yet. There are some timing related things in the protocol, and thus I cannot reliably start a session with it. Also the battery input only supports a voltage up to 650V.

Have a look at Deye or Afore, they have an input voltage of 150-800V on the battery side. And a sane behaviour on the communication side

A Capacitor is blown... Luckily nothing Else Happens. Bit Always remember: High DC voltage is Dangerous!

Ouch, glad to hear you are fine!


On the subject of supplying the correct voltage: There has been in interesting development around the Battery Emulator project for the MEB battery (VW etc.), which has a similar requirement for getting the contactors to close. The result is a modded step-up converter (the one that has been mentioned already in this thread) that can be controlled via PWM to adjust the voltage: https://github.com/dalathegreat/Battery ... ied-hia4v1

I haven't tried it yet, but it's on my todo list

[lewurm]

Some setback on my side. For context, my current setup looks like this: (1) RaspberryPi with pyPLC running (hooked up via WiFi to the local network), (2) an ESP32 running the battery emulator code for communication with the inverter via RS485 and also controls some additional contactors (also hooked up via WiFi) and then (3) the inverter itself hooked up via Ethernet to the local network.

There must be some care taken when it comes to stopping the charge session: No power should go over the wire. The base case is when the car user presses "stop charging" on the car UI, the car first will send a PowerDeliveryReq with ReadyToChargeState set to false, and then a SessionStopReq. For both messages it is fine to wait around for one second with an actual reply; In the meanwhile there is enough time to send modbus commands to the inverter to reduce the power to 0, and as a failsafe, on the SessionStopReq I'll also open the contactors attached to the battery emulator, the idea being I'd rather have those welded than the contactors in the car.

That works reasonably well... except for two issues:

1. For some reason the PLC connection starts getting hung up somehow a couple times already; the symptom being that the raspberry starts sending TCP retransmissions, which take too long and therefore the car will abort the session (reported on github), but on the pyPLC side no SessionStopReq is received.
2. If you read my description of my setup carefully, you will notice that I’m kind of insane and do safety critical communication over a wireless network. Well, that can be congested sometimes and requests can take a while.

So if those two occur at the same time you get this apparently (the inverter was drawing with around 4000W at this point):

That is the HV system wouldn’t come up anymore. Shout out to my wife for being super chill about me bricking our daily driver.

The behaviour at least is good news, I think: Before opening the contactors and risk welding, it will rather blow up the fuse (much cheaper to replace). At least that's my understanding, I don't have hard proof for it. I didn't capture all the messages in the service menu, and most of them were gone after a reboot, but I guess somewhere in there it would give a reason.

That happened last Thursday, and on Monday I had new pyrofuses in my hands. Initially I ordered two to have one as a backup, but since those weren’t OEM fuses and I read some scary stories about replicates in the meanwhile, I decided to blow one up before putting it into the car Luckily it did its job. Replacing the pyrofuse in the car is like a 2h job. I guess it could be done in about an hour if you are more experienced (let’s hope I cannot confirm this soon-ish ). HV system comes up again, everything seems fine

Anyway, further experiments are on hold on my side until I’ve a backup pyrofuse (hopefully before Christmas, actually picking up one from the local Tesla service center on the 23rd if everything goes as planned). In the meanwhile I’ll squash the battery emulator logic for talking to the inverter somehow onto the Raspberry Pi (probably within pyPLC, it’s really just a serial protocol over RS485 and controlling a few GPIOs for the contactors) to get rid of the wireless communication. Initially I wanted to stick with the battery emulator in the picture, because it supports a couple of inverters already, but oh well. Maybe I'll also run another cable to the inverter to not use ModBus over TCP but rather over RS485.


Additionally I want to be able to detect those TCP reconnections reliably. Not quite sure yet how to do that, but since the sniffer messages are popping up multiple times in the syslog there should be some way to detect it. And then I'd like to improve the situation to not even have those TCP reconnections anymore, but not really sure what I can improve on that front.


Let's hope blowing up a pyrofuse is the worst that can happen to the car with those kind of experiments

[peternooy]

This is new to me, never happended before. Based on my limited experiment with Tesla car when the PLC disconnected while power is still be drawn the car just abort the session, due to protocol timeout (defined for each message). This should be normal behaviuor of the system at SECC-EVCC interface point, but inside the car there are a lot more going on and OEM can always handle it differently.

Too bad that you don't have all the alerts captured, as it may provide some clues. If you manage to replicate this again, please try to capture as nuch as you can

As for the BMS_a076_SW_Dch_While_Charging alert, based on my experiment, it does happend more on Tesla car with NMC battery and much less for the LFP version. But now I don't have a car to test anymore so can't be sure if my observation is correct.

[MrZe]

Some setback on my side. For context, my current setup looks like this: (1) RaspberryPi with pyPLC running (hooked up via WiFi to the local network), (2) an ESP32 running the battery emulator code for communication with the inverter via RS485 and also controls some additional contactors (also hooked up via WiFi) and then (3) the inverter itself hooked up via Ethernet to the local network.

There must be some care taken when it comes to stopping the charge session: No power should go over the wire. The base case is when the car user presses "stop charging" on the car UI, the car first will send a PowerDeliveryReq with ReadyToChargeState set to false, and then a SessionStopReq. For both messages it is fine to wait around for one second with an actual reply; In the meanwhile there is enough time to send modbus commands to the inverter to reduce the power to 0, and as a failsafe, on the SessionStopReq I'll also open the contactors attached to the battery emulator, the idea being I'd rather have those welded than the contactors in the car.

That works reasonably well... except for two issues:

1. For some reason the PLC connection starts getting hung up somehow a couple times already; the symptom being that the raspberry starts sending TCP retransmissions, which take too long and therefore the car will abort the session (reported on github), but on the pyPLC side no SessionStopReq is received.
2. If you read my description of my setup carefully, you will notice that I’m kind of insane and do safety critical communication over a wireless network. Well, that can be congested sometimes and requests can take a while.

So if those two occur at the same time you get this apparently (the inverter was drawing with around 4000W at this point):
Screenshot 2024-12-17 at 23.22.27.png

That is the HV system wouldn’t come up anymore. Shout out to my wife for being super chill about me bricking our daily driver.

The behaviour at least is good news, I think: Before opening the contactors it will rather blow up the fuse (much cheaper to replace). At least that's my understanding, I don't have hard proof for it. I didn't capture all the messages in the service menu, and most of them were gone after a reboot, but I guess somewhere in there it would give a reason.

That happened last Thursday, and on Monday I had new pyrofuses in my hands. Initially I ordered two to have one as a backup, but since those weren’t OEM fuses and I read some scary stories about replicates in the meanwhile, I decided to blow one up before putting it into the car Luckily it did its job. Replacing the pyrofuse in the car is like a 2h job. I guess it could be done in about an hour if you are more experienced (let’s hope I cannot confirm this soon-ish ). HV system comes up again, everything seems fine

Anyway, further experiments are on hold on my side until I’ve a backup pyrofuse (hopefully before Christmas, actually picking up one from the local Tesla service center on the 23rd if everything goes as planned). In the meanwhile I’ll squash the battery emulator logic for talking to the inverter somehow onto the Raspberry Pi (probably within pyPLC, it’s really just a serial protocol over RS485 and controlling a few GPIOs for the contactors) to get rid of the wireless communication. Initially I wanted to stick with the battery emulator in the picture, because it supports a couple of inverters already, but oh well. Maybe I'll also run another cable to the inverter to not use ModBus over TCP but rather over RS485.


Additionally I want to be able to detect those TCP reconnections reliably. Not quite sure yet how to do that, but since the sniffer messages are popping up multiple times in the syslog there should be some way to detect it. And then I'd like to improve the situation to not even have those TCP reconnections anymore, but not really sure what I can improve on that front.


Let's hope blowing up a pyrofuse is the worst that can happen to the car with those kind of experiments

This happens when charging station reports that it is transmitting power and car doesn't see it. In this case tesla vehicle thinks that something is wrong and there is a huge problem and blows fuse in this case.

[vbarrier]

Some setback on my side. For context, my current setup looks like this: (1) RaspberryPi with pyPLC running (hooked up via WiFi to the local network), (2) an ESP32 running the battery emulator code for communication with the inverter via RS485 and also controls some additional contactors (also hooked up via WiFi) and then (3) the inverter itself hooked up via Ethernet to the local network.

There must be some care taken when it comes to stopping the charge session: No power should go over the wire. The base case is when the car user presses "stop charging" on the car UI, the car first will send a PowerDeliveryReq with ReadyToChargeState set to false, and then a SessionStopReq. For both messages it is fine to wait around for one second with an actual reply; In the meanwhile there is enough time to send modbus commands to the inverter to reduce the power to 0, and as a failsafe, on the SessionStopReq I'll also open the contactors attached to the battery emulator, the idea being I'd rather have those welded than the contactors in the car.

That works reasonably well... except for two issues:

1. For some reason the PLC connection starts getting hung up somehow a couple times already; the symptom being that the raspberry starts sending TCP retransmissions, which take too long and therefore the car will abort the session (reported on github), but on the pyPLC side no SessionStopReq is received.
2. If you read my description of my setup carefully, you will notice that I’m kind of insane and do safety critical communication over a wireless network. Well, that can be congested sometimes and requests can take a while.

So if those two occur at the same time you get this apparently (the inverter was drawing with around 4000W at this point):
Screenshot 2024-12-17 at 23.22.27.png

That is the HV system wouldn’t come up anymore. Shout out to my wife for being super chill about me bricking our daily driver.

The behaviour at least is good news, I think: Before opening the contactors and risk welding, it will rather blow up the fuse (much cheaper to replace). At least that's my understanding, I don't have hard proof for it. I didn't capture all the messages in the service menu, and most of them were gone after a reboot, but I guess somewhere in there it would give a reason.

That happened last Thursday, and on Monday I had new pyrofuses in my hands. Initially I ordered two to have one as a backup, but since those weren’t OEM fuses and I read some scary stories about replicates in the meanwhile, I decided to blow one up before putting it into the car Luckily it did its job. Replacing the pyrofuse in the car is like a 2h job. I guess it could be done in about an hour if you are more experienced (let’s hope I cannot confirm this soon-ish ). HV system comes up again, everything seems fine

Anyway, further experiments are on hold on my side until I’ve a backup pyrofuse (hopefully before Christmas, actually picking up one from the local Tesla service center on the 23rd if everything goes as planned). In the meanwhile I’ll squash the battery emulator logic for talking to the inverter somehow onto the Raspberry Pi (probably within pyPLC, it’s really just a serial protocol over RS485 and controlling a few GPIOs for the contactors) to get rid of the wireless communication. Initially I wanted to stick with the battery emulator in the picture, because it supports a couple of inverters already, but oh well. Maybe I'll also run another cable to the inverter to not use ModBus over TCP but rather over RS485.


Additionally I want to be able to detect those TCP reconnections reliably. Not quite sure yet how to do that, but since the sniffer messages are popping up multiple times in the syslog there should be some way to detect it. And then I'd like to improve the situation to not even have those TCP reconnections anymore, but not really sure what I can improve on that front.


Let's hope blowing up a pyrofuse is the worst that can happen to the car with those kind of experiments

Hi, thank you for your sharing!

Did you be able to continue your testing after Christmas?

(I'm looking to build a DC inverter as well, but I'm still in a process of understanding the things

[uhi22]

Looks like the Teslas 15Ah limit can be worked-around by pretending a charge current while actually discharging: viewtopic.php?p=78883#p78883

[dimonlipko]

Hi! I have model Y and hybrid HV inverter DEYE. And I want to make connection between there. First reason is charge EV from PV, and AC charge from 3ph because my tesla is from USA and have mono phase PCS.

I have Foccci and think about modify it, add PWM for EVSE and add external module voltage supply for emulate precharge.

Who has any thoughts on this?)

[lewurm]

Looks like the Teslas 15Ah limit can be worked-around by pretending a charge current while actually discharging: viewtopic.php?p=78883#p78883

Alas nope, there was a follow-up: https://teslamotorsclub.com/tmc/threads ... st-8579714
What's interesting: with that device the battery heater turns on, which is boring quickly in cold weather (it's like ~7kW and trying to heat up to 50°C). Interestingly with pyPLC I haven't seen that ever. Ingineerx (the author for that teardown) was so kind to send me a trace of the PLC communication. It's on my list to check if any differences in the messages pyPLC sends avoids the heating, or if it's due to the Tesla BMS firmware (he is using an older firmware version on his car).

Did you be able to continue your testing after Christmas?

Yes! I'm planning to do a more structured write-up somewhen next month, but for now a braindump for curious folks must do it; basically all the information is out there, I just built something on top of giants (pyPLC and battery emulator) and put them together

NO FURTHER PYROFUSE HAS BEEN HARMED IN THE FOLLOWING ACTIVITIES (first good news )

The first thing I tackled is the timeout issue. There are two ways to detect it: (1) Whenever the communication is in state CurrentDemand the expectation is that the next message will arrive within 110ms, if not, a stopDCSoft is triggered, and if it happens again a stopDCHard is triggered: https://github.com/lewurm/pyPLC/blob/cd ... #L473-L480 The difference is that stopDCSoft tells the inverter via ModBus to reduce the power to zero, while stopDCHard will open the contactors of the wallbox (ignoring any potential load and thus risk welding).
The (2) way is to hook into the sniffer https://github.com/lewurm/pyPLC/blob/cd ... #L317-L320 which will also trigger a stopDCSoft. This is however slower in terms of reaction time, it's somewhere around 300ms. I assume you could tune that value somewhere in the TCP settings of the kernel, but I guess the first variant is already good enough.

And then I replaced the jumper cables that I used within the wallbox for CP with some 2 pair telephone cable that has shielding, and suddenly the timeout situation was much much better. It's still happening, and from the few observations I have it seems to only happen when there is a lot of sun; I assume the DC cables between wallbox<>inverter are carrying some noisy stuff when the inverter is more at work? I ordered some ferrite rings to put on the DC cables (please tell me if this a bad idea, I have no idea what I'm doing regarding EMI).

I also gave up on using the Battery Emulator, and instead ported the inverter communication to Python and use it directly within the pyPLC loop. This makes the coordination much easier, it's basically another variant in hardwareInterface.py. It's also equipped with some additional tweaks that are easily possible in a Linux environment, e.g. I'm using the pykoplenti command that uses the REST API of the inverter to turn on/off its battery support. Probably possible on an ESP32 too (which Battery Emulator runs on), but much more cumbersome. And then there is some interaction with my local Home Assistant instance for high level control, logging state transitions and bookkeeping. By the way, I had some "performance issues" because that involves network stuff, which can have delays... and that's not good to do on the same thread as the car communication (which is pretty sensitive to timeouts, roughly one second). So there is another thread that polls/push certain stuff, to unblock the main thread. Seems good enough, but a bit hacky due to the GIL in cpython.

Regarding the step-up converter, I followed the mod described here: https://github.com/dalathegreat/Battery ... age-source
And have a little calibration script to figure out good frequencies for the PWM: https://github.com/lewurm/pyPLC/blob/di ... ter_mod.py
It depends on your input voltage, but then didn't require much tuning, it rarely needs more than one attempt before the car is happy: https://github.com/lewurm/pyPLC/blob/cd ... #L303-L339
It's pretty solid!


That's how it looks like currently.

Still janky... looks better if you hide it

So I did my first longer session last Sunday:

kostal SEM Power Saldierend is the sum of the three phases going to/from grid according to the Kostal smartmeter (an additional device). Scb-kostal-battery Total Power is the power to/from the battery according to the inverter. dcwb_strategy is the input to a script that controls via modbus regarding how much power should go to/from the battery (it runs as part of Home Assistant via PyScript https://gist.githubusercontent.com/lewu ... 3e/dcwb.py yes yes, I'm a Home Assistant fanboi ).

So it's discharging for a while, and then doing a little "charge pump" to hopefully reset the BMS state and thus bumps the 15Ah threshold. And it seems to work, because I sucked out more than 15Ah in this session. It was pretty cold in the garage already and I was tired, so I stopped the session. I thought that was already pretty cool, but there seems more to this 15Ah limit...

On Monday (electricity spot prices were high), I felt confident enough to leave it unattended (well I put a security cam inside the garage it's actually pretty useful for verifying the shutdown sequence on timeouts, the sound of the different contactors are distinctive ):

Here the car aborted with the infamous BMS_a076_SW_Dch_While_Charging, but interestingly enough without payload (it doesn't mention -15Ah):

Still great, that was a 6h session and I was already very happy with that.

For easy restarting a charging session I put CP behind a relay. So flipping that one for a few seconds works in some scenarios to restart the charging session, for example if the EVSE initiates stopping the charging session. Interestingly enough on TCP retransmission timeouts the session can also be restarted this way. However, on this BMS_a076_SW_Dch_While_Charging event the charge port LED pops up red. I can initiate another session, but it even refuses to precharge. It requires physical unplugging.

So I started another session, but exactly at midnight something happened: The inverter restarted. Apparently that's a thing, haha. I just didn't handle that case well, but I added some code to consider that and started another session a few minutes after midnight... and amazingly, the very same session tested next midnight, that is, it was running more than 24h

I want you to appreciate pyPLC for a second, it's amazing how well it works. Thank you uhi22!!!

What do we see here? So this FZ60e Battery value comes from TeslaFi which in turn polls the Tesla API... at some point the battery level got stuck, but it didn't on the Tesla App. I submitted a bug report and it was actually fixed pretty quickly then (or it was just a coincidence? I didn't get a response yet). Anyway, I thought that was funny

From the charts you can probably guess the more expensive hours. Also towards the evening the oven was on and the control loop to adjust power oscillated, but fortunately the car nor the inverter seemed to mind. In the 26th hour the car stopped the session with our dear friend BMS_a076_SW_Dch_While_Charging, this time showing the payload message again (see previous post) mentioning the 15Ah threshold. At this point I already added a session counter for charge/discharge amount, so you can see that those are almost equal. However, and here comes one of the drawbacks using a car as battery: There is some idle power used by the car if it's "online" (for example when it's charging). From what I've gathered from the CAN bus, it's around 200W. And that seems to match quite well: According to my session counters there was 500Wh more charged into the car than discharged. And then 200W for 25h => 200*25 + 500 = 5500Wh. Divided by 390V that's 14,1Ah. That seems to be the right ballpark. However, it's sort of surprising, given the "charge pumps", that have helped in the first chart in this post.

And an observation from today: I stopped the charging session after ~4.5kWh discharging and did the CP flipping, but unfortunately the next session aborted after ~1kWh of discharging with BMS_a076_SW_Dch_While_Charging. Only physically replugging helped then. A bit of a bummer; alas I can't "disconnect" PP (= putting a relay inbetween) on my plug, but not sure if that would even help.

More experiments are needed And maybe it's also time to have a closer look at the BMS firmware in a disassembler...

Anyway, I'm really really happy with the results so far. Thanks again to uhi22 and other pyPLC contributors for making all the work and information publicly available, and also shoutout to the folks over at the Battery Emulator Discord. It has been really fun so far and I learned a lot!


TODOs on my side:

• figure out EMI issue whenever there is too much PV energy

• figure out why inverter won't start battery usage when there is already PV energy there. My hope is that is related somehow with the previous point, but with the RS485 connection between inverter<>wallbox. There might be as well parts of the protocol that I'm missing in that situation. The current implementation is based on reverse engineering, so... if someone has good connections to Kostal, I would be very interesting in their custom protocol

• clean-up code more, I pushed my current state here: https://github.com/lewurm/pyPLC/commit/ ... 9f2bd52992

• do a structured write-up so others can reproduce the setup more easily

• more experiments and automation fine tuning to work around the 15Ah limit

[uhi22]

I have Foccci and think about modify it, add PWM for EVSE and add external module voltage supply for emulate precharge.

Who has any thoughts on this?)

This is definitely a possible way. However, it requires to implement the evse state machine on stm32. I think somebody did this but I cannot find it. An other way is using a raspberry running pyPLC instead of Focccis stm32, and connect the Raspberrys SPI to Focccis SPI.

[dimonlipko]

Or i think about make module for Foccci on the other MCU like esp32, that has HV Dieter, LV Dieter and DC-DC for precharge. Connect with Foccci by CAN.

HV Dieter i want to make with i2c ADC and i2c isolator and 5v dc-dc isolator.

For make Foccci work in PEV mode, what I need? As I understand important upload other dump in SPI Flash for QCA. And make some changes to the STM32 firmware, but I don't know how difficult it is)

[uhi22]

There is some confusion about which side (vehicle or station) we are talking. Foccci, DieterHV and DieterLV are all originally on PEV (vehicle) side.
I understand you want to construct something for the EVSE (station) side.
Regarding voltage measurement via i2c: recently found the INA226, this measures voltage (0 to 36V directly) and current (via external shunt, max 80mV). High resolution, cheap, fast, with configurable internal digital averaging. So just adding an voltage divider and a 0.1mohm shunt this would allow to sense e.g. 1000V/800A with 16 bit resolution. Nice.

[dimonlipko]

Your right! I think that DieterHV and DieterLV is for EVSE side.

For current measure id like to use sensor based on hall.

Ok, in first setup for make EVSE side and EV close CCS contactor i try to use Raspberry PI and PyPLC. But i need add for Raspberry PI module with voltage and current measure and 400v dc-dc for precharge?

[lewurm]

It's on my list to check if any differences in the messages pyPLC sends avoids the heating,

So from the logs of this V2L device that was discussed, it appears that it sends EVSEMaximumPowerLimit with 480kW. In the OpenV2G fork that is used for pyPLC, this value is hard coded to 10kW. For testing, I bumped it up to 250kW (that's the maximum power I have witnessed at a fast charger) and then indeed the car will start heating the battery pack.

CAN screenshot from the car. This is without any charge or discharge coming from the inverter.


So 10kW seems like a sane choice in pyPLC/OpenV2G


Otherwise I'm doing quite some testing, already cycled the pack almost 3x times

The 15Ah limitation is not that bad, I rarely hit that. I also figured out how to get the inverter to use the battery when there is already PV power coming on the other DC inputs. With that this setup was ready for wife usage: For the disconnect scenario I installed a button that first will drive down (dis)charge rate of the inverter, then open the contactors in the box, triggers the stopsession in pyPLC and then also unlocks the charge port via an API call. Overall that takes ~7s. Connecting is really just plugging the CCS connector in, but the hookup to the inverter can take up to two minutes. Still not too bad, but I guess if the inverter would have been designed for this, that could be faster

However the PLC communication is behaving weird and driving me nuts. On some days it works flawlessly (see the previous post where I mentioned a session lasting longer than 24h), and then other days it's timing out roughly once per hour. I tried a few things:

• put on ferrit cores on PE, and the DC+/- lines. Except that it adds interesting audio feedback to the setup (you can almost tell the charge rate by the sound) it didn't help.

• Since the ethernet port on the Raspberry is used for PLC, I use WiFi to communicate with the home network. I saw that the Raspberry sometimes connects with 2.4GHz and sometimes with 5GHz, and was kind of excited that this would be it. But after some testing, I can say: Nope, unrelated...

• ... because then I tried to disable WiFi and use an USB ethernet dongle (which was a good idea regardless), but that didn't change anything too.

• For good measurment I also turned off the bluetooth kernel module

• Rerouted the CP line a bit so that it isn't close to things like the 24V DC power supply

• Made sure that the shielding of the CP line is connected with PE

• Started to track the built-in temperature sensor of the Raspberry, but no correlection either (and also, the garage is not heated...)

I'm starting to think that the TL-PA4010P v2.3 I'm using is just messed up in some way.

Does anyone know how to check the "connection health" of the PLC device? I found this:

Code: Select all

$ /home/lewurm/private/open-plc-utils/plc/plcstat -t -i eth0 -d 2 -m -e
 P/L NET TEI ------ MAC ------ ------ BDA ------  TX  RX CHIPSET FIRMWARE
 LOC CCO 001 EC:08:6B:8B:DC:D6 DC:A6:32:21:1A:7E n/a n/a QCA7420 MAC-QCA7420-1.1.0.844-01-20120919-FINAL
 REM STA 002 DC:44:27:10:16:16 DC:44:27:10:16:15 009 009 QCA7005 MAC-QCA7005-1.2.5.3207-00-20180927-CS
 NID 01:02:0D:1E:56:64:07 SNID 001
 CCO TEI 001 MAC EC:08:6B:8B:DC:D6 BDA DC:A6:32:21:1A:7E
 STA TEI 002 MAC DC:44:27:10:16:16 BDA DC:44:27:10:16:15 TX 009 RX 009
   DIR ----------- PBs PASS ----------- PBs FAIL PBs ERR ---------- MPDU ACKD ---------- MPDU FAIL
    TX                    6                    0   0.00%                    6                    0                    0   0.00%
    RX                    0                    0   0.00%                    0                    0   0.00%

   PHY ----------- PBs PASS ----------- PBs FAIL PBs ERR ----------- BER PASS ----------- BER FAIL BER ERR
 0   0                    0                    0   0.00%                    0                    0   0.00%
 1   0                    0                    0   0.00%                    0                    0   0.00%
 2   0                    0                    0   0.00%                    0                    0   0.00%
 3   0                    0                    0   0.00%                    0                    0   0.00%
 4   0                    0                    0   0.00%                    0                    0   0.00%
 5   0                    0                    0   0.00%                    0                    0   0.00%
   ALL                    0                    0   0.00%                    0                    0   0.00%   0.00%

but that isn't too helpful: once the connection is gone, it won't output anything.

When looking for other options, I stumbled over this: https://www.tindie.com/products/evsec/hat-raspi-evse/ I tried to contact the seller, but alas no response yet. Would kinda seem like a perfect fit for a hardware noob like me... also lower the entry barrier to reproduce a setup like this.

I already see myself ending up hacking on foccci to get something more stable. But before getting into that rabbit hole I'll try to replace the TPlink TL-PA4010P v2.3 that I'm currently using with a v5.0 and hope that the higher version number implies higher reliability


PS: I'm curious how well this setup works with other cars. If anyone has a non-Tesla EV, is somewhat close to Linz in Austria and is willing to risk bricking their car in my garage: let me know!

[johu]

Sounds good! (except for the PLC)

BTW I connected the modem via an Ethernet switch. The same interface can be used for regular traffic and Homeplug at the same time

[jrichl]

PS: I'm curious how well this setup works with other cars. If anyone has a non-Tesla EV, is somewhat close to Linz in Austria and is willing to risk bricking their car in my garage: let me know!

I'm reading here in der forum since many weeks, and the inability of the German regulations which let to the situation that we have no DC BIDI Wallboxes since 2 or 3 years, although there are some manufacturers at the market that build such boxes brought me to the point, I need to try it be myself.
So it's absolut incredible what all the guys developed meanwhile and what is possible. Your approach seems to me the most promising, for my needs (V2H) although my car is a MEB Platform (ID.5), and the charging/discharging will interrupt after about 1 minute (about what I have read until now). Meanwhile I have started to build the necessary hardware for talking to my car, but you're living in the range of my ID.5 (approx. 160 km), and maybe we should try my ID.5 on your DC Wallbox.

[jrichl]

• Made sure that the shielding of the CP line is connected with PE

Which cable are you using from the Modem to the car connector - does the CP in inside the cable have a shield? Does the session interrupt when the charging/discharging power is at a high level or some peaks - the magnetic interference to the CP could maybe the cause as well. Unfortunately I didn't find a cable with a shielded CP inside a cable until now.

[johu]

I use a standard 5-pole 2.5mm² cable, so no shielding at all. Works flawlessly for entire days

[lewurm]

but you're living in the range of my ID.5 (approx. 160 km), and maybe we should try my ID.5 on your DC Wallbox.

that would be interesting send me a PM or find me otherwise on the internet (using the same nickname).

Unfortunately I didn't find a cable with a shielded CP inside a cable until now.

Sorry for the confusion: The CP cable from the CCS2 port to the box is indeed not shielded, but for "routing" CP inside the box I'm using a shielded cable (just a 4 wire telecommunication cable that I had around). This is me just being desparate; the way I understand PLC is that it's exactly built for noisy scenarios, so this shouldn't be needed.

[lewurm]

But before getting into that rabbit hole I'll try to replace the TPlink TL-PA4010P v2.3 that I'm currently using with a v5.0 and hope that the higher version number implies higher reliability

I did that a few days after I've posted that and with v5.0 I did not get a single timeout since. I'm also using the DC Wallbox exclusively since then.

The only limitation left is really the 15Ah discharge limit. The limit is okay on days like today were almost 30kWh have been charged into the car, so I have around ~35kWh to get through the night but still a bit annoying, e.g. if the car is taken for a trip in the evening. I think the state machine could be resetted if I would be able to put PP behind a relay, so that a physical unplug&plug could be simulated. I tried to open the CCS plug, but there seems to be some glue for sealing... I didn't dare to use too much force... yet.

Luckily there are two pairs for PT1000s on DC+ and DC-, which could be used for PP instead, so no extra cable must be run to the wallbox. Found a video where a CCS plug is disassembled: