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

[Kevin Wood]

Apologies for the delay.

I've actually been thinking about what would make an ideal boiler / valve
control node for me. On the basis that (hopefully!) the weather won't call
for heating too much longer, and that my current tank thermostat keeps
arcing, that might be a good place to do "summer hacking" for me.

I have got round to having a look into the RFM12Pi. It's basically an
ATTINY84 with an RFM12 connected to the SPI and it bit-bashes serial data
to and from the Pi on 2 other Io pins. 3 spare pins are brought out to a 3
pin header so I guess these could be employed to drive valves. It might
also be possible to read Onewire temperature sensors on one of the spare
pins, I guess. The serial protocol is a very simple human-readable ascii
command driven affair, so I don't see a problem with extending that.

I keep wondering if a very simple node talking to a Pi, which can give me
web access to set the schedules, etc. is what I want or whether this
should be a more autonomous "boiler programmer" with "advance" buttons,
scheduler, RTC and maybe even a user interface to program it manually.

I keep think that the RFM12Pi is a bit too minimal to cope with what I
might want to throw at it. I might build something around a more powerful
AVR, containing some switching for the valves, and see where that takes
me.

I wonder if I should still connect it to a Pi, or give it an ethernet
interface?

Kevin

> Hi Kevin
.
>
> i was thinking
. how hard would it be to add valve control on the rasPI +
> expansion board that open energy uses? it would be an perfect central unit
> and if it can control valves we would almost only need some boards that
> can sense temp
. just loose thoughts from me

>
>
> /bo
>
> Den 01/04/2013 kl. 10.35 skrev Kevin Wood:
>
>> Hi Damon,
>>
>> A few musings on using an AVR...
>>
>> It might be worth a read of the notes here if you haven't come across
>> it:
>>
>> http://openenergymonitor.org/emon/emontx
>>
>> No personal experience but a similar beast based loosely on an Uno.
>> There are some notes about optimisation of power consumption there which
>> might be worth a read.
>>
>> I've never used an Arduino but I've used AVR devices quite extensively
>> using just the GNU toolchain, AVR Libc and AVRDude to program them using
>> an STK500. Arduino adds a nice development environment and a boot loader
>> to allow the chip to be programmed through USB / RS232, as I understand
>> it. I must pick up an Arduino and have a play sometime.
>>
>> Unfortunately I don't know a lot about PICAXE.
>>
>> There are a couple of AVR libraries around to drive the RFM12. I did try
>> to get one working with the RFM01 and RFM02 but the latter devices are a
>> real pain to drive in comparison to the RFM12 and I haven't (yet!)
>> cracked them. I think an RFM12 will connect straight to the I2C pins on
>> port B of the 328.
>>
>> I've got some C code that drives Dallas 1wire temperature sensors from
>> an AVR, by the way. I use that in an AVR based PID controller I made for
>> my home brewery.
>>
>> The UNO has a separate AVR handling the serial port. I wonder how easily
>> the power supplies to this can be separated from that to the AVR device
>> running the "user code", as this will no doubt affect the current
>> consumption adversely. It might be that it'd be best to knock up a board
>> or two with an ATMega328, RFM12, Onewire device, etc. and use the UNO to
>> program it?
>>
>> Or just buy one from openenergymonitor.org, of course.... ;-)
>>
>> Cheers,
>>
>> Kevin
>>
>> On 30/03/13 12:31, Damon Hart-Davis wrote:
>>> Hi,
>>>
>>> I'll need some help getting going on this.
>>>
>>> Right from the outset I'd like to build something compatible with
>>> battery (and RFM23) voltage, relatively power-efficient, and that can
>>> share peripherals (I2C and SPI) with the PICAXE version for simplicity
>>> maintaining two stacks, and that is end-user reprogrammable.
>>>
>>> How should I start?
>>>
>>> (I have an UNO and a Leonardo on my desk, waiting.)
>>>
>>> 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
>
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>