Problem
Newer Pod 5 units ship with frozen firmware v1.4.19, but newer hub revisions removed the FDC1004 water level sensor (capacitance-to-digital converter on I2C bus 2). The firmware still attempts to poll address 0x50 for the FDC1004 — when the chip is absent, the polling loop hangs indefinitely, blocking the frozen firmware's main loop and preventing all heating commands from executing.
Symptoms:
- Pump briefly runs then stops
currentTemperatureF: 55 / currentTemperatureLevel: -100 (default values, never updated)- Both sides show
isOn: true with a target set, but no actual heating
- I2C probe fails at unexpected address (0x0002 instead of 0x0050)
This only manifests after jailbreak because the 8Sleep cloud normally pushes OTA firmware updates (v1.4.95+) that skip the FDC1004 poll on newer hub revisions. Blocking WAN freezes the pod on the factory firmware version.
Not a sleepypod-core bug
This is a firmware-hardware mismatch below our layer. sleepypod-core communicates with frankenfirmware via the DAC socket — if frankenfirmware's frozen firmware loop is stuck, no commands reach the hardware.
Known fix
Replace the frozen firmware binary with v1.4.95 (or newer):
# Back up the original
cp /opt/eight/lib/subsystem_updates/firmware-frozen.bbin \
/opt/eight/lib/subsystem_updates/firmware-frozen.bbin.bak
# Replace with v1.4.95 (extract from 8Sleep update server)
cp /path/to/firmware-frozen-v1.4.95.bbin \
/opt/eight/lib/subsystem_updates/firmware-frozen.bbin
# Restart frankenfirmware
systemctl restart frank.service
Side effects for sleepypod-core
waterLevelReadings table will always be empty on affected units (no FDC1004 = no water level data)waterLevelRaw fields in device.getStatus will be null- All other functionality (temperature control, schedules, alarms, biometrics) works once firmware is updated
Action items
Source
Community report from Discord (2026-04-06). Credit to nota-nota-nota for diagnosing the firmware version mismatch and identifying the update server as a source for the fix.
Problem
Newer Pod 5 units ship with frozen firmware v1.4.19, but newer hub revisions removed the FDC1004 water level sensor (capacitance-to-digital converter on I2C bus 2). The firmware still attempts to poll address 0x50 for the FDC1004 — when the chip is absent, the polling loop hangs indefinitely, blocking the frozen firmware's main loop and preventing all heating commands from executing.
Symptoms:
currentTemperatureF: 55/currentTemperatureLevel: -100(default values, never updated)isOn: truewith a target set, but no actual heatingThis only manifests after jailbreak because the 8Sleep cloud normally pushes OTA firmware updates (v1.4.95+) that skip the FDC1004 poll on newer hub revisions. Blocking WAN freezes the pod on the factory firmware version.
Not a sleepypod-core bug
This is a firmware-hardware mismatch below our layer. sleepypod-core communicates with frankenfirmware via the DAC socket — if frankenfirmware's frozen firmware loop is stuck, no commands reach the hardware.
Known fix
Replace the frozen firmware binary with v1.4.95 (or newer):
Side effects for sleepypod-core
waterLevelReadingstable will always be empty on affected units (no FDC1004 = no water level data)waterLevelRawfields indevice.getStatuswill be nullAction items
Source
Community report from Discord (2026-04-06). Credit to nota-nota-nota for diagnosing the firmware version mismatch and identifying the update server as a source for the fix.