Adapter with native executable

WebThings
#1

I’m trying to write an adapter for flic buttons. The manufacturer of the provides a native linux daemon to interact with them via bluetooth LE: https://github.com/50ButtonsEach/fliclib-linux-hci

However the daemon needs to run as root or similar to access hci0. Is there any way to make that happen in an adapter?

Further, it uses sqlite to persist data, where should that file be placed? Just within the adapter? Would that survive upgrades of the adapter?

And lastly, it’d be nice if there was some simple way to surface licenses of the bundled dependencies.

#2

@freaktechnik I don’t have a great solution for the flicd daemon right now, other than installing it in the base image. We could probably give the pi user access to hci0, but that won’t be very cross-platform.

For the database location, I would suggest putting it in the user profile directory, similar to the config database. You can find some code to locate that directory here. The add-on directory will not survive an upgrade.

As for the licenses, this would probably be a good thing to have. Could you open a PR in the gateway for that?

#3

Ooooh, I would like to see this work. :slight_smile:

I will poke more qualified developers to respond. We should also post an issue on the github Flic SDK project, asking them for advice on integration with the Mozilla Things Gateway running on RPi (or other embedded Linux platforms). The more hw/sw agnostic the solution, the better.

Ultimately we’d like to see the Flic button be a native web thing, broadcasting via Eddystone beacons for discovery. They may also have insights to help contribute to a standard iot “button” schema…

#4

Me too!

Bundling daemons for every new device type in the base image is obviously not going to scale, especially for things like this which are very specific to one device.

Would opening up access to hci0 be equivalent to what we already do for serial and GPIO? If so then it doesn’t sound un-reasonable. We are likely to have problems getting it to work cross-platform (including configuring what logical device to use) But presumably we’re going to have the same cross-platform issues for many add-ons.

At some point I imagine we’re going to have to decide whether we want platform-specific add-ons (with some way of filtering them in the UI) or to make add-ons far more restricted in what they can do via a safe cross-platform add-ons API.

I doubt that’s possible, the Flic button isn’t powerful enough to run a web server. The gateway integration pattern is the right one here.

#5

It would be a bit hacky, but there’s nothing to stop the adapter from installing a daemon when it gets run. The adapter should check to see if the daemon is already installed. On the pi sudo doesn’t require a password.

#6

Egad.

One thing I don’t think we should allow is an adapter downloading additional code or binaries from the Internet to install at runtime, since that would defeat the object of the checksums we currently use as part of our rudimentary add-on review process.

#7

we could add external resources’s checksums in the verified adapter
but this would be maintainer responsibility

#8

There’s nothing to stop add-on developers from doing that, but it will make the review process harder. It remains to be seen how well this is going to scale.