[OpenTRV-dev] Paul's case

Tue Apr 2 15:52:36 BST 2013

OK, ignoring the XAP issue at the moment, since the protocol we're currently speaking is that of the FHT8V / FS20 (my boiler node simply eavesdrops to work out when the central heat is needed), and that "COC-Extender" board seems able to at least receive plain FS20, then we could probably tack the temp and target on the end.

But it sounds to me that if we had wireless reporting of temperature over some agreed protocol back to the RPi then you could do control of FHT8Vs directly.  (The TX timing is a bit of a pain, as is the encoding, but you now have example code in two languages to do it all for an RFM22 or RFM23 radio.)

Then all your room sensors and actuators are pretty dumb and easy to do.  You provide all the cleverness in software on the RPi.

(There are various nice wireless temperature sensors that you may be able to use immediately.)

Rgds

Damon

On 2 Apr 2013, at 15:37, Paul Smith wrote:

> Hi Damon,
> 
> In an ideal world each TRV would be an XAP endpoint so that it can report its status, Temp, Target and Valve status.
> 
> However that would require some cleverness in the TRV, so I'm thinking that would be in the Rpi. The XAP Floorplan windows app allows me to do if/then things and also timers and buttons.
> 
> So i think a Rpi as the central point which reads temps from room and can control a TRV. I can the code up a XAP interface. and either put the schedule in the Rpi or in XAP Floorplan.
> 
> Regards
> 
> Paul
>  
> 
> Paul Smith
> 
> Your Local Computer Specialist, Supporting Your Business When You Need It Most
> 
> We also now do Portable Appliance Testing, if you would like to know more please drop us a line.
> 
> Tel:-  0845 009 6226 
> 
> This email and any attachments may be confidential and/or privileged.  Everything is intended for use of the addressee only. If you receive this message in error then you must not print it or pass it on to anyone else or use the information it contains.  Please inform Phoenix Technology UK  of the error by email or by telephoning (+44)(0)845 009 6226.  Please then delete all copies from your system.
> If you are not the intended recipient then you must not use the information in the message or attachments or allow anyone else to do so.
> 
> 
> On 2 April 2013 15:22, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:
> Hi,
> 
> Where would that target (and indeed the schedule) be maintained, with the valve or centrally?  I'm being thick, sorry.
> 
> On 2 Apr 2013, at 15:13, Paul Smith wrote:
> 
> > reporting back its target and current state
> 
> The current OpenTRV implementation such as it is reports in effect its current state in terms of how far the valve is open: if shut then the room is at or above target.  The target is not currently reported as there is no place in the valve-command packets for it, but it could probably be tacked on the end without doing any harm and the RPi could see that.
> 
> I think we may need to draw up a block diagram to understand what functionality would be where for your ideal system, probably for one room plus your central RPi.
> 
> Then we can see how close the current system is to doing what you want, and who easy it would be to bend to fit!
> 
> Rgds
> 
> Damon
> 
> 
> 
> 
> _______________________________________________
> 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