Hello everyone,
I am posting this here because I have already submitted a support ticket to SONOFF, but I would also like to know if anyone in the community has experienced the same issue or can reproduce it.
Before posting, I performed multiple tests to isolate the problem as much as possible.
Device
SONOFF iHost AIBridge-26 (4 GB RAM)
eWeLink CUBE 2.12.0
CoreBox image
Official image:
haos_ihost_CoreBox-16.3.img.xz
Downloaded from the official iHost Open Source GitHub repository.
Flashed using Raspberry Pi Imager.
Writing and verification completed successfully.
Boot behaviour
The device always follows exactly the same LED sequence:
Solid Red
Red marquee animation
Solid Blue
Boots eWeLink CUBE normally
The blue breathing LED never appears and Home Assistant never starts.
Home Assistant is never reachable on port 8123.
Troubleshooting already performed
Downloaded the official image again.
Flashed using Raspberry Pi Imager.
Successful write and verification.
Boot with the microSD already inserted.
Boot while pressing the Mute button during startup.
Boot without pressing any buttons.
Multiple reboot attempts.
Waited several minutes after each boot.
Important findings
To rule out SD card issues, I tested two different microSD cards.
Test 1 – 32 GB microSD
I first used a 32 GB microSD, which meets the recommended capacity requirements for CoreBox.
The official image was successfully written and verified using Raspberry Pi Imager.
Windows Disk Management correctly detects all expected Home Assistant partitions.
However, the iHost never boots Home Assistant and always starts eWeLink CUBE.
Test 2 – 16 GB microSD
I then used a second 16 GB microSD to perform additional diagnostics.
When formatted as FAT32, eWeLink CUBE immediately detects the TF card and Docker displays it correctly.
After flashing the same card with the official haos_ihost_CoreBox-16.3.img.xz image:
Raspberry Pi Imager completes writing and verification successfully.
Windows Disk Management correctly detects the Home Assistant partitions.
Docker no longer detects the TF card.
The iHost always boots eWeLink CUBE instead of Home Assistant.
The fact that both microSD cards show exactly the same behaviour after flashing the official CoreBox image makes me think this may not simply be an SD card issue.
Questions
Could someone please confirm:
Is haos_ihost_CoreBox-16.3.img.xz the correct image for the SONOFF iHost AIBridge-26 running eWeLink CUBE 2.12.0?
Has anyone experienced the same behaviour?
Is it expected that Docker no longer detects the TF card after flashing the official CoreBox image?
Could this indicate a compatibility issue between CoreBox 16.3 and firmware 2.12.0, or possibly a bootloader-related problem?
I have attached:
Raspberry Pi Imager successful write and verification.
Windows Disk Management showing the expected Home Assistant partitions.
Docker detecting the FAT32 microSD.
Docker no longer detecting the same microSD after flashing CoreBox.
System logs exported from the iHost.
Any advice, suggestions or confirmation would be greatly appreciated.
Thank you very much.
Indeed! After flashing haos_ihost_CoreBox‑16.3.img.xz, the iHost no longer runs CubeOS. It boots Home Assistant OS directly from the TF card, which means:
Docker from CubeOS is no longer active.
The TF card is no longer mounted as FAT32 storage.
HAOS repurposes the entire card as its own root filesystem (boot, kernel, data, overlay).
Windows still sees the HAOS partitions, but CubeOS/Docker cannot, because CubeOS is not running.
This is normal and expected, not a compatibility issue with firmware 2.12.0, and not a bootloader problem.
Answers to your questions:
Is CoreBox‑16.3 the correct image?
Yes — it’s the official HAOS image for SONOFF iHost.
Has anyone seen the same behaviour?
Yes — this is exactly how HAOS behaves on iHost.
Is it expected that Docker no longer detects the TF card?
Yes — Docker only works under CubeOS. Once HAOS boots, CubeOS (and Docker) are not used.
Could this be a compatibility or bootloader issue?
No — the system boots HAOS correctly, and the behaviour matches the HAOS design.
If you want Docker to see the TF card again, format the card back to FAT32 and boot CubeOS normally. To return to HAOS, flash CoreBox‑16.3 again.
Hello, thank you for your feedback. We have received your log files via our ticket system. In addition, to help us locate the issue more quickly, we would kindly ask you to provide the following supplementary information:
A video of the iHost booting up the Home Assistant Operating System, showing the entire startup process and the behavior of the indicator lights.
Once we receive this information, we will promptly forward it to our technical team for investigation and keep you updated on our progress. Thank you again for your understanding and cooperation.
Update
Thank you both for your replies. @jam3, thank you for your explanation. I completely understand that once Home Assistant OS boots successfully, CubeOS and its Docker environment are no longer active and the TF card is no longer detected by Docker. That part makes perfect sense.
However, my issue appears to be different. In my case, Home Assistant OS never actually starts. The iHost always follows the same LED sequence:
Solid red
Red marquee animation
Solid blue (stays permanently)
The blue breathing LED never appears, Home Assistant is never reachable on port 8123, and after waiting several minutes the device remains on the solid blue LED.
As requested by the SONOFF support team, I am attaching a complete boot video showing the entire startup sequence with the microSD card already inserted before powering on the iHost.
I have reproduced exactly the same behaviour with two different microSD cards (16 GB and 32 GB), both flashed with the official haos_ihost_CoreBox-16.3.img.xz image and successfully verified by Raspberry Pi Imager.
At this point, I suspect the issue occurs before Home Assistant OS is able to start, rather than being related to Docker or the TF card itself.
If anyone has experienced the same behaviour or is able to reproduce it, I would really appreciate your feedback.
Thank you.
Your analysis is correct: the issue happens before Home Assistant OS starts, during the transition from CubeOS to HAOS. It looks like this is not related to Docker, not related to HAOS runtime, and not caused by the TF card being ignored after boot. The iHost simply never reaches the HAOS bootloader stage, it seems.
These steps help determine exactly where the boot process fails.
Boot the iHost without the TF card
Purpose: confirm whether CubeOS always stops at solid blue.
Power off the device
Remove the TF card
Power on
Observe LED
If the device still stays on solid blue, it means CubeOS is not attempting to boot from TF at all.
Boot with TF card inserted but without LAN connected
Purpose: rule out network‑related delays.
Insert TF card
Disconnect Ethernet
Power on
HAOS should still reach blue breathing even without network.
If it does not → HAOS never starts.
Try a smaller TF card (8 GB if available)
Purpose: some iHost units have issues with >32 GB cards.
Flash HAOS again
Use 8 GB or 16 GB
If the behavior is identical → not a card size issue.
Flash the image using Balena Etcher instead of Raspberry Pi Imager
Purpose: eliminate partition offset / alignment issues.
Use Balena Etcher
Flash the same HAOS image
Boot again
If the result is unchanged → the TF card is readable, but CubeOS refuses to boot HAOS.
Check whether CubeOS detects the TF card at all
Purpose: confirm hardware detection.
Boot to CubeOS (solid blue)
Open iHost web UI
Check “Storage” or “System” section
If TF card is not listed → hardware detection issue.
Confirm your iHost hardware revision
Purpose: some early or late revisions have different bootloader behavior.
Check sticker on the bottom, and provide revision number here. If your revision is newer than the HAOS image supports → HAOS cannot boot.
Record full boot video (you already did)
Purpose: show eWeLink that HAOS never starts.
This is important because the LED sequence clearly proves the failure occurs before HAOS is launched.
With all due respect to Sonoff/eWeLink - and no offense, just the sarcastic reflections of someone who ditched the iHost and CUBE after weeks of wrestling and then sailed off into the blissfully uncomplicated waters of pure HAOS - how did we end up in a world where people heroically try to boot Home Assistant OS on a device that was never designed for it, while a Raspberry Pi sits there like the sensible grown‑up in the room, quietly running HAOS on the first attempt without turning its LED into a three‑act tragedy?
Because watching someone wrestle with an iHost has become a kind of modern tech folklore. You flash the TF card, verify the image, record the boot sequence like you’re submitting evidence to a war‑crimes tribunal… and in return the iHost gives you solid blue, the digital equivalent of a blank, slightly disappointed stare. No HAOS. No breathing LED. Just existential stillness.
And then comes the twist: the iHost is 32‑bit. A 32‑bit smart home hub trying to run a modern Home Assistant OS. It’s not just impractical - it’s borderline theatrical. The whole endeavour becomes gloriously grotesque, like trying to run a marathon in flip‑flops because the manufacturer promised they were “performance‑enhanced”. Meanwhile, the Raspberry Pi - the device actually meant to run HAOS - boots instantly, without CubeOS acting as a nightclub bouncer, without TF‑slot roulette, and without requiring a boot video worthy of Sundance.
But hey. Some people climb mountains because they’re there. Others try to boot HAOS on a 32‑bit iHost
Thank you for sharing your experience. Just out of curiosity, did you ever experience the same symptom as mine (solid blue LED with Home Assistant OS never starting), or was your issue different?
Since SONOFF provides an official HAOS image for the iHost, I’m trying to determine whether this is a known boot issue or something specific to my device.
I’ve lived through a similar mess. I’ve watched others suffer. The horror stories are probably still archived somewhere on this forum, like digital fossils of poor life choices. And honestly, looking back, I’m amazed any of us had the patience to endure that whole slapstick routine. It’s basically the smart‑home equivalent of running Windows XP on a phone. Sure, you can - but why would you?
I eventually bailed, factory‑reset the iHost, and gifted it to someone I don’t particularly like. Now I’m on a Intel-based mini‑PC, two Sonoff dongles, dozens of devices, and everything running smoothly. Home Assistant evolves at warp speed, Matter/Thread finally behaves like a dream, and the documentation is rich enough to use as ballast on a cargo ship. Meanwhile, the iHost still bravely insists it supports HAOS as long as you don’t expect the official image to actually boot.
To carry on, some mountains are climbed because they’re there. Some iHosts are flashed because… well, nobody really knows since they’re much better as they are.
Forgive the sarcasm, but honestly - with a 32‑bit system abandoned ages ago by the Home Assistant developers, you’re not just walking into a swamp, you’re voluntarily pitching a tent there. No matter how heroically you twist reality, this remains a niche hobbyist ritual, the kind performed by people who solder for fun and call it “relaxing”. And let’s be brutally honest: nothing spectacular is going to come out of it.
Thank you for sharing your experience and your thoughts.
I understand your point of view, and I appreciate your suggestions. My goal is simply to determine whether this is a problem with my specific iHost, the current bootloader, or a compatibility issue with the current software.
As an additional test, I have now flashed the official haos_ihost_CoreBox-16.3.img.xz image using Rufus, after previously testing with Raspberry Pi Imager.
Both tools completed the flashing process successfully, but the result is exactly the same:
• Solid red LED
• Red marquee animation
• Solid blue LED (never changes)
• Home Assistant OS never starts and the blue breathing LED never appears.
I have also tested with two different microSD cards (16 GB and 32 GB), both showing exactly the same behaviour.
At this point, I believe the issue is very unlikely to be related to the flashing software or the microSD card itself.
I have already provided the system logs and a complete boot video to the eWeLink support team, and I am currently waiting for their technical analysis.
Hopefully this information will also help anyone else who encounters the same issue in the future.
Hello, detailed operational recommendations regarding your reported issue have been provided in our internal ticket system. Please verify them at your convenience. Should you have any questions during the process, please do not hesitate to contact us. Thank you!
Final update – Solved!
The issue has been resolved, and it turned out to be entirely my mistake.
Throughout all my previous attempts, I had been pressing the Security button on the front panel instead of the Mute button, which SONOFF support had correctly instructed me to use.
After carefully checking the user manual again, I realized my mistake and repeated the procedure using the correct Mute button during startup.
The LED immediately changed to the expected breathing blue state, and Home Assistant OS booted successfully.
I would like to sincerely apologize for the confusion and for insisting on the wrong button during the troubleshooting process.
Thank you to the SONOFF support team for their patience and guidance, and also to everyone who took the time to reply and help.
Hopefully this update will help anyone who makes the same mistake in the future.
I understand that you’re consciously insisting on running Home Assistant on the hardware‑limited 32‑bit iHost, because sticking to the 32‑bit version of Home Assistant means your system becomes un‑upgradable and deprecated. As of December 2025 (release 2025.12), 32‑bit architectures are officially unsupported. The system will still run, but frozen in time. Home Assistant isn’t “cloud‑only”, so it won’t die immediately, but every passing month increases the risk of vulnerabilities. HA explicitly states that maintaining 32‑bit support was blocking the development of new features. The consequences:
new integrations will require 64‑bit,
older integrations will start depending on newer libraries unavailable on 32‑bit,
add‑ons will stop updating → will begin to break.
In short: HA on the 32‑bit iHost is a technical absurdity that works only because eWeLink performed a brutal, one‑off hack - not because Home Assistant actually supports this platform. The eWeLink Add‑ons repository is mostly non‑installable on 64‑bit, so the entire idea only makes sense in a world where the iHost remains a 32‑bit relic. In the world of the eWeLink platform/cloud it’s still a very good and kinky device, but that’s a completely different story
Thanks for taking the time to follow up and explain the situation.
I completely understand the limitations of running Home Assistant on a 32-bit iHost, and I agree that it’s not a long-term solution.
My goal is simply to learn Home Assistant, get familiar with it, and build my automations without investing in new hardware right away. Once everything is configured and I’m comfortable with HA, I’ll make a full backup and migrate to a supported 64-bit platform.
So, for me, the iHost is more of a learning platform than a permanent Home Assistant server. I appreciate your explanation.
