Multiple sleep summary rows for the same day about pywearable HOT 4 CLOSED

For additional context:

the get_time_in_sleep_stage function in the sleep module, breaks when the pd.Series is transformed to a dictionary with the .to_dict() method. In fact, while in the Series two rows can have the same index, in the dictionary only the last row is kept for the key.

3 possible ways to fix:

• Assume that the first sleep of the day is the important one (i.e. the person is sleeping at night) by: participant_sleep_summary = participant_sleep_summary.groupby("calendarDate").head(1)
• Filter out rows with sleep score 0 completely, before producing the dictionary
• Avoid the transformation to dict and return the pd.Series, giving the possibility to appropriately handle each sleep occurrence later on. In this case, note, however that if average=True, the mean can be skewed greatly by 0 sleep score naps.

from pywearable.

This was temporarily fixed in b07d089 . The new implementation returns only the first sleep of the day, and discards additional sleeps occuring during the day,
I am leaving this issue open for further improvements.

from pywearable.

I believe that the current implementation has to be improved. The order in which Labfront returns the sleep summaries is not always consistent with improving validation methods. In the example reported below, for example, we have that for the calendarDate 2023-08-04, the first sleep summary has a AUTO_TENTATIVE validation, the second one an ENHANCED_FINAL validation, and the third one a ENHANCED_TENTATIVE validation:

Some functions of the module currently retrieve only the first row for a given calendarDate: in this case, we would have gotten a AUTO_TENTATIVE sleep summary, while the proper one should be the ENHANCED_FINAL. Thus, an improved method would be:

1. Check if there are multiple sleep summaries for a given calendarDate (being aware of the fact that Garmin also tracks daily naps)
2. Get the sleep summary with the best validation available

Tagging here also @Vaeliss so that he can have a look at it

from pywearable.

Labfront suggests to follow these decision scheme based on the documentation reported here:

• The ENHANCED_FINAL one with the longest sleep period
• The ENHANCED_TENTATIVE one with the longest sleep period
• The AUTO_FINAL one with the longest sleep period
• The AUTO_TENTATIVE one with the longest sleep period

from pywearable.