...
Ok, this one is complicated. It seemed straightforward, I was very stoked to switch to Garmin, and I bought a Vivoactive 5. They were pretty new and I think I got it for $250, which was more than I'd ever paid for a FitBit, but it seemed like more smart less tracker, and I was right. It is an impressive little device and the folks at Garmin shoudl be applauded for squeezing even 5 days of battery out of this thing. But it gets better...
They have epic SDK support. Not only that, they have their own language for this thing, and it's called Monkey C. They really are embedded guys at heart, getting the most out of every ounce of hardware.
Anyways, I thought, I'm on my way. I did a ton of research and found some existing projects that looked close to what I wanted, but I still wanted to own the code base. It is closed for now, I'm still not sure about releasing stuff that is for monitoring glucose, and also right now I'm in a bit of repo transfer hell, cause I'm trying to move stuff out of another account. Maybe some day. Anyways, I found DexTrack, and really, the thing that drew me to it was the font, I loved that super-mono tech looking font, and the guy has a really good timing routine around the 5 minute message passing cycle, so I started with just the guts of that and basically nothing is the same now (except probably his timing routine, very nice...I literally just went and ⭐️'d his repo). Of course, all his networking stuff for Dexcom is OUS, so it required a lot of tweaking on my end, but once you get all the routes right...
It won't work. Not at all. So there is an issue (errrr...feature?) with the way that Garmin handles network traffic. You don't really have direct access to requests/responses. You're kind working with their interface via Connect IQ, so there is a bit of a bug where the content encoding is wrong in some of the Dexcom messages (or something like that...honestly I don't remember the specific issue, but it was a pain, I'll circle back if I track it down again). Anyways, the TLDR (and I confirmed by asking other devs, "Um...how the HECK did you do this without proxying all the traffic!?") is that you have proxy all the traffic 🤦♂️ and play catch and release with your watch app 😆. I know...it's kinda hilarious and (have I mentioned I'm cheap), I was immediately trying to figure out how on earth I could do this for free.
So, the next step is how to implement proxy for the traffic. I was (am?) a big time AWS nerd at the time so I was trying to figure out how to setup and API Gateway but those free tiers have time limits, not traffic/usage limits, so that was kind of out. Then I found out about a little thing call Lambda Function URLs. If you don't know already, Lambdas are these awesome mini runtimes that spin up, do a thing, and dispose of themselves. They're wonderful, and cheap and mega-scalable. But Function URLs allow you to route traffic directly to a Lambda without having to setup an API Gateway. The tricky business is that it's IAM permission (did I mention that doing HTTP in Garmin was sticky already?), or public. PUBLIC people. My 20+ glucose readings would just be...in the wind. People could see! For real though, at this point I took it as an experiment to do HMAC payload signing, and it was kind fun but totally overkill (I'd do it again in a heartbeat...just try to MITM my measily glucose traffic, just try...but for real, that's not a challenge...leave me be).
So a little Python Lambda, a little CDK, (make the image, push the image, build the Lambda ♻️) and I had a nice compact little cow 🐄 infrastructure that could stand up and tear down easily (we want cows not puppies, people). Now I was set to go, and after all that, I could put whatever I wanted in that Lambda (I have plans but nothing concrete).
But I think that is enough for now. I'll make another post on the UI itself, which is really the best part but like most things, it would be nothing without useful, actionable data (goodness...what a wall of text...here's an LOTR meme).
