[OpenTRV-dev] hello fellow rad devs!

[Damon Hart-Davis]

Hi

We can even give you access to JIRA!

We’re going to move across from SourceForge/SVN to GitHub when I get my act together, so at such point as we get there if you have some code/patches ready then we can do pull requests and so on.  Which is a round-about way of saying that I don’t think you need any commit access yet, but feel free to dispute that!

Rgds

Damon

On 3 Jul 2014, at 16:18, Gareth Coleman <EMAIL ADDRESS HIDDEN> wrote:

> Yes, I think that although my use case is a bit different from the wider goals there is still a lot of value in being able to control more than one valve per openTRV unit, for large rooms or 'zones' more generally.
> 
> I think it's an excellent idea that I look at that initially. After I get the hardware installed ready for the plumber sign-off in a couple of days!!!
> 
> Kind regards
> 
> Gareth
> 
> 
> On 2 July 2014 18:59, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:
> Hi,
> 
> We could do with lots of work on radios, including support for the RFM69CW, interrupt-driven code and security (encryption and key-distribution or pairing), to enable two-way working of the form you describe to be done safely.
> 
> But you could also consider developing run-time support to have multiple valves controlled from a single central node with the OpenTRV units just transmitting stats (eg temperature) to that central node and that central node controlling the valves.  That is not my preferred route for reliability and other reasons but may fit your use case better.  The OpenTRV nodes can already transmit stats without controlling a valve locally; I have one in my porch to track outside temperature…  And a side-effect might be to allow us to have one OpenTRV unit control multiple radiators in a single room.
> 
> Rgds
> 
> Damon
> 
> 
> On 2 Jul 2014, at 14:58, Gareth Coleman <EMAIL ADDRESS HIDDEN> wrote:
> 
> > I've just started hacking at the v2 board Damon was kind enough to send me.
> >
> > My immediate goal is to try to understand the differences between the RFM23 and the RMF12B's I've been playing with recently.
> >
> > Then I want to try to understand the protocol a bit better and how the system was designed to work.
> >
> > My end goal is to have actuators on the boiler and each radiator, a temperature sensor in most rooms, and a control system that is (or at least appears to be) a single interface.
> >
> > I can see that my use case is a bit different from the main project goals, in that I'd rather have a web/smart device as an interface over physical controls. I can see why that's good for some people but for me it's a real pain to have to go round the house twiddling knobs to affect the heating!!!
> >
> > I really believe it's all about the interface. If the interface isn't very very good - and this is a non-trivial problem - harder than building the physical device for example - then people won't use it effectively and therefore will miss out on energy savings.
> >
> > I've had a close look at the (daunting!) todo list at http://www.earth.org.uk/open-source-programmable-thermostatic-radiator-valve.html#planOE2014 - and it's not immediately obvious how I can help! Is there anything that I could usefully be doing for the project?
> >
> > Kind regards
> >
> > Gareth
> >
> > --
> > ------------------------
> > Gareth Coleman
> > layer zero labs
> > l0l.org.uk
> > _______________________________________________
> > OpenTRV-dev mailing list
> > EMAIL ADDRESS HIDDEN
> > http://lists.opentrv.org.uk/listinfo/opentrv-dev
> 
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
> 
> 
> 
> -- 
> ------------------------
> Gareth Coleman
> layer zero labs
> l0l.org.uk
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev