[Dev] NSv1/v3 is making duplicate entries to OpenAPS-log in AAPSClient and NS

[olorinmaia]

AAPS / Client 3.3.0-dev-e
Build: cab69e7-2024.11.30
Nightscout version: 15.0.2
Engineering mode enabled

In AAPSClient messages are duplicate and identical, in NS the information is abit different, one with mmol/l and other with mg/dl and some temp basal info.

Logs:
AAPS:AndroidAPS_LOG_1733057278672.log.zip

AAPSClient: AndroidAPS_LOG_1733057260440.log.zip

In AAPSClient messages are identical:

In NS there is some difference:

[emilisev]

Same issue for me on beta1

[olorinmaia]

Latest NS Dev with merged nightscout/cgm-remote-monitor#8234
Fixes issue with showing mg/dl but still duplicate openaps entry. Here with identical output
AndroidAPS_LOG_1734219330736.log.zip

[dsnallfot]

Latest NS Dev with merged nightscout/cgm-remote-monitor#8234

Fixes issue with showing mg/dl but still duplicate openaps entry. Here with identical output

AndroidAPS_LOG_1734219330736.log.zip

FYI. I'm pretty sure that one entry is the "suggested" device status and the other one is the "enacted" (the one with the temp basal string). They are almost identical as you noticed (besides the temp basal vs sensitivity strings that gets added in OpenAPS plugin for enacted vs suggested device statuses, and another attribute "received" that is hidden in the UI but present in the enacted DS payload)

I have no experience with AAPS but in Trio/iAPS the suggested payload always gets uploaded to NS, while the enacted payload only gets uploaded when the suggestion actually been received and enacted. (Pump com issues etc can block enacting as you most likely know).

But showing the same info 2 times in the AAPS/NS monitoring app screenshot seems unnecessary. I guess it could be resolved in the app code by filtering out suggested device status when there is a fresh enacted device status.

[olorinmaia]

Relevant comment here: #3620 (comment)

[bewest]

If possible, I recommend delaying sending a devicestatus until suggested and enacted can be reported as a single record. This is how things worked with openaps.

[MilosKozak]

from my point of view it's correct. Status is generated on more places (not only after enact) for example for cases like open loop, failed enact etc.
I added logging anyway so you can see the reason 5e70688