Hi, just tested this script on xiaomi 12.1 pro and it works well, thank you for your time on this project!
maybe it is possible to add more functionality like var treshold and custom wake word, because in my language or pronunciation sometimes is dificult to trigger 
but overall looks promising and maybe it is posible to add continuos conversation if assistant end with question? because then you need to use wake word again
See my replies above for how to setup the threshold and custom wake word.
The continuous conversation should be possible, but would be handled in your HA server, not the voice satellite.
Just wanted to say THANK you for this fix. I assume the SIGSYS fault is due to a call being blocked by the API in Android 10-11 due to that whitelist issue that wasnāt handled til Android 12.
The call doesnāt system to be vital as itās possible to continue, however by default the python script will exit with a fatal error. Adding the fault handler causes it to log the error but continue execution. Tested this on two devices with Android 10 and adding those lines does indeed fix the issue and allows the script to run.
AFAIK for Android 10 and 11, the best solution is to just add those lines to the main.py for Wyoming-Satellite. It should not hurt anything on newer devices as itās just a fault handler and the newer Android releases will not even trigger the fault, there should be no real downside to adding this to the main.py file as a workaround.
Everything works just great, thanks for the hard work.
To anyone getting a module initialization failure due to āpactl load-module-sles-sourceāā¦
First and foremost:
At this point, you can just reboot or manually test the script by running ./termux/boot/wyoming-satellite
If the issue persists then you have a bigger issue, this happens a lot on Huawei tablets due to their security measures implemented into the firmware/ROM/
For Huawei / Honor / HonorPad devices with āMagic OSā using the later Android versions aka Android 13, there is a fix:
Magic OS aka Huawei/Honor Pad devices have an extra security manager, and it doesnāt handle standard Android OS permission calls correctly when it comes to the Microphone. Steps 4-7 fix that to allow proper Microphone access. Steps 1-3 are because for whatever reason if we try to load the module with pulseaudio at boot, the OS/ROM blocks the request always. If we just delay it, load aaudiosink by default and then let the wyoming-satellite script handle loading the module at runtime, it works fine.
TLDR: Edit the default.pa file, uncomment the aaudio sink, comment out the module-sles, fix the microphone settings in privacy manager, launch the wyoming-satellite script again.
Tested + works fine on HonorPad X9 with Android 13, stock.
Did you try setting this up with a custom wake word?
I saw something earlier in the thread regarding the version numbers, but on the other hand not all tflite files appear to have one. I am also unsure if the right way to go is to place my own tflite file under the ābuild-inā directory.
On the HA side, there is a special directory for such purposes: āshare\openwakewordā, so perhaps someone has discovered an equivalent to this directory?
For others: Same directory works, as long as you stick a version number as pointed out before. So this works not only for the built-in pack, but also in general.
Another interesting find: if the initial audio prompt is even slightly too long, it can prevent wake word from triggering. Device: Lenovo TS, Lineage 15.1 Android 8.1.
First, thanks for all of the great work. I was able to use your description and scripts to get this working on a Fire HD 8 tablet. However, when I restart the tablet the mic is not active and the wake word does not work.
It appears that the boot script is running as all of the processes are running when I do a ps -aux. Also, I can verify that when I restart Termux and run the boot script manually, everything works (the mic is active and the wake word works).
Iām also running HA in Fully Kiosk which is also set to automatically start on startup.
Could there be a timing issue on startup?
I would appreciate it if you could clarify which file the wyoming-wakeword service file is, what directory it is in, and what threshold value worked well for you with the āHey Jarvisā wakeword.
Thanks.
Is this still working for you on Home Assistant 2025.04? I tried reinstalling everything and after the wakeword is detected the satellite seems to freeze, no end sound and no answer.
Still working for me, though I am now on 2025.4.1ā¦
I did have to reboot the tablet after the upgrade of Home Assistant (might have been when I first did 2025.4)
I have also recently updated the Satellite by re-running the install script, that was before 2025.4 was releasedā¦
Cheers.
I only tried the āhey_jarvisā wake word. Didnāt explore down the road of setting up a completely custom wakeword
Hi @randomuser123 . My View Assist project provides visual feedback for Assist voice. I would like to use the Wyoming device state device to use a trigger for keeping a view active while the STT response is still happening. What would happen would be if the state changes to āRespondingā to switch views and then keep the view until the state changes from āRespondingā. The issue Iām seeing is that the Termux Wyoming devices are often stuck in the āRespondingā state so I cannot use this as intended. Iāve asked another user if they are stuck with that state and they confirmed that they are as well. I am assuming this is happening to all.
Can you tell me if you are using the current version of Wyoming or is this an older version? Iām trying to figure out if this bug may have been fixed in a later version or if this should be reported as an issue wherever the code you are using originates.
Anyone have any ideas on a fix?
It appears that this was fixed in version 1.4.1 . I managed to get that installed by changing to the wyoming-satellite directory and doing a git pull to get the latest.
Can someone advise on the best way to update things short of what I did?
Has anyone gotten Wyoming working on Termux on boot working on Android 11+?
It looks like Android 11 changed behavior with respect to apps launching in the background asking for microphone permissions.
When I try to launch wyoming on termux on boot, I get:
04-18 17:35:14.786 1798 2301 W ActivityManager: Foreground service started from background can not have location/camera/microphone access: service com.termux/.app.TermuxService
Based on Background tasks overview | Background work | Android Developers it seems like this changed was introduced in Android ~11.
Any thoughts or suggestions on using this via Home Assistant Cloud? That is, could HASS_URL set to a Nabu Casa remote url, with a HASS_TOKEN work to use a device outside the HA LAN set up?
My goal is to set up a device I can travel with, and use voice capabilities regardless of the network Iām connected to.
Iāve got Remote Assist Display working great to show my dashboards, and looking for some solution to add voice capabilities without requiring a VPN.
Yes, in theory as long as the SSL certs are valid, it should just work if you set the HASS_URL to the remote url.
Should there be certs other than the cloud URL? That is, assuming my Remote Assist Display instance is connection seamlessly via the cloud URL, is there something cert related I need to implement locally in order to get your wyoming stuff working via that URL?
Also, Iām unclear what IP I would enter in the Wyoming integration on the HA side to establish the client. The transient LAN IP would be an issue, I assume, with a TSV that travels from place to place, network to network, no?
Actually, hereās a question. How might I go about testing events locally, on-device? Triggering an Event. The wyoming-openwakeword log shows the wake word recognized, and the wyoming-satellite and wyoming-events logs show nothing following the wake word being recognized? Can I trigger an event locally on wake word being acknowledged? This would get me closer to figuring this out without having to bother you. 
While the event forwarder would work, you would need to figure out how to securely connect to the satellite over the internetā¦ As there is no authentication in Wyoming it would be rather insecure.
What Iāve wrote isnāt a proxy for Wyoming - you are probably better off setting up zerotier or tailscale on your device and HA host, and then connecting via IP.
Seems this is where Iām getting stuck tooā¦ If I launch wyoming-satellite manually it works and detects the wake word, but fails to run on boot.
Does anyone have any suggestions how to get around this?
If Iām understanding you, a long-lived access token as hass-token and the Home Assistant Remote UI Remote Access URL as hass-url does exactly this. Am I misunderstanding something?
Do you have suggestions for how I could test your implementation locally before attempting the Home Assistant connection? That is, trigger an event via wake word just to see it appear in the local logs on termux? Iād like to test the full local flow first.
That would be super helpful! Thanks for creating this!