Nightscout API

Ik ben er gisteren in geslaagd om dingen te lezen met de Nightscout API, en ook om te schrijven. Anderzijds vraag ik me af of ik toch niet beter rechtstreeks naar de mlab database schrijf vanuit de app, want nu heb ik wel een manier om te testen tegen de API.

CoderDojo

Heb nog eens gebruik gemaakt van de CoderDojo om nog wat verder aan mijn project te werken.
Ben erin geslaagd om via ruby aan de Nightscout API te geraken (in elk geval al om entries te lezen).
Dit lukt zonder enige vorm van autorisatie, dus ben ik eigenlijk redelijk zeker dat ik niet via de API wil verbinden, maar via mongoDB. Daarvoor dacht ik aan Mongoid te gebruiken, maar op die moment lijkt het me nog een te high level interface om al direct in een gem te gieten. Langs de ene kant denk ik eraan om het rechtstreeks in mijn registratieappke te verwerken, maar dan heb ik geen controle over de consistentie tussen de Nightscout API en mijn assumpties over de database structuur.

Maar misschien moet ik die unittesten aan mijn registratieappke toevoegen, en dan zijn we wel zover.
Ik denk dat de meest directe winst zou zijn om mijn maaltijden ook te gaan pushen naar Nightscout; de rest kan later volgen.

Anderzijds begint ook de vraag om eens met die Arduino te beginnen zich op te dringen: ik denk dat de eerste stap de opbouw van een LimiTTer projectje moet zijn, en dan vervolgens dat ombouwen naar een transmitter. (Dus RFID ontvanger en zender op zelfde bordje.) In tweede instantie kan ik dat dan in twee splitsen en een geschikt wireless protocol voorzien.

FreestyleLibre released, en nu?

Vandaag FreestyleLibre release op RubyGems geplaatst, zij het incompleet. Ik heb het er wat moeilijk mee, maar in het verhaal van mijn Minimal Viable Product is er voldoende geïmplementeerd. Op dit moment zijn een aantal dingen meer prioritair: waarden opslaan en lezen vanuit de NightScout database. Eerste ding zal zijn een nieuwe NightScout op te zetten voor tests en dan te zien hoe die match met de database zit, en misschien opzetten met Azur zodat ik niet de restricties van Heroku heb. Langs de andere kant is het wel niet de bedoeling dat ik met NightScout blijf werken, want ik vind het een bijzonder slecht idee dat er geen vorm van authenticatie op de user interface van de app is. Waar ik eigenlijk naar toe wil is tweeërlei: enerzijds lezen en schrijven naar de database (al dan niet via de NightScout API), en anderzijds de NightScout API gaan implementeren, zodat ik zelf de data van LibreAlarm kan opvangen. Met dat laatste wil ik eigenlijk een behoorlijke alarmapp gaan implementeren: in eerste instantie een alarmapp voor iOS (en eigenlijk nog liefst OS agnostic) aangestuurd door een xDrip+ master, in tweede instantie vanuit libreAlarm zelf.

Ah, ja, en 't belangrijkste van dit artikel zou ik nog vergeten: de link naar de API van NightsScout: https://github.com/nightscout/cgm-remote-monitor/blob/master/swagger.yaml

FreeStyleLibre gem

Al een tijdje aan het prutsen aan een ruby gemmeke dat de waarden van de flash uitleest. Grotendeels als voorbereiding van een manier om met de arduino de reader te kunnen uitlezen, maar ook als een manier om makkelijker de data naar mijn eigen app of nightscout te krijgen,
Als unittest run ik het tegen een export file van de officiele app, wat dus wil zeggen dat ik twee parsers heb: één voor de export file, en één voor de data uit de flash. Maar wat betreft het dataformaat heb ik de indruk dat ik daar de bal nogal missla: ik heb voor de verschillende soorten data telkens verschillende objecten gemaakt, maar ik denk dat ik beter alles als een hash of openstruct opsla, en dus geen aparte objecten moet creeren.

27 april 2017

Vannacht was het zo mogelijk nog erger dan de dag voordien: de eerste ontvanger liet het telkens na een half uur afweten (wil dat dan zeggen dat er een probleem met de watch is, met de connectie of met de telefoon), en dus telkens een half uur later een alarm wegens onderbroken data. Ik het het volgehouden tot een uur of twee, en dan moet ik weer ergens een verkeerd knopje geduwd hebben zodat ik uiteindelijk kwart voor zes wakker werd en vaststelde dat het systeem intussen niet gewerkt had. Vroeger in de nacht al druivensuiker gegeven en dus rond kwart voor zes weer prijs, maar gelukkig nog niet zo diep.
De strategie die ik bedacht vandaag is dat ik meestal én de watch én de telefoon reboot, dus ben ik nu aan het proberen of dat werkt en ik een uur ononderbroken data kan volgen op de slave tablet. (We zitten nu aan een half uur zonder problemen...)

Verder vandaag bedacht dat mijn Ruby Library eigenlijk ook de exports van de officiële Abbott applicatie moet kunnen lezen, en dus dacht ik dat ik een method
AutoMeasurement.from_export_file moet aanmaken. Langs de andere kant lees ik in mijn diabeteslogboek applicatie ook de export file in om hem te kunnen uitschrijven naar de database, en dat is nu juist de case van mijn LibreDocker, dus hergebruiken die handel!

26 april 2017

Gisteravond behoorlijk aan het prutsen geweest met LibreAlarm: de laatste tijd lijkt het vrij onbetrouwbaar, en we zitten net in een fase waar we een plotse terugval van de insulineresistentie verwachten.

Het grootste probleem waar we nu mee kampen is onderbroken nachten: zowel door terechte alarmen als door 'valse' alarmen (langer dan een half uur geen data, of alarmen op basis van xDrip+ waarden die niet overeenkomen met waarden gemeten met vingerprik). De tweede categorie van alarmen kan ik niet onmiddellijk iets aan doen (op langere termijn wel, maar dat is een ander verhaal), maar de eerste categorie zou toch te vermijden moeten zijn. De oorzaken van de haperende datastroom zijn velerlei: verschoven smartwatch tov. sensor, en connectieverlies ergens in de ketting gegenereerd alarm - waarden opgemeten door sensor. Verschuiven op zich doet zich de laatste tijd niet meer voor (oorspronkelijk door hulpmiddel in FIMO, nu eerder door de sensor iets meer naar de binnenkant van de arm te plaatsen), maar ik heb nog niet echt zicht op waar de oorzaken zitten van connectieverlies.

Om dat connectieverlies wat in kaart te brengen, en er eventueel iets aan te doen heb ik momenteel Tasker en AutoWear geinstalleerd, maar zelfs met gecontroleerd connectieverlies (haal de smartwatch uit het bereik van de telefoon, zodat Android Wear aangeeft dat hij niet langer verbonden is) krijg ik geen consistente logging.

Verder nog een nieuw idee voor het project: we kunnen libreAlarm blijven gebruiken in eerste instantie en de nightscout API gebruiken.