[OpenTRV-dev] Possible basis of OpenTRV hub?

[Kevin Wood]

Well, the changes to the OpenTRV node shouldn't be too onerous. I guess
you'd need to reconfigure the RFM to talk OpenTRV mode, send your packet
of data to the hub, optionally listen for any response / acknowledgement
and retry as required, then revert back to OOK mode for next time you
access the radiator valve.

The hub could be a standard RFM12Pi on a raspberry Pi running OpenCMS,
initially, at least. You'd need some changes to the script that drives the
RFM12Pi if you want to send messages back to change settings on the
OpenTRV rather than just log what's going on, but for simple logging,
everything's already in place.

Kevin




> been thinking about it and kevin you are right
>
> extending the OpenTRV to talk OEM'ish is the way to go
>
> it can then send back temp, battery etc plus how much open it has decided
> the valve has to be.
>
> but how many of the paramters can be put in the central hub?
>
> and who have the skill to do such a programming job?
>
> i can only guess that the node side might be easy, but what about the
> emoncms side?
>
>
>
> -----Oprindelig meddelelse-----
> From: Kevin Wood
> Sent: Wednesday, April 09, 2014 3:15 PM
> To: Closed list for developer discussions
> Subject: Re: [OpenTRV-dev] Possible basis of OpenTRV hub?
>
> I've actually just come across this, which looks to be quite a good
> description of the Jeelib RFM12 implementation.
>
> http://jeelabs.org/2011/01/14/nodes-addresses-and-interference/
>
> Kevin
>
> _______________________________________________
> 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
>