Xdrip: Implement the receiption of scanned Libre 2 values via patched LibreLink

[dideldum]

The patched LibreLink sends many intents beside the currently accepted ones by xDrip+.

It also sends an Intent "com.librelink.app.ThirdPartyIntegration.SENSOR_SCAN" with all the scanned values (historic and realtime).

I tried it in a small test app and all the scanned values seem to be there.

It's just xDrip+, which doesn't take this intent and fills the gap with the scanned values.

Couldn't xDrip+ implement the reception of this patched LibreLink intent?

[Artemdrip]

Very good Idea.
I would give $ 10 to someone who could implement this feature in Xdrip +

[dideldum]

Unfortunately I have to add: the SENSOR_SCAN intent from the patched LibreLink doesn't contain the current 15 minute-by-minute values. So if you leave the phone for just a few minutes, it is not possible for xDrip+ to fill this current gap with the lost minute-by-minute values. Would be good, if the LibreLink patch developers just add a bundle with these 15 values. Probably xDrip+ developers could clarify this issue with the LibreLink patch developers?

[MasterPlexus]

@dideldum as you write you have tested the Intend in a other app, how did you see there the values. In your second note you state that it is not in there. As far as I understand the patch and librelink code itself has never included the data.
To include it is easy said than done, because smali code is Hardcore ;)
I don't think that the patch coders will try to implement that in the patch, as the last change itself was also not that problemfree...

[dideldum]

@MasterPlexus Yes, I changed the patch to send the intents not to xDrip+, but to my own app.
You misunderstood my second post.
The patch always has sent the scanned data, xDrip+ just doesnt accept it. But the scanned data intent is not fully complete. It contains the 8 hours history with its "every 15 minutes"-values and the so called realtime values, which are the sensor values at the moment of scanning (not only the last scanned, but also a history of scanned values).
The only data, which is not included in the intent sent by the patch, are the 15 minute-by-minute values of the last 15 minutes, which are also stored in the sensor and (as far as I know) are transmitted from the sensor, when it is scanned.
About which last change are you speaking? I only know the "the patch" itself, which was published once. There were never changes to the patch published, to my knowledge,

[MasterPlexus]

@dideldum , yes, last Patch was first patch, so the same ;)

Interesting, that in the dean intent also the values of 8houres are in, as I would that not see in the Patch. But this say nothing, as I said that smali is not really easy.

But I think there was a older cidepart of jamorham where he made the 8houres values fit into the 5 min area of older libre one scans. Maybe this could be used to transfer the 8houre values...

If the data is there I could maybe think about that, but can not say how long this could need.

[dideldum]

@MasterPlexus If you look into ThirdPartyIntegration.smali, which is the class for sending all intents, you can see a lot of "send...broadcast" methods (Only 2 of them are handled by xDrip+). One of these many broadcasts is "sendSensorScanBroadcast". The data transmitted in this intent is in various bundles, which are built together in the method "getSASFields". One of the bundles is the 8hour-history, another bundle contains the scanned data itself. So this must be identical to the historic and scanned data received via a transmitter.
If you use bytecode viewer, you can even see the ThirdPartyIntegration as a java class and can find, that the "sendSensorScanBroadcast" is called from com.librelink.app.ui.common.ScanSensorFragment.class in method scanSensor.
I'm still not informed enough, why here the "latest-15minute"-values are missing.

[MasterPlexus]

I have to digest that sometime if I find time.