Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tzachi libre multi receivers 3 #1385

Merged
merged 15 commits into from
Jul 25, 2020
Merged

Conversation

tzachi-dar
Copy link
Contributor

This replaces #1325

  1. It is resynchronized against latest master.
  2. All changes to gcm activity have been removed.
  3. Sensor will automatically be stopped when running in all house mode.

Still under testing.

1) Send the sensor age to the follower.
2) Use sync on classes and not on separate objects.
3) Move the rate limiter on new libreblock objects to GcmActivity.java
4) Only notify for bad sensor if the sensor has not advanced, and there are no new readings.

Signed-off-by: Tzachi Dar <[email protected]>
There have been cases that it did not work (for example when it had to close a sensor after sensor).

Signed-off-by: Tzachi Dar <[email protected]>
…ensor with clock not increasing.

Signed-off-by: Tzachi Dar <[email protected]>
Change gradlew to print results of testing when running (for example when running gradlew test :app:testDebugUnitTest)
…stopped, and started by the user and then new readings started.
1) Sensor will be stopped for libre all house case.
2) A message will tell the user when last reading was.
3) In the case that sensor is stopped, processing will stop.
@tzachi-dar
Copy link
Contributor Author

I have tested it on 3 phones and it works well.
Can be merged.


if(Home.get_master()) {
if (SensorSanity.checkLibreSensorChangeIfEnabled(lb.reference)) {
Log.e(TAG, "Problem with Libre Serial Number - not processing");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this missing a return as it reports that it isn't processing?

// reading, and then BT disconnects and connects after a few seconds, and we have a new reading (where
// sensor did not advance). This does not mean that a sensor is not advancing. Only if this is happening
// for a few minutes, this is a problem.
if(BgReading.getTimeSinceLastReading() > 11 * 60 * 1000) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like it should work, by the way you can use the msSince() helper and also Constants.MINUTE_IN_MS to improve readability.


if (SensorSanity.checkLibreSensorChangeIfEnabled(SensorSn)) {
Log.e(TAG, "Problem with Libre Serial Number - not processing");
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This logs that it isn't processing but still continues. Should the message be changed?



Log.e(TAG, "HandleGoodReading called");
SendLibrereading(tagId, data1, CaptureDateTime, patchUid, patchInfo);
Copy link
Collaborator

@jamorham jamorham Jul 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am concerned that this change not being restricted to whole house coverage is an unrelated change to functionality which has a much wider scope and could increase the data load for followers somewhat but I understand why its desired so I think we will see how it goes.

I'm also concerned that this is the only code path where an incoming message can generate an outgoing message of the same type (as mentioned with the previous PR) because that has the potential for a loop. I can see that it is restricted with a database check but when phones get out of storage they can fail to write database records. I think for a loop to occur that would have to happen to multiple devices in the follower group which is less likely.

It could be mitigated with an in memory check when sending the message that the message isn't the same one that was sent last time.

Copy link
Collaborator

@jamorham jamorham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets merge this for wider testing.

@jamorham jamorham merged commit 67014b0 into master Jul 25, 2020
tolot27 pushed a commit to tolot27/xDrip that referenced this pull request Sep 21, 2020
…n/tzachi-libre-multi-receivers-3

Tzachi libre multi receivers 3
@tolot27 tolot27 deleted the tzachi-libre-multi-receivers-3 branch November 5, 2020 22:44
@tolot27 tolot27 mentioned this pull request Nov 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants