[OpenTRV-dev] Possible basis of OpenTRV hub?

Tue May 6 14:13:32 BST 2014

do you think the sea bass wil be thawed or frozen? :-D

-----Oprindelig meddelelse----- 
From: Damon Hart-Davis
Sent: Tuesday, May 06, 2014 3:07 PM
To: Closed list for developer discussions
Subject: Re: [OpenTRV-dev] Possible basis of OpenTRV hub?

The stuff I’ve done is (or is to be) piggybacked on the existing FS20 
carrier and/or frames, and is not in conflict with OEM, and is forcing me to 
work thorough some the issues before Kevin slaps me in the face with a wet 
sea bass for my narrow-mindedness.

Kevin and I will have to talk soon!  I think I have a possible way of 
mapping the OEM IDs into a corner of the ID space I’ve currently extended 
from the FHT8V use...

There’s going to be a fairly big disconnect between OEM and FS20 and OpenTRV 
anyway.

Besides, I’ve learnt lots of lovely stuff about CRCs over the weekend.  And 
have my entire house wired for sensors as a side-effect: 
http://www.earth.org.uk/out/hourly/16WWmultisensortemp.png

I intend to be on IRC this Thursday as usual.

Rgds

Damon

On 6 May 2014, at 13:49, Bo Herrmannsen <EMAIL ADDRESS HIDDEN> wrote:

> Not that i'm a code person
>
> but maybe you should have IRC chat open more so you can poke each other?
>
>
>
> -----Oprindelig meddelelse----- From: Damon Hart-Davis
> Sent: Tuesday, May 06, 2014 2:38 PM
> To: Closed list for developer discussions
> Subject: Re: [OpenTRV-dev] Possible basis of OpenTRV hub?
>
> 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
>>
>
> _______________________________________________
> 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 