【FAQ】 "HA over iHost"

iHost Open Source Project HA over iHost
, ,
1

Here are some frequently asked questions (FAQ) to assist you with any concerns or issues that may arise. We hope this post helps you get the most out of your iHost device while running Home Assistant.

Prerequisites

Q: How do we handle the issue of HA add-ons requiring 64-bit support on a 32-bit iHost?

Currently, iHost supports only a 32-bit architecture, which means some HA add-ons that require 64-bit support will not work. However, we are actively planning an upgraded version of iHost with 64-bit support, 5G Wi-Fi, and larger eMMC storage, scheduled for release later this year. We encourage all users to share their ideas and feature requests for the new hardware.

Q: What happens when Home Assistant drops 32-bit support in six months? Will my iHost still work?

Home Assistant will indeed end 32-bit support in six months, after which new HA releases won’t run on 32-bit systems like today’s iHost. Your device will continue operating but won’t receive those newer HA versions. We’re aware of this timeline and are developing a next-generation iHost with 64-bit support to meet HA’s evolving requirements, stay tuned for its release later this year.

Q: Is the HA over iHost image created and supported by SONOFF?

Yes, the HA over iHost image in the iHost Open-Source Project is officially created by SONOFF. This project is part of an open-source initiative aimed at bringing more developers together to contribute and maintain it. If you encounter any issues or have questions, feel free to submit them on our GitHub issues page. We’ve built this image on the foundation of Darkxst’s HA operating system hosted on GitHub, and we are grateful for their initial contributions and support.

Q: Which TF cards do you recommend to avoid startup issues with Home Assistant on iHost? How can I verify that my TF card is compatible with iHost?

  • An (Application Class 2) (A2) card, with a minimum capacity of 32GB, is recommended for better performance, especially on small read&write operations. We would suggest using a TF card from SanDisk, Kingston, or Samsung. We have been internally using these brand cards for testing.
  • Simply insert the TF card and open iHost’s Docker interface on CUBEOS. If the system recognizes the card there, it’s also fully compatible with HA over iHost.
    image
    image918×482 70.9 KB

Booting Related

Q: How can I tell from the LED indicator whether Home Assistant over iHost has booted successfully?

  • If the LED indicator shows a BLUE breathing light pattern, you can access your new Home Assistant web interface next.
    img

  • If the LED Side Strip does not show a BLUE breathing light pattern but a RED breathing light pattern after powering on for 5 seconds or after pressing the button multiple times, the boot has failed.
    img

Q: How can I troubleshoot issues with accessing Home Assistant?

