| Age | Commit message (Collapse) | Author |
|---|
|
it seems that the sensor takes a while to warm up, and until it does, it will return 0.
This fixes a check that previously already existed, but was checking the wrong value - if the step offset causes step count to increase, we will be returning erroneous values.
|
|
|
|
|
|
this doesn't have a sensor associated with it, as it's meant to be logged manually through UI - but we're still using the same model as the other data sources
|
|
|
|
|
|
|
|
this also changes the behaviour of getTodayTotal()
|
|
This is a radical new approach where we just scrap all steps that have happened outside of the current day. Theoretically, this should be more robust. Remains to be seen whether it actually does work any better.
|
|
This provides a similar interface to the step data loader, but doesn't have a 'total' function because that's not really that useful.
|
|
This function shows up in quite a few places so this seems justified.
Other functions may get this treatment later
|
|
additionally, this renames the current data access function to 'getTotalForDate()' while the new function gets the old name of 'getDataForDate()'. This naming seems more appropriate.
This should allow apps using the QML interface to implement their own graphs
|
|
After making several attempts at integrating this element into asteroid-health, I'm still not happy with the heartrate graph code.
The issue is that this element doesn't seem to be usable 'as is', and needs some sort of wrapper around it to make it fit with the style of asteroid-health. Effectively this would split the code in half across the two codebases. I also didn't want to specialise this graph code too much for asteroid-health, as I still wanted it to be somewhat generic and reusable.
I've decided that I'm going to move this code to asteroid-health. This would allow that graph code to be much more integrated, and would mean that sensorlogd should become much more generic and much easier to use.:q
|
|
It seems that the step counter doesn't actually allow setting the steps value. While setSteps() will cause the reading to change, the step counter may reset back to the previous step count when more steps are taken.
|
|
|
|
some other checks should also be put in place to make sure that we aren't decreasing the previous day's step count
|
|
currently this doesn't interface with the daemon in any way, this is added for future use
|
|
This inconsistency suggests that these values should be saved somewhere in a common place
|
|
|
|
|
|
create random new files
This shouldn't happen anyway, but this change helps avoid error conditions
|
|
|
|
logger is constructed
otherwise the next recording would assume that a midnight has passed and write bad values to the sensor
|
|
The step counter is now set in hardware to the previous reading + any changes when the daemon starts
This means that the step counter now just records the raw step counter value, and adjusts it correctly when needed
This introduces a bug where the step counter will show bad readings if the daemon is restarted without a system reboot:
the step counter's current value will be added to the last recorded value, which will cause the number of steps to effectively double in most situations.
This might be fixed with some code to detect if a system reboot has passed since the last time the counter started.
|
|
The midnight detection code is basic, it just checks if the date has changed between days.
So that the user doesn't lose steps on their midnight outings, we write the current value to the previous day's log file before wiping the counter.
This will always be the previous day, even if recordings have been missing for a few days.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows the app to always show an up-to-date value
|
|
this works in general, but won't work on devices such as catfish or medaka, which are able to count steps when the step counter isn't active. Those will need custom code in the future.
|
|
This also renames it to sensorlogd from the obsolete asteroid-healthtracker and hides it by default
|
|
This code sets up all the paths used by sensorlogd before it is started
|
|
this independently accesses the settings file for the logger, and has a call to reinitialise it (which will cause settings to be reread)
|
|
This is to allow the logger to be reinitialised form qml
|
|
add interval and enabled settings for all sensors
get rid of some bad duplicates
make sure that application properties are set up before settings are accessed
|
|
- make sure that the reader doesn't create random files
- it is unclear why readwrite was used here in the first place, as readonly access is appropriate.
- make sure that `line` always has a value even if file is empty
|
|
|
|
|
|
- add separate subdirs for daemon and qml
- add some generic qml boilerplate
- add a really lazy 'last value' loader implementation
- license the project as gplv3 (add copyright notices and license text)
|
|
|
|
infrastructure to serve this.
I believe this is a useful improvement. The main two advantages are that a) it is very cheap to check whether a record exists for a given day - just check for file presence and b) there is a reasonable limit to the size of these files (never more than a few hundred records per day) which means that they can just be loaded into ram for processing without any complex splitting operations
Currently, the necessary `~/asteroid-healthloggerd/stepCounter` and `...loggerd/heartrateMonitor` directories are not automatically created and the code just vomits errors into log if it can't write to them.
|
|
initialising.
- This is quite crude - Firstly, we assume that the last record in the file is chronologically the last. This needs more consideration.
- we do check if we're on a fresh boot, but we just give up completely if it's not a fresh boot, which may work, but needs testing to figure out how it actually works in practice
|
|
- this should make things a lot easier to maintain. instead of having everything in the same file, each sensor provides a constructor that sets it up correctly etc.
- this should also get the step counter running when the service starts, which is necessary, since the sensor won't count on most devices unless the service is running.
- this also temporarily removes the gps module from the service. it's not implemented right now anyway.
|
|
|
|
|
