Developing and Deploying devices

[Dirk Hohndel]

On Tue, Apr 12, 2016 at 05:39:54PM +0200, Jeroen Massar wrote:
> >> 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.

You must be new here :-)

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

Thanks. I don't want to prevent super cool and exciting ideas for the
future - I just want to get something out that "works" and do that
"reasonably soon" :-)
And engineers easily get excited about things that make the project a lot
more complex and end up delaying things for limited improvement in
usefulness.

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

Yes, I realize that I may have made my point poorly. I want us to focus on
ONE platform for the "end user" - the people who need something that just
works. I see no reason not to enable people who want to run the software
stack on different hardware. Clearly a Pi3 would be an option - at 4x the
price, but if you have one already, why not.

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

There is an intersting detail that Jef reminded me of that makes it a much
better plan to transfer the binary data. Dive computer vendors don't often
break the data transfer layer, but we do see changes to the encoding /
parsing more often than I would like (that's one of the reasons we had
Subsurface 4.5.4 and 4.5.5). In the recent cases an update to the parser
fixed this - and I know that it will be MUCH easier to update Subsurface
and Subsurface-mobile than to have to update the software on the
Subsurface Box.

So having the Box just download the raw data, transfer that to Subsurface
and parse it there seems like the way to go.

Now how we encapsulate those raw data... let the bike shedding begin.

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

The advantage of this being supported by CHIP is that it would be
supported out of the box with no user intervention. I want to prevent ANY
need for us to tell the user "... and now start the terminal emulator
inside your terminal emulator window and log in as root..." :-)

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

That was my thought which is why I've started that conversation. This is a
problem that is in no way specific to Subsurface. Everyone building
something on top of the CHIP will run in to this at some point.

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

No kidding. I have found that adding nextthing chip usually helps.

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

Yep. I'd actually say "let's wait to see how many people ask for this"...
It just seems so silly...

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

The new Xeons are really light :-)
(in case that isn't common knowledge... I do work for Intel in my day job)

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

See above - I think my first response was sub-optimal. I agree that for
developers this is completely valid

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

I tend to spend all of my vacation time on
a) collecting data and then
b) working on Subsurface to make use of those data :-)

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

Or we can have no config at all beyond the initial out of box experience
install mentioned above... that would be my preference :-)

> And even config can be done using BLE if wanted.

I'll bite. What config?

Thanks for all the constructive feedback!

/D