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.