DEV Community: YMori

M5 StackChan pairing fails with No devices found — the factory firmware is the cause

YMori — Sat, 25 Jul 2026 09:00:55 +0000

TL;DR

I bought the official M5Stack StackChan (M5STACK-K151), and the "StackChan World" mobile app refused to finish setup: after selecting the device, it showed No devices found.

The cause was not Bluetooth permissions and not an app bug — the factory firmware was simply too old. After flashing the latest official firmware over USB, pairing went through on the first attempt.

What makes this worth writing about is that the situation is a closed loop you cannot escape on the device itself:

New firmware arrives via OTA
OTA needs Wi-Fi
Wi-Fi setup needs app pairing
Pairing fails on the old firmware

So flashing over USB is the only way out.

Environment and dates


Product	M5StackChan AI Desktop Robot (ESP32-S3) / `M5STACK-K151` (official assembled unit)
Purchased	2026-07-24 (Switch Science, Japan)
Setup attempted	2026-07-25
Factory firmware on the unit	1.2.4 (released 2026-04-20)
Latest official firmware that day	1.4.4 (released 2026-07-13)
Host	Windows 11
Phone	Android

The dates matter here. This product launched in 2026-05 and both the firmware and the app are still being updated frequently. The firmware version that ships with a unit depends on when you buy it, so whether you hit this problem depends on timing. If you buy stock that has been sitting for a few months, you are a good candidate for the same trap.

The symptom

The setup flow is:

Power on, pass the servo test
The device shows a 12-digit ID
In the app: "Add a new StackChan" → scan for nearby devices
Pick the entry matching the ID on the device screen
Set device name → AI agent → Wi-Fi

Step 4 immediately produced No devices found, and step 5 was never reachable.

What did not help

The message talks about devices not being found, so of course I attacked discovery first. None of this changed anything:

Granting Bluetooth and location permissions to the app (verified from the OS settings, not just the in-app prompt)
Turning location services on (BLE scanning on Android is entangled with location)
Force-stopping and restarting the app, rebooting the phone
Rebooting the device, returning to the ID screen before scanning
Toggling Bluetooth off and on

One thing I learned the hard way: do not pair from the OS Bluetooth settings screen. If you bond the device at the OS level, it gets registered as a known device and disappears from the app's "find a new device" list. I did exactly this while "just checking", which made the picture even muddier. If you already did it, remove the pairing.

The serial log told a completely different story

I stopped guessing about permissions and captured the USB serial log. When you connect the unit to a PC, the CoreS3 (ESP32-S3) native USB shows up as a serial port (VID_303A / PID_1001, USB-Serial/JTAG).

Here is what the log showed while the app was "not finding" anything:

I (111140) NimBLE: connection established; status=0
I (111160) NimBLE:  peer_ota_addr_type=1 peer_ota_addr=
I (111160) NimBLE: 63:a2:04:c7:fa:5d
[info] [WifiConfigServer] app Connected
I (112260) NimBLE: Stack-Chan characteristic write; conn_handle=1 attr_handle=22
I (112260) NimBLE: Config data received (42 bytes): {"cmd":"handshake","data":"1784964126892"}
I (112420) NimBLE: GATT procedure initiated: notify;
I (112430) NimBLE: notify_tx event; conn_handle=1 attr_handle=22 status=0 is_indication=0
I (112440) NimBLE: Config notification sent

Reading that:

The BLE connection was established (status=0)
The app was connected (app Connected)
The app sent a handshake ({"cmd":"handshake"})
The device answered (Config notification sent)
And then nothing more arrives from the app — not even a disconnect

So No devices found did not describe reality. The process was not failing at discovery; it was failing at verification of the response the device sent back. Trusting that message is what sent me down the permissions rabbit hole.

For confirmation I read the app side too. The firmware, the app, and the server for StackChan are all published in m5stack/StackChan — the Flutter app source lives in the same repository. The device-selection screen has a 30-second connect timeout and a 20-second verification timeout, with failure messages such as Device did not return encryption data. and Device verification decryption failed., and it registers the device with the server only after verification succeeds.

Root cause: firmware version, plus a deadlock

The boot log prints the version:

I (690) app_init: Project name:     stack-chan
I (696) app_init: App version:      1.2.4
I (700) app_init: Compile time:     Apr 15 2026 09:18:33

1.2.4, while the latest official build that day was 1.4.4 — nine versions apart.

And that is where the loop from the top of this post bites: OTA needs Wi-Fi, Wi-Fi needs pairing, pairing fails on old firmware. USB is the only remaining path.

Note that building the firmware yourself does not help. The handshake implementation in the public repository (firmware/main/hal/utils/secret_logic/secret_logic.cpp) is a stub whose token function returns a fixed string. It is declared as a weak symbol, and the real implementation is linked in at official build time. Only the official binary can satisfy the app's verification step.

The fix: flash the official firmware over USB, without M5Burner

The official flashing tool is M5Burner (a GUI), but the firmware distribution API it uses is public, so the whole thing can be done from the CLI. No Python required either.

1. List the official firmware versions

curl -s "https://m5burner-api.m5stack.com/api/firmware" \
  | jq -r '.[] | select(.name=="StackChan-UserDemo") | .versions[] | "\(.version)  \(.published_at)  \(.file)"'

The factory firmware is named StackChan-UserDemo (author: M5Stack):

V1.2.4   2026-04-20  3c8ffe6be0ca26375d836e10e06e3609.bin
V1.4.3   2026-07-02  fb75fa818e63b7ee6b0d35eba308f386.bin
V1.4.4   2026-07-13  790e3fcde496020aa7f188153b23e6f0.bin

Older versions stay available, so rolling back is possible too — which makes updating a lot less scary.

2. Download the binary

curl -sL "https://m5burner-cdn.m5stack.com/firmware/790e3fcde496020aa7f188153b23e6f0.bin" \
  -o stackchan-v1.4.4.bin

If the first byte is e9 (the ESP image magic), it is a merged full image to be written at offset 0x0:

od -An -tx1 -N 1 stackchan-v1.4.4.bin
#  e9

3. Get esptool (no Python needed)

Espressif ships standalone executables:

gh api repos/espressif/esptool/releases/latest \
  --jq '.assets[] | select(.name|test("windows-amd64")) | .browser_download_url'

4. Verify communication with a read-only command first

.\esptool.exe --port COM3 flash-id

Detecting chip type... ESP32-S3
Chip type:          ESP32-S3 (QFN56) (revision v0.2)
USB mode:           USB-Serial/JTAG
Detected flash size: 16MB

No manual download mode was necessary — esptool resets the chip through USB-Serial/JTAG. If it cannot connect, hold the reset button for about 2 seconds and release it once the internal green LED lights up.

5. Flash

.\esptool.exe --port COM3 write-flash 0x0 stackchan-v1.4.4.bin

Wrote 12783792 bytes (3185393 compressed) at 0x00000000 in 47.7 seconds
Verifying written data...
Hash of data verified.

About 50 seconds for just under 12.8 MB.

6. Confirm the version

Look for app_init: App version: 1.4.4 in the boot log. With that in place, pairing succeeded on the first try, and I went straight through AI agent setup, Wi-Fi setup, and an actual voice conversation.

Other traps worth knowing

Opening the serial port reboots the device

rst:0x15 (USB_UART_CHIP_RESET),boot:0x2b (SPI_FAST_FLASH_BOOT)

You cannot capture logs and operate the device at the same time. Opening the port in the middle of the setup wizard sends you back to the start (it did for me). The flip side is useful: if you want the boot log from the very first line, open the port and then trigger a reset.

There is no interactive serial console

Sending commands produces no response, and the write itself blocks. Treat the serial port as read-only.

Do not power both USB-C ports at once

The unit has a USB-C port on the CoreS3 and another on the heel (base). 5V fed into the CoreS3 side is routed to the base through the M-BUS BUS_5V line, so powering both ports puts two supplies on the same rail. The official documentation's "try powering from both ports" means one at a time. The heel port is the recommended one for power and flashing.

Servo zero positions survive a full flash erase

I backed up NVS before flashing, but the same zero positions were read back afterwards ([ScsServo] id: 1 get zero pos: 460 from settings). Those values appear to live in the servos themselves, so a full-flash rewrite does not lose them.

A separate warning about charging

The firmware sets the AXP2101 charge current to 700mA at boot:

auto ret = setChargerConstantCurr(XPOWERS_AXP2101_CHG_CUR_700MA);

The ESP32-S3 enumerates as a USB 2.0 device, so a PC USB port gives you 500mA at most. Combined with the system draw (LCD, camera, servos, radio) that exceeds the input limit, and charging never starts from a PC port. Use a USB charger with headroom at 5V.

If the servos do not report their current position ([ScsServo] ignore invalid current pos: -1), read that as another sign of insufficient power.

Takeaways

No devices found did not describe what was happening. The BLE connection and the handshake both succeeded; the failure was in response verification
The real cause was old factory firmware, fixed by flashing the latest official build over USB
OTA ↔ Wi-Fi ↔ pairing form a loop, so USB flashing is the only exit
Do not over-trust the error string — capture the log. Every minute I spent re-checking permissions would have been saved by one serial capture

Scripts and the full write-up are in the repository:

https://github.com/yasumorishima/stackchan-lab

References

Official docs: https://docs.m5stack.com/en/stackchan
Firmware / app / server source: https://github.com/m5stack/StackChan

M5 StackChan pairing fails with \"No devices found\"? The factory firmware is the cause

YMori — Sat, 25 Jul 2026 08:48:29 +0000

TL;DR

I bought the official M5Stack StackChan (M5STACK-K151), and the "StackChan World" mobile app refused to finish setup: after selecting the device, it showed No devices found.

What makes this worth writing about is that the situation is a closed loop you cannot escape on the device itself:

New firmware arrives via OTA
OTA needs Wi-Fi
Wi-Fi setup needs app pairing
Pairing fails on the old firmware

So flashing over USB is the only way out.

Environment and dates


