Split into frontend and backend #44

Open
opened 2018-09-21 15:47:07 -05:00 by mattbk · 2 comments
mattbk commented 2018-09-21 15:47:07 -05:00 (Migrated from github.com)

My goal with this project is still to develop a way to deploy multiple (cheap) sensors and be able to view data from them all simultaneously. This should not require each sensor to have its own full-fledged GUI running, just a barebones API endpoint that serves the data.

So there should be two apps in addition to the cron script that collects the data and saves it in the database; one to act as the API endpoint and one to act as a GUI for visualizing the data. The latter could be in Flask or Shiny or whatever. It would hook into the sensor APIs, cache the data, and allow the user to do whatever with it. If a web application isn't needed, the data could go straight to a live R/Python session or script. A nice feature to have would be for the sensors to all ping a server to announce their address periodically so they don't get lost when networks change around.

Notice how I haven't specified the sensor type? That's because it shouldn't matter. The system should be applicable to all types of sensors, plus pis with multiple sensors connected.

My goal with this project is still to develop a way to deploy multiple (cheap) sensors and be able to view data from them all simultaneously. This should not require each sensor to have its own full-fledged GUI running, just a barebones API endpoint that serves the data. So there should be two apps in addition to the cron script that collects the data and saves it in the database; one to act as the API endpoint and one to act as a GUI for visualizing the data. The latter could be in Flask or Shiny or whatever. It would hook into the sensor APIs, cache the data, and allow the user to do whatever with it. If a web application isn't needed, the data could go straight to a live R/Python session or script. A nice feature to have would be for the sensors to all ping a server to announce their address periodically so they don't get lost when networks change around. Notice how I haven't specified the sensor type? That's because it shouldn't matter. The system should be applicable to all types of sensors, plus pis with multiple sensors connected.
mattbk commented 2019-12-11 11:35:15 -06:00 (Migrated from github.com)

I think what I am looking for is MQTT: https://appcodelabs.com/introduction-to-iot-build-an-mqtt-server-using-raspberry-pi

MQTT stands for Message Queuing Telemetry Transport, which sounds scarier than it is. What it boils down to is an easy-to-use and flexible protocol that allows you to send arbitrary messages across a network to any other device that is interested.

Sounds a lot like APRS!

I think what I am looking for is MQTT: https://appcodelabs.com/introduction-to-iot-build-an-mqtt-server-using-raspberry-pi > MQTT stands for Message Queuing Telemetry Transport, which sounds scarier than it is. What it boils down to is an easy-to-use and flexible protocol that allows you to send arbitrary messages across a network to any other device that is interested. Sounds a lot like APRS!
mattbk commented 2020-06-06 11:18:09 -05:00 (Migrated from github.com)

To simplify plots, could use something like this:

Maybe a terminal view? 🤔

To simplify plots, could use something like this: - https://github.com/Evizero/UnicodePlots.jl - https://github.com/tammoippen/plotille - https://github.com/mkaz/termgraph Maybe a terminal view? 🤔
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: matt/pi-temp#44
No description provided.