search

nightscout / AndroidAPS

Opensource automated insulin delivery system (closed loop)
https://wiki.aaps.app
GNU Affero General Public License v3.0
722 stars 1.75k forks source link

[3.1.0.3] Wear entered treatments are not received by my phone (no confirmation) #2323

Closed old-square-eyes closed 9 months ago

old-square-eyes commented 1 year ago

Wear entered treatments are not received by my phone (no confirmation)

Keys should be the same for both mobile app and wear app, as was working fine for a month after an initial issue.

Reporting bugs

vanelsberg commented 1 year ago

Important information is missing on this issue:

Did you try uninstalling the wear app and select a stock watch face, then switch off the watch, then switch it on again and reinstall the AAPS wear app?

old-square-eyes commented 1 year ago

@vanelsberg

Will try the reinstall steps suggested and report back.

maheini commented 1 year ago

Does your watch have the latest built of AAPS? Have you tried to rebuild & generate the latest phone .apk

I'm using build 2022.12.15 on watch 4 & Huawei phone - everything is working - but just after I installed the latest build onto the watch.

old-square-eyes commented 1 year ago

I'm using 3.1.0.3

old-square-eyes commented 1 year ago

Factory reset my watch and installed the same apk I had before and it's working again. Would love to get to the bottom of it though as it seems like a fairly common problem and has happened to me twice from the same pair of apks. Loose a lot of time factory resetting the watch too reinstalling and configuring things. Appreciate it might be an Android thing too.

vanelsberg commented 1 year ago

Will testing dev I have been updating my Watch4 with new .apk versions multiply times without anu problems. Are you absolutely sure you did not by accident install a new version .APK that was build with a different signing key? This could cause a duplicate installation, hence problems?

old-square-eyes commented 1 year ago

100% sure on that. I built both the apks at the same time with the same key and stored them in my Google Drive where they are on thier own. Also it worked for a month. It's working again after a reinstall.

wootmasterslick commented 1 year ago

Same problem here with Galaxy watch 5. Works for short time after reboot of watch then it stops. Only happens when using a stock watchface. AAPS watchface seems to work ok.

Aeliassen commented 1 year ago

I have the same problem running Galaxy Watch 5 Pro. When using stock watchface the app stops sending commands (calculator, treatments tt). After restart of the watch the app works fine for a short while. The watch still recieves and displays data from AAPS (BG, IOB, COB)

I don't think this issue happens if I use a AAPS watchface

agmsd commented 1 year ago

Yep! Not working for me as well! It was working with the previous versions! I'm using a Samsung Galaxy Watch4 Classic with Wear OS 3.5

hartlijn commented 1 year ago

Same problem here. Samsung watch 6, WearOs4. When changing back to AAPS watchface and clear cache of AAPS wear, it works again. But not with another watchface

old-square-eyes commented 1 year ago

Seems worse when using another watchface too: https://www.facebook.com/groups/AndroidAPSUsers/posts/3653060784915312/

olorinmaia commented 1 year ago

https://github.com/nightscout/AndroidAPS/issues/2336 seem to be same issue. Have anyone tested this in dev/RC1?

Philoul commented 1 year ago

Hi, I confirm this issue on my side:

When AAPS Watchface is selected, everything is fine

When another watchface is selected (I selected one free watchface with complication and also put aaps complication within this external watchface) then:

This sequence applied twice today reproduced exactly the same result...

Test done with latest dev (aaps and watch side) Galaxy watch4.

I can help understanding where could be the issue (but I have a full released apk on my watch so with log message and logcat analysis...) some ideas where? Issue within rxbus sent from watch in tiles activities?

Philoul commented 1 year ago

When I check aapsLogger into DataLayerListenerServiceWear (on sendMessage) => Every minutes, a message is sent on /rx_bridge for ActionHearRate if an AAPS Watchface is selected => When I switch to another Watchface, these messages are no more sent and this immediatly! => When I switch back to AAPS Watchface, a new HeartRate is sent exactly one min later

See below status of ActionHearRate... First switch from AAPS to another WF at exactly 01:17:30 Switch back to AAPS WF at 01:19:58 Switch back to other WF at 01:22:45 Switch back to AAPS WF at 01:23:18

