It seems that you can now manage volumes and the files within them through file management - with the latest 1.7.0 version:
Yes, I have HomeAssistant (Docker) running + HACS. With Filebrowser I have access to the configuration folder and files. It looks pretty well now. One thing missing though, is direct access to the native Zigbee hub. At the moment Zigbee devices connected to the iHost need to go through Homebridge. Also the list of supported Zigbee devices is small, but growing.
Everything works so far. But I would love to see an ‘open’ iHost version running Home Assistant proper.
1 Like
How did you installed HACS on HA docker inside iHost?
This might be helpful:
Download the .zip version of HACS. Once you have Filebrowser access to the config folder, you can unpack the HACS zip file and upload it to the custom_components folder.
1 Like
Is the bootloader on the Zigbee chip in this locked up requiring signed firmware (similar to ZBBridge etc)
Also see the somewhat related question here → Integration for Zigbee-access on Sonoff iHost
It is a good question but if it requires a signed firmware image to update the Silicon Labs EFR32MG21 SoC (Zigbee/Thread radio chip) then I assume that ITead/Sonoff are probably using the same chip model, pins mapping, and the very same signature as they used for Sonoff ZBBridge and ZB-GW03 (Eachen eWeLink ZbBridge Pro Ethernet Zigbee Gateway), as they would at least be able to use the exact same signed EmberZNet Zigbee NCP firmware image available from xsp1989 and Tasmota. Regardless I would believe that I can presume that ITead today currently ships Sonoff iHost with EmberZNet 6.10.3 based Zigbee NCP firmware image by default, and if so the Zigbee can probably be tested as-is without modification as long as hack the iHost operating-system for serial access to the Zigbee SoC (or ITead/Sonoff opens up serial access to the Zigbee SoC), or what do you think?
Yes I would expect that xsp1989 signed firmwares will probably work, if the bootloader is not locked then zb-gw04 firmwares including multi-pan should work. Anything based on the SM011 reference designs likely has the same pinouts.
I wouldnt expect so, more likely to be a v8 firmware such as 6.7.x.
If anyone is able to gain access to the serial port, I would be interested to see a probe of bootloader and firmware versions.
I not real interested in iHost OS myself, wondering how feasible it will be to get HAOS running though.
Yeah, same here, and “Dusun DSGW-210-HA” hardware also looks interesting for Home Assistant OS → Dusun "DSGW-210-HA" Zigbee, Thread, Z-Wave, and BLE gateway appliance pre-installed with Home Assistant?
Firefly have a Debian 10 image that will likely work with the iHost. Not sure how well HA supervised would work with that older Debian though?
1 Like
These only support Debian + Supervised currently, porting HAOS would likely be similar effort to the iHost.
After I upgraded to the latest version of ihost’s software, I found that USB worked. I connected Sonoff zigbee dongle-E to the USB port and chose to mount it when running HA’s docker, and now I can successfully add various zigbee devices in HA using ZHA!
1 Like
This is a debian image leaked from the official, open SSH, the image is loaded with many tools and software :
More information about the content of this image :
If this is a full linux, then a standalone installation of the home assistant on it should be feasible?
I don’t want to overwrite the native system software just yet - I don’t want to brick it up, so I’m still trying to install HA on docker, and I’m glad that the latest version of the software already supports Docker for mounting USB devices. Therefore, through dongle, I can normally use Zigbee2Mqtt or ZHA to access various zigbee devices
1 Like
That is a buildroot based distro (which does not have anything to do with Debian), so you can run HA Core docker on it, but not HA supervised. Firefly do offer a Debian 10 image (linked previously), that should probably boot ok on iHost.
In theory you should be able to boot that Linux distro from an SD card (without overwriting native system). You probably need to enter maskROM mode first though.
I’ve been looking at building HAOS for this device and have some good news on that front.
Edgeble AI have kindly been hard at work upstreaming support for the RV1126 SoC. Their device the Neu2 is very similar hardware wise to the iHost, with a few minor differences such as different RTC and Wifi Chips. Support is available in upstream u-boot 2023.04 and kernel 6.3 (with some further bits due to land in 6.6). This should make a HAOS build entirely feasible, which otherwise would have been much more difficult as Rockchip are rather unfriendly to the DIY market. Access to SDK’s and datasheets is basically reliant on leaked copies unless you have a business license with Rockchip!
Edgeble patches are here (but per above most are upstreamed already):
2 Likes
Thank you for your kind and detailed answers . Since I don’t know much about linux, I still don’t quite understand what this “buildroot based distro” is…
If they can install the Supervisor on this “buildroot based distro”, does that mean that this “buildroot based distro” is like a HAOS? Or, what kind of information and data is needed to build a HAOS?
Buildroot is its own kind of distro builder, it is used for building highly custom/optimised images for embedded systems. As such it doesnt include many of the normal tools like the usual package management tools such as Debian apt-get and friends.
Supervised is only supported to be installed on Debian base system. Perhaps could manually cobble together all the required parts, but that wouldnt be easy or likely stable. So the only real option on that distro is HA Core installation (which would obviously not be able to use add-ons etc)
Now to perhaps confuse you, HAOS is also built using buildroot, customised at build time with all packages required to run HA and the supervisor etc. Porting HAOS to a new board, requires customising configs for u-boot, kernel, drivers etc specific to that board that are then used to build the new image. Given the upstream support, that shouldnt be too bad though.
2 Likes
This is not ideal given you have no control over the onboard Zigbee radio and channel. Interference between the two radios is quite possible if your not careful!
2 Likes
Yes. I also thought about installing HA on that distro after the refresh and directly using zigbee function of onboard,but I found that distro has no GUI and can only operate docker and other functions through command line,which is beyond my ability. I couldnot install HA Core on such a system and have HA coer communicate with zigbee modules by just coding…I can only use the mouse to click
I just probed the Zigbee chip in the iHost using the test pads. As expected its running an older EZSP v8. I’ve not seen that bootloader version before on the coolkit modules, so not sure if requires signed images or not yet.
INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
INFO Launched application from bootloader
INFO Detected bootloader version '1.A.3' (1.3)
INFO Probing ApplicationType.EZSP at 115200 baud
INFO Detected ApplicationType.EZSP, version '6.7.10.0 build 423' (6.7.10.0.423) at 115200 baudrate (bootloader baudrate 115200)
It also uses the same standard pinouts as most other devices with the SM-011 module (no hardware flow control ) so existing firmwares will work.
EDIT: I have flashed 6.10.7 onto it now, bootloader doesnt require signed firmware
EDIT2: Maybe surprising, but the stock OS also works fine with the updated ezsp 6.10.7 firmware.
3 Likes
This is great news. Eventhough it is pretty strange that we need to use a USB controller when it actually has Zigbee on board.
How did you configure the stick?