Please provide more info on modules used and wiring about c-zero_dashboard

[pierre-muth]

Hi dmit2k !
I was just going to take this free time rainy Sunday to catch up on some projects. I published this one a bit in a hurry, and it is time to complete it. At least, as you said, the wiring. I'll let you know in this github issue by tonight.
Thanks for your nice words, I hope you will iterate on this project. The arduino I used is quite limited, the CAN bus has a high data rate and data are skipped during display refresh...

[dmit2k]

Thank you for the prompt reply, now impatiently waiting for the wiring! ))

Yes I agree, this arduino is pretty limited in resource, but it is just perfect as a PoC! I was looking for a solution to upload my battery telemetry to my smarthome either by wifi when arriving to my garage or in some realtime manner using my mobile phone wifi hotspot while driving. The idea is to continuously monitor battery health in relation to weather conditions and kilometres driven, as well as individual cells misbalance. Some other useful options could be:

• catching DTC errors and alerting them immediately;
• triggering on the heater in winter or AC in summer 10 minutes before leaving my office.

But I didn't like the idea of having an OBD adapter always plugged in to the socket (it is easy to break the socket while driving) and I found those adapters very unreliable. Earlier I have had some positive experience with ESP modules and especially modular ESPHome framework. It has everything ready to maintain wifi access or hotspot, provides a web ui and misc displays support, has MQTT client built-in and even has a CAN bus integration:

https://esphome.io/components/canbus.html

I was just looking around on how to put everything together and connect to CAN bus of the car directly when explored your project! ))

So once you will feel ready to rebuild the thing on ESP32 you can evaluate the ESPhome platform )

[pierre-muth]

I've put a schematics/wiring diagram here : https://github.com/pierre-muth/c-zero_dashboard/tree/main/picture_shematics.
Plus some pictures. I've updated the blog post as well.

To summaries.

• I wired the two CAN bus lines from the ODB2 plug.
• I took the 12V from the radio to not drain the battery.

You can easily find the MCP2515 + transceiver CAN module on ebay, but I struggle to find the exact same OLED screen. Actually you can find the same 2.42" OLED 128x64 I2C module, but with a larger PCB.

It should be even easier with an ESP32, as you said there is a CAN bus interface. Only the transceiver is needed.

Turning on the heater during winter is, to me as well, the start of these procrastination. It is not easy as far as I understood. Cars equipped with the Remote option has 2 additional modules, a RF receiver and a CAN module. On the imiev forum some people are trying to record the full message on the CAN bus when commands from the remote are send. No luck so far.

• Forum : https://myimiev.com/forum/viewtopic.php?t=763&sid=0d867ea4a08a17a7b57c030ba32bd9b3&start=170
• iMiev workshop manual : http://mmc-manuals.ru/manuals/i-miev/online/Service_Manual/2017/index_M1.htm

I'll have a look on ESPhome, looks promising!

Thanks again, and of course don't hesitate for any question, I'll try to help.

[dmit2k]

@pierre-muth JFYI:

while waiting for the purchased components to arrive found this note regarding the possible performance issues:

combination with software SPI and the old MCP2515 a high busload will give you a high loss on receiving data packages
...
It would be best to support the CAN Interface inside the ESP32 which has a huge input queue and with hat even on high load a software filter would ne no issue.

esphome/issues#2642

So probably the performance issues you have experienced are not only related to Arduino board and it is not the main bottleneck... Rebuilding the project on esp32 looks more and more promising then )

[dmit2k]

@pierre-muth JFYI:

Found one more project similar to what I'd like to achieve:

https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3

The project is pretty mature but still being actively developed. It is also based on ESP32 chip with custom hardware board (opensourced) and additional interfaces (3G/4G modem, GPS, three (!) CAN buses, etc) + iPhone / Android apps.

What is interesting, it is able to get lots of additional info from i-Miev / C-Zero / iOn cars, it refers some interesting CAN bus IDs that I've not seen elsewhere:

https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/tree/master/vehicle/OVMS.V3/components/vehicle_mitsubishi/src

Maybe this can be useful for you too as I was able to reuse those IDs and calculation methods in my PoC ESPHome/ESP32 project I'm testing right now. Unfortunately, I'm not so good in CPP syntax and can't understand the logic of getting some values of my interest:
static const OvmsVehicle::poll_pid_t vehicle_mitsubishi_polls[] = { { 0x761, 0x762, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x01, { 0, 10, 10 }, 0, ISOTP_STD }, // cac { 0x765, 0x766, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x01, { 0, 10, 0 }, 0, ISOTP_STD }, // OBC { 0x771, 0x772, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x13, { 0, 10, 10 }, 0, ISOTP_STD }, //external/internal temp { 0x782, 0x783, VEHICLE_POLL_TYPE_OBDIIGROUP, 0xCE, { 0, 5, 0 }, 0, ISOTP_STD }, //Trip A/B POLL_LIST_END };
As far as I get (and if I'm not wrong), those values require polling them by sending some specific CAN bus frames which is happening within the mi_can_poll.cpp file. But I still can't get the full picture on how to interpret this OvmsVehicle::poll_pid_t syntax to reproduce it in my project...