If you’re having trouble accessing Home Assistant, here are a few steps to help troubleshoot:

  • Confirm that your iHost Ethernet port is working by verifying it connects to eWeLink CUBE and has an IP address.
  • Ensure the HA image is downloaded from our official GitHub and not from unofficial sources.
  • Check that the IP is reachable (ping test).
  • Use the Supervisor diagnostic interface (http://<HA_IP_or_HA_DOMAIN>:4357) to check if Supervisor is running.
  • If everything seems fine but you’re still facing issues, try rebooting the iHost and checking the brand and write speed of the TF card used.

Q: Can iHost boot Home Assistant from its internal storage, and can I add an SSD?

We’re working on a solution to flash Home Assistant directly onto the built-in eMMC, which is faster and more durable than a TF card. This feature will launch with our upcoming iHost hardware revision; stay tuned for details.

Q: After a power loss, does iHost require a button press to reboot into Home Assistant?

No, once you’ve successfully booted into Home Assistant over iHost, all subsequent restarts will automatically boot into HA without any button presses.

Q: I can’t switch back to eWeLink CUBE after using HA over iHost, what should I do?

If you are unable to switch back to the eWeLink CUBE system, press the Mute button multiple times immediately after powering on your iHost. The system should recognize this input, and if it doesn’t work the first time, try again.

Using Related

Q: Do devices paired under CUBEOS need to be re-added in Home Assistant, or is there a seamless migration path?

Starting in firmware v2.5.1, iHost supports exporting your Zigbee backup from CUBEOS and restoring it in Home Assistant, no need to re-pair devices. See our migration guide on GitHub:

image
image877×450 32 KB

Q: Does iHost support MQTT, Node-RED, and Zigbee2MQTT?

Yes, MQTT and Zigbee2MQTT work out of the box. Although Node-RED initially lacked 32-bit support, we’ve now released a 32-bit Node-RED add-on that runs smoothly on iHost.

Q: How do I seamlessly migrate my existing Home Assistant setup to iHost?

Simply upload your Home Assistant backup file to iHost’s HA environment, just make sure you’re running HA over iHost v15.2.1 or later for full compatibility.

Q: Why can’t I upgrade OTA from version 14.1 to 15.2.1?

This is a known limitation: v14.1 cannot upgrade directly to 15.x due to a porting issue. To work around it, follow these steps:

  1. In HA go to Settings → System → Backups → Backup Now and save your data.
  2. Download the HA over iHost v15.2.1 image and flash it to your TF card.
  3. Boot iHost from that card, wait for the dashboard to appear, then restore your backup.

Device Compatibility Related

Q: Which Zigbee devices are compatible with HA over iHost?

Zigbee support on iHost is provided via the Zigbee2MQTT add-on or the ZHA integration, so compatibility depends on those projects. In practice, any device supported by Zigbee2MQTT or ZHA will work seamlessly on iHost.

Network Related

Q: After installing HA over iHost, do I have to use Ethernet?

No, you can switch to Wi-Fi once HA is installed. However, we don’t recommend using Wi-Fi as your primary connection because signal instability may disrupt normal Home Assistant functionality. For the most reliable experience, keep your iHost on Ethernet.

Q: Will the Ethernet port work if it was damaged previously by flashing other HA images?

Unfortunately, if the Ethernet port was damaged due to previous flashing methods (e.g., opening the device and using a button to enter flashing mode), the damage is irreversible. This hardware issue is not covered under warranty, and we advise against any modifications that could void the warranty.

Warranty

Q: Will the Ethernet port work if it was damaged previously by flashing other HA images?

Unfortunately, if the Ethernet port was damaged due to previous flashing methods (e.g., opening the device and using a button to enter flashing mode), the damage is irreversible. This hardware issue is not covered under warranty, and we advise against any modifications that could void the warranty.

2 Likes
3

Oh, sure, the majority works. Some might even say the vast majority. But then, just when you start feeling confident, reality sneaks up and reminds you that quirks are apparently an optional feature. How about SNZB-03P and ZBMINIR2? Well, they seem to have missed the proper quirks.

4

I have tried using the SNZB-03P with HA over iHost, and it works as expected. As for the ZBMINIR2, I have not tested it yet. Could you please provide me with specific details regarding the issues you encountered? Thank you very much!

image
image1258×962 86.9 KB

5

Let me explain. The main issue is that the SNZB-03P “introduces itself” in ZHA as both an eWeLink and Sonoff device simultaneously. When using the quirk from the HA forum, we have, for example, two entities handling the same function: number.ewelink_snzb_03p_presence_detection_timeout and number.sonoff_motion_sensor_presence_detection_timeout. This can be seen in the attached screenshot.

image
image1023×540 56.8 KB

There is also the entity sensor.ewelink_snzb_03p_last_illumination_state, and its purpose is unclear. More information about the SNZB-03P quirk can be found on this GitHub forum.

If we do not use the ZHA quirk as in your example, we encounter the eWeLink SNZB-03P and Occupancy entities. The purpose of the first one is not obvious. Configuration of the Presence Detection Timeout parameter is not possible. Therefore, support exists but is incomplete, based mostly on the basic Zigbee 3.0 specification.

6

@jam3 This is an issue with SONOFF SNZB-03P device, not HA over iHost or Zigbee2MQTT. I will contact our product manager who is in charge of SNZB-03P. We will see what he will say about it.

7

Got it. Thanks a lot.

8

@jam3 Hi, after consulting with our R&D team, we would like to inform you that our current development resources are primarily allocated to other projects, resulting in a lower priority for the ZHA integration of SNZB-03P.

Additionally, as you noted, a developer/Geek has already provided a functional quirk for SNZB-03P implementation. Our preliminary testing indicates satisfactory performance. Nice work!
Regarding the Last illumination State feature, please be aware of the following considerations:

  1. Updates only occur upon motion detection (per firmware logic).

  2. When configuring automations in Home Assistant, Last illumination State must be searched and selected in the Entity

For detailed instructions on quirk installation, please refer to the following link. This may take a few minutes. Zigbee Guide: How-to add/setup local custom ZHA Device Handlers (also known as ”quirks”) in the ZHA integration - Community Guides - Home Assistant Community

image
image723×626 25.8 KB

9

Classic eWeLink, always chasing the next big thing while leaving pesky problems simmering on the back burner. Will I ever witness a product hitting the shelves that’s actually polished and ready to go? Because this frantic “rush it out, figure it out later” approach has been flopping for months. Time for a rethink, don’t you think?

Satisfactory performance? I’m not sure where your optimism comes from, but you clearly haven’t carefully read the discussion about the difficulties in developing a quirk for this product. For a developer/Geek, it works, but the experience feels more like trying to move your hand freely while it’s stuck in a vise.

Exactly! What the heck is this thing even supposed to do? I can configure this in Home Assistant with my eyes closed, but figuring out what it’s actually for? That’s the real mystery, and I’m not alone. Dozens of HA forum users are scratching their heads too. So, dear eWeLink team, do you hold the sacred knowledge? If so, kindly bestow upon us your wisdom.

I’ll be sarcastic, fair warning. Do you really think I’d be asking all these questions if I didn’t already know how to configure quirks in HA? You acknowledge that fact, yet still redirect me to the Community Guides. A bit of a paradox, wouldn’t you say?

10

Set up automation like this, and you can turn on your lights only when motion is detected in a dark environment(at night or rainy days). Different software platforms may have varying interaction methods to set up automations.

86D61E3A-48B3-4937-B6A7-6E1DE3544A39
86D61E3A-48B3-4937-B6A7-6E1DE3544A391161×895 26 KB

11

Hello,

thank you for your response and for sharing feedback from your R&D team.

I would like to clarify a few points based on my own long-term observations. I have been actively using and analyzing the SNZB-03P with Home Assistant (ZHA) over the course of several weeks, monitoring its behavior in real daily usage scenarios. The custom quirk I developed is a direct result of these observations, not short-term testing or theoretical assumptions.

  1. Dual exposure (eWeLink + Sonoff)

Through repeated testing, it is clear that the SNZB-03P introduces itself simultaneously as both an eWeLink and a Sonoff device, exposing:

  • standard Zigbee 3.0 clusters (e.g. OccupancySensing), and
  • vendor-specific clusters used by the firmware.

ZHA treats these as independent capability paths, which leads to duplicated entities (for example, two Presence Detection Timeout sliders referring to the same functional behavior). This is not a Home Assistant issue but a direct consequence of the firmware design.

  1. Motion timeout behavior

The firmware exposes both:

  • the standard OccupancySensing timeout, and
  • a vendor-specific motion timeout implementation.

In practice, these parameters are loosely synchronized inside the device, which explains why both sliders often appear to work simultaneously. This duplication is confusing for users but fully consistent with the firmware behavior observed over time.

  1. Last Illumination State

Based on extended observation:
Last Illumination State is a binary day/night–style threshold, not a lux measurement.

  • it is evaluated only at the moment motion is detected,
  • it is not updated continuously.

This behavior matches the internal firmware logic. The feature itself is valid, but its purpose is insufficiently documented, which understandably leads to confusion.

  1. ZHA support and priority

I understand your note that ZHA integration is currently a lower development priority. However, this is somewhat difficult to reconcile with the fact that SNZB-03P is marketed as working with Home Assistant.

From a user perspective, the expectation is that the device should behave correctly and consistently regardless of whether Home Assistant is used via ZHA or Zigbee2MQTT. Both are mainstream Zigbee stacks within the HA ecosystem, not niche solutions.

  1. Custom quirk status

Taking all of the above into account, I developed a stabilized ZHA quirk that:

  • respects the existing firmware behavior rather than attempting to override it,
  • avoids duplicated or misleading entities,
  • keeps standard Occupancy behavior intact,
  • exposes the motion timeout in a predictable way,
  • correctly presents Last Illumination State as a contextual flag.

This quirk has been working reliably in daily use. I would be happy to share this quirk with your team for:

  • review,
  • internal reference,
  • or optional redistribution to help other SNZB-03P users.

Here’s the quirk: SNZB-03P.py

@MichaelLearnsToCode @Leung Thank you again for the discussion. I believe clearer documentation of the firmware behavior — especially regarding duplicated clusters and illumination logic — would significantly improve the user experience across both ZHA and Z2M.

Best regards

1 Like