Developing and Deploying devices

[Dirk Hohndel]

> On Apr 12, 2016, at 5:16 AM, Jeroen Massar <jeroen at massar.ch> wrote:
> 
> On 2016-04-12 11:53, Robert Helling wrote:
>> Hi,
>> 
>> I have been thinking a bit more about setting up a small device
>> (C.H.I.P. or similar) to do the dive computer read out and communication
>> with the mobile device.
>> 
>> One thing I am worried about is how to collaboratively develop for such
>> a target. It is quite likely that we have to modify system files and
>> settings (like startup, maybe configure BT or networking, instilling
>> packages etc). How can we put that in version control? Do everything
>> with a script and version control that script? For configuration files,
>> one could have those in a directory under git and then have a small
>> script that writes them in the appropriate places (and sets permissions
>> etc). But maybe people have better ideas. Am I reinventing a packaging
>> system?
> 
> You would be re-inventing that.
> 
> Hence the best way to go is to just use the packaging system of the
> distro that gets chosen.

So the CHIP uses a Debian based system. But as I said in my last two
emails, exposing that to end users is already declaring defeat.

Yes, we can use the Debian tools behind the scenes (and no, I have
ZERO interest in going back to the fights with distros, and ESPECIALLY
with Debian, on how to package things and what is and is not in accordance
to their ideology). But the user experience needs to be very very different.

This will require help from the CHIP guys to pull off (or from whatever
platform we end up using).

>> The other thing is deployment. Initially, that’s simple, we provide disk
>> images. But then, what is the upgrade path? Connect to wifi and do git
>> pull? apt-get upgrade/update? Get a new disk image? That needs to be
>> thought about as well for devices like this.
> 
> Very good questions and still at the right time.
> 
> We should definitely have a list of requirements as one of the first
> things, as otherwise how do we know what we really want and who is going
> to be working on what (duplicate stuff or stuff that never gets used is
> rather an annoying downer for many people).

http://trac.subsurface-divelog.org/wiki/SubsurfaceBox <http://trac.subsurface-divelog.org/wiki/SubsurfaceBox>

> Assuming that the small size, flexibility and capabilities of a
> Adruino/USB/BT 'stick' is likely too little for us, lets go for a
> 'bigger' device which can run a proper-ish Linux.

YES. Please. Given the price point and capabilities of the CHIP I see
no reason to go to something less capable than that.

> As an initial list of things see below, (do we have a wiki or git repo
> where we could put this list in markdown or similar format, makes
> discussing easier...)
> 
> The device:
> * a name ("OnSurface" ? :)

Subsurface Box

But of course this is open to discussion :-)

> * a case
>  - mostly water-proof-ish
>  - nice bright yellow plastic so it can't get lost

please add to the wiki

> * selection of hardware [see note below though]
>  - CHIP
>  - Pi
>  - other?
> 
> * battery that can at least make it functional for "a day"
>  - we assume you get to land at one point where it is dry
>    and that you can charge the thing, but it should not be
>    after an hour of usage, the battery should at least survive
>    a day of going out and diving

I have a few words about that on the wiki, feel free to expand

> * Dive Computer connectivity
>   - USB Host to Dive Computer
>   - USB<->IRDA connector support
>   - others?
>   Likely USB is the minimum, and that then things can plug
>   into it that actually connect to the DC.

Linux gives us a wonderful starting point as all the devices will
just work and even the iRDA USB plugs usually are supported.
This will require some testing to ensure that the right modules
are loaded, but that's fairly straight forward

> * Connectivity between device and mobile:
>   - Bluetooth LE
>     - low throughput
>     - would require custom things for transfering items
>     + does not require switching WiFi on mobile device
>   - WiFi for connectivity
>     + high throughput
>     + can use standard HTTP transfers etc
>     - does require switching WiFi on mobile device
>       (but see below: Home/Away switch)

I have added this to the wiki (except for the home/away thing... to
me that is definitely a V2 functionality)

> * "OS" Selection: I'll stick to this Linux-based thing ;)
>   but we'll have to select a "Distro", and this will
>   also select what 'upgrade' options we have:
>   - Debian
>     - I am partial to this where possible
>       simply because of 'apt-get update && apt-get dist-upgrade"
>     - would mean we simply roll Debian packages in a
>       'addon' repo originally and if we can get them
>       into mainline Debian there, for setting everything up
>   - Depending on storage: small form factor might just
>     need custom strip-down distro
>     Could build this from components/kits offered by others
>     eg using OpenWRT as a base etc.
>     -> it does affect upgrade methods...
>   - something else?

I would be amiss if I didn't point out the Yocto Project as a way
to create an image, but realistically, I'd much rather build on top
of what the device vendor ships, in this case a simple Debian
distribution.

