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 [email protected] 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
#347 (comment),
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 [email protected] 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
#347 (comment),
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
#347 (comment),
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