Pebble Watch with xdrip for G5.

[borijess]

I am using the xdrip beta for the G5. Latest one on the closed beta on face book. I am using a pebble watch offline. The phone sends data straight to phone. When i toggle to off in the settings menu. The app still continues to send data to watch with toggle off.

[AdrianLxM]

@jstevensog: the pebble service has not changed from current xDrip-experimental to the G5-beta.

[jstevensog]

Interesting. I have not changed anything in the service that would cause it. Perhaps the service is not being stopped when the setting is changed. I'll try and take a look when i get my dev rig back. No chance in the next few days. Cheers

---- AdrianLxM wrote ----

@jstevensog: the pebble service has not changed from current xDrip-experimental to the G5-beta.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[tzachi-dar]

This is the function registerReceivedDataHandler.

private void init() { Log.i(TAG, "Initialising..."); Log.i(TAG, "configuring PebbleDataReceiver");

    PebbleKit.registerReceivedDataHandler(mContext, new

PebbleKit.PebbleDataReceiver(PEBBLEAPP_UUID) { @Override public void receiveData(final Context context, final int transactionId, final PebbleDictionary data) { Log.d(TAG, "receiveData: transactionId is " + String.valueOf(transactionId)); if (lastTransactionId == 0 || transactionId != lastTransactionId) { lastTransactionId = transactionId; Log.d(TAG, "Received Query. data: " + data.size() + ". sending ACK and data"); PebbleKit.sendAckToPebble(context, transactionId); sendData(); } else { Log.d(TAG, "receiveData: lastTransactionId is "+ String.valueOf(lastTransactionId)+ ", sending NACK"); PebbleKit.sendNackToPebble(context,transactionId); } } }); }

As one can see, if the pebble will ask, we send data without looking at the switch.

In the function onDestroy We have the following code: if(newSavedBgReceiver != null) { unregisterReceiver(newSavedBgReceiver); }

but newSavedBgReceiver is never being set to anything.

So this explains the bug...

How to fix, an obvious fix is to have a check in the function receiveData().

A more correct fix is to set the newSavedBgReceiver, but this requires some testing. Can I test this with a classic pebble?

Thanks Tzachi

On Tue, Jun 7, 2016 at 11:46 PM, John notifications@github.com wrote:

Interesting. I have not changed anything in the service that would cause it. Perhaps the service is not being stopped when the setting is changed. I'll try and take a look when i get my dev rig back. No chance in the next few days. Cheers

---- AdrianLxM wrote ----

@jstevensog: the pebble service has not changed from current xDrip-experimental to the G5-beta.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/347#issuecomment-224408894, or mute the thread https://github.com/notifications/unsubscribe/AHkw5A2f1VAkxiXMhOe04btaJ3Km5EH6ks5qJdi5gaJpZM4IwKgH .

[jstevensog]

Should be able to. They are the same. Cheers

---- tzachi-dar wrote ----

This is the function registerReceivedDataHandler.

private void init() { Log.i(TAG, "Initialising..."); Log.i(TAG, "configuring PebbleDataReceiver");

PebbleKit.registerReceivedDataHandler(mContext, new PebbleKit.PebbleDataReceiver(PEBBLEAPP_UUID) { @Override public void receiveData(final Context context, final int transactionId, final PebbleDictionary data) { Log.d(TAG, "receiveData: transactionId is " + String.valueOf(transactionId)); if (lastTransactionId == 0 || transactionId != lastTransactionId) { lastTransactionId = transactionId; Log.d(TAG, "Received Query. data: " + data.size() + ". sending ACK and data"); PebbleKit.sendAckToPebble(context, transactionId); sendData(); } else { Log.d(TAG, "receiveData: lastTransactionId is "+ String.valueOf(lastTransactionId)+ ", sending NACK"); PebbleKit.sendNackToPebble(context,transactionId); } } }); }

As one can see, if the pebble will ask, we send data without looking at the switch.

In the function onDestroy We have the following code: if(newSavedBgReceiver != null) { unregisterReceiver(newSavedBgReceiver); }

but newSavedBgReceiver is never being set to anything.

So this explains the bug...

How to fix, an obvious fix is to have a check in the function receiveData().

A more correct fix is to set the newSavedBgReceiver, but this requires some testing. Can I test this with a classic pebble?

Thanks Tzachi

On Tue, Jun 7, 2016 at 11:46 PM, John notifications@github.com wrote:

Interesting. I have not changed anything in the service that would cause it. Perhaps the service is not being stopped when the setting is changed. I'll try and take a look when i get my dev rig back. No chance in the next few days. Cheers

---- AdrianLxM wrote ----

@jstevensog: the pebble service has not changed from current xDrip-experimental to the G5-beta.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/347#issuecomment-224408894, or mute the thread https://github.com/notifications/unsubscribe/AHkw5A2f1VAkxiXMhOe04btaJ3Km5EH6ks5qJdi5gaJpZM4IwKgH .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[AdrianLxM]

I got that reproduced last night. It won't send the data right away if the setting is switched off, but it will at some point.

There are actually two places where data gets sent to the pebble. One at the start of the service that gets called on new data and is guarded. It still returns that the service is started (I guess we should change that as well?).

The other place where it sends data is via a Listener registered to the pebble-kit. When starting the service (e.g. because of setting changes) and run into the guard-clause, we should de-register this listener.

I'm not sure if it makes sense to tell the watchface in such a case to not request data anymore. It would be just a tiny bit of battery improvement but a lot of work and the possible problem that it won't catch up fast afterwards. Once you switch the watchface on the watch or unpair it (I assume the user will do that) there won't be any communication triggered by the watch at all.

Have a good Day

On 07/06/16 22:46, John wrote:

Interesting. I have not changed anything in the service that would cause it. Perhaps the service is not being stopped when the setting is changed. I'll try and take a look when i get my dev rig back. No chance in the next few days. Cheers

---- AdrianLxM wrote ----

@jstevensog: the pebble service has not changed from current xDrip-experimental to the G5-beta.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/347#issuecomment-224408894, or mute the thread https://github.com/notifications/unsubscribe/AJPmwt2je4QmRiyNi-erLLDxFcFnb7t7ks5qJdi6gaJpZM4IwKgH.

---

FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth