[OpenTRV-dev] V0.2-Arduino: getting started

[Mike Stirling]

On 01/04/13 13:07, Damon Hart-Davis wrote:
> On 1 Apr 2013, at 11:10, Stuart Poulton wrote:
>
>> I've been thinking about this, USB adds to the cost of a chip, yet allows for more configurability, I think I'm moving toward a model where USB and RF are used, so USB + Power for those TRV's where it's possible to cable, RF + Battery for those where cabling isn't possible.
> Hi,
>
> Note that any of the following may be reasonably wired or wired:
>
>    * (P) Power (eg wired via USB phone charger, unwired with batteries)
>    * (R) Radiator valve (direct drive via motor vs RF drive to allow for better placement of sensors and control)
>    * (B) Call for heat from central boiler (wired a la Wookey's house, RF where we don't have data cabling flood-wired)
>
> Where possible I'd like all units to be configurable (including setpoints, schedule and time) or reprogrammable via a local "USB" interface.
>
> But for lower-cost end-user deployments of very simple warm/frost devices that can go on the valve (wired valve) and have local mains power (wired power) available then I agree that a simpler design may be possible.  I suspect that wired boiler will be a rarity except for (a) geeks' flood-wired houses and (b) the TRV node in a room with the boiler such as my kitchen.
>
> We should maybe analyse the likely frequency of occurrence of the three wired/unwired combinations for our own possible deployments to get an idea of the combinations to support optimally?
>
> I'll start:
>
> 3 x bedrooms: power close to rads, no data wiring, so can be wired for power and rad (ie physical unit on valve head) but not boiler: 3 x P/R/nB.
> 1 x living room: power close to rad, *could put wire through wall to kitchen but probably unpopular*, so P/R/nB (or at a pinch P/R/B).
> 1 x kitchen: power not close to rad and rad not close to boiler, so current power-hungry always-RX combined node is good candidate for wireless rad valve and is P/nR/B.
>
> At least two of those bedroom TRVs would benefit a lot from being able to be locally configurable (ie not necessarily programmable) to have time and a schedule set, but a simple "learn" button on a 24h repeat (for 1h) might work fine.
>
> I'll copy some of this into the 'Case Studies' wiki page.
>
> Rgds
>
> Damon
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
Hi All,

Been too busy this weekend for anything other than lurking, but here is 
my 2p worth:

One thing not being considered here is value to OEMs.  I thought one of 
the key reasons for choosing a permissive license rather than something 
like GPL was to encourage manufacturers to use the project in their own 
products, encouraging interoperability.  If this is the case then there 
has to be a reference hardware design that is absolute lowest cost.

Using a hobbyist platform is likely to be off-putting as well, I 
therefore think that vanilla AVR is a good compromise, especially since 
the three of us here with AVR experience all prefer to work bare-metal 
anyway.  There is then nothing stopping us from doing a super-set 
reference platform with a more capacious AVR and the Arduino bootloader 
pre-loaded.

A cost-reduced platform (wired interfaces aside) would boil down to the 
AVR, radio, H-bridge and encoder, thermistor, and maybe a couple of 
buttons.  There isn't really a need for an external RTC since this can 
be implemented in software still with uA average power consumption, and 
it is even debatable whether the expense of a digital temperature sensor 
can be justified when a) it might not actually be any more accurate, b) 
we already talked about the UI being simply "I'm too hot" and "I'm too 
cold", in which case absolute accuracy isn't really that important.

I have been hacking at my Eurotronic Comet, by the way, but I will write 
about that in a separate post...

Cheers
Mike