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.8

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.
• A device that ran 6.0.0-beta.5 has its OBD chip on firmware V2.3.22. Open Quick Setup's vehicle step (or System > Maintenance) after the update and let it write V2.3.24: until then, an app that uses the automatic OBD protocol only connects after the device has been unplugged and plugged back in, and a restart of the device breaks it again.
• 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.7

• Quick Setup asks to update an OBD chip on firmware V2.3.22. On that chip firmware the warm start the device sends at every start stops the chip's automatic protocol search until the device is unplugged: apps that use the automatic protocol take minutes to connect or never do, and the vehicle detection cannot find the car (found 2026-11-08 with Car Scanner; V2.3.24 does not have the fault, and 6.0.0-beta.5 had written V2.3.22 onto chips that came with V2.3.24). The vehicle step of Quick Setup now opens with a popup when the chip's firmware is older than the one the device carries: one button, the records written as a bar, Done; a tap beside the popup leaves the same offer as a banner on the step, and the detection waits for the chip. The Status page shows the same banner and popup for a device that was set up before (the popup once per browser session, the banner until the chip is updated). System > Maintenance keeps its Update button. WiCAN stays awake while the chip is written: a running sleep countdown is pushed out a minute at a time (the countdown bar says so, GET /api/sleep carries activity_why, the sleep command prints it) and the sleep entry waits for the whole job, the chip's own restart included.
• Data destinations: the table reads at a glance. One status chip per row in a fixed column (Not applied yet, Paused, Sending with the count, Failing with the retry time, Waiting for network, the broker or a network), the row's facts (the networks it is active on, retained, the authentication, the certificate set, the first push) as a line under its topic or URL, Options as a named button that opens a panel with the row's settings and its delivery counters, a restart notice while a saved table is not running yet, and the Links row explains what waits while a link is down.
• A destination can be active on chosen WiFi networks only, and so can the Home Assistant webhook. A dropdown with check boxes lists the station networks under Settings > WiFi (All networks is the default; ticking a network clears All, unticking the last one puts All back). A restricted sender waits while WiCAN's WiFi is on another network, or on no WiFi at all (the ESPNetLink or USB Ethernet alone); nothing is counted as a failure meanwhile, and the status says which network it waits for. New networks key on both settings (network names separated by commas, empty = all; a name that itself contains a comma cannot be listed), networks / on_network / skipped_network and the station's ssid on GET /api/destinations, networks / on_network on GET /api/webhook, ssid on GET /api/wifi/status; the destinations and webhook commands print them.
• Store and forward for Home Assistant. A car away from home keeps recording its vehicle parameters on the SD card, and once it is back on the home network the Home Assistant integration (the meatpi-multi-device branch, updated the same day) pulls the recorded hours and imports them into each sensor's long-term statistics at the time they were recorded. One switch on Automate > Home Assistant turns it on (it sets the logger to JSON lines with every AutoPID sample); the card shows what is recorded, the files on the card and when Home Assistant last read the log, and the switch is unavailable without a usable SD card. With a VPN on, the card warns that the integration reaches the device away from home too and pulls the log over mobile data as well. Rows the device wrote before its clock was set (a dead RTC until the first time sync) are placed at their true hours by the integration from the device's clock journal. While Home Assistant reads the log (or the dashboard reads its history) a running sleep countdown is pushed out a minute at a time, ten minutes at most, so the pull finishes before the device sleeps; the countdown bar and the Power Saving page say so. GET /api/logger reports the parameter log's format and sink and an export block (reads, rows, bytes, the age of the last read and its cursor); GET /api/logger/export takes a plain epoch as since beside its own cursor; GET /api/sleep carries activity_s; the logger and sleep commands print the same. Hourly resolution: the live history detail and the logbook are not replayed. The integration side gains a Catch up history button and two options (the catch-up itself, and whether an hour Home Assistant already has is kept or replaced by the recorded one).
• The GPS track as a GPX file. The GPS fix recorded with the vehicle parameters (Store and forward, or the parameter log on) is served back as a GPX 1.1 track by GET /api/logger/gpx (a point per fix with elevation, time, speed, course and satellites; a new segment after ten minutes without a fix): the Logger page's GPS track card downloads the last hour, 3, 6 or 24 hours, 7 days or everything on the card, and the Home Assistant integration's wican.save_gpx service saves a device's track under www/wican/ (reachable as /local/wican/ followed by the file name), since Home Assistant's own history cannot hold past positions; the integration also ships a map card (custom:wican-gpx-card) that draws a device's recorded track on Home Assistant's own map.
• The Bluetooth console log tells a session's story. A phone app's connection used to leave two lines, client connected and client disconnected. Each session now logs who connected (the phone's on-air address and type), the connection interval it opened with and the one it settled on, when the device asked it to pair, when the data pipe was subscribed, when the app first wrote, and at the end why the link closed (the phone closed it, the radio link was lost, the device closed it, a stale bond) with the session in numbers: its length, the time to secured, the bytes each way, the last write before the end, drops. One line per milestone, for a support request about an app that "takes four tries" or "connects and shows nothing".
• GET /api/vpn reports derp_region, the Tailscale relay region the device is reachable at, and the vpn console command prints it beside relay up.
• The Status page's MQTT row says Not connected while MQTT is enabled and the broker cannot be reached, and Off only when MQTT is disabled. Before, an unreachable broker read as Off, which looks like a disabled setting.

Bug fixes since beta.7

• A bonded iPhone or iPad reconnecting over Bluetooth was refused for its first seconds and asked for the PIN again. iOS encrypts a bonded link within one connection interval, before the Bluetooth stack had told the firmware about the connection, and the firmware then treated the link as plain: the app's first commands were rejected, the device asked the phone to pair once more (the second PIN prompt), and apps such as Car Scanner or RealDash gave up or needed several attempts at every start. The firmware now reads the link's real security state at the connect and never asks an encrypted link to pair. Android phones were not affected (they encrypt later).
• The OBD chip is told to sleep before its sleep pin is pulled, as firmware 4.x did. At every sleep entry and at every re-sleep inside a nap the device now sends the chip the ST sleep command (STSLEEP0) and pulls the PowerEn pin behind it; v6 pulled the pin alone. The pin works only through the chip vendor's PowerEn function, so a chip whose PowerEn switch was off or inverted never slept under v6: the device reset it six times, rebooted to recover, stayed awake for the whole sleep delay and started over, all night on a low battery. Such a chip sleeps on the command now, and the console logs the chip's acknowledgement at every entry (chip asleep by command); a chip that refuses the word (one that is streaming a monitor, for example) gets one warning and the pin as before, and the nap's re-sleep waits for the chip to boot after its reset before sending the word. The command writes nothing to the chip's EEPROM; the wake is unchanged.
• The device no longer writes voltage thresholds or a UART timeout into the OBD chip. At start-up the device used to program the chip's own sleep and wake voltages and its UART inactivity timeout from three hidden settings, and to rewrite them whenever the chip's stored values differed, while keeping the chip's own sleep and wake triggers switched off, since the device itself decides when to sleep. A bench proof shows the chip ignores those stored values completely while its triggers are off: it neither sleeps under the stored threshold, nor wakes over it, nor sleeps after the stored UART silence. The start-up now only makes sure the chip's four triggers are off and leaves the stored values alone, so a chip is written less often and the three settings (wake_voltage_mv, sleep_voltage_mv, sleep_time_min under obd_chip) are kept but unused.
• The repair of the chip's PowerEn switch is read back before the reset. When the device finds the switch set to anything but 10 at start-up it writes VTPPSW10; the write is now acknowledged, left 600 ms to settle (as 4.x did) and read back as 10 before the reset pulse that applies it, where before the pulse came the instant the chip said OK. A switch the chip cannot report is left alone, and a refused write gets no reset.
• The parameter log export could cut a page in the middle of a row and glue the cursor line to it. GET /api/logger/export fills a page up to 64 KB; when that budget ran out exactly at the start of a 1 KB read window (about one page in sixteen) the window went out raw: a row cut in half, the cursor line glued to its end, no line break between. A client stopped paging there, and the Home Assistant integration could import an hour from a part of its rows (seen on the bench). A page now ends at its last complete line and the line that did not fit opens the next page; the integration of the same day treats a page without a cursor line as cut and reads it again a minute later, so it copes with devices still on an earlier build.
• Motion sensor: imu.bump fired about every 600 ms on a parked car, whatever the wake threshold. Wake on motion fired about 100 times a minute with all three axes flagged, a door slam was indistinguishable, raising the threshold changed nothing, and a logger rule on the event filled the SD card at about 144,000 rows a day. The wake threshold and the motion sensitivity live in a register bank of the sensor that is reachable only while the sensor's internal clock runs, and in the sensor's low-power mode that clock is off: the writes landed at random, an axis whose write was lost kept the sensor's reset threshold of zero and flagged a bump on every sample. The device now keeps the sensor's clock on, reads every threshold back after writing it and leaves wake on motion off if the sensor did not take it. The imu -x console command prints the sensor's registers as it holds them.
• Tailscale: the device opens connections to its peers through the relay now. An MQTT broker or Home Assistant behind a subnet router at home, with the WiCAN PRO on a phone hotspot, showed the VPN connected and the route listed while MQTT and the webhook timed out. The device never started a WireGuard session for its own traffic (a session only came when the peer contacted the device first, or over a direct path, which two NATs rarely allow), and it sent every relayed packet through its own relay region (Dallas) where a peer homed elsewhere is not. It also replied to connection probes over unrelated paths, which could make the peer mistake a relay address for a working direct endpoint. The device now starts the session itself when it has traffic for a peer, sends through the peer's own relay region (dialled on demand, closed after two minutes idle, up to two beside its home connection), keeps probe replies on their incoming transport and installs a direct address only once a probe has proven it. Relay-only traffic through rekey and recovery to a direct connection pass on the bench. The home region is still Dallas unless the control server assigns another; choosing the nearest by latency is planned.
• HTTPS servers whose certificate chain ends in a cross-signed root are accepted by the built-in certificate bundle. Cloudflare, among others, serves its chain under GTS Root R4 as signed by GlobalSign Root CA, a root the bundle no longer carries; the device trusts the chain at the GTS root it does carry now. Before, the Home Assistant webhook behind a Cloudflare tunnel, an HTTPS destination or any other HTTPS client on the device failed against such a server with No matching trusted root certificate found, and the workaround was uploading GlobalSign Root CA as a certificate set under Settings > Certificates and selecting it on the card. That workaround keeps working; it is no longer needed.

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), 6 min, 2026-11-08 07:32:35 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.8.bin by hand.
• Firmware 4.x: open the configuration page, System tab, Firmware Update section, upload wican-fw_obd_pro_v6.0.0-beta.8.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