Welcome to the CanZE app pages

canze-icon-shadingIf you want to learn about your Renault electric vehicle, you’ve come to a good starting point. We will supply you with an app that displays driving stats and lots of interesting information about your car. All you need is a Bluetooth OBDII dongle and an Android device. For a more detailed description of the app see the about or the screenshot page.

The app is also available on Google Play store here.

Posted in News

Next release coming up

We are close to releasing the next version, probably next weekend as we test for silly errors this week. Features:

  • Multi-language is now possible, and added languages (Dutch, French, and we think we’ll manage German too. Thank you all volunteers!)
  • Added a lot of diagnostics. This part still needs a lot of work. For some known ECU’s you now have:
    • Real descriptions of DTC’s, something like “Battery voltage:value below threshold”;
    • Dump of all diagnostic parameters to a file.
  • Added a Climate screen;
  • Changed the Firmware screen. This more expanded info is needed to import ECU definitions. More on that in a separate post later;
  • Lots of bug fixes in graphs and layouts.

Under the hood things have massively changed too.

  • Tons of cleanup, added comments and removal of old code;
  • Simplified and improved our development chain;
  • Improved and sped up existing code.

We’re still struggling with unstable Bluetooth and getting access to the BCB. We are working on both though.

Please note that this release of CanZE will ask for a new permission: Internet access. We use this only to have CanZE access a WiFi gateway (or a car emulator that uses the same protocol), see Developers geek talk . Regular users will probably never use this. Internet access is not used to send any data to the Internet. We have not implemented MQTT, we are not collecting any data, nothing.

Posted in News

The charge plug locking mechanism revisited

See this post for details. Yesterday I was charging at a Fastned station to test out an issue with harmonics. That went fine. Fastned here is a provider doing only high power charging and only at stations along the highways. Their equipment is supplied by ABB. What never happened before, I was bitten by this issue. One can argue (and I am one who does!) that the pin lock mechanism, and especially the micro-switch is a flimsy design. However, the plugs at those Fastned designs are simply insane. The thing is so long and the cable is so heavy that even my never-had-this-problem-in-three-years ZOE not only had a hard time locking the plug until I supported it while it tried, but the force pried the switch open after it was locked, already charging and I slowly let go. Immediate interruption of the charging process, BCI level 1 (just retry)  and after three tree times red nose and BCI level 2, rain dance ™ required. What a pain in the behind! In the end I repositioned the car and “draped” the cable in a way it sort of supported itself more or less and then all was dandy, see picture.

This is two rather lousy designs conspiring together to not make things work. What on earth were they thinking?

Posted in ZOE

iOS version ready

Today I got big news from Frederic RICHARD, telling me that the iOS version has been published in iTunes and available:

https://appsto.re/fr/k6jdbb.i

We are using the same issue tracker for both version, so you know where to go with whatever you will find.

Posted in Uncategorized

Connected services – thoughts

No, we’re not talking about Renault Connected Services, we are talking about CanZE. Let me start straight off the bat with this: we always have been, and still are, extremely reluctant to add any sort of Internet based logging or data transfer, even with your, the users, consent. That stance has not changed. Anything written in this post is, at most, dipping a toe in the water and no indication, let alone promise that we will implement any of this in this branch of CanZE. Our reasons are twofold: we don’t want to be responsible for your data, and there are possibly serious legal risks associated, depending on country of driver, home country of developer and/or country where the data is stored, again, even with your consent.

That doesn’t mean we haven’t had requests of various kinds. And actually, there is a lot to gain from it too. For instance, if we collect State of Health data from a couple of hundred cars, we could give you a lot of feedback on battery degradation. We have an idea floating around the developers to maybe make this possible after all. Not only that, maybe to make it in a way that anyone can make such analysis if he prepared to invest a little bit in a couple of tools. Let me explain.

Using a protocol called MQTT, you, the driver, could publish a data stream coming from your car through CanZE. That encrypted data stream would be sent to an MQTT broker service of your own choice. In fact, an MQTT broker can be your own, i.e. on a Raspberry Pi, but there are also cloud based brokers, such as Adafruit.io and Amazon CloudMQTT. In configuring this, you can decide who can subscribe to your car’s data stream. Maybe you don’t want anyone to, and that is fine. Or maybe the entire world, and that is fine too. Services that are allowed to your data can subscribe to it and from that moment on, they receive updates as they are pushed from CanZE. For arguments sake, lets say this is once every 10 minutes while CanZE is running.

An MQTT subscriber can be anything. It can be a small micro-controller that only enables your home charger if your battery is more than 50% empty. It can be a fancy dashboard on your tablet. It can be a data logger. It can be the light-switch of your living room (I wouldn’t hook that up to the data from your car really!).

There is no inherent storage (unless you tell your broker it should), and there is no ownership and responsibility of the data but yours. Of course anyone who is allowed to subscribe to your stream could decide to log it themselves, but the matter of fact is: we neither operate the broker (you do!) nor do we want to. We, the CanZE team, can only subscribe to a data stream that you would have made public and are therefor already, by definition, public. Anyone could check if what we are sending is what we promised to send and not more too. The only thing we would appreciate is any sort of mechanism to be informed if a driver decides to create a public stream of her data. I am not saying this should be automated. Maybe just courtesy based, we don’t know.

