[OpenTRV-dev] hello fellow rad devs!

Gareth Coleman EMAIL ADDRESS HIDDEN
Thu Jul 3 16:18:32 BST 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20140703/419fae47/attachment.html>


More information about the OpenTRV-dev mailing list