Things were moving along slowly, but smoothly for the 2016 revision of Mr. Gibbs. My newly updated bluetooth stack based on BlueZ 5 was working great with both the pebble and with BLE/Gatt and the Blend Micro
Any time you go over a major version change you expect some breakage, and indeed, pebble changed the way that apps are deployed, significantly in V3. Thankfully their reference implementation, libpebble2, is both up-to-date and opensource (thank you, pebble, for being such a good OSS citizen). The bad news is my python skills are virtually nonexistent, so updating my pebblesharp fork to reflect the changes required me to do some learnin'. That's OK of course, always nice to learn a new (to me) language, although history has taught me that for pet projects it's not a great idea to use unfamiliar tooling if making headway on the project itself is a priority.
The pebble has a fairly limited amount of storage, and the strategy for managing that storage is a major change between V2 and V3. In V2 there was simply a limitation on the number of apps you could install at a time, but once you installed them they were always available, irrespective of if the phone was available or not, since the bits were literally already on the phone. Installing and launching the Mr. Gibbs app was a fairly straightforward process of sending the app over then launching it.
In V3 they have added an additional API called BlobDB, which is exactly what it sounds like, a database of binary blobs. You register an application by inserting metadata about the app into the BlobDB, which causes it to appear on the pebble. You then request that the app be launched, at this point the pebble realizes it doesn't actually have the app bits, and requests them from the phone (played in this case by Mr. Gibbs on the Pi).
I assume that the way this works is that the pebble can show any number of apps as being available, and then fetch them on the fly as necessary from the phone, deleting other apps to make space as needed. I guess this makes sense for the majority use case of having it paired with a phone, but obviously it complicates things for me on this project. I do wear my pebble daily as well as using it with this project, and I never found the app limit in v2 very onerous, there just isn't a huge number of apps that I need on it. That being said, obviously hobbyists such as myself probably don't factor into their business plan, I should probably be thankful the libraries are open source.
The other change that I needed to sort out was that the contents of the .pbw have been restructured a bit. There are now multiple sub directories which contain platform specific bits for aplite/basalt/chalk which is a convenient way to support all the platforms with one pbw which is easily generated from cloudpebble.
My fork of pebblesharp is reaching that point where it "works", but it's not pretty. With a refactor there are a lot of things that could be cleaned up and a lot of things that could be wholesale removed, the question is do I prioritize this or do I prioritize other functionality on Mr. Gibbs. I have a feeling the latter is going to win.
With any luck, I should have my updates to the pebble plugin done soon and be able to move on to other Mr. Gibbs functions that I've been thinking about since last fall. The list is growing daily in anticipation of a regatta in mid April.