Please skip if you are getting tired of this development talk 🙂 ……

While I was debugging the WiFi interface today I was, of course still getting in and out, now and then resetting the dongle, making sure th car was awake, etcetera. And then one of those “aha”-moments struck me.

What if I took a web-server (or even the Wemos reprogrammed) and make it emulate my gateway with possibly prerecorded answers from my car?

Eureka! Not only would I not need to leave my desk anymore, I could do entirely without the car, even tweak values supposedly coming from it. As all the primitives that are available in the real ELM327 driver are also present in the WiFi gateway, it should work. So, I quickly threw together a small “Wemos WiFi Bluetooth gateway emulator” on my ancient Freecom NAS server and verified it could serve at least one IsoTp frame (module temperatures). Like this for the IsoTp primitive:

$PAR = $_GET['f'];
switch ($PAR) {
    case "7bb.79b.6101":
        echo "{\"C\":\"IsoTp\",\"F\":\"$PAR\",\"R\":\"61011381138700000000000000000000000009980D61033A20D000000548000000000000000E721D000001142927100000000000\"}";
    case "7bb.79b.6161":
        echo "{\"C\":\"IsoTp\",\"F\":\"$PAR\",\"R\":\"6161000972C0C8C8C8ACA40000DB8D00002D6DFF\"}";

So here is what that looks like, interface wise

jeroen:~$ curl http://[removed]/wemos/IsoTp?f=7bb.79b.6104

7bb and 79b is the ID pair of the LBC, and 6104 is the command to get the cell temperatures. The real frame contains more data but this is the only part used by CanZE in the heatmap. I have marked those fields in blue. Those are the 12 module temperatures in hex, with an offset of 40 degrees (32 hex is 50 decimal, minus the offset is 10). Then I continued working on the “ELM327Http” device in CanZE, which was sorta done, but was still full of errors. After a few hours of painstaking work, but not leaving my desk (the family was out with the ZOE anyway): success.

As I was 80% done with tedious under the hood changes for the new diagnostics, I had to fix the many problems I had introduced in that area too before CanZE was only slightly willing to operate at all. Did I already mention how that process goes? Well, exactly like that, but now without all of the car back and forth stuff.

Next: sniff the car on all possible frames and put that in the PHP code. After that is done, verify the other screens and then onto the diagnostics. Stay tuned.

Next day edit: of course errors keep popping up and I fix them as we go, but I have now committed the changes to the branch for internal testing. I also too a snapshot of my car (all free frames and all diagnostics of the EBV, LBC and CLIM computers) and put them all in said webserver “car emulator” code.

This post is not about the ZOE, Fluence or Kangoo Z.E., but about what it takes developing something like CanZE. Imagine debugging this beast without a car systems emulator on your desk and no Bluetooth emulation in Android Studio. The process goes a bit like this:

  1. Think of some great feature you always wanted to implement;
  2. Program it;
  3. Conclude you made some silly errors;
  4. Back to 2, when done…
  5. Download it to your phone;
  6. It crashes immediately;
  7. Back to 2, when done…
  8. Walk to the car, unlock it, wake it up, start Canze, wait for it to pair with the dongle, open your great new screen;
  9. It crashes immediately;
  10. Close car, kill remnants of CanZE, get back in the house, sit down, connect phone to USB only to conclude the crash post mortem is gone from the phone’s memory. Back to 2. When done…
  11. Notice it doesn’t do exactly what you intended. Often you’re now back to 1 instead of 2, as you need to think again where you conceptually went wrong. Sometimes that means creating entire new data structures. And all the existing functions need to work;
  12. It works! now at least test some of the old functionality!
  13. Old functionality is broken;
  14. Fix it. back to 10

And I am not even talking about version control, releasing, managing changes between developers. It is a far from complete list, but you get the idea: it is a tedious process often taking place in the hours after midnight.

As I am working on a major change involving getting more diagnostics data from the car I decided enough was enough. I build a special piece of hardware based on a “Wemos D1 mini” processor and a “HC-05” Bluetooth interface (eBay is your friend). It connects my WiFi network directly to the KONNWEI dongle in the car. The processor acts like a web server and all the primitives CanZE can ask the dongle, this little computer can too. In essence it is initializing the dongle, getting a free frame or a diagnostic command. Wemos runs about 1000 lines of C code to do that, part of which is very similar to the ELM327 driver in CanZE. Though CanZE is Java of course……..

This little thingy is now in the window sill near the car, while my desk is at the complete other end of the house. Total hardware cost is under 10 Euros, but of course many hours went into programming it. The Wemos is a fantastic implementation of the ESP8266 processor by the way, but I digress.

Next on my list: Modify CanZE (see process above!) so it can use http to get the data from the car. Not only would (notice that I am not saying “will”) that enable me to run CanZE from my phone while still at my desk, but it should also enable us to finally run CanZE in the Android Studio device emulator. There is one minor thing left though. The car must be awake for this to work. That usually means it should be on and started; in some cases, it just charging is enough. Oh well, we can’t have it all can we?

The AC charger cables have a resistor between protective earth (PE) and the proximity pin (PP) pin to indicate

  • that the plug is inserted
  • that the plug can therefore be locked (type 2 only)
  • the gauge of the cable, and thus the maximum current

Note that the PP pins are NOT wired through the cable. The most common resistor values and also those of your standard Renault cable are 220 ohms, corresponding to 6 mm2 and 32 amps continuous, and 680 ohm, corresponding to 2.5 mm2 and 20 amps continuous. These are per strand values and the power varies given the number of phases used.

These PP-PE resistors should be installed on both ends of the cable, which I had not realized before. Yesterday I helped a friend changing his home charger from a socket type to a fixed cable type, so that he didn’t have to get the cable from the trunk every evening. The cable came pre-wired with the resistor in the plug, but it didn’t work. Only when we installed a PP-PE resistor in the charger itself, indicating the cable was inserted on that end, the charger started the process. The other side effect is that if you measure the connectivity between the PP pins on your standard Renault cable, you’ll measure a confusing 440 ohms. That’s because both ends are wired to the ground lead with 220 ohm resistors.

1500 Ω resistor – 13A cable
680 Ω resistor – 20A cable
220 Ω resistor – 32A cable
100 Ω resistor – 63A cable

A (former?) Twizy and current Zoe driver in Austria called “AbRiNgOi” had a Twizplay laying around. This is an open source CANbus driven small display, based on Atmel micro controller. Anyone who has ever played with Arduinos knows what I am talking about. The specific controller used is an automotive version of an ATmega with a build in CAN controller.

He reprogrammed the Twizplay using the CANbus information that we gathered and that is available in the source code of CanZE on github. We are very pleased and proud that our hard work is spinning off toward other projects, in the true spirit of Open Source. Link here.


TwizPlay is originally programmed in BASCOM (a non-Free BASIC compiler for the Atmel and 8051 processors), but “AbRiNgOi” decided to do this the proper, but hard way and redo all using Atmel Studio 7 and C++, bringing it much, much closer to the Arduino community.


Our strong advice is not to leave the dongle active in the car while you’re away. In essence, it is a not-secure direct access device to the main CANbus of the car, with a default Bluetooth password. I have been able to wake up all the ECU’s from a sleeping Zoe using just the dongle. Things like opening doors are probably pretty hard to do but I wouldn’t consider it wise to believe it is impossible. That is one more reason we like the Konnwei – Maxiscans: they have this little on/off button on the top (unfortunately, they do not seem to go to sleep after half an hour of CANbus silence as the documentation suggests, but alas). At least it is easy to switch it off.

Another side of the question is power usage. I am bringing this up as my Zoe was completely and utterly dead this morning with a flat 12 volt battery. So, I decided to check how power hungry my dongle is: less than 1 mA when off, 40 mA when on with a sleeping CANbus, so that should drain the battery of not more than 1 Ah per day and should not be an issue.

Bottom line: be smart and switch it off. If not, and she’s still there where you left her, no harm done.

PS: It was really odd as the car was connected to the charger (had not charged for one reason or another), but the traction battery was still at least half full. My charging logging email from Renault suggested that she had her last charge in the night from December 30th to 31st. That could be right, as there was virtually no driving last week but last night definitely is strange. I have a suspicion about what happened but before I am sharing that I need to get rid of the error and ensure the 12 volt battery is not a dud.

Update: I had her up and running again after charging the 12 volt battery enough (a few hours on 3A) to wake her up and start charging. Never ever do this with the car connected. Remove the minus lead and, as the car can decide to try to charge the battery even with the contact off, make sure the lead is isolated. My suspicion is that the charger plug was not seated correctly and it tried locking it for a couple of hours with most of the ECU’s awakened by the dashboard computer. After charging there was a message to check the electrical system, but that went away by itself.