mbtown01 / frosti Goto Github PK

Currently, the FROSTI device has a database and stores all of it's state and configuration there.

To build a more resilient device, we need to make the SD card completely read-only. To do this, we need to at a high level:

• Remove our dependence on a database, keeping all local state in memory (with some reasonable buffer, say 1 month)
• Remove grafana from the device as it requires a database to communicate w/ the device
• Add a single-page app (hosted by the main FROSTI process) that lets the user interact with the device
• Build a back-end API that lets the device push measurements somewhere else to be analyzed

If done well, the back-end API could be on the web of hosted locally. 1st pass would just include pushing measurements so if FROSTI reboots it can pick up where it left off, even with historic data.

We can also potentially leverage the on-board EEPROM for storing things like

• A device UUID for the web API
• Last known configuration (which shouldn't take too much space, not sure if this is necessary)

Currently, we're pulling the entire window to get things like 'current temperature'. The scalar values need to have a static window of the past say 5 minutes... If the data isn't there, then something else is wrong.

Need to tie relays back to GPIO inputs to track their state (either replacing or putting in-line w/ the LEDs we're currently using)

Could pump this directly into influx from a separate daemon process

Should do this in the ThermostatService for consistency

Use case here is for setup where the main software isn't running, but we'd like to alert the user to what's going on. With the CLI, we can issue images to the display and operate the lights. Ideas were:

• During setup, show progress and what the current step is
• Clear all status at boot time

It may make sense to create a daemon service that owns both the LED ring and the epaper display (or maybe two daemons). With a simple API bound only to the local host, this daemon could run independently of the main logic and start early. This lets us do things like....

• Simplify what's actually happening in the more critical thermostat logic
• Separate python interpreter so that screen updates don't eat up event time

How does someone get started w/ the thermostat?? From imaging an SD card all the way to getting on the Wi-Fi network

This should effectively replace the terminal-based version of the user interface. Even for a developer experience, the UI could be exposed via a simple python window or even an HTML page w/ some kind of refresh

Focus on initial configuration and schedule design

Need to understand how frequently the watchdog timer is playing a role

Dash integration for a simple single-page app for configuration/setup

Guiding principles:

• This may be the only web-based integration a user gets (e.g. w/o backend container)
• Should some recent data, but not designed to keep all data over time, just from last boot (need back-end container)

Should expose the following:

• General configuration (things like the setup constants, time zone?? )
• Program (how many programs, when they run, how to respond to price)
• Status/Insights (some simple charts showing price/temperature)
• Controls (maybe even a web-based FROSTI w/ the buttons?!?!).

Watching the log, system kept saying price update was in 120 seconds (2 minutes) but said it every 5 minutes.

Currently, if a schedule is configured, it seems the thermostat will follow it even if it's in 'COOL' mode.

Maybe pick 4 and have 16 versions available??

I'm pretty sure the Pi is looking for a hi->low edge. A power dip could cause enough of a voltage drop at the pi for this to look like a button press. Maybe simply looking for low->hi edges would be a better solution here.

We are creating the SD card to have a read-only partition (hopefully to avoid "bricking"), so we should allow the user to drop a backup to their local machine and later restore it after FROSTI comes back online and re-creates /var.

thermostat
grid
power

curtailment
utilization

market
spot price
cost
bill
price
financial

open hardware, open source

warns / informs of power $$

What does it do??

• watches the power market responds to power price
  • less cooling when power is $$, saves money
• lights up with information on what's going on w/ price/temp
• sees what the market is doing

Ideas:

• Thermiser
• COST, TOaSTy?, GHOST, really anything with OST
• OUTPOST
• FROSTI (Financially Responsive Open-Source Thermostat Initiative)

Seems to occur when the thermostat board closes a relay for AC or HEAT. Solution could be as easy as some power filtering capacitors on the board

Good write-up of how to do this mostly with systemd and some python below:

https://www.medo64.com/2019/01/systemd-watchdog-for-any-service/

Installation process should include an influx docker image so the local process can direct data here instead of somewhere off-board. Can also be used to log as events occur and not at a specific time interval. Would need to have some kind of data warehousing scheme to only keep x days/weeks/months/years of data.

• .1 and 1 uF capacitors need redistributed for power filter near the LED drivers
• the 4.8kOhm resistors are still NOT 0805?!?
• cap C10 should be grouped w/ the other .1 uF caps
• MOSI and SCLK are backwards
• Potential issue w/ GPIO 7 and 8 being related to the SPI function??
  • Should be able to use GPIO 5 and 6 on pins 29 and 31

Starting from cooling, moving to 'heat' mode and make the target super high. Thermostat never seems to change out of cooling.

Combined with alerting, a health-check module could look at past trends and see whether the AC system is performing like it has previously.

Would probably want to combine this w/ a weather station as close to your home as possible so we can correlate outdoor/indoor temperatures.

Could potentially detect poor performance, but should be relatively easy to check for NO performance!

Need to eliminate the noise. For production, need to rely on syslog.

Item used to track feature requests for board v5

• Relay feedback via GPIO so we know we've successfully opened each relay
• Clear labels for each connection so it's obvious how to connect (includes board-to-board connections, jumpers, and even the connection to the thermostat wires to not just be color but also function)
• Diagnostic LED header so it can be enabled/disabled
• Encode a hardware 'version' somehow

Currently, we're using postgres locally on the RPi to store data. This was already a fairly heavy solution, but if we want FROSTI to be as rugged as possible, frequent use of the local SD card as the backing store for Postgres is a weak spot.

If we can cache updates locally and then push data to Azure at some frequency, it would essentially eliminate the need for the local SD card to be anything but readonly.

Need to talk w/ some cloud folks on the right first steps here. A cloud-based DB with an API frontend may be ideal, but I'm sure there are lots of other ways.