> Then the actual work for binding stuff together:
> 
> * Installation of (minimal?) Subsurface on the device
>   - if Debian or other such system: packages!

As I said before, forget Uemis (I certainly have) and just go with
the command line version of libdivecomputer. I have that working
already. And as Jef points out, if we transfer the binary data
instead of XML we also get super-dense data files that would
make things more feasible for BLE

> * Upgrade system
>   - if Debian or other such system: packages!
> 
> * First-time Setup Interface
>   - SDcard slot option:
>     could have an program that writes a simple configuration
>     file to that medium config can be on a partition formatted
>     with FAT32 or something else that any computer can read
>     This 'program' could just be a menu option in SubSurface
>     as we have all GUI parts sorted out there already.
>     - won't work without a computer
>   - WiFi option:
>     it should just become an AP when initially enabled
>     the user then connects, gets an IP, connects to http://<ip>
>     and gets a nice web interface for configuration
>     - in combo with broadcast mentioned below, mobile tool
>       could actually just be the configuration tool
>       with some kind of REST interface on the device.
>   - USB:
>     - Would require a non-host USB port next to host USB
>     - Requires a computer
>     -> not a really good option

So as I said, I'm talking to the CHIP guys about this. This is
something that needs support from whoever builds the device.
We could of course have some company assemble the boxes
and flash them with a custom image, but I'd much rather work
with NextThing on creating an easy way for all of the projects
running on CHIP to bootstrap.

What I suggested to them is that CHIP should ship with an open
WiFi access point running and a web server to connect to and
then a simple web interface where you enter a URL from which
a package is then installed. Super easy for end users.

> * Configuration Interface
>   After setup we should be able to reconfigure
>   Likely this will be a component of the Mobile edition when wifi
>   or heck the full version; but with BE or SDCard this would be
>   quite a different tool to do.

My vision so far (and I need to add this to the wiki) is that we have
a simple command/respond system that works over BLE. There
isn't THAT much configuration that we need. Pick the dive computer,
transfer the last fingerprint we have. Download from dive computer.
Wait for that to finish. Transfer to Subsurface/Subsurface-mobile

> * "Home"/"Away" switch:
>   - When switched to "Home" it will try to connect to the local
>     home WiFi Network, that way it becomes available to the home
>     network and one can use it that way, thus avoiding need
>     to have to have your mobile device switch between the home-wifi
>     and the device wifi.
>   - When switched to "Away" it will be a AP, your mobile device
>     can then connect to it and use it directly.

V2

> * Device discovery (for WiFi)
>   - Simple edition: allow the user to enter the IP/hostname of
>     the device in the mobile tool
>   - Broadcast packet on local WiFi:
>     Likely UPNP packets are a good tool for that, but we can use
>     whatever is good. This way tool can autodetect it.
>     (this option should of course have the option of being disabled
>      in the configuration, I hate broadcasting stuff myself...)
> * Security policy: minimal exposure of anything

Interesting question. Since I am still hoping to convince everyone
of a BLE solution instead of a much more elaborate setup that
some here seem to envision, discovery becomes easy. BLE 
advertisement. Connection. Go. If people are really worried that
someone else can download data from their dive computer we
could of course add a PIN but frankly... WHY?

> Yes, that is a long list of things, but if we have the list we want,
> then people can say "I'll tackle that part" and together we can get
> there quite fast.

That's why I started the wiki.

> Note that the hardware could just be a variety of things, having it
> based on Debian could just mean that somebody runs this on a cheap
> laptop (great for devel, but indeed then you do not really need a mobile
> version anymore), while others use a mini-device. Or the in-house
> edition that you have on your desk could just be a VM on a bigger device
> etc, while you keep the tiny one in your dive bag.

Yes, we could also support Xeon servers for those who usually take
one on a trip :-)

Seriously, we need to very very very clearly separate two user groups:

A) people who are comfortable installing debian on some random device
and making all this work
B) actual divers and users of Subsurface-mobile on their iPhone with no
discernible knowledge of computers

On every dive trip I'm on I somehow end up meeting about zero or one
people in group A and everyone else is in group B. For group B we should
pick ONE device, ONE solution, ONE way of doing this. Keep it as simple
as humanly possible.

Yes, you can set up a git server on the box with automatic hook based
triggering of cryptographic signatures on your dive data that are then 
uploaded to the Subsurface cloud. And nine pages of configuration 
including ipv6 support and whatever else you can think of. Go ahead,
knock yourself out.

But that is for YOU and for three others in group A that can actually agree
on the same features and the same hardware to use and the same distribution 
to use etc. But for everyone else we need something that is really, really simple
and really really reliable and well tested. Otherwise why bother.


/D

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160412/2dab3566/attachment-0001.html>