|
2 months ago | |
---|---|---|
bin | 2 months ago | |
include | 2 months ago | |
src | 2 months ago | |
LICENSE | 3 months ago | |
Makefile | 2 months ago | |
README.md | 2 months ago |
Smart Thermostat for Raspberry Pi and eInk Display
Currently under development with no working release.
This project strives to create a control server and graphical client for the Raspberry Pi (specifically the Zero W) to provide smart thremostat options to a standard 2-wire mercury thermostat or 3-wire digital thermostat.
The goal is to create a server with a socket that allows for commands to be given, logic to determine the correct state of the furnace control given the commands and current conditions, and a configuration management system to store schedules and other preferences.
The server should also be readable with details provided for the current state and existing configuration settings.
The built-in client will provide a GUI for an eInk display with multi-button interface via the Pi's GPIO pins. Optional clients can also be created, such as a Web UI to send commands to the server and display current data.
See HARDWARE.pdf for detailed build documentation.
Integrating a smart device into either type of thermostat is quite simple. We simply need our device to be capable of completing the curcuit using two of the wires available within the existing thermostat. In either case, the existing thermostat should be left with all the wires where they are, but with an extra leads coming from the positive and negative lines. These will allow us to complete the curcuit using our relay, regardless of whether it is being completed by the existing thermostat. The control on the existing thermostat should be set as low as possible, or at least to the minimum “safe” temperature so that it will only kick in if the relay fails to complete the curcuit (ie. if the smart device is not functioning as expected). The furnace will be run if either or both thermostats complete the curcuit, so this will allow for a backup minimum temperature without interfering with the smart thermostats normal operations.
The interface with a standard 2-pin mercury thermostat is quite simple. In these devices, the mercury balances within a glass tube. When the room is at or above the desired temperature the mercury has expanded such that it's balance tips to the vacant end of the tube. When the room cools, it contracts, allowing the balance of the tube to shift, causing the mercury to slide to the other end of the tube. This end of the tube contains the positive and negative lead for the thermostat control and since mercury is conductive, it is able to bridge the gap between these and complete the curcuit.
Thermostats in North America traditionally run on 28V DC, so we simply need a couple of lead wires to a relay that is then controlled by one of the 3.3v GPIO pins on the Raspberry Pi.
Note that the hardware setup described here works correctly. I can modify the display using the WaveShare sample code and when I command heat via the Relay using the raspi-gpio
command I successfully get heat. So few, if any changes are expected to the hardware design.
Similar to the mercury thermostat, the 28V circuit simply needs to be completed. The difference with these devices is that the third wire provides a constant voltage so that the digital display may remain powered even when this circuit is incomplete. Simply identify the control and ground wires and leave the constant line alone. As above, change your digital thermostat settings to a backup temperature below that which you expect to be reached during normal operation so that it will only override the Pi in the event that it fails.
Exact implementation of the hardware is up to your own personal design decisions, but here are a few comments on my design:
The following heating modes will be targetted for an initial release:
The following preferences will be targetted for an initial release:
The following API functions will be targetted for an initial release:
The following Server functionality will be targetted (required) for an initial release:
In order to allow for other clients, a simple wrapper library will be created for each function of the API. This will provide easier reference material for other programmers to make their own clients in a high-level programming language. I'll probably do this in JavaScript since that will likely be my first target for a client, but it could easily be Perl or Python depending on how I feel at the time.
Development will be targetted at Debian Bullseye but the aim will be for Posix compliance. Will also aim for minimum dependencies, included in source or fetched during install where possible.
The bcm2835 C library has been selected for interfacing with the GPIO pins. This should be included with Raspbian (Raspberry Pi OS).
JSMN JSON parser is likely to be used.
Instructions will be available in INSTALL.md once a production release is available.
I'd be very interested in contributions for other localizations, heating modes, libraries and so on. Note that nothing is anywhere near being decided upon, so all aspects of the architecture, API, libraries, etc. are subject to change, so I'm open to all suggestions early on but cannot promise not to break anything if you do not communicate. Please open issues and pull requests through my Gitea (GitHub authentication is supported).