mattbk / pi-temp Goto Github PK

See https://gitlab.com/eerc/pnlz.

Page URLs aren't intuitive.

Have a switch on the history page so you can go between monotonically increasing and monotonically decreasing segments.

See #30 and #7.

In interface, e.g., period of time where T is above 75 degF, or below 59 degF during the selected period.

So they show up in the chooser.

Other ways exist now! I just recreated most of this in a few hours with an ESP32 dev board, MQTT, and Node-RED.

There's no need to dedicate an entire Linux machine (i.e., Raspberry Pi) to the simple task of passing along data to be visualized.

Can't use the calendar buttons.

Replicate: http://xx.xx.xx.xx:8080/history?from=2017-11-24+22%3A29&to=2017-11-25+22%3A30&timezone=America%2FChicago

Related to range_h being undefined. Need to calculate that based on input values in get_records.

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.

I just hardcoded it a few places to get things to work when started from rc.local, but this should be set as a variable and used as needed.

If you have two pis running on the same network, should be on different ports for forwarding (although could use local IP for passing data).

Original code in DHT22, but I have a DHT11 to use for outdoor measurements. Need some sort of config to read each one the right way?

DHT11: https://www.raspberrypi-spy.co.uk/2017/09/dht11-temperature-and-humidity-sensor-raspberry-pi/

With Flask.

Should improve performance because data don't need to be sent for plotting.

• source code is from book, modified by [fork source]
• include cron command
• include example use case(s)
• include how to start and keep running (screen) and how to kill

So loading them is easy.

Not sure if date pickers really needed anyway.

Both for storage and display. Why would they be in different db tables anyway?

Absolute path to be used for config.ini and database, because this script is run by cron.

http://getskeleton.com is in use now. Bootstrap if fancier things are needed.

Including 1 week, 1 month, etc.

Not a pi issue, definitely the flask app. Not memory or cpu limit afaict...

To note changes, etc.

Following #30 and #31, what if you're in a shoulder season? Maybe check monotonicity as well as rate of increase/decrease of temperature.

I think this is because it's trying to query and getting nothing, after plugging in after a long time without data. Message in terminal:

REQUEST:
ImmutableMultiDict([])
range_h_form not a number
Received from browser: 2019-12-09 00:00, 2019-12-09 17:07, Etc/UTC, nan
2. From: 2019-12-09 00:00, to: 2019-12-09 17:07, timezone: Etc/UTC

Depends on data frequency, obviously.

Original plan was to use second Raspberry Pi to log hyperlocal outside temp and use that to compare, but probably quicker and nearly as accurate to query daily average temperature from a weather API.

The reason for doing this is to get more granularity for temperature values than a monthly therms statement does. Over the course of a year, you would get 12 pairs of therms/temperature values (and some of those would be meaningless if during the summer). That's not enough data to draw reasonable conclusions about the relationship (and confidence envelope) between the temperature and how much the furnace runs.

More granularity is needed if you want to change something about the house (raise or lower the thermostat setting, add insulation/sealing, increase/decrease number of people living in the house, etc.) and see the effects sooner (within days or weeks) rather than later (months on the statement) or never (if there are multiple factors, during the month, or the outside temperature doesn't hold steady).

I don't have a good grasp on an easy way to automate significance testing, but confidence limits around the regression line would be a start. Now this is starting to sound like my day job...

Delete old database entries so the db doesn’t take over all available space (“if count()>1000 drop etc.” or by timestamp, but row count is easier).

Probably configurable in the Flask app itself.

Set up API endpoint to query, then a main application can query known URLs to build a comprehensive interface.

I'm not sure how other multi-pi solutions work, but this seems simple enough.

Put table of values below plot. Combine with #4 and #2.