Developing and Deploying devices

[Jeroen Massar]

On 2016-04-12 16:58, Dirk Hohndel wrote:
[..]
>> 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.

Indeed, hence why SSH would not be (per-default :) exposed.

They would get a button labeled "Upgrade".

> 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.

Fully agree.

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

I don't think they will be used.


>>> 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

Great!

>> 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.

Fully agree.

>> 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 :-)

I am not one to do a long bikeshed.

A Poll would be the proper way to select this.

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

Done

>> * 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

What you wrote suffices for me ;)

>> * 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

Agree.

>> * 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)

Adding a 'future' section.


>> * "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.

Raspberry Pi also, thus if people want different hardware (as they
already have one for instance) then that should not be too tricky to
accommodate.

Noted in Wiki.

>> 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

Makes sense, added to wiki.

(XML fans will shout that one can do binary XML ;)
[nope not one of those folks ;)

>> * 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.

That would be a really great method of doing this.

And yes, 'out of the box' would be a great thing to have.

I was thinking of just going down the DIY route... but if somebody can
do the above, that would be pretty amazing.

Actually, it would open up their platform for auto-installers of any
kind of tools, just plug in in your CHIP, connect the wireless, and
chose the function from a ChipStore.

(google is not very friendly for searching for "chip" btw...)

>> * 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

Yep. Very minimal.

>> * "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

In the wiki marked as 'future'.

>> * 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?

The attack surface is indeed quite minimal.

We could have a option for that in the future where one could require a
PIN though that is configuration time.

>> 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 :-)

mmmm those are sometimes heavier than tanks, thus they do not come along
on the heli ;)

I meant the above more for development work, one does not want to cross
compile all the time in a lot of cases.

> 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

Good separation. Added to requirements as that is very important.

And yes, it should be a plug-and-play box first. Advanced features we
can add in a V2 edition, hence those things go to that section.

While on vacation I don't want to meddle to much with computer stuff
anyway, as well, one is on vacation ;)

> 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.

Full ack.

> 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.

Except for possible updates, the device does not need IP.
In the config we can just have a "Enable IPv4" and "Enable IPv6" option.

And even config can be done using BLE if wanted.

> 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.

I fully agree ;)

Greets,
 Jeroen