Developing and Deploying devices

[Dirk Hohndel]

> On Apr 12, 2016, at 2:53 AM, Robert Helling <helling at lmu.de> 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?
> 
> 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.

I have created a Wiki page where we can track all this: http://trac.subsurface-divelog.org/wiki/SubsurfaceBox <http://trac.subsurface-divelog.org/wiki/SubsurfaceBox>

As for the development process, right now I consider this the "storming" phase. Let's throw something together that actually demonstrates that we are trying to do. My current approach has a libdivecomputer based on our branch with patches to the dctool (will push those soon) for the download and so far just a few random attempts down three different paths for the BLE communication (I have a JS based framework that I have working, I have the Python example from bluez that I can't get to work, and I have started to look at the C code in bluez (which also doesn't seem functional - I'll be talking to the bluez guys about those two approaches).

Once we know what the pieces are that we need, for tracking development it would be enough to just have a script that installs all the pieces needed and hooks them together.

For packaging for end-users I'm talking to the guys at NextThing about a much more robust way to deploy things. We know from experience that the vast majority of our user base couldn't find a command prompt if it was blinking at them. So any solution that starts with "plug this into your serial port and run a terminal emulator, then run "sudo apt-get install..." is a non-starter. This will limit the user base to two dozen people - not interesting.
This is something that CHIP needs to solve in a broader way and I have some ideas how that could work - but that doesn't work unless it is driven by NextThing

/D

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