So, I try to run a script at HA start, to change (default) audio output (the audio card will stay the same). It work perfectly from terminal (core-ssh), but isn’t doing anything from automation, nor from developer tools/services. No errors there!
First i thought that the script will be useless until audio container will start; but even after this, the result will be the same.
After some days of reading forums and so, i gave up… maybe someone could help and correct me.
The script: (ch_audio.sh; chmod a+x; the third line is just for redundancy; last line is there only for debugging)
The ssh addon and HA are separate docker containers. A script that works while ssh’ed won’t necessarily work from a shell command as each docker container has different things installed. In this case the problem is the HA CLI is unavailable in the HA container, it’s only in the ssh container.
To do what you want your shell command would need to ssh to the ssh addon and run the script there. See the linked guide for how to set that up
tried various options, bash, sh, . , no action!
now, i tried directly putting commands into shell_command. no action, also no error in logbook
put a single line in shell_command - /bin/touch /tmp/test … no action. no log. no /tmp/test file created.
(should i mention i use HAOS x86-64?)
@ [CentralCommand] - many thanks, i’ll study how to do this right now. thought, anyway, that /tmp is in overlay fs,
ok after reading CentralCommand indications, i found that the command should be, in my case,
ssh -l root ha.local -p 22222 -i /config/.ssh/id_rsa '. /mnt/data/supervisor/homeassistant/ch_audio.sh'
using ssh back to host (as ssh-core is on “host” network", and hassio_audio isn’t accessible for ssh, so no direct commands).
and the script will be, accordingly:
A docker container on the host network is just as accessible as the host itself? Did you try just using port 22 with the same url?
EDIT: oh wait, you’re doing a docker exec into the audio plugin to change something, that’s why you need the host shell. Well alternatively you can use the ssh addon in the community repo with protection mode disabled as that has docker access. Although bear in mind any changes you make in the audio plugin container are not persistent. The audio container is removed by supervisor every time it restarts, is updated or the system is rebooted. And then it will be remade from the image without your changes.
no, you’re right, never thought to login in :22 (ssh_core), there will be also all commands necessary.
i used official ssh addon, that’s why i didn’t even tried.
this approach, using ssh to host, is working for any restart, files are in persistent locations , as in your instructions.
i tried, before this, to use a udev approach, but required commands are in containers not even started at that time!
i also used some edits (to set samplerates) on 3 /mnt/data/docker/overlay2/xxxxxx/diff/etc/pulse/daemon.conf files, but i don’t think the’ll survive an update (though i don’t know yet how to identify exactly which one is; one is from webtop-kde, one from hassio_audio, the last one has a lot of alsa files, probably also from hassio_addon)
these are inelegant, but working solutions.