@ -60,6 +60,8 @@ Most of the data is captured by two cheap RTL-SDRs (software-defined radios) tha
The data gets collected by a central Python script that process and stores it in an InfluxDB database for "efficient" storage. The script also runs a web server that queries the database and exposes the data over an API to the dashboard at various dates and ranges. The dashboard is written in JavaScript / React using a simple chart library.
My biggest regret was using InfluxDB. It's a stupid database and I wouldn't recommend it to anyone. I ran into timezone issues with `group by time()`. It also assumes the column data type is an integer if your sensor happens to send it a whole number at first and it won't let you change that. Their docs are terrible. They dropped the SQL-like InfluxQL syntax for querying with a pipeline-like syntax called Flux in version 2.0. Debian's repos seem to be staying with version 1.x though. You can only delete data by time ranges, not values. It also logs every single thing to `/var/log/syslog` and there's no easy way to disable it (completely).
## InfluxDB Regrets
Just stick to Postgres / SQLite.
My biggest regret was using InfluxDB. It's a stupid database that I wouldn't recommend it to anyone. I ran into timezone issues with `group by time()`. It assumes the column data type is an integer if your sensor happens to send it a whole number at first and it won't let you change it. Their docs are a confusing mess. They dropped the SQL-like InfluxQL syntax for querying with a pipeline-like syntax called Flux in version 2.0. Debian's repos seem to be staying with version 1.x though. You can only delete data by time ranges, not values. It also logs every single thing to `/var/log/syslog` and there's no easy way to disable it (completely). They shut down InfluxDB cloud in Belgium and [didn't warn customers](https://community.influxdata.com/t/getting-weird-results-from-gcp-europe-west1/30615/7) before deleting all their data.
