[OpenTRV-dev] Scope of the project

Tue Apr 2 18:43:05 BST 2013

One thing I realize I am uncertain about is the intended scope and
ultimate purpose of the OpenTRV project.

Several people have said that they got interested in the project
because nothing commercially available is adequate to their needs. On
the OpenTRV website Damon talks about the itch he wanted to scratch
which — I hope I interpret him correctly — was the desire to have
time-programmable TRVs with boiler control and room occupancy sensing.

Looking at the systems that are commercially available we see that
some of them already do almost all of what we have talked about here.
The most extensive system (Honeywell Evohome) lacks only room
occupancy detection and seamless integration with home automation
systems. MAX! is less extensive but it can be controlled from a
Control4 home automation system using a third party driver[1]; and
Living Connect TRVs can be controlled from a Fibaro[2]. These
commerical systems are still very new. Honeywell, Danfoss and eQ-3 are
occasionally announcing new components. It is quite possible that
desired features and modules will be added.  Then the question arises:
if one can buy an adequate system off the shelf, does one have any
need for the OpenTRV project?

This brings us to the "open" part of OpenTRV. Damon also talks about
this on the website. Even if, say, Honeywell comes out with occupancy
sensors for its Evohome system, it will still fail to be open. How
much does this matter?

Assuming that it matters enough for OpenTRV to carry on even when
functionally adequate commercial systems are available, the
supplementary question is, how much of the system has to be open?
Does the hardware have to be open, or is it sufficient for the
software to be open, so long as we can burn the software onto hardware
components for which there is assured supply?

Open-source software developer  ;)

More information about the OpenTRV-dev mailing list