I think.it is worthy porting the current Ihost as well due to several.reasons:
It will assure, and convey a message of long term.support of Sonoff products and help.build loyalty to Ihost and Sonoff, in general.t.
It will support more adaptation.of Ihost hardware for HA. My assumption is that the HA32 bit sunset announcement might have slowed down potential.procurement of the hardware. For example, I was also planning to.purchase an additional.Ihost for more projects.but I am.now waiting for the new hardware.
I recently checked online, there was a shortage of HA green.
Ihost is still a very capable hardware, well built and comes bundled with what other hardware sells separately.
There may be a risk.of the current Ihost eating a a part of the new Ihost market. The differentiation.can.be on the pricing.
Thank you very much for your feedback. These are good points.
But we really can’t give any promises right now. As you can see, we released iHost three years ago, but we have never promised that iHost will always get updates of eWeLink CUBE OS for like 3 years, 5 years, or 8 years, despite the fact that we are continuing developing eWeLink CUBE OS.
What we can promise is that iHost has been open sourced, and it will stay this way. Anyone could build a Linux distribution for iHost, or port other Linux OS to iHost, like we did with HA over iHost.
Btw. Are you planning to.push software update for the Sonoff Hub Pro to rnable it to be used as a router? The NS Panel.Pro-like firmware.
“Sonoff Hub Pro”? You mean SONOFF Zigbee-Bridge Pro? I am working on iHost (and will probably on ZBBridge-U, NSPanel Pro), so I don’t know the roadmap for other SONOFF products. But I know the open source project Tasmota supports Zigbee-Bridge Pro. So it should be possible to flash Zigbee Router firmware into Zigbee-Bridge Pro.
Please note: SONOFF Zigbee-Bridge Pro is using TI CC2652p chip instead of Silicon Labs MG21.
We have released eWeLink-Remote Gateway add-on v0.2.0. This time, eWeLink-Remote Gateway will not just working on HA over iHost, but also on other Home Assistant OS running on ARM64 and AMD64 devices.
Here is release note:
Add-on adds support for x64 architecture
Optimizes the default name display of the eWeLink-Remote sub-device entity
After the eWeLink-Remote sub-device entity name is changed, the entity name associated in the automation will change accordingly (after the entity name is changed, the automation can run normally but the UI display will change to Unknown trigger. After re-saving, the UI display can return to normal)
The v1.1.0 add-on is available in armv7, aarch64, amd64 architecture, so you can use it not only on iHost, but also on other HAOS installations. It supports flashing Zigbee Coordinator, Thead, Multiprotocol, 3rd-party firmware onto SONOFF ZBDongle-E (Silicon Labs MG21 chip), and Zigbee Coordinator, 3rd-party firmware on to SONOFF ZBDongle-P (TI CC2652p chip).
Please take your time to try it out, and tell us how do you like it.
Hi @alyusuph thank you for trying out the SONOFF Dongle Flasher add-on.
The URL ghcr.io/ihost-open-source-project/hassio-ihost-sonoff-dongle-flasher-aarch64:1.1.0 itself is correct. You can verify it by visiting the URL in your browser.
Hi, we have done an internal test and also discussed about the issue. We believe this is a bug related to HA itself.
The SoC of HA Green is RK3566, an 64-bit aarch64 SoC. SONOFF Dongle Flasher add-on before version v1.1.0 is only available in 32-bit armhf architecture. In version v1.1.0 SONOFF Dongle Flasher add-on is also available in aarch64 and amd64 architecture. So, whether an update for SONOFF Dongle Flasher v1.0.2 (32-bit) on HA Green should be v1.1.0 of 32-bit armhf or v1.1.0 of 64-bit aarch64, HA Green chose v1.1.0 of 64-bit aarch64, but it messed up.
A temporary solution to this issue, could be that uninstall the old v1.0.2 version (32-bit) first, and then install the latest v1.1.0 version (64-bit). Please let me know if it solves the issue for you.
I was able to install the updates successfully withoujt ejecting the Dongle. The only problem.is that when I tried torun the process again, after updating, the firmware, with the intention of checking the updated firmwareversion, i lost ZHA device onnections. I was only able to restore ZHA with a backup..
Using SONOFF Dongle Flasher Add-on to manage MG21 chip firmware will stop ZHA and Z2M from working because Dongle Flasher Add-on will take over the UART interface of MG21.
After updating firmware, you should be able to use ZHA by restarting Home Assistant Core, or to use Z2M by restarting Z2M add-on.
If you met issue after updating firmware, it’s most likely caused by imcompatible version between ZHA/Z2M and the firmware. For example, if you update MG21 firmware to Zigbee Coordinator 7.4.x/8.0.x, you will need to change Z2M driver from ezsp to ember.
Hi, in instruction of using HA you explained that wifi can be also used for connection. On my ihost HA instalation there is no wlan recognised. Did anyone suceedd to use wifi instead of lan.
If you don’t see wlan0 on page Settings -> System -> Network -> Configure network interfaces, then you can verify whether the Wi-Fi adapter is broken by:
Boot into eWeLink CUBE OS (the internal eMMC, not the HA on the TF card).
In the Web interface of eWeLink CUBE OS, goto page Pilot Features -> Wi-Fi
Enable Wi-Fi
Goto page Settings, you should see WiFi: Not connected > under Features. Click on Not connected > link, you will see Wi-Fi SSIDs detected by CUBE OS.
If the Wi-Fi adapter works on eWeLink CUBE OS, then it should also work on HA over iHost. If the Wi-Fi adapter doesn’t work on eWeLink CUBE OS, then it probably is broken. But you can still post the errors you encountered so we may diagnose it.
The following screenshots are for your referrence.
