Getting Bluetooth work in a Nerves application with BlueZ/DBus

Great to see some bluetooth love.

You are on the right track. You will have to start dbus and bluetoothd manually as part of your supervision tree. Check out muontrap

Yes, I am writing a tiny app to test that a BLE device works properly, and Elixir is a great language to get things done quickly.

Thanks for the tip, I’ll check muontrap and see what I can do from that.

Ooo, this looks awesome, many uses for it! Deserves it’s own post!

I believe it was announced on the forum here a while back. Its really useful for this kind of thing.

Hmm, I checked the forum via a quick search and there was no result, did a bigger google search on the site and no result, so not yet.

hm maybe i made that up then. I’ll poke Frank

Hey there . I’m on the footsteps of @ejpcmac in setting up bluetooth an I’m following @ConnorRigby 's advice of using muontrap. I am stuck at creating the /run/dbus directory that dbus-daemon --system needs. I’ve tried multiple approaches:

• Creating the directory in post-build.sh with mkdir -p /run/dbus
• Creating the directory through rootfs_overlay
• Creating the directory with a new config file in /etc/dbus.config with content -d /run/dbus

All of them failed in providing a /run/dbus directory at boot time.

Can someone steer me back on the right path?
Your help is much appreciated! Thanks!

In your Elixir application’s start function, call File.mkdir("/run/dbus").

Here’s the longer answer:

The default Nerves configuration mounts several different filesystems. The main one, /, is read-only and contains OTP, Linux programs, and your Elixir application and all of its dependencies. You can add to that one via the rootfs_overlay. However, some directories are made writable at runtime. Anything placed in those directories at compile-time isn’t accessible at runtime and that’s what you’re running into. Examples are the /tmp, /dev, /run, and /root directories. In the case of /tmp, /dev, and /run, Nerves mounts small in-memory filesystems. They’ll lose their contents on reboots so if you’re going to create a directory in them, you need to do it each boot. This is generally desirable since if something gets messed up in them, a reboot returns you to a good state. In the case of /root, a writable filesystem is mounted there so that iex prompt history and other things survive reboots.

As a general rule of thumb, I try to avoid using the rootfs_overlay feature. Usually Linux programs have a way to tell them where their configuration files are. That lets me put the config file in a more convenient location - like in my OTP application’s priv directory and tell it to read it from there. If programs need to write data, I can redirect them some place on /data, etc. Of course, it’s nice to see things work once before moving paths around, so this might be something to consider after the dust settles.

Thanks for the great answer! That explains everything. Happy New Year, cheers!