[OpenTRV-dev] Possible basis of OpenTRV hub?
Damon Hart-Davis
EMAIL ADDRESS HIDDEN
Tue May 6 13:38:21 BST 2014
Hi,
As I have now done some work on IDs and packet design for at least piggyback on FHT8V frames maybe we should chat sooner rather than later!
Thanks for getting started and leaping those initial hurdles.
Have a look in Messaging.h for example.
Rgds
Damon
On 6 May 2014, at 12:39, Kevin Wood <EMAIL ADDRESS HIDDEN> wrote:
>>> 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
>
More information about the OpenTRV-dev
mailing list