Pi Zero Ruuvi Gateway implementations


#21

I’m really intrested to get RuuviTracker when the time is ready, but would definitely buy this RPi Zero W from you now if available. In fact I already today ordered ingnics gateway, but have to cancel that order cause even when the price was reasonable (42USD), the shipping to my address wasn’t (70USD). So back to startpoint…

Just few questions about this RPi Zero W option:

  1. Could there be two option, one with grafena, another as gateway to thigsboard.io?
  2. When you say gateway, I assume it will send the data to the cloud service, no need to act as server, open port (not always possible, depends…) for data to be read from server?
  3. Would it help with SD card usage time, if some partitions would be read only (unless needed to upgrade whole system with updatescript*) and bit smaller partition for sensor data with write permission? At the end the data would be at the cloud anyway.
    *scurip would unmount readonly partitions & remount those with write permissions for update process, after that again unmount those partitions and mount as read only…

Offtopic: I hope you will make raincauge and wind meter also + IR distance meter (for snow measurements). Probably not suitable for RuuviTracker, but as separate Beacons.


#22

Good ideas. I agree. I really like the ruuvicollector - influx - grafana combination running in raspi3. However I need a connection to any common cloud service in order to handle the data further.
I am a dummy in programming, that’s why I like node red approach of block building. I have done some experiments in IBM cloud collecting data from LoraWAN devices through Digita’s network and Thingpark service, as well as from RuuviStation by simple HTTP POST commands. It seems to work OK.
What about splitting existing RuuviCollecor-influx-grafana into separate parts and doing a new HTTP POST interface (similar than in RuuviStation) in between RuuviCollector and Influx?
If possible, would be fine to get it running in Raspi zero W. Unfortunately I can not much contribute this work, because my lacks in programming skills and lack of Linux skills, but I am ready to make e.g. instructions how to set up the system, if I get some advice.
Just one comment about using Raspi: The BLE + WiFi antenna is very poor and gives very small coverage. Needs to install an external antenna. Then the coverage is about the same than by mobile phone, but this may violate EMC regulations.


#23

What about splitting existing RuuviCollecor-influx-grafana into separate parts and doing a new HTTP POST interface (similar than in RuuviStation) in between RuuviCollector and Influx?

Actually that’s how it works at the moment, the data points are sent from RuuviCollector to InfluxDB over HTTP POST using the InfluxDB Line Protocol, similarly how Grafana is querying the data from InfluxDB over the InfluxDB’s HTTP endpoint. So if you want to add something in between without needing to alter the code of the existing applications, you can just add your implementation in between.

For example, if you want to create a middleware between RuuviCollector and InfluxDB that both sends the data to InfluxDB and saves to a .csv file for example, you can do it so that the custom application in between is able to receive data with HTTP POST and understand the InfluxDB Line Protocol, do whatever it wants with the data (ie. write to a CSV file) and send the same data payload further to InfluxDB with the same HTTP POST.


#24

Sorry to keep banging on about it but the Sensor data collection really should be decoupled from the Cloud data collection as is done in the Android Ruuvi Station where the collected data is passed to a Cloud system via a HTTP POST that isn’t going directly to a backend database. I’ve done some work over the weekend on writing a Node Red Flow that works like the Ruuvi Station in terms of sending the collected data via a Gateway.


#25

Has anyone considered using the syslog set of protocols/utilities for gatewaying the ruuvi data. It seems like a natural. It’s implemented on most systems, includes considerations for rapid data reception, classification of messages, well defined configuration, archiving data, forwarding to other systems. The rsyslog implementation includes storing data in various databases in addition to regular files. This subsystem is already used to collect data from various devices including routers and printers. Some of my thoughts at http://mybeacons.info/jakoavain.html