Glad to see that. Bravo and thank you for your work
1 Like
show! so the operating sys is updated from the official repositories, very good and good work. for ihost 2gb ram cpu thermal issue?
HAOS itself runs fine with 2GB RAM, I though the cpu might be an issue on this model, however I have been testing it and mostly it seems ok. Maybe slower install addons, and ESPHome would really stress it, but otherwise performance seems ok.
No support for thermals yetâŚ
Hi @Alexie, @hiconkong,
I am trying to get sound working at the moment. Kernel is loading alsa drivers and sound card is detected, however I get no audio output. Audio input (Mic) is working if not a bit noisy. Any ideas why output is not working? what channel is the Speaker connected too?
Card #0
Name: alsa_card.platform-rk809-sound
Driver: module-alsa-card.c
Owner Module: 6
Properties:
alsa.card = "1"
alsa.card_name = "Analog RK809"
alsa.long_card_name = "Analog RK809"
device.bus_path = "platform-rk809-sound"
sysfs.path = "/devices/platform/rk809-sound/sound/card1"
device.form_factor = "internal"
device.string = "1"
device.description = "Built-in Audio"
module-udev-detect.discovered = "1"
device.icon_name = "audio-card"
Profiles:
input:stereo-fallback: Stereo Input (sinks: 0, sources: 1, priority: 51, available: yes)
output:stereo-fallback: Stereo Output (sinks: 1, sources: 0, priority: 5100, available: yes)
output:stereo-fallback+input:stereo-fallback: Stereo Output + Stereo Input (sinks: 1, sources: 1, priority: 5151, available: yes)
off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
Active Profile: output:stereo-fallback+input:stereo-fallback
Ports:
analog-input: Analog Input (type: Analog, priority: 10000, latency offset: 0 usec, availability unknown)
Part of profile(s): input:stereo-fallback, output:stereo-fallback+input:stereo-fallback
analog-output: Analog Output (type: Analog, priority: 9900, latency offset: 0 usec, availability unknown)
Part of profile(s): output:stereo-fallback, output:stereo-fallback+input:stereo-fallback
Sink Input #3
Driver: protocol-native.c
Owner Module: 10
Client: 24
Sink: 0
Sample Specification: s16le 2ch 8000Hz
Channel Map: front-left,front-right
Format: pcm, format.sample_format = "\"s16le\"" format.rate = "8000" format.channels = "2" format.channel_map = "\"front-left,front-right\""
Corked: no
Mute: no
Volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
balance 0.00
Buffer Latency: 500000 usec
Sink Latency: 0 usec
Resample method: speex-float-1
Properties:
media.name = "ALSA Playback"
application.name = "ALSA plug-in [aplay]"
native-protocol.peer = "UNIX socket client"
native-protocol.version = "35"
application.process.id = "738"
application.process.user = "root"
application.process.host = "a0d7b954-ssh"
application.process.binary = "aplay"
application.language = "C"
module-stream-restore.id = "sink-input-by-application-name:ALSA plug-in [aplay]"
firstly, make sure your external speakers are working.
and then pls exec amixer -c 0 contents to display all card0 available devices.
What do you mean external speakers? there is no headphone jack on the iHost only the internal speaker.
I canât select a specific card with amixer, possibly related to pulseadudio being active (where card0 is the default), but here is the output:
~ amixer contents
numid=4,iface=MIXER,name='Master Playback Switch'
; type=BOOLEAN,access=rw------,values=1
: values=on
numid=3,iface=MIXER,name='Master Playback Volume'
; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1
: values=65536,65536
numid=2,iface=MIXER,name='Capture Switch'
; type=BOOLEAN,access=rw------,values=1
: values=on
numid=1,iface=MIXER,name='Capture Volume'
; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1
: values=65536,65536
as you see below. We always set numid=1 Item#2 SPK as our media output and it works. Iâm not very familiar with pluseaudio, but it should also have corresponding settings.
amixer contents
numid=5,iface=MIXER,name='Master Playback Volume'
; type=INTEGER,access=rw---RW-,values=2,min=0,max=100,step=0
: values=50,50
| dBscale-min=-30.00dB,step=0.30dB,mute=0
numid=2,iface=MIXER,name='Capture MIC Path'
; type=ENUMERATED,access=rw------,values=1,items=4
; Item #0 'MIC OFF'
; Item #1 'Main Mic'
; Item #2 'Hands Free Mic'
; Item #3 'BT Sco Mic'
: values=0
numid=1,iface=MIXER,name='Playback Path'
; type=ENUMERATED,access=rw------,values=1,items=11
; Item #0 'OFF'
; Item #1 'RCV'
; Item #2 'SPK'
; Item #3 'HP'
; Item #4 'HP_NO_MIC'
; Item #5 'BT'
; Item #6 'SPK_HP'
; Item #7 'RING_SPK'
; Item #8 'RING_HP'
; Item #9 'RING_HP_NO_MIC'
; Item #10 'RING_SPK_HP'
: values=2
numid=3,iface=MIXER,name='Digital Capture Volume'
; type=INTEGER,access=rw---RW-,values=2,min=0,max=120,step=0
: values=72,72
| dBscale-min=-30.00dB,step=0.41dB,mute=0
After the investigation and analysis of the ethernet malfunction issue, we found that there is a problem with the configuration in this project (0023-dts-pmu_io_domain-set-wifi-to-3.3v.patch). This incorrect voltage domain configuration can damage the IO ports of the RV1126ďźRV1109ďź during use, preventing them from outputting proper voltage or data waveforms. This hardware damage issue has been verified and confirmed on the faulty devices received. Rockchipâs official response also indicates that such a misconfiguration carries the risk of causing this damage - as clearly warned in the official Datasheet, advising users to avoid incorrect voltage domain parameters to prevent irreversible hardware damage. Once the IO ports are damaged, they can no longer communicate normally with the external Ethernet chip, which results in the failure of your Ethernet functionality. Even if you switch back to the native system at this point, your hardware has already been damaged by running the system with the incorrect voltage configuration. We have asked @darkxst to correct the pmu_io_domains Ethernet configuration ASAP.
For all the iHost users who would like to run the Home Assistant OS on iHost, please note this potential risk, do not run Home Assistant OS on iHost until this configuration has been corrected to avoid the Ethernet malfunction and hardware damage risk.
1 Like
With all due respect to @darkxst (chapeau bas! 
) and genuine admiration for his design and determination, I think to myself that this is a bit like adapting a bike to ride on water. Of course, there are such designs, some very successful. Usually, though, a boat or a dinghy is a better option. But there are, after all, extremely imaginative tinkerers.
Iâve followed the whole thread and have the perhaps mistaken impression that eWeLink staff are doing their best to help without helping. I also think the stuff should be embarrassed by the fact that one guy has achieved more in a relatively short time than their entire team has since the launch of iHost. The situation is bizarre. eWeLink defends like independence the âsecrecyâ of their solutions and doesnât allow independent developers to get access to the code so they can offer alternative solutions to enthusiasts. In turn, to those who were hoping for a mature âexperience out of the boxâ solution, it is unable to offer stable and well-functioning software, condemning them to constant troubleshooting. Worse still, new versions of the software bring new problems. In this way, robust, well conceived and designed hardware is systematically crippled. Sonoff marketing concocts imaginary stories proclaiming the capabilities of products that do not exist or will one day exist. And when those capabilities are finally there, they are like a mother-in-law falling into an abyss in your dream car. You have mixed feelings.
In conclusion, what is the harm in opening up and building a community of enthusiasts around eWeLink/Sonoff? After all, in parallel, you can develop your own system/platform and give supporters âout of the boxâ a mature, functional solution, using the experience of the community. For now you have sunk iHost, both NSPanels or SNZB-06P because you canât take a grip on yourselves. I wrote this not because I donât like you, guys. On the contrary. Best of luck.
3 Likes