It turns out that for the database used by Nightscout, when two carb entries have the same time of consumption, the most recent entry overwrites the prior one.
Please see: cgm-remote-monitor Issue 8185: Carb treatments disappearing
One proposed work around is to modify LoopCaregiver to keep the current time including seconds )and maybe msec) when the picker wheel is selected and only adjust the hours and minutes with the time picker. The odd of having the same time for remote carb entry then becomes miniscule.
The current method is to send selected hours and minutes with 0 seconds.
Please note that Loop behaves as expected, but for the remote carb entries selected to be at the same time from LoopCaregiver, Nightscout treatment history and display do not match Loop.
It turns out that for the database used by Nightscout, when two carb entries have the same time of consumption, the most recent entry overwrites the prior one.
Please see: cgm-remote-monitor Issue 8185: Carb treatments disappearing
One proposed work around is to modify LoopCaregiver to keep the current time including seconds )and maybe msec) when the picker wheel is selected and only adjust the hours and minutes with the time picker. The odd of having the same time for remote carb entry then becomes miniscule.
The current method is to send selected hours and minutes with 0 seconds.
Please note that Loop behaves as expected, but for the remote carb entries selected to be at the same time from LoopCaregiver, Nightscout treatment history and display do not match Loop.