[OpenTRV-dev] Scope of the project

[Damon Hart-Davis]

Hi,

All good questions!

My overriding primary aim is to try to make it easy and cheap and pleasant for everyone to save carbon emissions from heating: I think most people in the UK could halve theirs without hardship, and the UK has crappy housing stock and will for many years to come.

I think that open protocols (and software and hardware) will bring costs down and enable mix-n-match in the way I expect to be able to buy headphones from anyone that work when plugged into the stereo jack of anyone's laptop or MP3 player.

I also expect OpenTRV to make available combinations that are not currently available, including bridges into energy monitoring and HA.

I'm after a system which is less hassle and more efficient than what I (and many others) currently have, and maybe has a touch of Star Trek (TM) about it.

The reference implementations don't have to be the absolute best or cheapest, and they can have closed components as long as those components (such as the PICAXE BASIC interpreter) are not somehow fundamental to the entire chain from valve pin to boiler and have ready substitutes (eg that's why I'd like a parallel Arduino stack).

No, we're not building anything entirely new, but we're building something more open, more fun, more flexible, and ultimately cheaper and widely useable by more of the 26 million UK households (and Bo in Denmark!) that need to radically cut their carbon footprint.

Well, that's what I hope.

Rgds

Damon


On 2 Apr 2013, at 18:43, Thomas Hood wrote:

> 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?
> 
> [1]http://www.extravegetables.com/products/max_trv_heating
> [2]http://www.fibaro.com/en/the-fibaro-system
> --
> Thomas
> Open-source software developer  ;)
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>