Battery log

[jmlich]

I am collecting battery information into kexi and painting graph.

(Data are fake on the screenshot).

[jmlich]

After few days it looks like this:

Current implementation stores only a few points per day.

sqlite> SELECT timestamp_dt, count(*) FROM battery_log GROUP BY date(timestamp_dt) ;
2023-09-29T14:28:15.911|3
2023-09-30T07:18:47.616|3
2023-10-01T13:01:14.502|2
2023-10-03T06:20:43.640|4
2023-10-04T07:02:44.950|3
2023-10-05T18:06:24.284|1
2023-10-06T09:17:03.669|8

Restart of daemon leads to storing extra point

[piggz]

I wonder if instead of being a battery-log, we could make this a bit more generic, and make it a log of some key, Battery being the first? This would let us log many other values in the future without creating more tables. What do you think?

[jmlich]

Yes, I was considering that as well. I ended up with feeling, that it worth of it to create new table, because otherwise there must be always extra condition for certain value. On the other hand the separate table will have better probably performance. I have testing branch https://github.com/jmlich/harbour-amazfish/tree/ubports-with-other-patches I am logging steps and heart rate activity separately. I don't have strong opinion about that. I was also wondering if it should store the device id same as are in steps+hrm table

The daemon stores value into database only when the value is changed. The trouble is that it is a new value after every restart of daemon (when app is reinstalled or device rebooted). I am not sure how graph component works, because big number (e.g. 10 samples) of same battery level changes angle of line in graph.

[jmlich]

It looks like this is working as expected. I have implemented also generic info log in the other pull request, but personally I prefer this one.