03-30 18:06:04.489 10335-10397/info.nightscout.android W/System.err: org.json.JSONException: No value for batteryLevel
03-30 18:06:04.489 10335-10397/info.nightscout.android W/System.err:     at org.json.JSONObject.get(JSONObject.java:389)
03-30 18:06:04.489 10335-10397/info.nightscout.android W/System.err:     at org.json.JSONObject.getDouble(JSONObject.java:444)
03-30 18:06:04.489 10335-10397/info.nightscout.android W/System.err:     at com.bugfender.sdk.a.a.a.c.b.a(Unknown Source)
03-30 18:06:04.489 10335-10397/info.nightscout.android W/System.err:     at com.bugfender.sdk.a.a.a.c.b.b(Unknown Source)
03-30 18:06:04.489 10335-10397/info.nightscout.android W/System.err:     at com.bugfender.sdk.a.a.a.c.a.a(Unknown Source)
03-30 18:06:04.489 10335-10397/info.nightscout.android W/System.err:     at com.bugfender.sdk.a.d.a.c(Unknown Source)
03-30 18:06:04.490 10335-10397/info.nightscout.android W/System.err:     at com.bugfender.sdk.a.a.k.a.c.d.a(Unknown Source)
03-30 18:06:04.490 10335-10397/info.nightscout.android W/System.err:     at com.bugfender.sdk.a.a.k.a.c.d.call(Unknown Source)
03-30 18:06:04.490 10335-10397/info.nightscout.android W/System.err:     at java.util.concurrent.FutureTask.run(FutureTask.java:237)
03-30 18:06:04.490 10335-10397/info.nightscout.android W/System.err:     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
03-30 18:06:04.490 10335-10397/info.nightscout.android W/System.err:     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
03-30 18:06:04.490 10335-10397/info.nightscout.android W/System.err:     at java.lang.Thread.run(Thread.java:818)

rename bolusApi to bolusEndpoints to be consistant

Add support for getting pump basal rates.

- cleanup commented out code

- move sgv format conversion to main

- removed need for EHSM pump comms

- removed redundant channel change detection

- removed temporary dbg code

- added single retry for get pump time and status as occasional short lived noise can casue bad comms and retrying once catchs this rather then waiting until next poll

align restart of polling with last known event. It'll try to align with the last poll up to 2h (hardcoded). After that we assume that there is may be a sensor initialisation and restart polling immediately

using a read "pause" has no effect on outcome and likely redundant due to clearMessage intercepting unread messages

changed the hardcoded 500 to use TIMEOUT_MS and set it to 0 while long term testing

If user has double polling set then poll sooner with this error type

 Intercept unexpected messages from the CNL

These usually come from pump requests as it can occasionally resend message responses several times (possibly due to a missed CNL ACK during CNL-PUMP comms?)

Mostly noted on the higher radio channels, channel 26 shows this the most

If these messages are not cleared the CNL will likely error needing to be unplugged to reset as it expects them to be read before any further commands are sent

- user attempts to initiate a poll too close to sensor/pump comms will inform user to wait that poll is due in number of seconds

- app restarted and a poll is requested but close too sensor/pump comms will inform user to wait that poll is due in number of seconds

- startup poll time clash with sensor/pump is detected and auto adjusted

- unavailable SGV from pump due sensor/pump poll time changes/clashes will auto adjust poll time

- ongoing unavailable SGV attempts will start poll time auto adjust and user warned and number of unavailable SGV attempts shown

- missed SGV due to radio channel change avoids EHSM comms reducing the chance of extended channel changes

- occasionly the pump is late with the current SGV and returns the same SGV event as privious poll, this is detected and a new poll is scheduled

Uploading before cnl comms finishes and may cause occasional channel changes due to wifi noise - cnl intent already handles ns upload trigger after all comms finish

Shows user percentage feedback of radio signal to help them diagnose reception issues.

RSSI (Recieved Signal Strength Indicator) is a common name for the signal strength in a wireless network environment. It is a measure of the power level that a RF client device is receiving from an access point, for example.

configChanges="uiMode" added to avoid restart of AsyncTasks when phone is plugged into charger/dock (for phones that can do usb otg & charging simultaneously