[OpenTRV-dev] Possible basis of OpenTRV hub?

Tue May 6 12:50:43 BST 2014

And do they not also have a group id ?

ie so that one house or unit have one id, and the people next door picks 
another?

just so that 2 unit with same id close to each other dont clash

-----Oprindelig meddelelse----- 
From: Kevin Wood
Sent: Tuesday, May 06, 2014 1:39 PM
To: Closed list for developer discussions
Subject: Re: [OpenTRV-dev] Possible basis of OpenTRV hub?

>>I guess we're going to have to think about what we want to log and how
>>often.
>
> Yes temp and valve
>
> but we also have an LDR there... and battery level...

Yes, good point. I forgot about these.

Another issue I forgot is how that OEM nodes are identified using a 5 bit
ID. We should consider the easiest way to allocate IDs to the nodes.

> cant think of anything else right now
>
>
>
> But kudos to the work you do... its much needed and guess damon will look
> with much interest too
>

Well, I haven't actually *done* much yet, but I'm working on it!

Kevin

>
> /Bo
>
> -----Oprindelig meddelelse-----
> From: Kevin Wood
> Sent: Tuesday, May 06, 2014 1:29 PM
> To: Closed list for developer discussions
> Subject: Re: [OpenTRV-dev] Possible basis of OpenTRV hub?
>
> Hi Guys,
>
> Just a short update. Not spent much time on this yet but I've got an
> OpenTRV and managed to fetch and build the latest OpenTRV code and flash
> the resulting binary to the OpenTRV, so I have a usable development
> environment!
>
> Sounds trivial but there were a few hurdles to cross, such as realising
> that my FTDI adaptor was non-standard and trying to present 3.3v to one of
> the ground pins on the OpenTRV. Fortunately I noticed the hot IC on the
> adaptor before it perished! It might be worth us bearing in mind that this
> issue exists with FTDI cables sourced from the OpenEnergyMonitor shop.
>
> I'm now working on the RFM23 configuration for the OpenEnergyMonitor
> signalling protocol. Unfortunately they use the RFM12b as opposed to the
> RFM23, and the 2 modules are different enough that I might as well start
> from scratch there. I will put together a code module to reconfigure the
> RFM23, send a packet as an OpenEnergyMonitor node, then configure it back
> to suit the FHT8 signalling. Initially I'll trigger this using a GUI
> command. Once it's working we can figure out how to schedule it into the
> normal operation of the OpenTRV.
>
> I guess we're going to have to think about what we want to log and how
> often. Temperature and valve opening are obvious candidates but I'm not
> yet familiar enough with the internal workings of OpenTRV to know what
> else might be of interest. Something to ponder, but not critical at this
> stage. I'll concentrate on getting basic comms working first.
>
> I've also realised that my OpenEnergyMonitor stuff all uses 433MHz RF
> modules, so I'm hoping they will work well enough at 868 for some basic
> testing, at least.
>
> Anyway, I'll keep you updated with my progress.
>
> Best Regards
>
> Kevin
>
>
>> I think Damon got some spare units you can play with, if not I'm home
>> going
>> so can test code pretty often during the day
>>
>> Do you have SVN access?
>>
>> it will be 3 weeks or so before the boards get back from china so not so
>> much rush
>>
>>
>>
>>
>> -----Oprindelig meddelelse-----
>> From: Kevin Wood
>> Sent: Friday, April 11, 2014 12:22 PM
>> To: Closed list for developer discussions
>> Subject: Re: [OpenTRV-dev] Possible basis of OpenTRV hub?
>>
>> I could probably add the code to OpenTRV reasonably easily - to send
>> values for logging on EMonCMS, at any rate. Receiving data from any
>> scheduling extension to EMonCMS might be more of a challenge.
>>
>> The problem is, I don't have any OpenTRV hardware to test it on, so I'd
>> have to code it "blind".
>>
>> One thing I would say about EMonCMS on the Pi is make sure you get the
>> RFM12Pi V2 rather than the earlier one, as the RFM12Pi firmware can then
>> be updated from the Pi itself and this makes it much easier to
>> experiment.
>>
>> Kevin
>>
>>> if it helps anything i have thought of setting up a pi to run
>>> emoncms...
>>> need to have a platform to test my version of the GivMon interface
>>> anyway
>>>
>>> if anyone are up to coding a module for Emoncms and extending the
>>> OpenTRV
>>> i'm happy to provide ssh access etc to the pi and test arduino code...
>>>
>>> mind you i run Rev1 boards
>>>
>>>
>>> i imagine if anyone has the time and success with this we could almost
>>> drop
>>> the UI at the box and concentrate on a web ui instead :-D
>>>
>>>
>>>
>>> -----Oprindelig meddelelse-----
>>> From: Damon Hart-Davis
>>> Sent: Wednesday, April 09, 2014 9:04 PM
>>> To: Closed list for developer discussions
>>> Subject: Re: [OpenTRV-dev] Possible basis of OpenTRV hub?
>>>
>>> DonÃ¢â‚¬â„¢t know.
>>>
>>> I think that Mike has some of the RFM23 setup worked out, but with the
>>> information that Kevin gathered, and an OEM unit to play with, I could
>>> probably do it.  Just depends as I say what other priorities there are
>>> and
>>> how much time I have!
>>>
>>> Or maybe someone here could tinker with a REV1 or REV2 board to get it
>>> to
>>> talk OEM and contribute a code module?
>>>
>>> Rgds
>>>
>>> Damon
>>>
>>>
>>> On 9 Apr 2014, at 19:50, Bo Herrmannsen <EMAIL ADDRESS HIDDEN>
>>> wrote:
>>>
>>>> Yo Damon
>>>>
>>>> How hard do you think it is to extend OpenTRV to talk OEM'ish ?
>>>>
>>>>
>>>>
>>>> -----Oprindelig meddelelse----- From: Damon Hart-Davis
>>>> Sent: Wednesday, April 09, 2014 8:19 PM
>>>> To: Closed list for developer discussions
>>>> Subject: Re: [OpenTRV-dev] Possible basis of OpenTRV hub?
>>>>
>>>> Hi Kevin,
>>>>
>>>> Thanks for all the juicy RFM12 info: I have replicated it to a number
>>>> of
>>>> places where I (and others) might actually be able to find it again!
>>>>
>>>> Wow, my excuses may be evaporating!
>>>>
>>>> Rgds
>>>>
>>>> Damon
>>>>
>>>>
>>>> On 9 Apr 2014, at 14:15, Kevin Wood <EMAIL ADDRESS HIDDEN> wrote:
>>>>
>>>>> 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
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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 