01:10:44.627  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":59999,"timestamp":1694819444597,"beatsPerMinute":60.057700961682706,"device":"samsung SM-R890"}
01:11:44.619  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":60000,"timestamp":1694819504597,"beatsPerMinute":68.09698469465583,"device":"samsung SM-R890"}
01:12:44.632  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":59999,"timestamp":1694819564596,"beatsPerMinute":58.45579211445232,"device":"samsung SM-R890"}
01:13:44.613  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":60001,"timestamp":1694819624597,"beatsPerMinute":63.5341244312595,"device":"samsung SM-R890"}
01:14:44.628  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":60000,"timestamp":1694819684597,"beatsPerMinute":61.69691165502747,"device":"samsung SM-R890"}
01:15:44.608  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":59999,"timestamp":1694819744596,"beatsPerMinute":68.29785181937744,"device":"samsung SM-R890"}
01:16:44.643  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":60001,"timestamp":1694819804597,"beatsPerMinute":72.97246133328711,"device":"samsung SM-R890"}
01:20:58.480  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":60033,"timestamp":1694820058453,"beatsPerMinute":56.6060195701555,"device":"samsung SM-R890"}
01:21:58.483  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":60000,"timestamp":1694820118453,"beatsPerMinute":58.352866666666664,"device":"samsung SM-R890"}
01:24:18.611  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":60045,"timestamp":1694820258577,"beatsPerMinute":60.137160956638525,"device":"samsung SM-R890"}
01:25:18.607  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":60001,"timestamp":1694820318578,"beatsPerMinute":61.79001914090117,"device":"samsung SM-R890"}
01:26:18.613  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":60005,"timestamp":1694820378583,"beatsPerMinute":64.00511899111804,"device":"samsung SM-R890"}
01:27:18.604  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":59994,"timestamp":1694820438577,"beatsPerMinute":65.66088651580644,"device":"samsung SM-R890"}
01:28:18.599  D  [main]: [DataLayerListenerServiceWear.sendMessage():178]: sendMessage: /rx_bridge {"type":"info.nightscout.rx.weardata.EventData.ActionHeartRate","duration":59999,"timestamp":1694820498576,"beatsPerMinute":63.46273539332509,"device":"samsung SM-R890"}
old-square-eyes commented 11 months ago

On 3.2.0.2 where I know there may have been improvements. Unfortunately still seeing this for both native and third party watch faces.

M0P commented 10 months ago

I had the same problem with third party watchfaces. Since it bothered me, I tried some random things I found on the internet and chatGPT suggested (I am not a developer) and currently I (or better ChatGPT) had an idea that works for me so far. I have been using my watch for 6 hours with a third party watchface and everything still works.

I changed this line of code (WearApp.kt line 34): startService(Intent(this, DataLayerListenerServiceWear::class.java))

to startForegroundService(Intent(this, DataLayerListenerServiceWear::class.java))

I don't know if this breaks anything else. I haven't noticed any problems yet.

I am running AAPS 3.2.0.3 and have a GW6 with WearOS 4.0.

MilosKozak commented 10 months ago

try latest dev https://github.com/nightscout/AndroidAPS/commit/8836f90a59e29de9f5a6f47a8e546d156c2f2b67 now it uses foreground service

vanelsberg commented 10 months ago

Interesting!

olorinmaia commented 10 months ago

Tested one day now and problem seem to be fixed by this change :) @MilosKozak could this be added for a possible 3.2.0.4 release?

old-square-eyes commented 10 months ago

Also tested for one day and looking good. I have been testing a 3rd party watch face (yet to test native). No issues so far and it worked after the watch charged all night so would have had every opportunity to sleep the app/treatment cards.

I'm super stoked about this one. Thanks @M0P and @MilosKozak.

