We've ended up adding a lot more fields than I originally anticipated
> SHOW FIELD KEYS FROM zepp
name: zepp
fieldKey fieldType
-------- ---------
activity_duration_m integer
calories integer
current_activity_type string
current_activity_type_int integer
current_sleep_state string
current_sleep_state_int integer
current_stress_level integer
deep_sleep_min integer
distance_m integer
high_stress_time_perc integer
last_sync integer
max_stress_level integer
mean_stress_level integer
medium_stress_time_perc integer
minimum_stress_level integer
normal_stress_time_perc integer
odi_read float
recorded_REM_events integer
recorded_activities integer
recorded_awake_events integer
recorded_deep_sleep_events integer
recorded_fast_walking_events integer
recorded_light_activity_events integer
recorded_light_sleep_events integer
recorded_sleep_stages integer
recorded_slow_walking_events integer
relaxed_time_perc integer
rem_sleep_min integer
score float
slept_from string
slept_to string
spo2_decrease float
step_goal integer
total_sleep_min integer
total_steps integer
That's only going to grow with time.
Whilst documenting the fields I've spotted a few possible headaches, so it seems worth doing a schema review before publishing a write-up.
Activity
05-Aug-23 13:39
assigned to @btasker
05-Aug-23 13:50
Non Specific Field Names
For the most part, it's possible to use the existing tagset to identify which category a series falls under - you could conceivable filter for
r.activity_type == 'sleep'
to get sleep related entries etc.Where this breaks, though, is the trackers within the general stats:
recorded_{$activity_type}_events
: the number of recorded activities of that type that dayrecorded_{$stage}_events
: the number of recorded instances of that sleep stage that dayThe different sleep stages and activity types are dynamic, so it's not possible for a query to know which fields relate to sleep and which relate to activity.
Possible fixes
Variance in field names
The tracker points themselves use slightly different field names
current_sleep_state
: string representation of the sleep typecurrent_sleep_state_int
: Zepp's integer representation of the sleep typecurrent_activity_type
current_activity_type_int
: Zepp's integer representation of the activity typeWhilst these are descriptive, it means we have 4 columns when we could instead just have two:
There's a similar concern with the general stats -
recorded_sleep_stages
andrecorded_activities
could similarly share a column name.Fixes:
05-Aug-23 13:53
The big question, really, is whether we want to split things out across multiple measurements.
Rather than just having
zepp
we could havezepp
zepp_activity
zepp_sleep
zepp_blood
zepp_stress
etc (with the
zepp_
prefix perhaps being optional).It'd definitely be better schema design, the question is whether it's worth the effort.
I only keep the data for about 7 days, having had a downsampling task normalise the data into a new platform agnostic measurement so it doesn't quite seem worth it.
05-Aug-23 13:57
mentioned in commit 8d205919b2c37962dce0cfb7163a84f968737b8c
Message
Rename the sleep/activity stage counters to specify which category they relate to (for utilities/zepp_to_influxdb#5)
This moves both types from using field names of the form
recorded_{type}_events
to using one ofrecorded_activity_{type}_events
recorded_sleep_{type}_events
05-Aug-23 13:58
I'm going to leave the tracker field names alone - whilst it's technically less correct, it only gets rid of 2 columns and it doesn't seem worth having to update my downsampling jobs and dashboards for such a small gain.
05-Aug-23 15:23
mentioned in commit sysconfigs/downsample_configs@f07cb53f52444b386e7a603332438941031df403
Message
Update downsample field matches to reflect changes in utilities/zepp_to_influxdb#5
05-Aug-23 15:33
Just for completeness, here's how I ported my existing downsampled data over.
Copy data to the new columns
Delete the original columns
08-Aug-23 16:54
mentioned in issue #7