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?
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.
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.
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
Create an addon docker container that hosts pianobar - I /think/ this would be similar to the spotify add on.
Modify the component to setup the config directly (I actually have this somewhat working locally but haven’t been able to test it completely)
Create a one off solution with docker-compose.yaml as you mentioned. I think this would be the /easiest/ path forward given my hass.io on my raspberry pi already has pianobar in the path…
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
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
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…
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.
How/where did you find the docker-compose.yml file. Should I have one? (I cant seem to find one)
If I don’t have a docker-compose.yml file can I just make one? where would I place it
Where is Home Assistant looking for the configuration file for PianoBar? is it under /etc/homeassistant/root/? or is that just where you defined it?
docker-compose.yml only exists if you create it. It’s a standard docker tool for making the ephemeral contents of a docker run command line into a permanent configuration file.
HomeAssistant doesn’t actually look for the PianoBar configuration file - PianoBar does. HomeAssistant just starts the program and lets it do its thing. If you look at the docs Pianobar - ArchWiki pianobar wants a config file at ~/.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.
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.
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)?