-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Conversation
…rom other masters.
…nd libre wifi. Signed-off-by: Tzachi Dar <[email protected]>
Signed-off-by: Tzachi Dar <[email protected]>
…wifi and one gmc reader.
Signed-off-by: Tzachi Dar <[email protected]>
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]>
…llector. 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)
Signed-off-by: Tzachi Dar <[email protected]>
…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.
I have tested it on 3 phones and it works well. |
|
||
if(Home.get_master()) { | ||
if (SensorSanity.checkLibreSensorChangeIfEnabled(lb.reference)) { | ||
Log.e(TAG, "Problem with Libre Serial Number - not processing"); |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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"); | ||
} |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
…n/tzachi-libre-multi-receivers-3 Tzachi libre multi receivers 3
This replaces #1325
Still under testing.