Product	M5StackChan AI Desktop Robot (ESP32-S3) / `M5STACK-K151` (official assembled unit)
Purchased	2026-07-24 (Switch Science, Japan)
Setup attempted	2026-07-25
Factory firmware on the unit	1.2.4 (released 2026-04-20)
Latest official firmware that day	1.4.4 (released 2026-07-13)
Host	Windows 11
Phone	Android

The symptom

The setup flow is:

Power on, pass the servo test
The device shows a 12-digit ID
In the app: "Add a new StackChan" → scan for nearby devices
Pick the entry matching the ID on the device screen
Set device name → AI agent → Wi-Fi

Step 4 immediately produced No devices found, and step 5 was never reachable.

What did not help

The message talks about devices not being found, so of course I attacked discovery first. None of this changed anything:

Granting Bluetooth and location permissions to the app (verified from the OS settings, not just the in-app prompt)
Turning location services on (BLE scanning on Android is entangled with location)
Force-stopping and restarting the app, rebooting the phone
Rebooting the device, returning to the ID screen before scanning
Toggling Bluetooth off and on

The serial log told a completely different story

Here is what the log showed while the app was "not finding" anything:

I (111140) NimBLE: connection established; status=0
I (111160) NimBLE:  peer_ota_addr_type=1 peer_ota_addr=
I (111160) NimBLE: 63:a2:04:c7:fa:5d
[info] [WifiConfigServer] app Connected
I (112260) NimBLE: Stack-Chan characteristic write; conn_handle=1 attr_handle=22
I (112260) NimBLE: Config data received (42 bytes): {"cmd":"handshake","data":"1784964126892"}
I (112420) NimBLE: GATT procedure initiated: notify;
I (112430) NimBLE: notify_tx event; conn_handle=1 attr_handle=22 status=0 is_indication=0
I (112440) NimBLE: Config notification sent

Reading that:

The BLE connection was established (status=0)
The app was connected (app Connected)
The app sent a handshake ({"cmd":"handshake"})
The device answered (Config notification sent)
And then nothing more arrives from the app — not even a disconnect

Root cause: firmware version, plus a deadlock

The boot log prints the version:

I (690) app_init: Project name:     stack-chan
I (696) app_init: App version:      1.2.4
I (700) app_init: Compile time:     Apr 15 2026 09:18:33

1.2.4, while the latest official build that day was 1.4.4 — nine versions apart.

And that is where the loop from the top of this post bites: OTA needs Wi-Fi, Wi-Fi needs pairing, pairing fails on old firmware. USB is the only remaining path.

The fix: flash the official firmware over USB, without M5Burner

The official flashing tool is M5Burner (a GUI), but the firmware distribution API it uses is public, so the whole thing can be done from the CLI. No Python required either.

1. List the official firmware versions

curl -s "https://m5burner-api.m5stack.com/api/firmware" \
  | jq -r '.[] | select(.name=="StackChan-UserDemo") | .versions[] | "\(.version)  \(.published_at)  \(.file)"'

The factory firmware is named StackChan-UserDemo (author: M5Stack):

V1.2.4   2026-04-20  3c8ffe6be0ca26375d836e10e06e3609.bin
V1.4.3   2026-07-02  fb75fa818e63b7ee6b0d35eba308f386.bin
V1.4.4   2026-07-13  790e3fcde496020aa7f188153b23e6f0.bin

Older versions stay available, so rolling back is possible too — which makes updating a lot less scary.

2. Download the binary

curl -sL "https://m5burner-cdn.m5stack.com/firmware/790e3fcde496020aa7f188153b23e6f0.bin" \
  -o stackchan-v1.4.4.bin

If the first byte is e9 (the ESP image magic), it is a merged full image to be written at offset 0x0:

od -An -tx1 -N 1 stackchan-v1.4.4.bin
#  e9

3. Get esptool (no Python needed)

Espressif ships standalone executables:

gh api repos/espressif/esptool/releases/latest \
  --jq '.assets[] | select(.name|test("windows-amd64")) | .browser_download_url'

4. Verify communication with a read-only command first

.\esptool.exe --port COM3 flash-id

Detecting chip type... ESP32-S3
Chip type:          ESP32-S3 (QFN56) (revision v0.2)
USB mode:           USB-Serial/JTAG
Detected flash size: 16MB

5. Flash

.\esptool.exe --port COM3 write-flash 0x0 stackchan-v1.4.4.bin

Wrote 12783792 bytes (3185393 compressed) at 0x00000000 in 47.7 seconds
Verifying written data...
Hash of data verified.

About 50 seconds for just under 12.8 MB.

6. Confirm the version

Other traps worth knowing

Opening the serial port reboots the device

rst:0x15 (USB_UART_CHIP_RESET),boot:0x2b (SPI_FAST_FLASH_BOOT)

There is no interactive serial console

Sending commands produces no response, and the write itself blocks. Treat the serial port as read-only.

Do not power both USB-C ports at once

Servo zero positions survive a full flash erase

A separate warning about charging

The firmware sets the AXP2101 charge current to 700mA at boot:

auto ret = setChargerConstantCurr(XPOWERS_AXP2101_CHG_CUR_700MA);

If the servos do not report their current position ([ScsServo] ignore invalid current pos: -1), read that as another sign of insufficient power.

Takeaways

No devices found did not describe what was happening. The BLE connection and the handshake both succeeded; the failure was in response verification
The real cause was old factory firmware, fixed by flashing the latest official build over USB
OTA ↔ Wi-Fi ↔ pairing form a loop, so USB flashing is the only exit
Do not over-trust the error string — capture the log. Every minute I spent re-checking permissions would have been saved by one serial capture

Scripts and the full write-up are in the repository:

https://github.com/yasumorishima/stackchan-lab

References

Official docs: https://docs.m5stack.com/en/stackchan
Firmware / app / server source: https://github.com/m5stack/StackChan

My Raspberry Pi 5 Kept Vanishing From the Network — Diagnosing With journalctl and Fixing It With a Watchdog

YMori — Tue, 23 Jun 2026 14:33:34 +0000

The symptom

I run a headless Raspberry Pi 5 (over Wi-Fi) via SSH and Tailscale. Every so often it would stay powered on (LED lit) but completely vanish from the network:

SSH over LAN → timeout
SSH over Tailscale → timeout
RDP → timeout

And it kept recurring — every time I "fixed" it by power-cycling. Here is how I actually diagnosed it and set up auto-recovery.

Step 1: `tailscale status` tells you device-side vs your-side

When SSH hangs, it's tempting to assume "the Pi died." But the problem can be on your side (your PC's Wi-Fi / VPN). Rule that out first.

If you use Tailscale, tailscale status is the fastest check:

100.x.y.z   raspberrypi   user@   linux   active; relay "..."; offline, last seen 1h ago, tx 124956 rx 0

The key is the peer line: offline, last seen 1h ago. This comes from Tailscale's coordination server — it's a third-party fact, independent of your own SSH attempt.

peer offline → the Pi really did drop off the network
peer active/online → it's your side that's broken (your VPN/network)

last seen also tells you when it dropped. tx ... rx 0 means "you're sending, but getting zero bytes back."

Confirm your own side is healthy too via tailscale status --json → BackendState=Running / Self.Online=true.

Step 2: After recovery, read `journalctl -b -1` (the previous boot)

This is the part people miss. While the Pi is off the network you obviously can't pull its logs — you read them after it's back. But the moment you reboot, the "current boot" is brand new, so journalctl (default) and dmesg won't contain the moment it dropped.

The drop is in the previous boot:

# tail of the previous boot
journalctl -b -1 --no-pager | tail -30

# only wlan0 / network-related lines
journalctl -b -1 --no-pager | grep -iE "wlan0|cfg80211|brcmfmac|LinkChange|network is unreachable" | tail -40

What I found, in order:

19:57  avahi-daemon: Withdrawing address record ... on wlan0   # IPv6 address flapping
20:08  tailscaled: LinkChange: major, rebinding ... rebind-reason=[time-jumped(13m50s),ips-changed,protocols-changed]
22:06  tailscaled: ... connect: network is unreachable          # fully down

The important part: the logs kept flowing the whole time. So this was not a full OS freeze or OOM — only the wlan0 / network layer dropped while the OS stayed alive (no oom, no panic at the tail of journalctl -b -1).

I couldn't pin the root trigger (why wlan0 dropped) from the logs — there was no explicit driver crash line, and vcgencmd get_throttled read 0x0 after recovery (no undervoltage flag). So from here it's a symptomatic fix for wlan0 drops in general.

The fix: a NetworkManager watchdog

If "the OS is alive but only the network is down," then a cron job that watches for it and restarts networking can auto-recover. Recent Pi OS uses NetworkManager (resolv.conf says # Generated by NetworkManager), so restart that.

/home/pi/.local/bin/net-watchdog.sh:

#!/usr/bin/env bash
# If the gateway is unreachable, restart NetworkManager to bring wlan0 back.
GATEWAY=192.168.1.1   # replace with your router IP
LOG=/home/pi/logs/net-watchdog.log
if ping -c 3 -W 3 "$GATEWAY" >/dev/null 2>&1; then
  exit 0
fi
echo "$(date -Is) gateway $GATEWAY unreachable, restarting NetworkManager" >> "$LOG"
systemctl restart NetworkManager

/etc/cron.d/net-watchdog (every 3 minutes, as root):

*/3 * * * * root /home/pi/.local/bin/net-watchdog.sh

Install:

chmod +x /home/pi/.local/bin/net-watchdog.sh
mkdir -p /home/pi/logs
echo "*/3 * * * * root /home/pi/.local/bin/net-watchdog.sh" | sudo tee /etc/cron.d/net-watchdog

Verify it does NOT restart when the network is fine

You don't want spurious restarts. Run it once by hand while the network is healthy:

/home/pi/.local/bin/net-watchdog.sh
echo $?        # → 0
cat /home/pi/logs/net-watchdog.log   # → no such file (= it did not restart anything)

While ping succeeds, nothing is logged and systemctl restart never runs. It only acts when the network is actually down.

Takeaways

"Powered on but gone from the network" is usually a network-layer drop — the OS is still alive.
Fastest triage: tailscale status (third-party offline record) → after recovery, journalctl -b -1 (the previous boot).
A gateway-ping → restart-NetworkManager watchdog in cron auto-recovers within minutes, as long as the OS keeps running.
Caveat: a cron-driven watchdog can't help if the OS itself stops executing.

I still haven't pinned the root cause, but at least I'm out of the "power-cycle it by hand every time" loop.

Follow-up: a selective outage the watchdog couldn't see — and watchdog v2

About two weeks after deploying the watchdog above, the Pi died in a completely different way — and since the gateway ping still succeeded, the watchdog never fired.

The symptom (nothing like last time)

SSH (over Tailscale) worked fine
Ping to the gateway worked fine
But DNS resolution was completely dead (getent hosts github.com failed)
Behavior differed per destination:
- Google properties returned HTTPS 200
- GitHub / Cloudflare (1.1.1.1) / everything else → TCP connect timeout
- IPv6 was entirely dead

With "only Google works," it looks like an ISP or router outage. Spoiler: it was the Pi itself again — a wedged wlan0 Wi-Fi client state.

Triage 1: hit the same destinations from another device on the same router (the decisive check)

From a PC on the same Wi-Fi, GitHub and everything else worked normally. → The router and the ISP are innocent; the problem is Pi-specific. Skipping this check would have sent me down the useless "reboot the router" path.

Triage 2: probe each DNS server directly over UDP

No dig or nslookup on the Pi? A few lines of python3 can send a raw DNS query:

import socket, struct

def q(server, timeout=3):
    # minimal DNS A query for github.com
    pkt = struct.pack('>HHHHHH', 0x1234, 0x0100, 1, 0, 0, 0)
    for part in b'github com'.split():
        pkt += bytes([len(part)]) + part
    pkt += b'\x00' + struct.pack('>HH', 1, 1)
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    s.settimeout(timeout)
    try:
        s.sendto(pkt, (server, 53))
        data, _ = s.recvfrom(512)
        return f'OK answers={struct.unpack(">H", data[6:8])[0]}'
    except Exception as e:
        return f'FAIL {type(e).__name__}'
    finally:
        s.close()

for srv in ['192.168.1.1', '100.100.100.100', '8.8.8.8', '1.1.1.1']:
    print(srv, '->', q(srv))

Result: router=FAIL / Tailscale MagicDNS=FAIL / 8.8.8.8=OK / 1.1.1.1=FAIL. So DNS wasn't "down" — traffic to specific destinations was down, and DNS failure was just one symptom. ip route get and the firewall were both normal.

The fix: a full wlan0 reconnect (`reapply` is not enough)

nmcli dev reapply wlan0 (re-applying the config) did not fix it. What fixed it was a full disconnect → connect. Since SSH itself rides on wlan0, detach the command so it survives your own disconnection:

sudo nohup bash -c 'nmcli dev disconnect wlan0; sleep 3; nmcli dev connect wlan0' >/dev/null 2>&1 &

About 20 seconds later everything was back: all destinations 200, and the router DNS that had "looked dead" was answering again. The DNS death, the selective timeouts, and the IPv6 blackout were all symptoms of one root cause: the wedged wlan0 client state.

watchdog v2: also probe external connectivity

Gateway ping alone misses this failure mode, so I added a second tier:

#!/bin/bash
# net-watchdog v2: two-tier self-healing
# tier1: gateway unreachable -> restart NetworkManager
# tier2: gateway OK but external connectivity mostly dead (<2 of 4 probes) -> full wlan0 reconnect
LOG=/home/pi/logs/net-watchdog.log
STATE=/home/pi/logs/net-watchdog.last-reconnect
GW=192.168.1.1   # replace with your router IP
mkdir -p /home/pi/logs

if ! ping -c3 -W3 $GW >/dev/null 2>&1; then
  echo "$(date -Is) gateway unreachable -> restart NetworkManager" >> $LOG
  systemctl restart NetworkManager
  exit 0
fi

alive=0
for url in https://www.google.com https://github.com https://1.1.1.1 https://www.yahoo.co.jp; do
  curl -4 -sS --max-time 5 -o /dev/null "$url" 2>/dev/null && alive=$((alive+1))
done

if [ "$alive" -lt 2 ]; then
  now=$(date +%s)
  last=$(cat "$STATE" 2>/dev/null || echo 0)
  if [ $((now - last)) -lt 1800 ]; then
    echo "$(date -Is) external dead (alive=$alive/4) but reconnected <30min ago, skip" >> $LOG
    exit 0
  fi
  echo "$now" > "$STATE"
  echo "$(date -Is) gateway OK but external dead (alive=$alive/4) -> wlan0 reconnect" >> $LOG
  nmcli dev disconnect wlan0
  sleep 3
  nmcli dev connect wlan0
fi
exit 0

Design notes:

2 of 4 independent probes alive = healthy — a single site being down never triggers a reconnect
https://1.1.1.1 is IP-literal, so this probe still works when DNS is dead
Reconnects have a 30-minute cooldown (no flapping)
As with v1: run it by hand while healthy and confirm it does nothing before wiring it into cron

Follow-up takeaways

A gateway-ping watchdog is blind to "selective outage caused by a wedged Wi-Fi client state"
"Only some sites work" looks like an ISP problem but can be your own device. The fastest triage is hitting the same destinations from another device on the same LAN
nmcli dev reapply and a full disconnect/connect are different things — escalate to the full reconnect when reapply doesn't cut it

I Had Claude Fable 5 Review My Indie Diary App Before It Got Pulled — The Bugs It Caught

YMori — Mon, 15 Jun 2026 13:00:53 +0000

Intro

I had Claude Fable 5 review and fix my Flutter diary app, Daily Diary (live on Google Play), before a release. This is a record of that.

Fable 5 was pulled worldwide just three days after launch (June 9 -> June 12, 2026) by a US Commerce Department export-control directive — but I got this pass in right before it went dark. Instead of generic "it caught what other models missed" claims, I'm pasting the actual diffs from my repo's commit history.

The app: Daily Diary

A simple offline diary app.

📱 Offline-first: data stays on the device, no cloud
🌐 5 languages: Japanese / English / Chinese / Korean / Spanish
🌙 Dark mode, 📅 calendar with mood indicators, 📊 stats (streaks, mood trends), 🔍 full-text search, 🎲 random past entry, 💾 JSON export/import
Google Play: https://play.google.com/store/apps/details?id=com.diary.daily

Stack: Flutter 3.x / Dart, Provider, Hive (local NoSQL), Flutter intl.

What I asked for

Not "rewrite everything" — more like "find and fix what's questionable quality-wise": resolve flutter analyze warnings (there were 47), set up tests, add CI, update dependencies.

1. BuildContext used across an async gap

Several spots touched BuildContext (Navigator, localization) after an await. If the widget is disposed during the await, that throws. Fable inserted if (!mounted) return; right after the await:

   final db = DatabaseService();
   final existingEntry = await db.getEntryByDate(_selectedDate);
+  if (!mounted) return;

   final result = await Navigator.push(
     context,

You rarely hit this in normal use, so it's easy to miss even when testing yourself.

2. Hoisting the l10n lookup before the await

In the import handler _importData, AppLocalizations.of(context) (localized strings) was looked up repeatedly after awaits. It got hoisted to a single lookup before the first await, with a mounted guard before showing the confirmation dialog:

       _isImporting = true;
     });
