In the previous episodes of developers geek talk I explained a bit how the hardware you use is terrible for actual software development. Sitting in a cold car, often at night with a laptop is no fun, and the process is slow. The http gateway changed a lot in that respect. We can now test new features in CanZE without having to leave the desk. So code, upload to the phone and it will get to the car over WiFi through http and in the car itself it is still using a real ELM327 KONNWEI 902 dongle. More about an alternative approach in another episode of geek talk.

Another benefit is that CanZE can now be run in an Android Studio emulator. Here you see an emulated Nexus phone running CanZE on my Ubuntu laptop showing the latest Climate screen. I went outside while it was running an pushed my hand against the outside temperature sensor that is mounted under the right side mirror. We can now test different screen sizes and orientations too without actually owning such devices. All this has never been possible as the Android emulators do not support Bluetooth. Also, we can quickly test different language settings without messing up our own devices.

So now you know why the latest release of CanZE asked for network permissions: next to using Bluetooth to get raw data from the car, it can use WiFi or even the Internet over the cell network to get that data through a gateway.

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?