I think before we call it resolved it would be good for others to chime in. Keen to hear is battery is affected (I haven't noticed so far).

vanelsberg commented 10 months ago

try latest dev 8836f90 now it uses foreground service

@MilosKozak Unfortunately [edit] with todays commit (https://github.com/nightscout/AndroidAPS/commit/041d0f0b7bd43042dbf201f442c1a48433eb22cd), on my Samsung Watch4 I now get a continuesly "ongoing notification" that can not be cleared.

So I would say this solves posters problem for non-AAPS watchfaces, but introduces a problem for users when using the AAPS watchface (which was operating just fine before this fix.

(Not sure if this is a bug (not closing notification channel) or a result of the latest "Wear: create notification channel" commit?)

[edit] See issue https://github.com/nightscout/AndroidAPS/issues/3137 Ongoing notification that can not be cleared

old-square-eyes commented 10 months ago

@vanelsberg interesting. I just switched to AAPS watchface and tested with a bolus and didn't get that. I also have a Samsung Watch 4.

vanelsberg commented 10 months ago

@old-square-eyes Did you build latest commit https://github.com/nightscout/AndroidAPS/commit/041d0f0b7bd43042dbf201f442c1a48433eb22cd

Note: my initial message pointed to the wrong commit...

old-square-eyes commented 10 months ago

@old-square-eyes Did you build latest commit 041d0f0

Note: my initial message pointed to the wrong commit...

Oh my mistake. I only built the one right after (https://github.com/nightscout/AndroidAPS/commit/8836f90a59e29de9f5a6f47a8e546d156c2f2b67)

vanelsberg commented 10 months ago

@MilosKozak @old-square-eyes Confirming problem was introduced by commit Wear: create notification channel

Tested with previous commit #f3be1bbfe1fe78aee30d791ae5f5e6dadab579b1 (updated both AAPS and Wear app): That build was ok. Problem is not in this commit.

vanelsberg commented 10 months ago

@MilosKozak @old-square-eyes Confirming problem was introduced by commit Wear: create notification channel

Problem partly fixed through https://github.com/nightscout/AndroidAPS/pull/3141

Additional info: Still getting "Datalayer Foreground Service Channel" notification that can't be cleared (Samsung Watch4).

Solution: Switching off this notification from watch developer options, while still getting bolus notification: App Notifications -> All watch apps -> AAPS -> Data layer Foreground Service Channel: OFF

old-square-eyes commented 10 months ago

Just reporting back after a week of use (https://github.com/nightscout/AndroidAPS/commit/8836f90a59e29de9f5a6f47a8e546d156c2f2b67). Issue is significantly reduced.

I have had my watch run out of battery during the day twice, and a couple of times later in the day, where it doesn't matter so much. I have the 44mm Watch 4 variant with the bigger battery and it's a couple of years old. I have also experienced unresponsive treatments a couple of times requiring a watch restart.

Not sure if subsequent commits have changed things much. But over-all I'd say things are usable and significantly better. I'm loving treatments by watch and am finally able to use a 3rd party WF with xDrip + AAPS complications.

20231228_081644-COLLAGE~2

wootmasterslick commented 10 months ago

Just reporting back after a week of use (https://github.com/nightscout/AndroidAPS/commit/8836f90a59e29de9f5a6f47a8e546d156c2f2b67). Issue is significantly reduced.

I have had my watch run out of battery during the day twice, and a couple of times later in the day, where it doesn't matter so much. I have the 44mm Watch 4 variant with the bigger battery and it's a couple of years old. I have also experienced unresponsive treatments a couple of times requiring a watch restart.

Not sure if subsequent commits have changed things much. But over-all I'd say things are usable and significantly better. I'm loving treatments by watch and am finally able to use a 3rd party WF with xDrip + AAPS complications.

20231228_081644-COLLAGE~2

Odd that you still have some unresponsiveness.

Would you suggest that battery usage of the watchface is now significantly increased? What do you think is the % difference?

M0P commented 9 months ago

I have also been using version 8836f90 since I suggested the change here. I have had practically no unresponsive treatments. I also have no persistent notification.

I did not use the 041d0f0 commit. As @vanelsberg says, it may be that issue #3141 was introduced by the 041d0f0 commit.

Since @old-square-eyes and I have no problems with 8836f90, maybe 041d0f0 is not needed at all? Maybe someone with problems can re-test version 8836f90?

For me, the battery life has improved since I can use a custom watch face. But I think that depends a lot on the watchface.