+
+    final l10n = AppLocalizations.of(context)!;

     try {
       final result = await FilePicker...
       ...
       if (file.bytes == null) {
-        final l10n = AppLocalizations.of(context)!;   // looked up after await
         throw Exception(l10n.fileReadError);
       }
       ...
-      final l10n = AppLocalizations.of(context)!;
+      if (!mounted) return;                            // guard before dialog

3. The test that tested nothing

The leftover template widget_test.dart referenced a non-existent MyApp and didn't even compile (= effectively zero tests). It was removed and replaced with 12 real tests for the model and Hive persistence:

removed test/widget_test.dart             (broken template)
added  test/diary_entry_test.dart   +49   (model serialization, etc.)
added  test/database_service_test.dart +92 (Hive-backed save/load)

"You think you have tests, you don't" is the scariest state to be in, so fixing this mattered most.

4. 47 analyzer warnings to zero

The headline one was the Color.withOpacity() deprecation (withValues is now preferred for color precision). 27 spots replaced:

-  color: Colors.white.withOpacity(0.1),
+  color: Colors.white.withValues(alpha: 0.1),

Plus removing the deprecated ColorScheme.background / onBackground, and migrating RadioListTile (groupValue / onChanged removed) to the RadioGroup ancestor API. dart fix --apply handled the mechanical ones; API migrations were done by hand.

5. Major dependency bumps

Bumped the main dependencies, with two breaking API changes:

-  google_mobile_ads: ^4.0.0
+  google_mobile_ads: ^9.0.0
-  share_plus: ^7.2.1
-  file_picker: ^8.1.4
+  share_plus: ^12.0.2
+  file_picker: ^11.0.2

share_plus: Share.shareXFiles(...) -> SharePlus.instance.share(ShareParams(...)).

-  await Share.shareXFiles(
-    [XFile(file.path)],
-    subject: fileName,
+  await SharePlus.instance.share(
+    ShareParams(
+      files: [XFile(file.path)],
+      subject: fileName,
+    ),
   );

file_picker: the instance API FilePicker.platform.pickFiles(...) became a static FilePicker.pickFiles(...).

-  final result = await FilePicker.platform.pickFiles(
+  final result = await FilePicker.pickFiles(

On the pins: share_plus 13 conflicts with file_picker 11, and file_picker 12 is beta-only — so I settled on share_plus 12 / file_picker 11.

6. Added CI

A new flutter-ci.yml runs flutter analyze + tests on push/PR, so the project can't slip back into the "broken test" state.

How it felt as a solo dev

Honestly, what Fable caught wasn't flashy features — it was the class of things I systematically don't check on my own:

async-gap mounted -> only crashes on certain timing
a broken test -> you think you have tests, you don't
a pile of deprecations -> works now, breaks later
stale dependencies -> major bumps get postponed out of fear of breaking changes

I can write the features myself, but "only fails under specific conditions," "are the tests actually testing anything," and "deprecated-API + dependency housekeeping" tend to slip without a dedicated reviewer. One thorough pass on that was genuinely useful for a side project.

There are limits too: device-UI-dependent behavior (ads, export/import sharing) can't be verified in CI — I still test that on a real device. Concept, design, device testing, store submission, and final review stay my job.

It's a shame it went dark after three days, but I'm glad I got this pass in before it did.

Daily Diary is live on Google Play — give it a try:

📱 https://play.google.com/store/apps/details?id=com.diary.daily

transform: translateY(0) Breaks position: fixed — A Hidden Trap in SPA Animations

YMori — Mon, 06 Apr 2026 09:55:09 +0000

The Bug

One day I got this bug report on my Next.js site:

Clicking a photo near the bottom of the gallery opens a lightbox, but it's completely black. Scroll up and the image is there.

A position: fixed; inset: 0 overlay was not covering the viewport — it was stuck at the top of the page. Browser bug? No. This is CSS working exactly as specified.

How to Reproduce

Two ingredients:

An ancestor element with transform set (even translateY(0))
A descendant with position: fixed

/* Page transition animation */
@keyframes page-enter {
  from {
    opacity: 0;
    transform: translateY(12px);
  }
  to {
    opacity: 1;
    transform: translateY(0); /* The culprit */
  }
}

.page-enter {
  animation: page-enter 0.35s ease both; /* both = keeps final values */
}

// Lightbox (descendant of .page-enter)
<div className="fixed inset-0 z-50 bg-black/90">
  <img src={photo.url} />
</div>

Near the top of the page, everything looks fine. Scroll down and open the lightbox — it renders at the top of the ancestor element, not the viewport.

Why This Happens — The CSS Spec

From MDN's position: fixed documentation:

The element is positioned relative to the initial containing block established by the viewport, except when one of its ancestors has a transform, perspective, or filter property set to something other than none.

Ancestor's `transform`	`fixed` is relative to
`none` or unset	viewport (expected)
`translateY(0)`	that ancestor (broken)
`translateY(12px)`	that ancestor (broken)

translateY(0) is not the same as no transform. It's a transform that moves nothing — but the CSS engine still creates a new containing block.

The `animation-fill-mode: both` Trap

.page-enter {
  animation: page-enter 0.35s ease both;
}

both (forwards + backwards) keeps the final keyframe values after the animation ends. So transform: translateY(0) persists for the lifetime of the element.

The same applies to JavaScript inline styles:

// IntersectionObserver fadeIn component
<div style={{
  transform: visible ? "translateY(0)" : "translateY(16px)",
  // After visible=true, translateY(0) stays forever
}}>
  {children}
</div>

Blast Radius

Every fixed descendant of a transform-bearing ancestor is affected:

Lightboxes / modals
Toast notifications
Cookie consent banners
PWA install prompts
Progress bars
Scroll-to-top buttons

Bottom navs and sticky headers may not visibly break (they sit at viewport edges), but they are technically affected too.

The Fix

1. Use `transform: none` (Most Important)

@keyframes page-enter {
  from {
    opacity: 0;
    transform: translateY(12px);
  }
  to {
    opacity: 1;
    transform: none; /* Not translateY(0) */
  }
}

<div style={{
  transform: visible ? "none" : "translateY(16px)",
}}>

transform: none means "no transform is applied" — no containing block is created.

2. Use `createPortal` to Escape the DOM Tree (Defensive)

import { createPortal } from "react-dom";

function Lightbox() {
  return createPortal(
    <div className="fixed inset-0 z-50 bg-black/90">
      {/* ... */}
    </div>,
    document.body // Renders at body root — immune to ancestor CSS
  );
}

No matter what ancestors do, the overlay is not affected. This is a best practice for any viewport-covering overlay.

3. Do Both (Recommended)

Fix the root cause with transform: none, and add createPortal as defense-in-depth. If someone later adds a new transform ancestor, overlays still work.

Summary

Don't	Do
Use `translateY(0)` as animation end value	Use `transform: none`
Render `fixed` overlays deep in the DOM tree	Use `createPortal(document.body)`
Add animations without checking `fixed` elements	Audit `fixed` descendants when adding `transform`

translateY(0) and none look identical but behave differently. Miss this spec detail and every overlay on your site breaks the moment you add a page transition animation.

NPB 2021 Backtest: Could a Bayesian Model Predict Last-Place-to-Champion?

YMori — Tue, 24 Mar 2026 02:51:07 +0000

Introduction

In a previous article, I added Bayesian integration to my NPB prediction system. The 8-year backtest showed "97% probability of beating Marcel." But how did it perform in the worst year for predictions?

2021 was NPB's biggest upset: both Yakult (CL) and Orix (PL) went from last place to champions. I ran a full backtest with 25 new foreign players individually projected using FanGraphs and Baseball Savant data.

GitHub: npb-2021-backtest
Main model: npb-prediction

Team Standings: Predicted vs Actual

Central League

Team	Actual	Bayes (no foreign)	Bayes (with foreign)	Foreign Effect
Yakult	73W (1st)	69.5W (4th)	70.7W (4th)	+1.2W (Santana, Osuna)
Hanshin	77W (2nd)	72.8W (2nd)	72.6W (2nd)	-0.2W
Giants	61W (3rd)	83.1W (1st)	84.3W (1st)	+1.2W (Smoak, Thames)

Pacific League

Team	Actual	Bayes (no foreign)	Bayes (with foreign)	Foreign Effect
Orix	70W (1st)	64.5W (6th)	62.0W (6th)	-2.5W (worse)
SoftBank	60W (4th)	77.6W (1st)	76.2W (1st)	-1.4W

MAE: 10.4 wins → 10.7 wins. Foreign player predictions slightly worsened accuracy.

Foreign Player Predictions vs Actual

Accurate Predictions (average MLB players)

Player	Team	Pred OPS	Actual OPS	Diff
Kevin Cron	Carp	.703	.701	-.002
Jose Osuna	Swallows	.683	.694	+.011
Cy Sneed	Swallows	ERA 3.53	ERA 3.41	-0.12

Major Misses (extreme players)

Player	Team	Pred OPS	Actual OPS	Diff
Mike Gerber	Dragons	.862	.352	-.510
Mel Rojas Jr.	Tigers	.867	.663	-.204
Domingo Santana	Swallows	.713	.877	+.164

Gerber had an MLB wOBA of .127 (49.3% K rate) — the model over-regressed toward the mean, predicting .862 OPS when the actual was .352.

Santana was predicted from 84 PA in 2020 (COVID-shortened). His career .757 OPS would have been more predictive.

What Actually Drove the 2021 Standings

Yakult's Championship Run

Player	2020	2021	Change
Tetsuto Yamada	OPS .766	OPS .885	+.119
Domingo Santana	—	OPS .877	New signing
Noboru Shimizu	ERA 3.54	ERA 2.39	-1.15

Orix's Championship Run

Player	2020	2021	Change
Yutaro Sugimoto	OPS .695	OPS .931	+.236 (HR King at 31)
Hiroya Miyagi	—	ERA 2.51 (147IP)	20-year-old, 13 wins
Yoshinobu Yamamoto	ERA 2.20	ERA 1.39	-0.81 (Sawamura Award)

Sugimoto and Miyagi's breakouts were impossible to predict from past data. This is a structural change, not a statistical fluctuation.

Giants Collapse (Predicted 84.3W → Actual 61W)

Sugano (ERA 1.97→3.19), Sakamoto (OPS .844→.657), Maru (OPS .899→.775) — three stars declining simultaneously. The Bayesian model trusted their skill metrics and predicted even higher than Marcel.

Key Findings

Average MLB players predicted well (Cron .703 vs .701 actual)
Extreme players over-regressed (Gerber .862 vs .352) → need regression limits
Single-year small samples mislead (Santana's 84 PA in 2020) → use career stats
Bad MLB pitchers stay bad in NPB (Sparkman 6.02→3.88 pred→6.88 actual)
2021 was driven by Japanese player breakouts, not foreign players

Conclusion

Individual foreign player projections improve accuracy for "average" players but carry risk for extreme cases. In 2021, Japanese player breakouts and collapses determined the standings — foreign player predictions had minimal impact (MAE +0.3 wins).

This is a personal hobby project. There may be oversights in data collection and verification.

Data Sources

Baseball Data Freak — NPB player stats
NPB Official — Official records
FanGraphs — MLB wOBA/K%/BB%
Baseball Savant — MLB Statcast
Baseball Reference — MLB/MiLB stats

Adding Bayesian Ensemble + Monte Carlo to an NPB Prediction App

YMori — Mon, 23 Mar 2026 21:48:12 +0000

Introduction

I've been running a personal NPB (Japanese pro baseball) prediction app:

Dashboard: npb-prediction.streamlit.app
GitHub: npb-prediction

It used Marcel projections (3-year weighted average) and ML (XGBoost/LightGBM). Decent, but I wanted better accuracy. After adding Bayesian corrections, the predicted standings changed significantly.

Terms

Term	Meaning
Marcel	Predict next year from weighted average of past 3 years
Bayesian	Combine prior knowledge with data. Gives uncertainty estimates
CI	Credible interval — range where the true value falls with 80%/95% probability
OPS	On-base + Slugging. Overall batting metric
ERA	Earned Run Average. Runs allowed per 9 innings
MAE	Mean Absolute Error. Average prediction miss. Lower = better

Problems with the Previous Approach

Problem 1: All Foreign Players Treated as "Average"

Marcel needs 3 years of NPB data. First-year foreign players have none, so all 24 of them were treated as league-average. Dalbec (Giants, .355 wOBA in MLB) and Hummel (BayStars, .240 wOBA) were calculated identically.

Problem 2: Skill Metrics Ignored

Marcel averages past results directly. Two players with OPS .800 might have very different K% and BB% profiles, which affects how stable their performance will be next year.

Problem 3: No Uncertainty

"Maki's OPS: .812" gives no sense of how much it might vary. The difference between .750-.870 and .790-.830 matters a lot for team projections.

What Changed with Bayesian Integration

Foreign Players: Average → Individual Predictions

Built a model to convert MLB/KBO stats to NPB projections. For example, a .350 wOBA MLB hitter maps to approximately .350 × 1.235 = .432 NPB-equivalent wOBA.

All 24 players' names and prior-league stats were individually web-verified (guessing English names from katakana is surprisingly error-prone).

Foreign hitter examples:

Player	Team	Prior wOBA	NPB Pred OPS	80% CI
Sano	Dragons	.370	.760	.632–.889
Seymour	Buffaloes	.365	.735	.607–.863
Dalbec	Giants	.355	.725	.577–.884
Hummel	BayStars	.240	.694	.530–.849

Foreign pitcher examples:

Player	Team	Prior ERA	NPB Pred ERA	80% CI
Quijada	Swallows	3.26	2.76	1.28–4.24
Hjelle	Buffaloes	3.90	3.34	1.05–5.59
Cox	BayStars	8.86	3.36	1.82–4.85

Players with poor prior-league stats get pulled toward league average (Bayesian regression effect), but with wider CIs = lower confidence.

Japanese Players: K%/BB%/BABIP Corrections

Three models combined into a final prediction:

Model	Weight	Notes
Marcel	35%	Strong baseline, especially for pitcher ERA
Bayesian correction	40%	K%/BB%/BABIP/age adjustment on top of Marcel
ML	25%	XGBoost/LightGBM

Did Accuracy Improve?

8-year backtest (2018–2025, predict each year and compare to actual):

Metric	Marcel MAE	Bayesian MAE	Improvement prob.
Hitter wOBA	0.05023	0.04980	97.1%
Pitcher ERA	1.23008	1.22241	97.1%

Small improvement, but consistent — 97% probability of beating Marcel across 8 years.

Historical Marcel Accuracy for Context

Overall (8 years × 12 teams = 96 team-years):

Metric	Value
Wins MAE	6.4 wins
Avg rank error	1.42 positions
Exact rank rate	18%
Within 1 rank	65%

Recent examples of Marcel misses:

Year	Team	Actual	Predicted	Miss
2025	Swallows (CL)	57W (6th)	72W (4th)	+15
2024	SoftBank (PL)	91W (1st)	75W (2nd)	-16
2024	Buffaloes (PL)	63W (5th)	78W (1st)	+15

Patterns:

Overestimates bottom teams, underestimates top teams (regression to mean)
Can't predict collapses (2024 Buffaloes: defending champions → 5th place)
Foreign player impact not captured when all treated as average

How Did the 2026 Standings Change?

Central League — Tigers Runaway Disappears, 4-Team Deadlock

Team	Marcel	Bayesian	Diff	P(Pennant)
Tigers	80.1W (1st)	71.5W (1st)	-8.6	26.0%
Giants	70.7W (3rd)	71.1W (2nd)	+0.4	20.2%
Dragons	68.8W (5th)	71.0W (3rd)	+2.2	21.2%
BayStars	71.3W (2nd)	70.7W (4th)	-0.6	20.2%
Carp	70.4W (4th)	69.1W (5th)	-1.3	12.3%
Swallows	64.3W (6th)	61.2W (6th)	-3.1	0.1%

Tigers dropped from 80.1W to 71.5W (-8.6). Skill corrections pulled them down. Giants at 71.1W even after losing Okamoto to MLB. Four teams within 0.8 wins — Tigers 26%, Dragons 21%, Giants 20%, BayStars 20%. Swallows at 61.2W (78% last place) after Murakami's MLB departure.

Pacific League — Lions Surge

Team	Marcel	Bayesian	Diff	P(Pennant)
Hawks	80.5W (1st)	81.3W (1st)	+0.8	47.9%
Fighters	76.8W (2nd)	79.1W (2nd)	+2.3	27.2%
Buffaloes	73.8W (3rd)	77.5W (3rd)	+3.7	17.6%
Lions	68.6W (4th)	74.9W (4th)	+6.3	7.1%
Eagles	65.5W (5th)	66.7W (5th)	+1.2	0.1%
Marines	67.1W (6th)	64.9W (6th)	-2.2	0.1%

Lions +6.3 wins — foreign player projections offsetting Imai's MLB departure.

Summary

Problem	Before	After
Foreign players	All league-average	24 individual projections from prior-league stats
Skill metrics	Not used	K%/BB%/BABIP corrections on Marcel
Uncertainty	None (point estimates)	80%/95% credible intervals on every prediction
Team standings	Single number	10,000 Monte Carlo sims with pennant probabilities
Accuracy	Marcel MAE 0.050	0.0498 (97% probability of improvement)

The accuracy gain is modest, but "foreign players are no longer invisible," "MLB departures are reflected," and "every prediction comes with uncertainty" meaningfully changed the standings picture. The CL went from "Tigers runaway" to a four-team deadlock.

Caveat: Data Limitations

During this work, I discovered that players who moved to MLB (Murakami, Okamoto) were still included in the team simulation — the roster filter only existed in the Streamlit display layer, not in the CSV generation pipeline. Fixed and regenerated, but there may be other oversights I haven't caught.

This is a personal project without professional-grade QA. The data is best treated as automated model output, not authoritative predictions.

Dashboard: npb-prediction.streamlit.app
GitHub: github.com/yasumorishima/npb-prediction

Data Sources

Baseball Data Freak — NPB player stats
NPB Official — Official records

Adding Bayesian Ensemble + Monte Carlo to an NPB Prediction System

YMori — Mon, 23 Mar 2026 20:55:48 +0000

Introduction

In a previous article, I documented my journey adding Bayesian regression (Stan/Ridge) to my NPB (Japanese pro baseball) prediction system.

Previous article: Beyond Marcel: Adding Bayesian Regression to NPB Predictions

That work lived in a separate experiment repository (npb-bayes-projection). This article covers adding those pieces into the main app — a 7-phase process that touched 19 files and added 4,087 lines.

GitHub: npb-prediction
Live dashboard: npb-prediction.streamlit.app

Before: Point Estimates Only

Marcel (3-year weighted avg) → ML (XGBoost/LightGBM)
    ↓                              ↓
  Point estimate               Point estimate
    ↓
Pythagorean Win% → Team standings

Problems:

No uncertainty quantification
24 new foreign players treated as league-average (wRAA=0)
Marcel and ML run independently — no ensemble
Team standings are a single number with no confidence interval

After: Bayesian Ensemble + Monte Carlo

Layer 1: Marcel (unchanged)
    ↓
Layer 2: Stan Bayesian correction
  - Japanese: Ridge correction via K%/BB%/BABIP/age
  - Foreign: Prior-league stats × league-specific conversion (Stan v2)
    ↓
Layer 3: ML (XGBoost/LightGBM)
    ↓
Layer 4: BMA (Bayesian Model Averaging)
  - Marcel 35% + Stan 40% + ML 25%
  - 80%/95% credible intervals on every prediction
    ↓
Monte Carlo 10,000 draws → Team win distributions
  - P(pennant) / P(Climax Series) / P(last place)

The 7 Phases

Phase 1: Japanese Player Bayesian Inference

The key design decision: Stan does not run at inference time.

cmdstanpy is heavy to install and won't fit on a Raspberry Pi 5 (4GB RAM). Instead, I pre-compute posterior parameters into posteriors.json during training (in GitHub Actions), then sample with NumPy at runtime.

# posteriors.json structure (hitter example)
{
  "japanese_hitter": {
    "beta": [0.152, -0.089, -0.245, -0.003],
    "sigma_residual": 0.06215,
    "feature_names": ["K_pct", "BB_pct", "BABIP", "age_from_peak"]
  }
}

# Runtime sampling (milliseconds, not seconds)
z = (features - scaler_mean) / scaler_std
correction = beta @ z
samples = marcel_value + correction + rng.normal(0, sigma, size=5000)
ci_80 = np.percentile(samples, [10, 90])

Phase 2: Foreign Player Stan v2 Predictions

The most labor-intensive phase. I had to web-verify all 24 foreign players individually:

Katakana name → correct English name
Origin league (MLB / KBO / independent)
Most recent season stats

Lesson learned: Never guess English names from katakana.

Over 10 of my initial 28 guesses were wrong:

NPB Name	Initial Guess	Correct
Dalbec	Spencer Torkelson	Bobby Dalbec
Jerry	Sean Gerry	Sean Hjelle
Lucas	Josh Lucas	Easton Lucas

I also misidentified 4 Japanese draft picks (with katakana names) as foreign players. The rule: verify every single entry via web search before committing.

Phase 3: Monte Carlo Team Simulation

Player-level uncertainty propagates to team-level through 10,000 independent simulations:

for sim in range(10000):
    for team in teams:
        rs = sum(sample_hitter_runs(h) for h in team.hitters)
        ra = sum(sample_pitcher_runs(p) for p in team.pitchers)
        rs, ra = apply_park_factor(rs, ra, team)
        wins[team][sim] = 143 * rs**1.83 / (rs**1.83 + ra**1.83)

Foreign players get 1.5x sigma (wider uncertainty since they have no NPB data).

Phase 5: API Integration

Three new FastAPI endpoints:

Endpoint	Description
`/predict/hitter/{name}`	Bayesian OPS + 80%/95% CI (added to existing)
`/predict/foreign/{name}`	Foreign player Stan v2 projections (new)
`/standings/simulation`	Monte Carlo team standings (new)

Phase 6: Streamlit Integration

The largest phase — added ~370 lines to the 1,669-line streamlit_app.py:

Bayesian CI bars on existing prediction pages (Plotly overlay bars for 80%/95% intervals)
Team Simulation page (new) — fan chart + probability table
Foreign Players page (new) — prior-league stats + NPB projection with CI

Phase 7: BigQuery Integration

Added 8 tables (25 → 33 total): Bayesian predictions, foreign player data, simulation results, and conversion factors.

Technical Decisions

posteriors.json vs. cmdstanpy at runtime

	posteriors.json	cmdstanpy runtime
Inference speed	NumPy only (ms)	Stan call (seconds)
Memory	Few KB	Hundreds of MB
Updates	Annual retraining via GitHub Actions	Fit every time

For a system running on RPi5 with 4GB RAM, this was the only viable option. With annual data updates, there's no need to re-fit on every request.

BMA Weight Rationale

Marcel 35% + Stan 40% + ML 25% was determined by 8-year LOO-CV:

Stan correction improved Marcel 97.1% of the time (bootstrap)
ML matched Marcel on hitter OPS but underperformed on pitcher ERA
The 3-model BMA was more robust than any single model

The Full-Width Space Trap

Marcel CSVs used full-width spaces (U+3000) in player names while sabermetrics CSVs used half-width spaces. This caused 237 of 463 players to fail matching until I normalized with a player_join column.

Results

Metric	Value
New files	12 (2 Python + 10 data)
Modified files	7
Lines added	+4,087
BigQuery tables	25 → 33
Streamlit pages	7 → 9
Foreign players individually projected	0 → 24

The system moved from point estimates to probability distributions. "The Giants have a 42.6% chance of winning the pennant" is more useful than "The Giants are projected to win 74 games."

Takeaways

Moving experiment code into an app has its own challenges, distinct from the experiments themselves:

Data quality matters more than model quality. Incorrect foreign player names/stats would have propagated through the entire pipeline
Design for your runtime constraints. posteriors.json lets a 4GB RPi5 do Bayesian inference
Uncertainty visualization needs thought. CI bars, fan charts, and probability tables each communicate different aspects of the same distributions

Phase 4 (automated Stan retraining pipeline) remains for next season. But the prediction system now runs Bayesian ensemble predictions end-to-end, from individual players to team championship probabilities.

Dashboard: npb-prediction.streamlit.app
GitHub: github.com/yasumorishima/npb-prediction

Data Sources

Baseball Data Freak — NPB player stats
NPB Official — Official records

5 Pitfalls of Grafana + BigQuery — When Your Dashboard Shows Nothing

YMori — Sun, 22 Mar 2026 05:37:11 +0000

Introduction

I built 7 Grafana dashboards (70+ panels) on Grafana Cloud with BigQuery as the data source. Along the way, I hit multiple issues where queries returned data through the API but panels showed nothing in the UI.

Here are the 5 pitfalls I encountered and how to fix them. Verified on Grafana 13 + BigQuery datasource plugin.

1. Non-ASCII Column Aliases Need Backticks

Symptom

Syntax error: Illegal input character

Cause

If you use non-ASCII characters (e.g., Japanese, Chinese) in column aliases, they must be wrapped in backticks.

-- Fails
SELECT team AS チーム, HR AS 本塁打 FROM ...

-- Works
SELECT team AS `チーム`, HR AS `本塁打` FROM ...

This also applies to mixed ASCII + non-ASCII aliases like K率 and references in GROUP BY / ORDER BY clauses.

2. BigQuery Datasource Doesn't Support `format: "time_series"`

Symptom

error unmarshaling query JSON to the Query Model: invalid format value: time_series

Fix

Always use format: "table". For time series data, return a TIMESTAMP column named time — Grafana auto-detects it.

SELECT CAST(date AS TIMESTAMP) AS time, value FROM ...

3. Historical Data in Timeseries Panels Shows "Data outside time range"

Symptom

Panel displays "Data outside time range" with a "Zoom to data" button.

Cause

Timeseries panels filter by the dashboard time range (e.g., "Last 6 hours"). Historical data from 2015–2025 falls outside this range.

Fix

Use barchart panels for historical aggregations. Return the year as a string:

SELECT CAST(year AS STRING) AS year, value FROM ...

4. Extra fieldConfig Properties Can Break Barchart Rendering

Symptom

Barchart panel is completely blank. No error message. Query returns data when tested directly.

Cause

In Grafana 13, adding color, decimals, unit, or custom.axisLabel to fieldConfig.defaults can silently prevent barchart rendering.

// Broken — renders nothing
"fieldConfig": {
  "defaults": {
    "color": {"fixedColor": "#5470c6", "mode": "fixed"},
    "decimals": 0,
    "unit": "none"
  }
}

// Works
"fieldConfig": {
  "defaults": {},
  "overrides": []
}

Start with minimal config, verify it renders, then add properties one at a time.

5. Panels Inside Expanded Row's `panels` Array Are Invisible

Symptom

Panels exist in the dashboard JSON but don't appear in the UI.

Cause

Grafana row panels have two modes:

Collapsed (collapsed: true): child panels stored in the row's panels array
Expanded (collapsed: false): child panels must be top-level siblings after the row. The row's panels array must be empty.

If collapsed: false but the panels array still contains panels, those panels are invisible.

// Broken — panels inside expanded row are hidden
{
  "type": "row",
  "collapsed": false,
  "panels": [{"type": "barchart", "title": "Hidden Panel"}]
}

// Fixed — panels at top level after the row
{"type": "row", "collapsed": false, "panels": []},
{"type": "barchart", "title": "Visible Panel"}

Also check gridPos.y — if a panel's Y position is above its row header, it won't appear in the expected section.

Conclusion

Grafana + BigQuery is a powerful combination, but building dashboards via the API exposes issues you'd never encounter through the UI editor. The hardest to debug: "query is correct but panel is blank." Hope this saves you some time.

Moving an NPB Prediction System to BigQuery — BQML and Cloud Run on the Free Tier

YMori — Sun, 22 Mar 2026 00:34:23 +0000

Background

I've been running an NPB (Japanese professional baseball) player performance prediction project for over a year.

→ Previous articles:

The setup was: GitHub Actions fetches data → trains models → saves CSVs → Streamlit displays results. Data lived in CSVs, the API ran on a Raspberry Pi 5 Docker container, and analysis was done in local Python.

I added Google BigQuery to centralize the data, run SQL analysis, compare BQML accuracy against Python ML, and deploy the API to Cloud Run. Everything fits within GCP's free tier.

→ GitHub: https://github.com/yasumorishima/npb-prediction

Why BigQuery

Pain points with the CSV-based setup:

Full re-fetch every run — The annual pipeline re-downloads all data from scratch. No incremental updates
Cross-analysis was tedious — JOINing hitter stats with park factors meant writing pandas merge code every time
Wanted SQL access — Quick queries like "wRC+ TOP 10" or "age curve peak" required writing Python each time
Wanted to try BQML — How far can SQL-only ML go compared to Python?

Architecture

GitHub Actions (Annual Pipeline)
  ├── Data fetch (baseball-data.com / npb.jp)
  ├── Marcel projections
  ├── ML projections (XGBoost / LightGBM)
  ├── load_to_bq.py → BigQuery 25 tables
  ├── bqml_train.py → BQML 4 models
  └── Cloud Run deploy (on master merge)

BigQuery (npb dataset)
  ├── Raw data: 15 tables
  ├── Predictions: 4 tables
  ├── Metrics: 6 tables
  ├── BQML: 4 models
  └── Analysis views: 10

Display layer
  ├── Streamlit Cloud (dashboard)
  ├── Cloud Run API (serverless)
  └── Raspberry Pi 5 API (always-on)

Loading Data to BigQuery

load_to_bq.py loads CSV files into BigQuery.

RAW_TABLE_MAP = {
    "npb_hitters_2015_2025.csv": "raw_hitters",
    "npb_pitchers_2015_2025.csv": "raw_pitchers",
    "npb_batting_detailed_2015_2025.csv": "raw_batting_detailed",
    "npb_sabermetrics_2015_2025.csv": "sabermetrics",
    # ... 25 tables
}

NPB data has column names like K%, BB%, HR/9 which BigQuery doesn't accept. The loader sanitizes them:

new = new.replace("%", "_pct")
new = new.replace("/", "_per_")
new = re.sub(r"[^a-zA-Z0-9_]", "_", new)

All tables use WRITE_TRUNCATE (full replace) on each run, so schema changes are handled automatically.

BQML: ML with SQL Only

BigQuery ML lets you build features with SQL window functions and train models with CREATE MODEL.

Training View (Feature Engineering)

CREATE OR REPLACE VIEW `npb.v_batter_train` AS
WITH base AS (
  SELECT player, season, OPS, wOBA, K_pct, BB_pct, Age, PA, ...
  FROM `npb.raw_hitters`
  WHERE PA >= 100
),
lagged AS (
  SELECT
    player, season,
    LAG(OPS, 1) OVER w AS OPS_y1,
    LAG(wOBA, 1) OVER w AS wOBA_y1,
    LAG(OPS, 2) OVER w AS OPS_y2,
    LAG(OPS, 1) OVER w - LAG(OPS, 2) OVER w AS OPS_delta,
    LAG(Age, 1) OVER w - 27 AS age_from_peak,
    POW(LAG(Age, 1) OVER w - 27, 2) AS age_sq,
    OPS AS target_ops
  FROM base
  WINDOW w AS (PARTITION BY player ORDER BY season)
)
SELECT * FROM lagged WHERE OPS_y1 IS NOT NULL;

The same lag features, deltas, and age curves I had in Python, reimplemented as SQL window functions.

Model Training

CREATE OR REPLACE MODEL `npb.bqml_batter_ops`
OPTIONS(
  model_type = 'BOOSTED_TREE_REGRESSOR',
  input_label_cols = ['target_ops'],
  max_iterations = 200,
  learn_rate = 0.05,
  early_stop = TRUE
) AS
SELECT OPS_y1, wOBA_y1, K_pct_y1, BB_pct_y1,
       age_from_peak, age_sq, OPS_delta, ...
FROM `npb.v_batter_train`;

4 models total:

Model	Target	Type
`bqml_batter_ops`	Next-year OPS	Boosted Tree
`bqml_batter_ops_linear`	Next-year OPS	Linear Regression
`bqml_pitcher_era`	Next-year ERA	Boosted Tree
`bqml_pitcher_era_linear`	Next-year ERA	Linear Regression

BQML vs Python ML Accuracy

Same data, same evaluation period, MAE comparison.

Batter OPS MAE (lower is better)

Model	MAE
BQML Boosted Tree	.0642
Python (XGBoost)	.063
Python (LightGBM)	.066
Marcel	.063

Pitcher ERA MAE (lower is better)

Model	MAE
BQML Boosted Tree	.909
Python (XGBoost)	.93
Python (LightGBM)	.92
Marcel	.78

BQML performed comparably to Python ML. For pitcher ERA, both fall short of Marcel (0.78) — an ongoing challenge for ML approaches.

BQML uses more features (park factors, DIPS metrics, Marcel weighted averages), which may contribute to its Boosted Tree performance.

Analysis Views

10 views for my own analysis use:

View	Purpose
`v_batter_trend`	Player OPS/wOBA trends by season
`v_pitcher_trend`	Player ERA/WHIP trends + FIP approximation
`v_team_pythagorean`	Team win% vs Pythagorean expectation
`v_sabermetrics_leaders`	wRC+ leaderboard by season
`v_marcel_accuracy`	Marcel historical accuracy validation
`v_age_curve`	NPB-wide age curve (OPS × age)
`v_park_effects`	Park factor impact analysis
`v_data_coverage`	Season-by-season data coverage
`v_data_quality`	Per-table NULL/missing value summary

For example, checking "2025 wRC+ TOP 10" or "age curve peak" now takes SQL instead of writing pandas code.

-- Example query from my environment
SELECT player, team, season, wRC_plus, wOBA, OPS
FROM `npb.v_sabermetrics_leaders`
WHERE season = 2025
ORDER BY wrc_rank
LIMIT 10;

Cloud Run Deployment

Deployed the existing FastAPI to Cloud Run.

FROM python:3.12-slim
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["uvicorn", "api:app", "--host", "0.0.0.0", "--port", "${PORT:-8080}"]

Merging to master triggers automatic deployment via Artifact Registry.

The same API runs on both the Raspberry Pi 5 Docker container and Cloud Run.

Free Tier Usage

Everything runs within GCP's free tier.

Resource	Free Tier	Usage	% Used
Storage	10 GB/mo	~5 MB	0.05%
Queries	1 TB/mo	~22 GB	2.2%
Cloud Run	2M requests/mo	minimal	≈0%

Daily BigQuery usage monitoring with projected month-end pace is sent to Discord.

GitHub Actions Pipeline

The annual pipeline (annual_update.yml) now includes BigQuery loading, BQML training, and Cloud Run deployment.

Step 1: fetch_npb_data.py       → Scrape hitter/pitcher stats
Step 2: fetch_npb_detailed.py   → Detailed batting stats (for wOBA)
Step 3: pythagorean.py          → Standings + Pythagorean win%
Step 4: sabermetrics.py         → wOBA/wRC+/wRAA calculation
Step 5: marcel_projection.py    → Marcel projections
Step 6: ml_projection.py        → ML projections + model save
Step 7: git commit & push       → Auto-commit data/
Step 8: load_to_bq.py           → Load all data to BigQuery  ← NEW
Step 9: bqml_train.py           → BQML train & evaluate      ← NEW

BQML steps use continue-on-error: true, so BigQuery issues don't break the Python ML pipeline.

Takeaways

BQML accuracy was comparable to Python. Writing features as SQL window functions takes getting used to, but views make them reusable
Analysis views are quietly useful. SQL replaces pandas for routine queries
At ~40,000 rows, free tier usage is negligible
Having the API on both Cloud Run and RPi5 means one can go down without losing service

Monitoring the Strait of Hormuz Blockade with Open AIS Data and a Raspberry Pi

YMori — Sun, 15 Mar 2026 23:57:21 +0000

Data scope disclaimer: All data in this article comes from aisstream.io's terrestrial AIS receivers. Coverage in open water (mid-strait) is limited; satellite AIS would provide a more complete picture. All figures are from mid-March 2026 and the situation is evolving daily.

What This Is

In March 2026, shipping through the Strait of Hormuz — through which roughly 20% of the world's oil passes — was reported to be severely restricted. I built a monitoring system to observe this using free AIS (Automatic Identification System) data and a Raspberry Pi 5.

This post covers the system architecture, the analytics pipeline, and what the data shows within the limitations of terrestrial AIS coverage.

Repository: yasumorishima/hormuz-ship-tracker

Auto-generated snapshot (every 6 hours). Shows gate line positions, transit IN/OUT stats, and vessel type distribution. Note the concentration around UAE ports and the near-empty strait center.

AIS Data

AIS is a maritime safety system where vessels automatically broadcast their position, speed, course, name, and type over VHF radio. It's mandatory for international vessels over 300 gross tonnage.

aisstream.io aggregates terrestrial AIS receiver data worldwide and streams it via a free WebSocket API. This is the data source for this project.

Architecture

aisstream.io (WebSocket)
  → Collector (AIS receiver + land filter + SQLite)
  → Analytics Engine (gate-line transit detection + vessel classification)
  → FastAPI + Leaflet.js + Chart.js (dashboard)
  → matplotlib (6-hourly snapshot → GitHub auto-push)

Two Docker containers run 24/7 on a Raspberry Pi 5: the main collector/API and a snapshot cron job.

What the Data Shows

67% Anchored Ratio (mid-March 2026)

Of ~290 monitored vessels, about 67% were stationary (speed < 0.5 knots). In a typical port area, this ratio is usually around 30–40%. The elevated value is notable.

35 Vessels Waiting 6+ Hours (mid-March 2026)

Vessels that haven't moved for over 6 hours are counted as the "waiting fleet." About 35 vessels met this criterion, with 11 stuck for over 24 hours.

Waiting fleet flags (estimated from MMSI MID):

Flag	Count
Panama	9
Marshall Islands	3
UAE	3
Kuwait	2
Others	1 each

Panama and Marshall Islands are open registries — commonly used by large commercial ships and tankers. Seven tankers were among the waiting fleet.

Near-Zero Strait Transits on Terrestrial AIS (mid-March 2026)

A virtual gate line across the narrowest point of the Strait of Hormuz detects vessel crossings automatically. Only 1 transit was detected in 24 hours.

Important caveat: this only reflects what aisstream.io's terrestrial AIS receivers can capture. Coverage in mid-strait open water is limited. News reports indicate some vessels (Turkish, Indian, Saudi-flagged) have been allowed limited passage — these may not appear in terrestrial AIS data. "No data" does not equal "no ships." This caveat applies to all figures in this article.

Traffic Concentrated Around UAE Coast (mid-March 2026)

Most data clusters around Dubai, Jebel Ali, and Fujairah. Three gate lines capture port approach traffic:

Gate	Inbound	Outbound
Dubai / Jebel Ali Approach	20	9
Fujairah Approach	0	7
Strait of Hormuz	0	1

Dubai inbound significantly exceeds outbound. Fujairah shows only outbound traffic — likely vessels departing after bunkering (refueling).

Technical Implementation

Gate-Line Transit Detection

Virtual gate lines (line segments) are defined at the strait and port approaches. For each vessel, consecutive position reports are checked for intersection with each gate using computational geometry:

def segments_intersect(p1, p2, p3, p4):
    d1 = cross_product(p3, p4, p1)
    d2 = cross_product(p3, p4, p2)
    d3 = cross_product(p1, p2, p3)
    d4 = cross_product(p1, p2, p4)
    if ((d1 > 0 and d2 < 0) or (d1 < 0 and d2 > 0)) and \
       ((d3 > 0 and d4 < 0) or (d3 < 0 and d4 > 0)):
        return True
    return False

Direction (INBOUND/OUTBOUND) is determined by the sign of the cross product relative to the gate vector. Same-vessel crossings within 6 hours are deduplicated.

Data-Driven Situation Assessment

All dashboard text is auto-generated from data patterns. The system classifies the situation level based on strait transits, anchored ratio, and waiting fleet size:

if strait_transits == 0 and anchored_pct > 40:
    return {"level": "critical", "title": "Strait Transit Suspended"}
elif 0 < strait_transits <= 5:
    return {"level": "elevated", "title": "Limited Strait Transit"}
else:
    return {"level": "normal", "title": "Monitoring Active"}

When conditions normalize, the UI automatically shifts to normal mode — no hardcoded crisis messaging.

MMSI → Flag Mapping

Since aisstream.io's metadata doesn't reliably include country codes, flags are derived from the first 3 digits of the 9-digit MMSI number (Maritime Identification Digits). The system maps 100+ MIDs to countries.

Destination Normalization

AIS destination fields are free-text and wildly inconsistent (DUBAI, AE DXB, AEDXB, DMC DUBAI, etc.). Over 40 variants are mapped to canonical port names.

4-Day Data Analysis Update (March 18)

After 4 days of continuous collection (43,000+ position records, 384 unique vessels), several new insights emerged.

Traffic Density Heatmap

Left: Full Gulf hexbin density. Right: Zoomed strait with AIS dead zone. Bottom: Port area, flag state, and vessel type breakdowns.

Metric	Value
Clean positions	36,000
Anomalous (filtered)	7,300 (17%)
Unique vessels	384
Strait crossings confirmed	0
Dubai / Jebel Ali gate crossings	61

Timelapse — 24 Hours of Vessel Movement

24-hour vessel movement animation. Positions are linearly interpolated between data points, with land-crossing prevention.

AIS Data Quality: What the Anomalies Actually Are

About 17% of positions contained anomalous data. Two distinct patterns were identified:

Anomaly	Count	Cause
Speed = 102.3 kn	~3,200	AIS protocol "not available" sentinel (10-bit 0x3FF)
Speed 40–99 kn	~4,100	Coastal receiver decode errors

The ~48 kn cluster was particularly interesting: on 2026-03-16 at 07:00 UTC, 4 vessels simultaneously appeared at the same coordinates in the strait with identical speeds. This was a single receiver malfunction — no ships were actually there. These anomalies had produced 41 false transit detections, which were eliminated by filtering positions with speed >= 40 kn.

The dashboard now shows anomalous vessels with red dashed markers and a "DATA QUALITY WARNING" popup.

Browser-Based Replay

The /replay endpoint provides a Leaflet.js animated replay with play/pause, speed control (0.25x–16x), timeline scrubbing, and keyboard shortcuts.

Limitations

Terrestrial AIS coverage: Free aisstream.io data comes from shore-based receivers. Open-water coverage (mid-strait) is limited
AIS speed 102.3 knots: The "not available" sentinel value (0x3FF). Must be filtered
Speed 40–99 kn receiver glitches: Coastal receiver decode errors produce phantom positions. Transit detection filters speed >= 40 kn
Collection period: Ongoing collection. Longer-term trend analysis requires further accumulation

Summary

Using aisstream.io's free API and a Raspberry Pi 5, this system continuously collects and analyzes vessel traffic across the entire Persian Gulf. After 4 days, 43,000+ positions have been collected, with heatmap visualization, timelapse animation, and data quality analysis fully implemented.

Statistics are auto-updated every 6 hours.

Live Statistics (auto-updated) / Repository

Data source: aisstream.io / Land polygons: Natural Earth

I Built a WBC Quarterfinal Scouting App with MLB Statcast Data

YMori — Fri, 13 Mar 2026 16:58:40 +0000

What I Built

A Streamlit scouting dashboard for the WBC 2026 Quarterfinal: Japan vs Venezuela.

App: https://wbc-qf-jpn-ven.streamlit.app/
GitHub: https://github.com/yasumorishima/wbc-scouting

For the pool round, I built 30 team-level dashboards (20 teams). But quarterfinals are head-to-head matchups — you want to know "which pitch type is effective against this batter?" and "which zone has the highest opponent BA against this pitcher?" in one place.

5-Tab Structure

🎯 Tab 1: Matchup Preview

Venezuela's predicted starting lineup (9 batters) table, an alert for Machado (NPB player, no Statcast data), and a bench/pinch-hit candidates table.

Each batter expands into a full scouting report:

6 key metrics (AVG/OBP/SLG/OPS/K%/BB%) with MLB average comparison
Radar chart (5-axis, MLB average line overlay)
Zone heatmaps (3x3, 5x5) — BA and xwOBA by zone, split by vs LHP/RHP
Spray charts — split by vs LHP/RHP

Platoon splits (OPS/AVG/K%/BB% side by side)
Pitching plan — overall + vs LHP + vs RHP. Auto-generated from pitch type whiff rates, zone-level BA, count-split OPS, and platoon data
Defensive positioning — auto-generated from spray angle, ground ball rate, and exit velocity, split by pitcher handedness
Pitch type performance table (BA, SLG, Whiff%, Chase%)
Count-based performance (color-coded: green=hitter ahead, red=behind, amber=even)

At the bottom, there's a full analysis section for the starting pitcher (Ranger Suárez, LHP) with hitting approach (as LHB/RHB), arsenal table, movement chart, location heatmaps, platoon splits, and pitch selection by count — all in collapsible expanders.

📋 Tab 2: Game Plan

Statcast data organized by game phase:

Team weakness detection — batters with K% ≥ 22.4% (MLB avg), BB% < 8.3%, or platoon OPS gap ≥ 80 pts, auto-extracted with player names and values
Innings 1-3 vs Suárez (starter) — Batting: SP's K%/BB%/Whiff%/velocity and pitch mix. Pitching: per-batter AVG/K%/BB% grouped by lineup position (#1-3, #4-6, #7-9)
Innings 4-5 (2nd time through or bullpen transition) — Batting: bridge reliever stats. Pitching: MLB league-wide trend (opp OPS rises 15-20% on 2nd time through) plus batter classification by K% and BB%
Innings 6+ (high-leverage) — Batting: closer/setup K%/Whiff%/Chase%/velocity with pitcher type classification. Pitching: platoon matchup data for batters with significant splits, full per-batter stat line
Pinch-hit candidates — bench player AVG/OPS/K%

Every piece of text is driven by MLB Statcast numbers only. No coaching instructions — just data.

⚔️ Tab 3: Lineup Scouting

Team batting radar chart at the top (AVG/OBP/SLG/K%/BB%, 5-axis, MLB average line overlay). Below that, a full roster table and a dropdown selector for individual player analysis (metrics, scouting summary, pitching plan, defensive positioning, radar chart, zone heatmaps, spray charts, etc.).

🎱 Tab 4: Starting Pitcher Analysis

Ranger Suárez's pitching data. Metric cards (avg velocity, avg spin, whiff%, chase%, put away%, opp avg, etc.) and scouting summary, plus collapsible expanders for:

Hitting approach (as LHB / as RHB)
Arsenal table (velocity mph/km/h, break, whiff%, put away%) + movement chart
Pitch location heatmap + platoon splits
Pitch selection by count (donut charts) + count-based performance

🔥 Tab 5: Bullpen Scouting

Bullpen overview (all relievers' ERA, K%, velocity in one info box), then a dropdown selector for individual reliever analysis. Same structure as Tab 4 (metric cards, scouting summary, hitting approach, arsenal, heatmaps, count analysis).

Technical Highlights

Dynamic text generation from raw Statcast data

Six generator functions compute per-player analysis from pitch-by-pitch data:

Function	Purpose
`generate_player_summary()`	Batter scouting summary (strengths/weaknesses)
`generate_pitcher_summary()`	Pitcher scouting summary
`generate_pitching_plan()`	How to pitch to a batter (pitch types, zones, counts, platoon)
`generate_hitting_plan()`	How to hit a pitcher (hittable pitches, zones, counts)
`generate_defensive_positioning()`	Infield/outfield shift recommendation from spray data
`generate_sp_pitch_analysis()`	Starting pitcher's pitch-by-pitch analysis

Each function calculates stats from raw Statcast data and outputs only items that cross statistical thresholds:

# Example: identify the pitch type with highest opponent BA
hittable = sorted(
    [p for p in pt_stats if p["ba"] is not None],
    key=lambda x: x["ba"], reverse=True
)
if hittable and hittable[0]["ba"] >= 0.250:
    h = hittable[0]
    lines.append(
        f"- **Highest opp BA pitch:** {h['label']}"
        f" (BA .{int(h['ba']*1000):03d})"
    )

MLB average as baseline for every stat

A raw number like "SLG .476" is meaningless without context. Every stat shows the MLB average alongside it:

K% 28.3% (MLB avg 22.4%)
BB% 6.1% (MLB avg 8.3%)

Handedness-aware zone names

"Inside" and "outside" flip depending on batter handedness. _zone_names_for_bats() automatically adjusts zone labels so "inside high" is always correct relative to the batter's stance.

Glossary built into every section

Every stat has a ? tooltip (Streamlit's help parameter) showing its definition and MLB average. Count displays include a reading guide ("Balls-Strikes" format) with color legend (🟢 hitter ahead, 🔴 hitter behind, 🟡 even).

Data Source

Baseball Savant Statcast data (2024-2025 MLB regular season)
Retrieved via pybaseball

I Built a WBC 2026 Scouting Dashboard with MLB Statcast Data

DEV Community: YMori

M5 StackChan pairing fails with No devices found — the factory firmware is the cause

TL;DR

Environment and dates

The symptom

What did not help

The serial log told a completely different story

Root cause: firmware version, plus a deadlock

The fix: flash the official firmware over USB, without M5Burner

1. List the official firmware versions

2. Download the binary

3. Get esptool (no Python needed)

4. Verify communication with a read-only command first

5. Flash

6. Confirm the version

Other traps worth knowing

Opening the serial port reboots the device

There is no interactive serial console

Do not power both USB-C ports at once

Servo zero positions survive a full flash erase

A separate warning about charging

Takeaways

References

M5 StackChan pairing fails with \"No devices found\"? The factory firmware is the cause

TL;DR

Environment and dates

The symptom

What did not help

The serial log told a completely different story

Root cause: firmware version, plus a deadlock

The fix: flash the official firmware over USB, without M5Burner

1. List the official firmware versions

2. Download the binary

3. Get esptool (no Python needed)

4. Verify communication with a read-only command first

5. Flash

6. Confirm the version

Other traps worth knowing

Opening the serial port reboots the device

There is no interactive serial console

Do not power both USB-C ports at once

Servo zero positions survive a full flash erase

A separate warning about charging

Takeaways

References

My Raspberry Pi 5 Kept Vanishing From the Network — Diagnosing With journalctl and Fixing It With a Watchdog

The symptom

Step 1: tailscale status tells you device-side vs your-side

Step 2: After recovery, read journalctl -b -1 (the previous boot)

The fix: a NetworkManager watchdog

Verify it does NOT restart when the network is fine

Takeaways

Follow-up: a selective outage the watchdog couldn't see — and watchdog v2

The symptom (nothing like last time)

Triage 1: hit the same destinations from another device on the same router (the decisive check)

Triage 2: probe each DNS server directly over UDP

The fix: a full wlan0 reconnect (reapply is not enough)

watchdog v2: also probe external connectivity

Follow-up takeaways

I Had Claude Fable 5 Review My Indie Diary App Before It Got Pulled — The Bugs It Caught

Intro

The app: Daily Diary

What I asked for

1. BuildContext used across an async gap

2. Hoisting the l10n lookup before the await

3. The test that tested nothing

4. 47 analyzer warnings to zero

5. Major dependency bumps

6. Added CI

How it felt as a solo dev

transform: translateY(0) Breaks position: fixed — A Hidden Trap in SPA Animations

The Bug

How to Reproduce

Why This Happens — The CSS Spec

The animation-fill-mode: both Trap

Blast Radius

The Fix

1. Use transform: none (Most Important)

2. Use createPortal to Escape the DOM Tree (Defensive)

3. Do Both (Recommended)

Step 1: `tailscale status` tells you device-side vs your-side

Step 2: After recovery, read `journalctl -b -1` (the previous boot)

The fix: a full wlan0 reconnect (`reapply` is not enough)

The `animation-fill-mode: both` Trap

1. Use `transform: none` (Most Important)

2. Use `createPortal` to Escape the DOM Tree (Defensive)

2. BigQuery Datasource Doesn't Support `format: "time_series"`

5. Panels Inside Expanded Row's `panels` Array Are Invisible