Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image docker ready #16

Closed
humbertosales opened this issue Oct 28, 2017 · 11 comments · Fixed by #56
Closed

Image docker ready #16

humbertosales opened this issue Oct 28, 2017 · 11 comments · Fixed by #56

Comments

@humbertosales
Copy link

Hello Gordon...

Image docker created for quick start...
https://github.com/humbertosales/espruinohub-docker-rpi

@sebi5361
Copy link

sebi5361 commented Nov 4, 2019

Indeed it would be nice to have an officially maintained docker image~~

@gfwilliams
Copy link
Member

Does this actually work? Interfacing to bluetooth via docker could be problematic?

@jjok
Copy link
Contributor

jjok commented May 22, 2020

Does this actually work? Interfacing to bluetooth via docker could be problematic?

It should be. There are Home Assistant integrations that connect to Bluetooth devices. I don't know if they've had to do any magic to get that to happen.
In terms of actual devices on the host, a container can access them if you pass an option for it. Eg I run my music streaming server in a container, so I do docker run --device /dev/sound-card-on-host ....
I don't really know how Bluetooth works though. Is there some kind of daemon running? If so,.should that be in the container or on the host?

@jjok
Copy link
Contributor

jjok commented May 22, 2020

Related conversation here: http://forum.espruino.com/conversations/347915/

@maxkueng
Copy link

maxkueng commented May 22, 2020

I'm running EspruinoHub in Docker on a Raspberry Pi. All I had to do is run the container with --network=host and it worked. There is no need to to set the --privileged flag as mentioned in the repo linked in the first comment. I mounted the config file as a volume.

Is there some kind of daemon running?

I believe that if you run it with --network=host it will use the host's Bluetooth stack. If, instead, you map the BT device using --device /dev/... you would have to have a BT stack running inside the container. This could be an advantage if you had multiple BT adapters. Then you could let the host use one and EspruinoHub use another one.

I'm not running the EsprionoHub container on the same host as Home Assistant because it seems that the way EspruinoHub works, and because I'm using the onboard BT adapter, it occupies the entire BT device and other programs on the same host can't scan for BLE devices anymore. So I'm just using a second Raspberry Pi.

@jjok
Copy link
Contributor

jjok commented May 22, 2020

Thanks for the info. I did wonder if Home Assistant might be totally hogging the Bluetooth.
At least we know if definitely works. I think it would be cool to have a container available to make setup easier. I'm guessing you aren't too familiar with Docker @gfwilliams ? Would you want to have a container config be part of this repo, or would you prefer someone else to maintain it?

@gfwilliams
Copy link
Member

I'm happy to have a Docker config in here if you think it's handy.

My personal feeling has been that unless you're actually well-versed in Docker already, if you just want to get this running it's just more stuff to download and learn how to use - but the more ways to get this running well the better.

With multiple adaptors: I'm not 100% sure what Noble defaults to, but you can use NOBLE_HCI_DEVICE_ID=1 for instance to get it to use a numbered HCI device. It might be a way to get two distinct things running with two BLE adaptors.

@jjok
Copy link
Contributor

jjok commented May 27, 2020

unless you're actually well-versed in Docker already, if you just want to get this running it's just more stuff to download and learn how to use

The way I see it is that, if I have Docker, I could do docker run espruinohub (or likely something a bit more complicated), and it's up and running with all the dependencies included. So I don't need to know about Mosquitto or NPM or git, and you don't have to worry about which versions of those things you have installed. So I see it as being simpler.

And it wouldn't stop people from installing it in the way that's currently documented, if that's what they prefer.

@jjok
Copy link
Contributor

jjok commented Jul 17, 2020

I've finally got this working on a Pi Zero W. Installing a working version of Node is the painful bit.

I'll open a PR.

@gfwilliams
Copy link
Member

Great - thanks!

@GrumpyMeow
Copy link
Contributor

Here's my version for Raspberry PI Zero:

FROM balenalib/rpi-debian:buster-build

ARG repo=https://github.com/espruino/EspruinoHub.git
ARG branch=master
USER root

# Install dependencies
RUN apt-get -yqq update && \
    apt-get -yqq --no-install-recommends install git build-essential python-rpi.gpio bluetooth bluez libbluetooth-dev libudev-dev bluez-tools rfkill && \
    apt-get -yqq autoremove && \
    apt-get -yqq clean && \
    rm -rf /var/lib/apt/lists/* /var/cache/* /tmp/* /var/tmp/*

RUN cd / && \
    wget http://nodejs.org/dist/v8.11.1/node-v8.11.1-linux-armv6l.tar.gz && \
    tar -xzf node-v8.11.1-linux-armv6l.tar.gz && \
    cd node-v8.11.1-linux-armv6l/ && \
    cp -R * /usr/local/ && \
    cd / && \
    rm -r node-v8.11.1-linux-armv6l && \
    rm node-v8.11.1-linux-armv6l.tar.gz && \
    export PATH=$PATH:/usr/local/bin


RUN usermod -a -G bluetooth root && \
    setcap cap_net_raw+eip /usr/local/bin/node

RUN git clone --single-branch --branch ${branch} ${repo} /var/espruinohub && \
    rm -r /var/espruinohub/.git

WORKDIR /var/espruinohub

RUN npm install && \
    npm cache clean --force
	

#Run other commands for start BLE...
RUN chmod +x /var/espruinohub/start.sh && \
    rm /var/espruinohub/config.json
ENTRYPOINT [ "/var/espruinohub/start.sh" ]

@jjok jjok mentioned this issue Aug 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants