Temperature logging?

[martonmiklos]

Hello!

Many thanks for sharing this great project!

I was wondering if the plenty of flash memory could be used to store historical temperature data with low sampling rate. I do not want to use this for very accurately timed measurements just I think it would be a nice feature if the last couple days humidity and temperature could be stored and read later with --let's say-- 10 minute intervals.

I found an EEPROM emulation like function set in the API which could be used to store data (if working).

I was thinking about how to deal with the fact of lacking proper time source. Adding external 32.786 xtal is not an option because it overlaps with the I2C pins. Adding an external RTC to I2C would be an option but would be an overkill for my purpose.

My last idea was to send (and store) the time from the beginning of the measurement and when the stored measurement data is queried the current time and the measurement count could be used to assign an approximate timestamp to the measued data points. (If the internal RC clock used during sleep mode does not drifts too much during the measurements).

[atc1441]

Hey. Logging would be definitely a nice feature to have.

It is quite a lot of work thats why its not added right now. It is not only the firmware we need to change but also the browser side to get the data from the device and display it somehow.

It will be a future feature 👍

[martonmiklos]

Hey @atc1441

Many thanks for the answer! By thinking it forward (and inspired from the HaD comments) it might be better to utilise the remaining free RAM for data storage. I have not set up the build env yet, but do you have any indicative information on the available RAM?

[michapr]

I think it is a nice idea. Maybe it is more easy not to save the real time, but a counter of the timeframe? As sample if you have set a 10 minute interval then save the data every 10 minutes and increase a counter. So you will have a history depending on the last request time. Additional you could set the value of last internal clock counter for last save operation to define the last save time (3 minutes ago or 9 ... ;) ) - if needed. In such case you do not need to sync the real time and must not care about the internal clock sync after some time.

[atc1441]

Both ideas are good, so saving it to ram and making a history via the sync time, so when 10 datasets are there you know the firdt one is 100 minutes old plus the current time from the meassurement.

One problem might occour when using ram for this, it needs to be retention ram so it will not be erased on deep sleep

Thanks to @pvvx we have a good overview of the overall size https://user-images.githubusercontent.com/12629515/99157824-8c652980-26dd-11eb-98b9-c93018b3aaa2.png

https://github.com/atc1441/ATC_MiThermometer/issues/80

Also it looks like currently a lot of ram is wasted

[hldrm]

I think memory cleanup is something to worry about later – once we got it working ;-)

Let’s estimate the memory consumption of such logging mechanism.

Correct me if I'm wrong, here are the specifications that I am aware of: Temperature range: 0 to 60 °C, 0.1 °C intervals Humidity range: 0 to 99 %, 1 % intervals (Note: In case the sensors provide higher resolution, we might want to use that later on. Let’s stick to the resolution as displayed for now.) Thus, there are 601 distinct temperature values and 100 values for humidity.

For logging one data point (temperature and humidity), that leaves us with (at least) 10 bits for temperature and 7 bits for humidity, 17 total.

For logging intervals of 1 min, we need 60 * 24 * 17 = 24.480 bits = 3.060 bytes of data per day. For 10 minute intervals, that reduces to 306 bytes per day (plus maybe an additional byte for how long ago was the last measurement).

Those numbers basically mean that we can log data for a few days before having to worry about memory usage.

Once data is logged, how will we retrieve it? Via advertising would take some time. So connecting to the device manually (or later, some time triggered service) and then downloading it?

Looking forward to your thoughts.

[martonmiklos]

Hi @hlrdm

Yeah I wanted to start writing some specifications about this feature before my devices arrive.

I think we should implement the logging with a ring buffer approach which will be sized to the available memory. (Only the last n measurements could be retrieved after the buffer got filled.) I would make the logging of the two parameters (temp/humidity) optional (one might not care about the Humidity logging for e.g.) It might also make sense to introduce some GPIO change logging just in case if someone would hook a switch or whatever to the available pins. I would not hardcode the sampling interval. If I understood the current code correctly it woke up every 5 second. Above that granularity I would not limit the sampling time.

Retrieving wise: I am not familiar with the possibilities of the current stack, but I think we should download it via connection not by advertising.