The amount of data coming from RuuviTags is so little that it’s trivial to do the initial crunching anywhere (converting the raw data to a more human friendly format, ie. temperature into a decimal number in celcius, rather than an integer describing one 200th of a celcius), and thus it makes sense to do this as early in the “pipeline” as possible, and leave the “heavier crunching” like computing averages and trends over a longer time period to later stages. Though it shouldn’t be an issue to process the data later, as mentioned. I guess it all depends on the desired setup.
The 2.4Ghz radio frequencies for Bluetooth will be overly saturated far before a RPi runs out of processing capacity for the initial processing in the collector. A synthetic benchmark earlier in RuuviCollector development showed the capacity to process around 20 000 measurements per second on a RPi3b, and far exceeding 100 000 measurements per second capacity on my PC. (the benchmark was done from a dummy datasource generating fake hcidump output as fast as possible and the collector parsing it as normal). Not being a bottleneck was one of the original design criterias for RuuviCollector development, and it turned out to be trivial to accomplish.
Another design criteria for RuuviCollector was to have a relatively standard and easy way to “decouple” the collection process from everything else, ie. have the collector running on a RPi somewhere in the corner and everything else on a real server (or everything just on the RPi itself). It’s nice to see a well documented and implemented setup of this “decoupling”, nice work there @bostrom I’m planning on adding a small “example setups” section to the RuuviCollector repo, I hope you don’t mind if I link to your setup from there