I would add any ideas/enhancements to the issues list, so we can evaluate them. Issues · wambs/wican-fw · GitHub
Follow instructions on System · WiCAN Docs
- Download the latest firmware
.binfile from the Wambs Forked GitHub Releases page. (Note: The UI will display a notification banner at the bottom of the sidebar if a new version is detected). - Click Choose File and select the
.binfile you downloaded. - Click Update.
- A progress bar will appear to track the upload. Once it reaches 100%, the device will apply the update and automatically reboot.
So no need to update stock firmware first?
Those instructions do update the stock firmware to the forked SW.
when do you think it would be merged in, which is ideal - ?
Yes, latest firmware on it and connected to wifi (WPA3 did put a wrench in the wheel. Change to WPA2 and i got connectiion).
Now i have to get it working with reading a Fiat 500 hybride (model 700e appears not working). Manual reading 
So far, so good.
The entire wambs forked SW, probably never get merged with the stock. I tried to get it merged, but Mr. MeatPi said too many changes. Parts of it, maybe.
Their loss 
Would this fork help with the Wican Pro in silent mode? I’m trying to use it with the Banks Idash and when I plug the iDash back in, the Wican Pro stops working. Would this fork work with the Banks iDash?
Replied to your issue
The short answer is no, this fork likely will not magically fix the issue on its own, though the memory leak fixes in your build might prevent the device from completely hard-crashing.
When a WiCAN Pro (or any ESP32-based OBD2 device) “stops working” the moment a Banks iDash is plugged into the same network, it is almost always a CAN buffer overflow problem, not a PID calculation or extraction bug.
Here is a breakdown of why this happens and how you can advise the user to actually fix it.
The Root Cause: The Banks iDash Flood
The Banks iDash is an incredibly aggressive gauge. To provide its signature fluid, high-refresh-rate data, it spams the CAN bus with proprietary, high-speed polling requests—often asking the ECU for dozens of parameters per second.
When the WiCAN Pro is placed in Silent Mode (Listen-Only) on a Y-splitter cable, here is what happens:
- The Firehose: The ESP32’s CAN controller (the TWAI driver) suddenly sees all of the iDash’s requests plus all of the vehicle’s rapid-fire responses.
- Buffer Overrun: The WiCAN firmware reads CAN frames sequentially. Because the Banks iDash causes the bus traffic to skyrocket, the ESP32’s hardware RX (receive) queue fills up faster than the firmware’s
autopidloop can pull frames out. - The Freeze: Once the TWAI driver’s receive buffer overflows, the CAN controller stalls, drops frames, or crashes the polling task. To the user, the WiCAN simply “stops working.”
Why the Supercharged Fork Doesn’t Solve This Alone
Your fork makes excellent improvements to the MQTT buffer size and autopid.c memory handling (preventing memory leaks when parsing). However, those fixes apply after a CAN frame has been successfully pulled from the hardware buffer.
If the ESP32 is drowning in 500kbps of raw Banks iDash traffic, the hardware buffer will still overflow before your fixed autopid.c logic ever gets a chance to look at the data.
The Solution: Aggressive Hardware Filtering
To make the WiCAN Pro survive on the same bus as an iDash, the user cannot just put it in silent mode and listen to everything. They must use CAN Masks and Filters to block the ESP32 hardware from even seeing the traffic they don’t care about.
If they only want the WiCAN to sniff a few specific ECU responses that the iDash is already requesting, they need to set ELM327 filter commands before entering silent mode:
AT CM <mask_hex>(CAN Mask): Tells the CAN hardware which bits of the CAN ID to check.AT CF <filter_hex>(CAN Filter): Tells the CAN hardware exactly which CAN ID to allow through to the firmware.
By applying strict hardware filters, the ESP32’s TWAI driver will physically ignore all the extraneous iDash traffic, preventing the buffer overflow and allowing the WiCAN to peacefully eavesdrop on the exact ECU data they want.
Are you currently using ATCM and ATCF commands in your initialization string, or are you just sending ATCSM1 (Silent Mode) and hoping to filter the data on the software side?
@KevinWombat I added a reply in the above, thanks for your detailed answers, very much looking forward to your reply!
On your 2nd screenshot, he’s talking about the Custom Initialisation field and the PID Init field for each sensor. Those are where you put your vehicle’s commands in order to request the data for your sensor. This is also where you may need to do some “legwork” in order to find out what they are. Referring to the WiCAN wiki, you can use the Car Scanner App to help you figure those out. However, some vehicles have multiple CAN’s that are ran on different bitrates and Car Scanner, in my experience, only polls the HS-CAN at 500. For example, if you have a Ford, Ford has a proprietary MS-CAN at 125.
FWIW, the way I figured my data out is using FORScan and WireShark. Made it super easy to find my Global Init string and each sensor’s PID init strings. Good luck!
Hello @KevinWombat again and thank you for your comments. I was able to test more, have more results and have a workaround, and a more specific suggestion for the tweak. I put all the information in the same bug above.
Any update regarding the SD data restore to HA or MQTT in lost connection?
Hi,
Its delayed, We’re in the process of moving to a new house. The next release, in a couple of weeks, will just include pull requests.