Hi
We fixed that nasty bug quiet fast, so version 1.21 is online now which should fix the issue. If you encounter problems, despite of this patch, please use the issue tracker on GitHub to let us know about your problems …
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:
Under the hood things have massively changed too.
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?
Today I got big news from Frederic RICHARD, telling me that the iOS version has been published in iTunes and available:
We are using the same issue tracker for both version, so you know where to go with whatever you will find.
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.
