Pre-release on the beta channel. Devices on that channel install it from their own page (System > Firmware update); the files below are for a manual upload.

WiCAN PRO 6.0.0-beta.7

Supported device: WiCAN PRO only. Home Assistant: v6 requires the meatpi-multi-device branch of the ha-wican integration.

Before you update

Units already on this partition layout (v6 (settings and storage LittleFS)) update in place.
Units coming from firmware 4.40.0 to 4.51.0 (factory v4.x (one 6 MB FAT storage)): the first boot restarts once more and the stored files, logs and the saved configuration are reset.
Running the Audi Q4 e-tron, Skoda Enyaq or Elroq, VW ID or Porsche Taycan profile on 6.0.0-beta.1 to beta.6: update now, or poll the standard PIDs only until you do. Those profiles made the OBD chip write its EEPROM on every poll cycle (the first bug fix below).
Coming from a v6 alfa or beta: settings, profiles and files are kept; the standard PID rows are re-numbered at the first start. A custom PID you wrote on a v6 alfa or beta against a single-frame reply reads one byte too far: run Test a PID (B0 is the first byte after the CAN id) and move each B index up by one, or re-import the published profile.
A beta.1 device that parked itself (LED breathing red) updates from safe mode: hold the button until the LED turns sky blue, then yellow, join the device's own access point (its name starts with WiCAN_, password @meatpi#), open http://192.168.0.10 and upload the firmware there. Settings are kept.
Coming from firmware 4.x: the stored files, logs and the saved configuration are erased by the new partition layout; download a backup first (System > Maintenance > Configuration backup). The device restarts once more on its first start.
In case of a boot loop, perform a factory reset.

New since beta.6

