[OpenTRV-dev] Possible basis of OpenTRV hub?

[Kevin Wood]

Yes, that's true. Group and node ID.

> 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
>
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>