You could build your own homeassistant docker image with pianobar included.
I am new to docker (and home assistant) but am a software engineer who uses linux daily…
pianobar /is/ included in the docker image in so far as I can execute the command itself.
I /think/ this is what the linked post is trying to do for sshpass (get it into the path of the docker container).
I am likely incorrect though so can you help explain how modifying the container would work?
hmmm but something funky is going on. I went to see if I could just modify the component to read the user/password from configuration.
On my raspberry pi (prod) pianobar is available. However when running it in a docker from vscode on my desktop it is /not/ available.
what does “prod” mean?
sorry I am working on 2 different machines.
My raspberry pi is the one that is connected to everything in my house (prod). For some reason the docker container there has pianobar in /usr/bin
My desktop, where I’m playing around with the code for home assistant, the docker container vscode created does NOT have pianobar in /usr/bin even though its installed correctly
Hi @longinoa, welcome to the HA community. Using docker and having separate prod and test systems are a sensible way to develop your HA system, but you need to be cautious about certain aspects.
First you want to make sure your test system is representative of your prod environment to avoid you chasing down red herrings. the first thing is to make sure you are basing things on the same images and configuration - I use a private git repo to store my config in - that way I fiddle with code on my desktop, push it to the repo, fetch it to test and try it out before promoting it to prod.
I go a step further and make sure my test OS and docker is similar to prod, so I run a VirtualBox VM with ubuntu server on my desktop - that way my prod and test really do match each other. I also snapshot my test VM just after OS updates and Docker install, so it’s easy to dispose of any rubbish accumulated during tests.
So once you are sure that your test and prod systems are using the same stack AND the same config, then you have the joys of docker containers to deal with, but I’ll address that in a different post.
I hope this helps
In order to get something ‘into’ docker it has to go into the image - you can’t put something in at ‘runtime’ because that is totally transient. If you imagine Docker is as if you have to ‘compile’ the OS build, putting all files and packages into the image, then you can simply execute whatever is already there - maybe not the clearest analogy, but let me try to explain.
You use a Dockerfile to add things into the image, so they are available when you run the container. The previously linked example used apk to add a package. Here are some examples using COPY to get files into an image, and that’s one technique you can use for config files like for your pianobar, see more examples here
There is an alternative to creating your pianobar config in the folder and using the Dockerfile to COPY it in – to RUN the echo command and create the file from a heredoc, such as the example here.
In any case you need to get the file into the docker image before you run it, that is the way that docker works. And I do hope that you are using a docker-compose.yaml file to run your image, because that puts everything into a nice clear editable, version-controllable file.
Good luck!
This is great information, thanks for the thorough explanation!
I used the hassio-installer GitHub - home-assistant/supervised-installer: Installer for a generic Linux system to setup the docker the first time so I dont think I have a direct docker-compose.yaml file …
In playing around another option I found was to do this in __init__.py before attempting to startup the pianobar service.
But really at this point I’m wondering if its going to be better to either
As I mentioned in my first reply @longinoa I personally would plump for the option that makes my test as similar to my prod as reasonable. However quick and simple is always a handy alternative if you are still proving a concept.
I like Home Assistant on Docker as it’s quick and easy to try, retry – play around and unbreak again just by putting your config back to how it was (version control 
) so I would start by trying your third option out.
Even if you go for the first, do consider using docker-compose to string the whole thing together, as its much easier than running individual containers by hand. And if you get stuck you can paste your compose file into a post on this forum and others can see immediately what you are trying. And consider Portainer as a GUI for the whole thing too. If you want to see some examples check https://github.com/artmg/home-assistant-docker - but you don’t have to get that complicated - just chuck what you have on your run commands into a docker-compose and hack it til it works
Happy HAcking
I have been able to get this working.
As noted above, pianobar is included in the home-assistant docker image - at least as of current (108) versions. The only challenges are to get the pianobar config file into the container and sound to work.
I created a new directory on my host and mapped it into docker by adding a second volume in my docker-compose file. I also had to expose the sound devices so that apps inside the container have access to my sound card(s)
Here are the important additions to docker-compose.yml
volumes:
- '/etc/homeassistant/root:/root'
devices:
- /dev/snd
The volumes setting maps my host’s /etc/homeassistant/root directory into the container as root’s home directory. I then created the requisite pianobar config file.
$ cat /etc/homeassistant/root/.config/pianobar/config
password = XXXXX
user = [email protected]
I also had to create an .asoundrc file for ALSA to work. I have two sound cards in my host. YMMV.
$ cat /etc/homeassistant/root/.asoundrc
pcm.!default {
type hw
card 1
}
ctl.!default {
type hw
card 0
}
The only thing missing is volume control. The provided docker image doesn’t have alsa-utils, so no amixer to control volume. So this setup works nice if you’re plugging into a receiver/amp that has HA controllable volume. Mine doesn’t - I need my volume control on my HA server…
Hi vrazumihin,
I am jealous you have gotten this working. I have the same scenario as you (I believe) running on an RPI4. I am a bit new to RPI and command line so I am curious if you could clarify a few things for me.
Really appreciate your help!
Hi mstephens13 - sorry for the slow response.
~/.config/pianobar/config Since everything inside the docker container is running as the root user, this translates as /root/.config/pianobar/config Put the sub-directories and config file somewhere on your host (I put mine under /etc/homeassistant/root right next to my homeassistant configuration /etc/homeassistant/config) and then map that directory into the /root/ directory inside the container with the volumes:
- '/etc/homeassistant/root:/root'
If that doesn’t make sense, post your docker run command line and I can probably set it up for you (or come pretty close)
Just switched from venv to docker and I’ve managed to get pianobar working great inside the container, thanks vrazumihin for the docker-compse yaml, it even plays sounds! For whatever reason though the Pandora integration just vomits a bunch of python EOF errors and the HA log shows a long traceback whenever I attempt to power it on. I saw one other reference to this on github, but that post got no attention: pandora media player error · Issue #38051 · home-assistant/core · GitHub. I can knock over there too, but thought I’d refresh this thread as I bet a bunch of people are now using the Alpine containers and may be seeing the same thing I am. If you’ve solved it, would love to hear how.
I just updated my HomeAssistant (Docker) from something old (circal 2020.12 IIRC) to the latest and am now seeing the same error you see. Pianobar seems to run fine when run manually but errors when called from HomeAssistant, so, yeah.
Anybody using a docker repo that works with pianobar? I’m using ghcr.io/home-assistant/raspberrypi4-homeassistant:stable, willing to try something else. Patiobar looks interesting but I’d have to build a few other things, would love to keep pianobar as a media_player instead of an iframe or something else.
I am not aware of any other docker repo for hs. What exactly are you trying to do?
Basically run the default pianobar integration using HA on docker (and alsa on the host box). It used to work apparently but now gives all kinds of EOF errors as described in the github issue I referenced above.
Do you mean the pandora integration?
Also there are two sets of error messages in the github issue, where is yours?
Does pianobar work from the commandline?
Yes, pandora integration relies on pianobar. Pianobar works when run from docker shell with no errors.
Here’s a trace if you’re curious. Does yours work?
[2864154104] End Of File (EOF). Exception style platform. <pexpect.pty_spawn.spawn object at 0xa9677ad8> command: /usr/bin/pianobar args: ['/usr/bin/pianobar'] buffer (last 100 chars): b'' before (last 100 chars): b'Welcome to pianobar (2020.11.28)! Press ? for a list of commands.\r\n\x1b[2K(i) Login... ' after: <class 'pexpect.exceptions.EOF'> match: None match_index: None exitstatus: None flag_eof: True pid: 3898 child_fd: 49 closed: False timeout: 30 delimiter: <class 'pexpect.exceptions.EOF'> logfile: None logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 searcher: searcher_re: 0: re.compile(b'Receiving new playlist') 1: re.compile(b'Select station:') 2: re.compile(b'Email:')
I just updated to the latest docker container 2021.11.5 and am seeing that error too. It was working fine on my older docker container 2021.1.4. Not sure what changed as it’s working when I run it from command line inside the container.
It is strange- glad I’m not the only one. I’m not sure what to do with it, anybody have any ideas on what to try (or failing that, where to file an issue for someone to look into)?