By Posted on Posted in Builds, Teaser No Comments

Working for over a year, we’ve been making slow but steady progress on changing the way how we fundamentally talk to the dongle. The cheap Chinese dongles are awful coping with what we call “Free Frames”, and especially the torque bars make extensive use of those. Reliability is low, delay is high and many dongles won’t work at all. Finally, since the ZE40 models came along, many dongles were overwhelmed by the busier traffic on that type’s CANbus.

We’re getting close to releasing a version of CanZE that tackles all of the above. The downside will be that we will need to drop a few fields but we regard then as rather unessential. Think of indications like cabin temperature set-point, flap open; things that are clearly visible on the dashboard anyway.

For the technically minded readers: if approved, the next version will have an alternate mode that will use only ISOTP request-response type of communications. Next to loosing mentioned fields, a ISOTP is by definition somewhat intrusive to the car compared to free frame “sniffing”. This is academical though.

We will encourage all users using and ELM327 type of dongle, such as the KONNWEI902, to try switching on “Use ISOTP fields” in the settings; things might improve significantly. For those who have build or want to build an CanSee dongle, we suggest to keep using free frames. It will beat the ELM dongles in speed hands down. After feedback, we might automate the switch based on dongle type.

Stay tuned, all coding is done and we’re now testing.

Edit: As silly cheap dongles sometimes have no secure Bluetooth capabilities, CanZE switches to an insecure Bluetooth connection when “Use ISOTP fields” mode is switched on.

By Posted on Posted in Car, Help, ZOE 7 Comments

The Tire IDs (and pressures) are conveniently labeled Front Left, Front Right, etcetera, but the car has no separate receivers for the individual wheels. It just sees four values coming in and checks it. Enough for the warning light, but not for us users. We want to make sure the pressure is stated for the correct wheel, and the ID for the correct wheel is displayed.

We’re in a pickle a bit as we received a report that the Rear IDs in CanZE are swapped, while we have followed available documentation. As none of the developers have a TPMS equipped car, it’s impossible to experiment. So in case you are a “tire guy” with a TPMS equipped ZOE, please do some experiments and confirm (or deny) said report. Thanks!

By Posted on Posted in Builds

In the next release we plan to introduce dark mode for Android 9 and 10 devices. It will have a dark, light and System (as in, follow what Android does) mode.

Until now, we’ve been keeping CanZE compatible with API level 15, meaning Android 4.0.3. For reference, we’re talking Samsung S2 era, early 2012 phones. To make dark mode work without over-complicating the code, we have to let go of supporting Android 4 and make API level 21 the minimum requirement. These are late 2014/early 2015 phones. The number of active users below API level 21 is approximately 2.5% of the active users, so we feel this is a fair compromise.

The sun-setting of Android 4 support has been announced starting today in the news bar. If you run CanZE on an Android 4 device it will no longer receive updates, but it will still run the older versions.

By Posted on Posted in Builds

Things have been slow as vacation progressed. And of course now work is competing. But that doesn’t mean things have halted. A new release is in the making, though it mainly fixes language and edge case stability issues. No new functionality.

  • Growth has slowed down but is still going on quite nicely: 2.4% in the last 30 days and we’re now at about 5300 active Android devices
  • ANR’s are virtually zero (one user impacted)
  • Crashes are down to a record low 0.15%, less than one per day. This is half of the peer median. And half of those are Bluetooth related.

By Posted on Posted in Geek talk

Renault changed it’s API totally for the complimentary MY Renault app. Muscat did massive reverse engineering, implemented a python library and CLI. I implemented that in Node-RED. Please note there is zero error checking. The bottom two rows are examples that can be fed the same message as the Get battery status node.

Please note that the API has changed again. The current implementation is here.

The kamereon_id key has changed early 2021. See this post.

By Posted on Posted in ZOE

I’ve been busy recoding the interface between my home automation and ZE services as Renault changed their entire apps and API to “MY Renault”. That worked out with the kind help provided by James. All back on track again in Node-RED.

While doing some research I ran into a post from one of the developers on the French forum. This was one of the things he mentioned that has always been “somewhat known”, but more precisely formulated now.

  • Start of charge
  • During charging, every 30 minutes (every 15min for Z.E. 40)
  • End of charge
  • Beginning of a journey
  • During the trip, every 30 minutes (every 15min for Z.E. 40) or every 5% of SOC (state of charge of the battery)
  • End of a trip
  • Before sleep (3 min after lockout) if the battery value has changed since the last message
  • Before sleep (3 min after lockout) if the car is not connected, a charge is programmed and the charge level is less than 100%
  • Low battery alert
  • Instant pre-conditioning set point.