Supported-cameras table: firmware 1.8.7.0F_201809191400 is a false positive — 22US/22EU Yi Home 720p ignores rootfs_y18/home_y18

[Stephonomon]

Summary

The Base Firmware column in the supported-cameras table can produce a false positive. My camera's firmware string is a character-for-character match to the listed Yi Home / y18 baseline, but the camera is not a y18 and silently ignores rootfs_y18 / home_y18.

This is the identification gap @Nixellion asked about in #421 ("this project should improve on its list of supported cameras by adding numbers"), and the same hardware @WojciechBednarski hit in #382 with a 22EU unit. I have a full device fingerprint, so I'm posting it as concrete data toward closing that gap.

The false positive

README says	Yi Home | rootfs_y18 | home_y18 | 1.8.7.0F_201809191400
My camera reports	1.8.7.0F_201809191400

Identical. By the table, this is a supported y18. It isn't.

Device fingerprint

Model YHS-113-IR (Yi Home 720p), serial prefix 22US, NIC OUI b0:d5:9d (Shenzhen Zowee).

From the camera's own diagnostic dump, which stock firmware writes to the SD card as log_<id>_tnp_init_finish.tar.gz:

# version
version=1.8.7.0F_201809191400
devtype=18E
provider=18E

# dmesg
Linux version 3.0.8 (gcc 4.4.1 (Hisilicon_v100...)) #1 Wed Apr 30 16:56:49 CST 2014
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ)
Machine: hi3518
mem=40M   Chip:16MB SPI
mtdparts=hi_sfc:256k(boot)ro,128k(env),128k(conf),3072k(os),3584k(rootfs),9088k(home),128k(vd)

Note devtype=18E, not y18.

What happened with 0.4.1

Copied rootfs_y18, home_y18 and the yi-hack-v5/ folder to the FAT32 card root, powered off, inserted, powered on. Brief yellow, then a completely normal stock boot. No web UI, no open ports.

Pulling the card afterwards shows the camera was working the whole time and just ignored the firmware:

• created by the camera: record/2026Y08M30D22H/*.mp4 (1280x720 h264 @20fps + aac), record_sub/ (640x360), four log_*.tar.gz, timesec, timesec1
• untouched: rootfs_y18 and home_y18, both still byte-identical to the release (sha256 verified before and after)

Matches @WojciechBednarski exactly in #382:

my camera is only accepting firmware files which are named home and rootfs, files named home_y18, rootfs_y18 are ignored by the camera. When I renamed them to home and rootfs, flashing was in progress, but camera refused to boot

Things worth ruling out up front

These are the usual answers, and none of them apply here — I checked each before writing:

• Card too big / not FAT32. The card is 32 GB FAT32 and the camera is perfectly happy with it: mmc0: new SDHC card at address 544c, mmcblk0: MSSD0 29.1 GiB, /dev/hd1 29.1G 30.4M 29.1G 0% /tmp/hd1. It recorded video to that card during the failed attempt.

• yi-hack-v5 folder missing. Present, all 274 files, diff -r against the extracted release is identical.

• Mac mangled the download (Cannot flash Yi Home 47US camera, light gets stuck on solid yellow and never moves forward. #390). Release tarball sha256 matches, tree diff is clean, zero AppleDouble ._* sidecars on the card.

• home image too big ([0.4.1.e] - Yi Home 27US - Unable to Flash #334). It fits: home partition is 9,088 KB = 9,306,112 b, home_y18 in 0.4.1 is 7,374,496 b — ~1.9 MB spare. For reference, 0.4.1's home_y18 is also smaller than 0.4.1f (7,608,364) and about the same as 0.4.1g (7,375,072), both of which @Minims confirmed flashing on a 27US in [0.4.1.e] - Yi Home 27US - Unable to Flash #334.

• Wrong CPU architecture. Also not it, and I want to head this off because it's the intuitive guess given Hi3518ev200 in the project description. I decoded .ARM.attributes from the shipped 0.4.1 binaries:

  bin/rRTSPServer  Tag_CPU_name='5TE'         Tag_CPU_arch=ARMv5TEJ
  bin/imggrabber   Tag_CPU_name='5TE'         Tag_CPU_arch=ARMv5TEJ
  sbin/dropbear    Tag_CPU_name='5TE'         Tag_CPU_arch=ARMv5TEJ
  lib/libc.so.0    Tag_CPU_name='ARM926EJ-S'  Tag_CPU_arch=ARMv5TEJ
  

  Same core this camera has. The binaries would run. The blocker is upstream of that — the updater never recognises the filenames.

Suggestion

The firmware column alone isn't a sufficient identifier, because Yi reused 1.8.7.0F_201809191400 across hardware that the y18 images don't install on. Two low-cost options:

1. Add a serial-prefix column (17CN / 27US / 47US supported; 22US / 22EU known-not-supported), or
2. Add a note under the table: if your camera ignores the files entirely and boots normally, check your serial prefix and see 22EU Yi home 720p support #382 — do not rename the images.

Either would have saved me the attempt, and both directly answer #421.

Worth stating loudly wherever this lands: renaming to rootfs / home is the brick path. It flashes and then won't boot, and @brudnypiotr needed a stranger's recovery zip in #382 to get back. Silently-ignored is the safe failure; renaming converts it into a dead camera.

Happy to open a PR against the README table if you'd like — just say which of the two shapes you prefer.

---

Investigated with Claude Code. Every claim above is from my own camera's logs or from files I verified locally; the two cross-referenced reports are linked rather than paraphrased.