MQTT is not very complex. Bare minimum you would need an account from a broker provider, fill in half a dozen fields in CanZE, and then most providers will allow you do start making web or app based dashboards.

We would like to know if people are interested in this approach, again without any commitment from our end. If you want to know more about the nitty gritty of MQTT, here is part one of a quite detailed description.

Posted in Uncategorized

Charging and cosphi

Dutch forum member, Q210 driver and multifuntion charger builder “fivari”, posted this table today, stating charging behavior of the Q210 on a single phase line under chargepoint power conditions. Measurements were done in this order, so charginging definately starts at 8A. Three phase table will follow on a later date. Great info, thank you!

Pilot chargepoint (A) - Pilot CanZE (A) - Current (A) - Power (kW) - cos phi
=====================   ===============   ===========   ==========   =======
6                                 no charging,  pinkish dash
8                       7                 7,7           1213         0,66
10                      9                 9,6           1808         0,80
12                      11                11,2          2281         0,87
14                      13                13,1          2763         0,91
16                      16                15,7          3374         0,94
18                      18                17,3          3750         0,95
20                      20                19,5          4271         0,96

Here is more data. Also Q210, now on a 3 phase settable charger. Unfortunately no real AC power data

Pilot chargepoint (A) - Pilot CanZE (A) - Available CanZE (kW) - DC CanZE (kW)
=====================   ===============   ==================== - =============
10                      0, not charging   3,0                    -0.2
12                      11                4,2                    4.0
13                      12                5,1                    5,1
14                      13                6,0                    5.6
Posted in ZOE

DTCs unraveled (teaser alert)

Truth to be told, the DTC READOUT screen never worked very well. Codes did not always appear and when they did, well, it was just codes. Not anymore in the next release! We’re adding the actual meaning of the Diagnostic Trouble Codes for every computer we have them for. Here’s a little teaser screen, showing the result of querying the Uncoupled Brake Pedal computer of my ZOE:

Let’s dissect the second one. 405155 can be split in three parts. The first one (4) means it is usually displayed on diagnostic tools as “C0”, meaning it is a SAE  standardised chassis trouble code. The next 3 (051) define what hard- or software component of this computer is causing this DTC. Here it is the Steering wheel angle sensor, which is interesting as it is part of the Power steering (EPS), not the UBP. The last two hexadecimal numbers indicate what test triggered this DTC to be fired. Here (55) it is “Not configured”. Finally, zero or more flags can be sent with the DTC. In this case the “testNotCompletedThisOperationCycle” flag.

This particular DTC is completely benign. If a flag called “warningIndicatorRequested” is included, we’re in different territory. It  means the orange spot light in the dash comes on.

Posted in ZOE

Climate computer loosing it’s mind?

I read quite a few complaints about the heater system. Not that it’s a bit underpowered, but really off, as in just blowing cold air when heat is requested. I am more or less trying to compile a list of user-fixable, or -detectable causes, from what I read on forums. Please comment if any of what’s listed here is wrong by your experience, or right!

  • Low on coolant gas. Rattling sound by the compressor. Dealer trip needed. Note: I hope to have this situation shown in CanZE soon;
  • Cabin sensor (which is said to be in the dashboard between the front windshield vents) ticked off by direct sun radiation. I’d sat that is easily provable with a piece of carton;
  • CLIM computer bug: it is said that in combination with or after a demist, the car can refuse to heat. I am not sure if a hard reset (next bullet) is needed, but one could at least switch de-misting off;
  • CLIM computer lost it’s mind. Things happen. Pull/push fuse F3. It is the rightmost column, the first fuse counting bottom up in the fuse panel in the cabin. Should be a 10 amps fuse.
Posted in ZOE

Developers Geek talk revisited

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:

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

So here is what that looks like, interface wise

jeroen:~$ curl http://[removed]/wemos/IsoTp?f=7bb.79b.6104
{"C":"IsoTp","F":"7bb.79b.6104","R":"6104000032000033000032000032000032000032000032000032000032000032000032000032"}
jeroen:~$

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.

Posted in Hardware

First steps into diagnostics

With mentioned gateway now in place, and the car happily charging (therefor awake) in my front yard, and what seems to be a fairly good description of all diagnostic fields, it is SO much easier to peek into the car’s diagnostics. So, on my laptop I made a little program plowing through the database of diagnostic commands of the EVC (motor controller), the LBC (battery controller)  and the CLIM (heater / airco computer), request every known diagnostic frame, pull out the values of each frame and write that back into the database. We are talking over 3000 values for these 3 computers only.

I can see the pressure in the Airco circuit, which is not fairly low as it was not running, but laso things like the positions of every airflow valve.

Here some data from the LBC.

Posted in ZOE

Developers geek talk

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?

Posted in Hardware