Skip to content
A python-based intelligent home thermostat, targeted at the RaspberryPi.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github
docs
rpymostat
.coveragerc
.gitignore
.landscape.yaml
CHANGES.rst
LICENSE
MANIFEST.in
README.rst
pytest.ini
requirements_dev.txt
requirements_rtd.txt
setup.cfg
setup.py
tox.ini

README.rst

RPyMostat

Project Status: Abandoned – Initial development has started, but there has not yet been a stable, usable release; the project has been abandoned and the author(s) do not intend on continuing development.

A python-based modular intelligent home thermostat, targeted at (but not requiring) the RaspberryPi and similar small computers, with a documented open API. (Originally "RaspberryPyMostat", for 'RaspberryPi Python Thermostat', but that's too long to reasonably name a Python package).

Note that I attempted something like this a long time ago.

See docs/ for information.

This repository will hold the main Engine component

Status

This Project is Abandoned. I started work on it and decided not to continue. I doubt I ever will, but I'm leaving the code up nonetheless.

Architecture

RPyMostat is made up of four components, each of which is distributed separately. They can all be run on one host/RPi, or can be spread across multiple machines. All components communicate over a documented HTTP ReST API, so aside from the Engine, other components can be replaced with API-compatible versions written in other languages or for specific hardware.

  • Engine (this repo) - the "brains" which serve the API and make all decisions.
  • UI - the Web UI, which is simply a web-based API client.
  • Sensor - the temperature sensor daemon.
  • Control - the physical relay control daemon.

For further information, see the architecture documentation.

Features

Features planned for the initial release:

  • Flexible rules-based scheduling. This can include cron-like schedules (do X at a given time of day, or time of day on one or more days of week, etc.), one-time schedule overrides ("I'm going to be away from December 21st to 28th this year, just keep the temperature above Y"), or instant adjustments ("make the temperature X degress NOW", in the web UI). The most specific schedule wins. Inital scheduling will support some mix of what can be represented by ISO8601 time intervals and cron expressions.
  • Support for N temperature sensors, and scheduling based on them; i.e. set a daytime target temperature based on the temperature of your office, and a nighttime target based on the temperature in the bedroom.
  • Web UI with robust mobile and touch support. Ideally, the entire system should be configurable by a web UI once it's installed (which should be done with a Puppet module).
  • Some sort of physical on-the-wall touchscreen control, using the web UI.
  • Everything AGPL 3.0.
  • Scheduling and decision (system run) implemented in plugins (packages, entry points) that use a defined API; some way of reflecting this in the Web UI (maybe this should come over the master API). Initially just implement scheduling as described above and setting temperature based on one temp input; subsequent plugins could include averaging across multiple inputs, weighted average, and predictive on/off cycles (including outside temperature input).
  • Support running all on one RPi, or splitting components apart; should support as many OSes as possible. Support for smaller devices as temperature sensors would be nice.
  • Microservice/component architecture.
  • Open, documented APIs. Aside from the main engine, it should be possible to implement the other components in other languages.
  • mDNS / DNS-SD for zero configuration on devices other than the engine.

Features planned for future releases:

  • Data on current and desired temperature(s) and heating/cooling state will be collected. This should allow the scheduling engine to build up historical data on how long it takes to heat or cool one degree at a given temperature, and should allow us to trigger heating/cooling to reach the scheduled temperature at the scheduled time (as opposed to starting the heating/cooling at the scheduled time).
  • Historical data stored in some time-series database; should include all temperature values at the beginning of a run, and every X minutes during a run.

Requirements

  • Python 2.7 or 3.3+ (currently tested with 2.7, 3.3, 3.4, 3.5; tested on pypy but does not support pypy3)
  • Python VirtualEnv and pip (recommended installation method; your OS/distribution should have packages for these)
  • MongoDB (developed against 2.4, which is available in the Debian and Raspbian repos)

Installation, Configuration and Usage

See the Installation, Configuration and Usage documentation.

Development

See the development documentation.

License

RPyMostat is licensed under the GNU Affero General Public License, version 3 or later.

You can’t perform that action at this time.