ESP32 Based Web Interface & Data Logger

[Leo M]

The interface is working... but there is a problem with downloading the parameters file! when uploading, the transmission fails at the end of the parameter list. Have you tried uploading a parameter file via the interface?

[Leo M]

It is necessary to fix something in the code ((( according to the test results, this gadget cannot be considered fully functional.

[johu]

I have to test parameter upload. What other issues did you find?

[Leo M]

I was assembling this interface for use with your 16-channel bms. the delivery turned out to be long and I decided to connect the interface to the version 3 board. the general conclusion is unstable operation, hanging, breaking of messages. …

[uhi22]

From some experiences I learned that the ESP is picky regarding the power supply. Wifi causes supply current peaks, and if this leads to certain voltage drops, it causes random effects. The other issue is CAN bus load. The ESPs CAN controller is crap (they even avoid to call it CAN), it seems to be fine with single messages and low bus load, but I do not trust it for more. I'm a little bit tired to analyse and workaround espressifs crap. Maybe better to use an external real CAN controller, to have a solid reliable piece of hardware.

[Leo M]

maybe it's worth trying to implement can on stm32 and the interface on esp8266 in the likeness of the version 3 board?

[johu]

Either that or some dedicated CAN chip the JLCPCB stocks like MCP2515. Some say that chip is problematic, too but I don't know details.

Also I now remember something strange: when I had the interface connected via the CHAdeMO port I noticed it had flawlessly downloaded the inverter json file (because that is on the same bus and had node id 1). So apparently if it is first powered up and then connected to the bus it works. Have to try that again...

[Yahha777]

I have to test parameter upload. What other issues did you find?

I am loading parameters

I tried it on both controllers. But the "CAN MAPPING" tab does not display anything. But I also noticed this on the old ESP 8266 interface connected to the controller via UART.

[johu]

I have used the gadget some more. I found that R6 is way to high at 100k! That disturbs CAN comms. Either bridge it completely or replace with 10k. This must have been the reason why it disturbed the bus in my car.

Also it only downloaded the parameter json partly and that led to errors in displaying the CAN map. Please retry.

[Yahha777]

R6 is way to high at 100k! That disturbs CAN comms. Either bridge it completely or replace with 10k

Is this what you mean?

[johu]

Exactly! On the CANLite that I based the board on that you can buy in the shop it is 100k

[uhi22]

Just to summarize my experiences:
1. From other ESP32 projects I know, that the ESP32 is picky regarding the power supply. I had an application, running wifi, and randomly after days of perfect working, it crashed and needed a power-on-reset to work again. After using a different power supply and a short, direct soldered power cable instead of the USB cable, the issue was gone.
2. The ESPs "CAN" controller is buggy. After debugging my own software for a longer time, it became clear, that a hardware issue causes hang-up. Found descriptions from other people, and the conclusion is, that it needs fast interrupt reaction to avoid running into unrecoverable hardware buffer overflow.
3. Different versions of the espressif driver seem to have different issues with the queue handling in the software. In my wifican project (https://github.com/uhi22/wifican) I found and worked-around some strange things. So the overall impression is: not reliable.
4. On the other hand, there are examples, where the ESP32 perfectly runs over years, with Wifi, web interface, MQTT, with no hang-ups or resets at all. I had an Sonoff PowR2 running Tasmota, four years running perfectly fine.
5. The web interface for parametrization and spot values works on my side 90%. Sometimes it needs a restart of the ESP and/or control unit, and reload in browser, to work. But in most cases it is fine.
6. The software update using the web interface usually works perfect the first time a day. But the second or third often fails, software is erased, and I need to use the STLink to flash again.
7. There are wrongly labeled or defective CAN transceiver on the market. If strange things happen, it is worth a try to use a different transceiver, and/or make some scope measurement of the CAN TX, CAN RX, CANH, CANL.

What I propose as improvements:
- short-term: check the currently used "bad" devices regarding power-supply (big elcap?), transceiver and transceiver resistor(s).
- mid-term: using a real CAN controller and transceiver. The MCP2515 controller with MCP2551 transceiver has been working here since 10 years perfectly (on AVRs)
- Improve the verbosity of the web interface regarding connection status. At the moment it is sometimes not clear, whether the shown spot values are "live" or just a left-over. There is an ongoing improvement activity here: https://github.com/jsphuebner/esp8266-w ... /issues/23

[asavage]

No. 7 (counterfeit/non-working CAN transceivers) has bit a lot of people I know. When you're lucky, they work not-at-all: easy to locate, curse at, replace.

Unlucky ones fail intermittently

[johu]

From other ESP32 projects I know, that the ESP32 is picky regarding the power supply

Oh yes, same goes for ESP8266

Different versions of the espressif driver seem to have different issues with the queue handling in the software

It doesn't seem to affect the SDO protocol as that
a) uses message filters to only receive the expected SDO reply
b) is request-reply

The web interface for parametrization and spot values works on my side 90%

I found once the json is downloaded it is 100% reliable (have you had hickups in that case?). But when you do an update that requires re-downloading the json you can run into troubles where the json download is incomplete. This needs to be implemented more robustly, i.e automatic re-download of incomplete files.

The software update using the web interface usually works perfect the first time a day

I don't have a 100% success rate on that either. It sometimes works 5 times in a row and then fails. The boot loader, as intended, is then in the boot loop where it keeps sending the welcome message but the ESP doesn't really seem to pick that up. If I then run the firmware update via CAN from my PC it runs just fine. I think this can also be fixed in the ESP firmware.

[royhen99]

I am having problem with get <param> on command line via CAN/WIFI interface. Set works ok and both work with the on board ESP8266. Get probably isn't used very much but I am using it with a python script for testing.

[johu]

I am having problem with get <param> on command line via CAN/WIFI interface

Yes, get is not implemented. Basically the esp32 firmware translates the legacy string commands to CAN commands (whereas the esp8266 just forwarded them to UART).
You'd have to do "stream 1 <name>" for now

[johu]

I ran the ESP32 module in Touran again and at least now it no longer disturbs the bus. That was the 100k resistor indeed.
It did also download the json from inverter and VCU but VCU needed a few attempts.
Strange thing was with the CAN mapping which wasn't always fully received and also the parameters and values were not received in the correct order. So e.g. "opmode" would receive the value of "version". That could be down to the way libopeninv queues CAN messages or down to retries. It is especially pronounced on the busy CAN bus, with just 1 or 2 devices it doesn't happen.

The fix is easy as the reply contains the addressing information. So rather than assuming the reply matching the last request I should read what the reply actually contains. Likewise with the CAN map as I assume it's the same issue.