The Firmware update page loads a release's notes in the browser, straight from the release server, instead of through the device: the device no longer downloads them (they were of no use to it) and the 16 KB limit on a release's notes is gone. A phone without internet sees "could not be loaded" for the notes; the update check and the install are unchanged.
Bluetooth behaves as firmware 4.x did again (Settings > Bluetooth). The device advertises with its fixed hardware address, so presence detection by MAC and apps that remember the address work; the previous betas used a private address that changed at every reconnect and every 15 minutes, which stays available as address = private. The device asks the phone to pair the moment it connects (security_request, on by default; off for a Windows app with its own pairing dialog), and subscribing to the data pipe needs the paired link, so an OBD app pairs at its first step instead of writing into a link that silently dropped everything. Out of the box the OBD chip is bridged to Bluetooth (the new factory connection br_ble_obd on the Connections page; an existing device gets it once at the update unless a connection already uses Bluetooth), so pairing an app is all it takes, as on 4.x; the Bluetooth page warns when Bluetooth is on and no connection carries its data pipe. GET /api/ble reports address, address_type and security_request.
Tailscale subnet routes. A network another tailnet node advertises as a subnet router (and the admin console approved) is reachable from the WiCAN PRO now, the way it is from a phone: an MQTT broker or Home Assistant at home behind the home router's Tailscale node can be addressed by its LAN address while the car is away. Up to 8 such networks are taken from the tailnet; an exit node's default route is not. GET /api/vpn lists them as routes, the vpn command prints each with the node it goes through, and a network the device is directly on (at home, on that very LAN) stays local.
Tailscale reports its relay: GET /api/vpn carries derp (the relay connection is up), the vpn command prints relay up or relay down, and the vpn_manager: connected log line carries the internal RAM left at that moment. Tailscale starts only when the device has 30 KB of internal RAM free at that moment (its own start takes about 20 KB); otherwise it waits, says why on /api/vpn (reason), in the vpn command and on the VPN page, naming what frees memory on that device (Bluetooth off, about 32 KB; the WiFi memory profile set to Lean, about 14 KB; or WireGuard), and starts by itself once memory is free. Its own tasks run on PSRAM stacks now, about 13 KB of internal RAM less while the tunnel is up.
Bluetooth and Tailscale can run together. The Bluetooth controller's code moved from internal RAM to flash, which gives a WiCAN PRO about 19 KB more internal RAM (69 KB free at idle instead of 51 KB on a station-mode device with the dongle, 38 KB with Bluetooth on instead of 14). On the bench, with Bluetooth on the Lean profile, Tailscale starts, reaches its relay and a peer, and the device keeps 18 KB of internal RAM free. Two costs: Bluetooth throughput on the 2M PHY is about a quarter lower (about 370 kbps instead of 480 for notifications beside an active WiFi station; the 1M PHY is unchanged), and while the device erases its internal flash (a settings save, a firmware update) the Bluetooth controller pauses for the erase; a 512 KB file written to the internal flash over a live Bluetooth link still arrived complete.
Bluetooth has a memory profile (Settings > Bluetooth). Lean, the default, runs one phone at a time with the ordinary advertising on the 1M PHY and no scanning, and frees about 3 KB of internal RAM; Full keeps the BLE 5 options (2M and coded PHY, extended advertising) at the full cost; Custom exposes the radio controller's own knobs. A device that had chosen a BLE 5 option keeps it on Full. GET /api/ble reports the profile and the controller sizing in use. The Bluetooth host's own task runs on a PSRAM stack as well, about 4.5 KB of internal RAM less while Bluetooth is on (about 30 KB on Full, 27 KB on Lean, measured on the bench unit); pairing, bonding and the bond that survives a reboot are unchanged.
About 13 KB more internal RAM free at idle (83.8 KB instead of 70.7 KB on the bench unit at the same point after boot): the web server's task and the internal filesystem's writer run on PSRAM stacks now, and the flash work their requests need (a settings save, a file, the crash report, an update upload) runs on a small worker task that exists only while such work is going on. The console's http command lists the routes that touched the flash since boot, system -m and GET /api/status (health.flash_jobs) the worker's counters; a device too short of internal RAM to run a flash job latches a flash_jobs_refused fault. The script engine's file loads, the firmware updater's bookkeeping and the ESPNetLink pairing store use the same worker, and the vehicle store's writer gave back 6 KB of internal RAM.
The device checks at every start that the OBD chip cannot wake itself on bus traffic while the device sleeps (the chip's programmable parameter 0F, set once at provisioning since 4.x) and writes it back only when a chip firmware image or a tool had changed it. GET /api/obd_chip counts such repairs under eeprom_guard.pp_restores; an untouched chip costs one read and no write.
The OBD chip's firmware is only ever updated, never rewritten. The "Rewrite the chip firmware" button is gone from System > Maintenance: the OBD chip card now offers an update only while the chip's firmware is older than the one the device carries (a chip still on V2.3.22 sees "A newer chip firmware is available" with an Update to V2.3.24 button), and no path, not the card, not POST /api/obd_chip/update, not obd_chip update, writes a chip that already runs that version or a newer one. A chip caught in its download mode by an interrupted write is still recovered by completing the download. The card names the chip's firmware by its version alone and keeps its tools in one order: the state, the update when there is one, the configuration report, the wire tools. The --force option and the force key are refused with the reason.

Bug fixes since beta.6

Fixed Bluetooth apps built for firmware 4.x getting no answer on 6.0: the device no longer asked the phone to pair at the connect, a subscribe to the data pipe went through on an unpaired link, and the app's commands written without response were then dropped without any error (the Discord report of writes refused with insufficient authentication and no notification coming back), and out of the box no connection carried the Bluetooth data pipe at all, so even a paired app got nothing. See the Bluetooth entry under New.
Fixed a crash when a WireGuard tunnel was torn down while connections still ran through it (two beta.5 crash reports in task vpn_state: a double free, an instruction fetch error): the tunnel was taken down from the VPN's own task while the network stack was using the tunnel's connections (an MQTT broker or Home Assistant behind the tunnel). Every teardown is such a moment: the peer silent for 30 s, the WiFi or LTE uplink lost, a Pause VPN network joined. The tunnel's network-stack work now runs on the network stack's own thread, for WireGuard and for Tailscale alike.
Fixed the OBD chip's start taking a hardware reset and about 4 seconds instead of 1 on roughly every third restart of the device: the chip's answer to the ATZ the device sent now and then begins with a few stray bytes, which made the device believe the reset had not happened. The device warm-starts the chip now (ATWS, as firmware 4.x did), which answers clean within milliseconds, and reads past stray bytes anyway. The chip is ready about 1.3 seconds sooner at every start.
Fixed the OBD chip memorising every protocol switch into its EEPROM: the chip's memory function is on after every reset, and under v6 every switch to another protocol that a request then answered on was written to the chip's non-volatile protocol store, even through the RAM-only ATTP the device sends. A profile that pins different protocols on its rows (the VW MEB family: Audi Q4 e-tron, Skoda Enyaq and Elroq, the VW ID models, Porsche Taycan) wrote that store on every row change, up to seven times per poll cycle, against a rating of 10,000 writes; firmware 4.x switched the memory function off at every AutoPID start and v6 never did. The device now switches it off at every chip start and again right before every protocol switch it sends itself (AutoPID, the vehicle detection, the UDS tool, J2534, the CAN self-test), so no switch is memorised any more. A connected OBD app's ATZ is answered as a warm start (the same banner, about a second sooner, as firmware 4.x did) with the memory function switched off behind it, so the app's own protocol choice no longer writes the store either; the app sees exactly the reply it asked for. GET /api/obd_chip counts the words under eeprom_guard.memory_off and app_resets, and the obd_chip console command prints them (#1023).
Fixed Tailscale on v6 never reaching Tailscale's relay servers (DERP): every relay connection failed its TLS handshake on the relay's extra Ed25519 certificate (TLS handshake failed: X509 - Requested OID is unknown in the log), so peers that need a relay never connected while direct paths still did. Fixed every failed relay attempt leaking memory (about 21 KB of PSRAM and a few hundred bytes of internal RAM each, several times a minute): a device with Tailscale on ran out of memory within minutes of a start, name lookups and new connections then failed, and with Bluetooth on the device crashed at its first name lookup, three times in a row, and parked itself (#1024). A relay that cannot be reached is retried with a growing wait (10 s to 5 min) instead of three handshakes every few seconds, the Tailscale client's per-packet log lines moved to debug level, and a device out of internal RAM now fails the name lookup or socket call with an error instead of crashing.
Fixed a device that could not save any settings page once a connection pointed at a TCP/UDP server or WebSocket path that no longer existed: every Submit answered "Apply failed: br4: unknown endpoint 'udp3333'", the connection could not be removed, and a boot_errors fault latched at every start. The device accepts the list, leaves such a connection unbuilt with one warning line and the reason on /api/bridges, and the Connections page shows the row with the missing server named: Submit re-creates the server, or the row's trash button removes it. A connection and its new TCP/UDP server or WebSocket path submitted together, the way the Connections page builds them, are accepted now and come up after the restart. The Connections page no longer stages a change just by being opened, a refused save names the settings group it came from, and a connection refused at start because its server is already taken by another connection releases its queues.

New since beta.5

System > Maintenance has an OBD chip card: the chip's state and firmware, a warning when the chip is still on V2.3.22 while the device carries V2.3.24 (with the update behind a confirmation, since beta.7), what the chip answered when it did not come up, "Read the chip configuration" (identity, voltage, protocol, programmable parameters and sleep settings as one block to paste into a bug report), and wire tools for a chip that will not come up.
A CAN self-test card beside it: the OBD chip asks for engine speed the way every OBD app does and the WiCAN's own CAN controller answers it as an engine ECU over the shared bus, so one exchange proves both transceivers, both directions and the wiring, with or without a vehicle. The result is one block to copy. Afterwards the chip is put back as the start-up left it and AutoPID re-sends its set-up, so polling carries on as before.
The Maintenance card (Reboot, Restart History, Run Quick Setup again, Factory Reset) now leads the Maintenance page.
Console and API: obd_chip (state, version, report, update, probe [baud] [scan|auto] [word], listen), can_selftest run; GET /api/obd_chip with fw.outdated, /api/obd_chip/report, /api/obd_chip/probe, /api/obd_chip/update, /api/can/selftest.

Bug fixes since beta.5

Fixed the OBD chip's firmware being downgraded: v6 shipped chip firmware V2.3.22 and rewrote any chip not on it, so a WiCAN PRO that firmware 4.52 had taken to V2.3.24 was written back 3557 records at its first v6 start, and a chip left in its download mode by an interrupted write could not be recovered from the device. The packaged chip firmware is V2.3.24 and, as in 4.52, a chip on V2.3.22 or V2.3.24 is left alone (V2.3.22 is flagged on the card). A chip that does not answer in the normal way is probed at both UART speeds, what it sends is logged, and the recovery download is attempted as 4.x did; only a silent chip is left untouched. The sleep entry waits for a running chip update (#1023).
Fixed the ESPNetLink's APN, username, password and SIM PIN set on the WiCAN (Settings > USB > ESPNetLink, or the Quick Setup) never reaching the dongle in the default USB Ethernet mode: the dongle kept its own APN (internet), a SIM that needs another one (a Simbase SIM needs simbase) never attached, and the page still said the APN was on the dongle. The settings travel with the dongle's USB sharing settings and are applied by the one dongle restart the pairing makes. WiFi modem mode was not affected.
Fixed the Test button, the vehicle detection and the trouble-code jobs answering "chip busy" when they started while a passive filter was listening on the bus; they wait for that window now.

New features in v6

New UI design, Quick Setup, improved AutoPID, CAN logger (raw CAN, SQLite, binary, JSON), Dashboard and CAN monitor
Tailscale VPN; VPN split tunnel (up to 8 routes, .conf import, replaces the Allowed IP and Mask fields, #975); Pause VPN per WiFi network (#976)
USB devices: ESPNetLink, GPS, USB to Ethernet adapter. ESPNetLink made easy: USB data mode (RNDIS) by default, the header shows the dongle and its LTE/GPS state, a dedicated page, SIM PIN entry, a hint when the GPS gets no fix, a Quick Setup path with no home WiFi; a console-only dongle is detected, and the USB port power is cycled once when a dongle never enumerates
DTC trouble codes, DBC signals, Rules and Events, Scripting, UDS Tools, J2534, File Manager (SD card and internal flash), System logs and System Monitor pages
AutoPID and Quick Setup support ISO 27145 (WWH-OBD) vehicles, such as Euro VI Sprinters over 3.5 t that answer only 22F4xx on 29-bit CAN (#298, reported by @billybigpotatoes, protocol findings by @CzarofAK)
Full configuration Backup and Restore (settings, vehicle profiles and PIDs, code databases, DBC files, scripts, dashboard layout), optional removal of sensitive data, optional encryption, copies on the internal flash and SD card with a checksum per part (#979)
Logger clock history: every clock step journaled on the SD card, queued records re-based, the clock context on the History chart and the file list (#984)
ABRP: paced deliveries (5 s minimum, backoff on HTTP 429), a coverage view of the ABRP fields your vehicle provides, ABRP's own error text
Connections: a socket server that no connection uses is flagged with a one-click CAN bus row. About 10 KB of internal RAM freed (long-lived state in PSRAM)

Bug fixes in v6

Fixed settings not persisting when upgrading from v4.51 to v6.00
Fixed USB GPS not reporting until "Dongle console" was enabled; GPS is read by default with its own switch (#978)
"Download Config" did not include AutoPID PIDs or vehicle profiles; replaced by Backup and Restore (#979)
Fixed writing over an existing file on the SD card; fixed the File Manager's capacity for cards over 4 GB (a 32 GB card showed 976 MB, #982)
Fixed console commands that fail with an internal error printing nothing (#980)
Home Assistant: the station IP in the webhook payload (#977); no second full payload after registration; vpn_status no longer reads past its table while the VPN is connected (#985)
Fixed SD logger timestamps shifting by one or two hours depending on whether the time server answered at boot (#984)
Fixed a crash when an ESPNetLink or USB Ethernet adapter disconnected during a USB power repair cycle
Fixed an encrypted backup made with "Remove sensitive data" restoring blank secrets (#986); the automatic backup copy losing its settings 20 s after a factory reset (#987); a backup silently leaving out some files (#989)
Fixed the VPN settings migration routing the Allowed IPs network instead of the tunnel subnet (#988); after an Alfa-04 upgrade with the old fields set, check the Routes list once
Fixed slcan over TCP connecting but receiving nothing when the socket server had no CAN bus connection row
Fixed J2534 "no comm with the bus" with Automatic bit rate on a bus that only answers when asked: the tester's bit rate is adopted
Fixed the USB device mode (WiCAN as a network adapter to a PC) leaving a stale USB transfer across a restart

Known issues

A few published vehicle profiles carry rows that never read right on any firmware version (an i3 and Mini state of charge, the bZ4X cell list, a Volvo XC40 state of charge, the pack voltage ranges of the 800 V Hyundai, Kia, Genesis and Xpeng cars). They are being corrected on the profile side.
A TP 2.0 (VW) reflash over J2534 runs at one round trip per block acknowledgement (about 3 ms over USB, 28 ms over WiFi): flash over the USB cable.
The ESPNetLink cannot update itself yet; it updates through a WiCAN PRO. A dongle on firmware 1.20 or older must be flashed once over USB.
J2534: J1850 PWM and K-line are not supported; J1850 VPW is request and response only, no 4x speed.
A firmware upload started within ten minutes of an update may show that update as "not yet verified" on the Updates card until the ten-minute mark.

Bench: RELEASE TEST PASS, 14 steps (skipped: r12), 5 min, 2026-11-02 11:55:06 UTC.

Update instructions

Firmware 6.x: open the device page, System > Firmware update > Check for updates, or upload wican-fw_obd_pro_v6.0.0-beta.7.bin by hand.
Firmware 4.x: open the configuration page, System tab, Firmware Update section, upload wican-fw_obd_pro_v6.0.0-beta.7.bin and press Update. The first boot restarts once more; see Before you update.
Home Assistant: the MeatPi integration offers this version in the Firmware update entity.

In case of a boot loop

Perform a factory reset.

Home Assistant

Firmware 6.x requires the meatpi-multi-device branch of the ha-wican integration.

Contributors: ConorIA billybigpotatoes jtruland jeremysells CzarofAK eljeeb anthonysecco KoljaWindeler nuaimat

meatpiHQ/wican-fw v6.0.0p-beta.7 WiCAN PRO 6.0.0-beta.7 on GitHub