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.
As a consumer, or should I say as data submitter, I’m interested in this approach. Certainly regarding de SoH data, I’m very interested and therefore willing to make my data available in a way as described in the blogpost. Hoping that more users will do so, and in this way building a data base from which we can learn how to maintain our battery best and make predications about battery life and capacity in the future.
Thank you Gertjan. My idea is to post: Hash of VIN (so a consumer can “follow” each individual car, without actually knowing it’s VIN), SOH, SOC, Max DC charging power, minimum, mean and maximum battery module temperature.
I would be interested in contributing with data.
Me too
I would be interested in sharing my data, too!
I think not a lot of CanZE users are aware of this post – maybe you could advertise it once within the app (or have a link to it in the options or something), just to make it more discoverable.
(Or even have two links (Yes/No) asking directly if people would be willing to share their SoH data (and a third link here explaining the details) – like some kind of poll.)
Thanks for caring about our data so much!
Hi there,
Since I sometimes make long trips (1800km round trip this summer!) with my trusty Renault Zoe Q90, the possibility to send the real-time data collected by CanZE to an external server, as in the case of ABRP, would be a real plus.
As I said on GitHub, if the user has the possibility to control how the request is forged (with, for example, a system of variables/placeholders in the URL), and if the destination server supports HTTPS, I don’t see any significant problem in terms of privacy.
Moreover, the prediction models for the Renault Zoe on ABRP are still in alpha because they lack real-life data. Personally, I would very much appreciate being able to rely on a refined prediction model, because these kind of long trips are quite complex! If CanZE had had this feature this summer, I could have provided quite a bit of data to refine their prediction model. 🙂
Hi
If we would implement this, whether the feature will be active or not, the app would require the “internet connection” right. During the last discussions about this subject, the teams decided always against this. But I like your idea of a custom URL, which would kill the argument about GDPR because then, none of the authors could be hold responsible for any data breach 😉
Personally, I agree. The same would have been true using MQTT(S) which has an advantage of possibly having multiple subscribers. So the discussion is I think about doing it, and not doing it in a stupid way. Using querystrings while encrypted is not really best practice as it’s usually logged by webservers.