RFC: format 5+1 i.e. 6

I would like to solicit comments regarding a proposed new packet format.
It is actually a one byte extension of RAW format (format 05) called RawWithDelta.

Background:
Regarding air pressure reported for the environmental (weather) considerations: in addition to the current value, the change is considered important. It is generally considered that increasing air pressure indicates a change to fair weather and a decrease a change for stormy weather.

Regarding temperature it is desirable to know whether the temperature is greater than previously which may be interpreted that the temperature will continue to rise, at least in the near future.

Similarly with humidity.

Proposal:
I would like to propose 1 additional byte as a set of 3 2-bit fields to indicate recent change of temperature, humidity and air pressure (total 6 bits with 2 for future usage).
Where
00 indicates no change (or small enough to be considered insignificant),
01 indicates a significant reduction in the value,
10 indicates a significant increase and
11 indicates that either the current or previous value was invalid.

Considerations include:

  1. Will previous time period of 1 hour provide a good reference?
    2a) Is a value of 1 degree centigrade a good choice for significant change?
    2b) Is a value of 5% a good choice for a significant change in humidity?
    2c) Is a value of 2hPa a good choice for a significant change in air pressure?

As an example:
If the average air pressure during the previous hour was 1002 and the current value is 1020, the air pressure delta bits would be 10.

Notes:
A) The android phone app can show a graph of values but only if the tag is continuously available.
B) The iOS version cannot show history because of the apple restriction prohibiting receiving packets when the app in not in foreground. .
C) The RuuviCollector - InfluxDB - Grafana on RaspberyPi is an excellent set of hardware and software which can be used to infer trends but it can only do so when the tag is within range for an extended period.
D) Parsing this new packet is simply parsing the RAW (format 05 ) packet and then parsing the additional byte.
E) I am in the process of finalizing the code additions which require a one line function call in the main program and additions to the packet formatting module.

There are no free/unused bytes in the data format 5. :thinking:

Instead of amending the format 5 with a single byte like that, I would suggest an actual “delta dataformat” that would, for example, be identical to the current data format 5, with the difference that the “measurement sequence number” is replaced by a “measurement age indicator”, perhaps at 1 unit = 1 minute (or something).

That way a value of 60 would indicate that “this measurement was taken 1 hour ago”. A tag could then, for example, alternate between format 5 and this delta format on every 2nd transmission (or any ratio) and the client device could then draw its own conclusions regarding the change after having received one of each format. This would also keep backwards compatibility with existing client applications that support only format 5 (or ones that only care about the latest measurement).

With a format like this a tag could even be, for example, alternating between current (format 5), 1 minute ago, 1 hour ago and 1 day ago measurements, and a client application could then display this information, too (after receiving one of each). This would actually be quite similar to what I have done by using Automate on my phone to pull delta data from my RuuviCollector setup and display it in a minimum-priority notification (similar to how Nearby notifications used to work):

1 Like

Thanks for you thoughts.

Having two bits for direction of change might be a little too open for interpretation: for example a fridge oscillates quite a bit and the direction would change as the timeslots move over the temperature oscillations.

That same problem is present in difference to one hour or one day ago. Ideally data would be stored to RAM and older data could be read over GATT, but adding 2-way communication brings its own implementation and security issues :thinking:

1 Like

The idea is to “dampen” oscillations like in the fridge and indicate a trend. If the fridge temperature changes every time you open the door that’s OK. Over time, like overnight (excluding those 2AM snacks) an upward trend is important to know.

My initial idea was prompted by the fact that many of the commercially available temperature/humidity/ air-pressure displays include a trend indicator.

Regarding air-pressure: I always thought that, for weather predicting, the important thing was: rising indicates clearing; falling indicates stormy. However, looking at the data I’ve collected lately I cannot see any correlation between air-pressure and weather we’ve experienced!