Things have not been quiet since the last release. In the development version, more languages have been added (German and Slovenian), thanks to several volunteers. Thank you! Also, a new release makes users go through a lot of screens and quite a few bugs have already been found. And fixed. We try not to do hotfixes, unless (like with this last release) CanZE really crashes. So, the more benign bugs are fixed or being fixed in the development branch.

As always, feel free to report issues on the github issue tracker, where you can also see what other reported and what has already been closed.

We also got some feedback on the new “Clima” screen. Notably, there was a request to also show the power the climate system takes. This has not been proven possible (maybe “not yet”, see below), so after some experimentation, we added the compressor RPM as a separate graph to the climate screen. Here’s a teaser (pardon the Dutch).

Finally, we are very happy to have been able to crowd-fund the acquisition of a CLIP system (yes, a clone). Many users made a contribution to make this possible. Thank you! We really hope we can dissect the BCB (the charger) with it, as it is unwilling to give us it’s secrets just like the other computers do. Stuff has been ordered and we can’t wait to get our hands on it. We’ll most certainly report back here when it’s arrived, and later if it was able to give us what we want! Stay tuned.

With the release of version 1.21 CanZE (Android version) is now officially a multi-language application. We have included English as default, and locales for Dutch and French. German is on it’s way. The language files are roughly 350 lines of XML. If there are volunteers who would like to see other languages added we would be very grateful and of course will be happy to include them. You can grab the complete English file here which contains as you know them, including untranslatable ones, and any of the other files (Dutch, French) as a template on how to format your language file.

The best way to get the file to us is by dropping it as an attachment to a new issue on GitHub.

Hi

Version 1.20 has been dispatched by Google’s Playstore, but I got noticed that it crashes on some devices. If you want to help or get some details, please go here:

https://github.com/fesch/CanZE/issues/407

In order to fix it, we need to be able to reproduce it, so reporting every setting of your device may help us! We introduced localized strings with this version, and probably this is the reason for the crashes.

Edit: On first glance, it seems to be related to the SD card logging, Fields option switched on. If true, switching it off is your temporary workaround until we have fixed it, but we would appreciate if you could report on the issue tracker above if this matches what you are experiencing.

Edit: hotfix (1.21) is being deployed now.

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.

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?

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.

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

R240, now on a 3 phase settable charger.

Pilot chargepoint (A) - Pilot CanZE (A) - Available CanZE (kW) - DC CanZE (kW)
=====================   ===============   ==================== - =============
6                       6                 2,4                    1,2
7                       6                 2,4                    1,8
8                       7                 3,0                    2,7
9                       8                 3,9                    3,4
10                      9                 4,5                    4,0
11                      10                5,1                    4,7
12                      11                6,6                    6,1
13                      12                7,5                    7,0
14                      13                8,1                    7,5
15                      14                8,7                    8,0
16                      15                9,6                    9,1
17                      16                10,2                   9,5
18                      17                11,1                   10,4
19                      18                11,7                   10,9
20                      19                12,3                   11,5
21                      20                12,9                   12,0
22                      20                12,9                   12,0

Edit: We now have much more technical background, see this post and a few before that.

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.