[OpenTRV-dev] Possible basis of OpenTRV hub?

[Kevin Wood]

OK, but, you need the following in each room anyway:

A radiator valve
A temperature measurement node

If the temperature measurement node is a standard EmonTx, then it knows
nothing about the radiator valve and can only send its' measurement to the
central node. The central node then has to send any commands to the valve.
Once you have to keep synchronisation with all the valves in the system
from the central node, your opportunities to monitor EmonTx traffic get
rather more sparse.

But.. we already have a node which can monitor temperature AND control the
radiator valve local to it.. so why not just extend OpenTRV so that it can
report its' status to, and, perhaps, accept temperature commands from, the
central node in EmonTx format, and then your central node can be in EmonTx
mode 100% of the time.

Furthermore, the valve is always being controlled by its' local node, so
the wireless range is minimised, and each OpenTRV node only need keep
synchronisation with one FHT device.

Kevin


> I was thinking of one central hub to do it all... if its possible...
>
> of course there needs to be a messureing device/node in each room, but why
> have one small box instead of 2?
>
> i'm not sure on the transmission time, the blink from openTRV box is very
> faint... so my estimate is half sec or less
>
> and with the central hub idea we can have one interface to both see what
> have happend in the past and access control interface
>
>
>
>
>
> -----Oprindelig meddelelse-----
> From: Kevin Wood
> Sent: Wednesday, April 09, 2014 1:15 PM
> To: Closed list for developer discussions
> Subject: Re: [OpenTRV-dev] Possible basis of OpenTRV hub?
>
> Switching to control the valves every 2 minutes might not be a huge
> overhead.
>
> But are you talking about using this setup in place of OpenTRV to control
> the valves, or in addition to it?
>
> I'm thinking that if every valve has an OpenTRV controlling it, then only
> the openTRV really needs to worry about the FHT protocol to control its'
> local valve. OpenTRV could easily switch to the OpenEnergy protocol to
> report its' state to a central node that then only needs to sit and
> monitor the OpenEnergy protocol.
>
> It gets more complex if you're thinking of controlling a house full of
> valves from one central node that also needs to handle the OpenEnergy
> protocol. As I said, though, it may well be that you can't even do that
> with 2 radios without compromising the OpenEnergy protocol listening due
> to interference between the radios.
>
> How long does a transmission to a valve take?
>
> Kevin
>
>> The thing with the valves is that you need to send them a command every
>> 2
>> minuttes within a 1 sec window, if they do not get an command for 1 hour
>> they will go in error mode and open 30%
>>
>> The reason why i wondered about the 2nd radio is that the emoncms system
>> can
>> still work like it does, plus we can send commands to the valves without
>> much degrade in performance
>>
>> and since they allready have the monitoring part in place it seems ideal
>> just to add control of the valves..... the new feature of simple on/off
>> of
>> a
>> boiler seems to have a bit of the framework in place...
>>
>>
>>
>>
>> -----Oprindelig meddelelse-----
>> From: Kevin Wood
>> Sent: Wednesday, April 09, 2014 12:33 PM
>> To: Closed list for developer discussions
>> Subject: Re: [OpenTRV-dev] Possible basis of OpenTRV hub?
>>
>> Hi Bo,
>>
>> I think it depends what we want to achieve.
>>
>> If we want to listen for EMonTX nodes and control FHT valves with the
>> same
>> hub node then there are going to be some compromises.
>>
>> I haven't looked into the FHT protocol much but I assume that, because
>> the
>> nodes are both battery powered, that they must establish some sort of
>> schedule rather than have the receiver monitoring constantly, so we know
>> when we need to be active in the FHT protocol, and it doesn't matter to
>> the valves what the radio module is doing in-between.
>>
>> That gives us windows in-between FHT radio activities that we could use
>> to
>> listen out for EmonTx nodes. If the duty cycle is good enough we might
>> not
>> miss too many node transmissions.
>>
>> Even with 2 radios, FHT activity might well swamp reception of EmonTx
>> nodes, especially if we operate both in the same band, although we could
>> easily move EmonTx activity to 433MHz. So, 2 radio modules might not
>> actually buy us anything.
>>
>> Of course, the OpenEnergy protocols as they stand are unsuitable for
>> reception by a node that is battery powered since the protocol requires
>> the receiver to be "always on". With a bit of work they could be made to
>> work on a schedule that we could arrange such that the two protocols
>> could
>> co-exist without any compromises with a single radio - but then it
>> wouldn't be a "standard" EmonTx.
>>
>> But.. Back to the original question - what would we be looking to
>> achieve
>> by interworking with the OpenEnergy kit? ;-)
>>
>> Best Regards
>>
>>
>> Kevin
>>
>>> Before reading the details one Q:
>>>
>>> Would it be better to have dual radios? one for OEM and one for the
>>> valves?
>>>
>>> And then adding a kind of module for OEM that allows control of the
>>> valves?
>>>
>>>
>>>
>>> -----Oprindelig meddelelse-----
>>> From: Kevin Wood
>>> Sent: Wednesday, April 09, 2014 12:03 PM
>>> To: Closed list for developer discussions
>>> Subject: Re: [OpenTRV-dev] Possible basis of OpenTRV hub?
>>>
>>> Hi All,
>>>
>>> As promised, here's a brain dump of everything I've discovered about
>>> the
>>> RFM12 protocol used by OpenEnergyMonitor.
>>>
>>> It's very different to the OOK protocol used by the FHT valves, of
>>> course.
>>> Whether we'd be able to use a single RF module and reconfigure it
>>> between
>>> the two "standards" each time we need to talk to a valve I don't know.
>>> There is no synchronisation of the OpenEnergy nodes at the moment, so
>>> the
>>> hub would need to monitor the OpenEnergy signalling for the majority of
>>> the time in order not to miss too many transmissions.
>>>
>>> That said, the most valuable part of the OpenEnergyMonitor suite for us
>>> is
>>> probably EmonCMS, and I think the best way to interwork with that would
>>> be
>>> to have a hub node that speaks to it using JSON, so the RF protocol
>>> would
>>> then become irrelevant and we could "roll our own".
>>>
>>> Anyway, here's the detail. If there's a better place to post this (a
>>> wiki,
>>> etc?) then please feel free to do so, or point me in the right
>>> direction.
>>>
>>> Cheers,
>>>
>>> Kevin
>>>
>>>
>>> OpenEnergyMonitor RFM12 signalling protocol:
>>>
>>> Jeelib defaults are used for the radio parameters. These are as
>>> follows:
>>>
>>> Centre Frequency:
>>> 434.0 MHz (with 433 MHz module selected)
>>> 868.0 MHz (with 868 MHz module selected)
>>>
>>> Transmission settings:
>>>
>>> FSK, 90KHz deviation, 49.2kbps
>>> RX and TX FIFO enabled
>>> 12 pf load capacitor
>>> Fast VDI
>>> 134KHz RX Baseband bandwidth
>>> LNA gain 0db
>>> RSSI threshold -91dbm
>>> Auto clock recovery, slow mode, digital filter, DQD threshold 4
>>> FIFO it level 8, 16 bit sync pattern, RX FIFO fill after sync pattern
>>> Sync pattern 0x2d,<group id>
>>> AFC auto, keep during VDI, deviation unrestricted, coarse mode
>>> Mod polarity 0 (1= fc+dev 0=fc-dev), 90kHz deviation, output power max.
>>> PLL BW wide
>>> Wakeup disabled
>>> Low duty cycle disabled
>>>
>>>
>>> Packet format:
>>>
>>> {transmission start}
>>> 0xaa
>>> 0xaa - 24 bit preamble
>>> 0xaa
>>>
>>> 0x2d - 16 bit receiver wakeup sequence
>>> <group id> (configurable - default is 210 decimal)
>>>
>>> <header byte> - Combined node ID and flags:
>>> bit 7: CTL
>>> bit 6: DST
>>> bit 5: ACK
>>> bit 4-0: <node id>
>>>
>>> <length byte> - Number of bytes in payload
>>> <payload> - 66 bytes maximum
>>> ...
>>> <CRC low byte> - Initialised to 0xffff for each packet. Calculated on
>>> group byte onwards.
>>> <CRC high byte>
>>> {transmission end}
>>>
>>>
>>> Protocol Detail:
>>>
>>> If a group ID is allocated, only nodes with the same group ID can
>>> communicate. If a group ID is not allocated,
>>> the module is configured with an 8 bit wakeup byte of 0x2d.
>>>
>>> If the DST flag is set, the node ID indicates that of the destination
>>> node, else it is that
>>> of the source node.
>>>
>>> If the DST flag is set, a node will ignore packets that don't match
>>> its'
>>> node ID unless its' node ID is 31.
>>>
>>> The ACK flag appears to request that a transmission is acknowledged by
>>> the
>>> receiving node.
>>>
>>> The CTL flag in conjunction with the DST flag appears to indicate that
>>> a
>>> packet is an acknowledgement
>>> initiated by a previous packet from the addressed node with the ACK
>>> flag
>>> set.
>>>
>>> CRC Check:
>>>
>>> The CRC algorithm employs the avr-libc function _crc16_update
>>> (util/crc16.h). Note that the inline assembler
>>> version of this algorithm seems to bear no relation to the C version
>>> shown
>>> in the comments!
>>>
>>> The CRC is initialised to 0xffff at the beginning of each packet
>>> transmit
>>> operation and
>>> each byte from the group id byte onwards (excluding the first byte
>>> (0x2d)
>>> of the wakeup sequence)
>>> is incorporated by a call to _crc16_update.
>>>
>>> On the receive side, the CRC is initialised to 0x0000 and each received
>>> byte from the
>>> group id onwards is incorporated by a call to _crc16_update. Since the
>>> group id is part of
>>> the wakeup sequence and not passed to the AVR from the RFM12, the local
>>> group id is used.
>>>
>>> Upon error free packet reception, the receiver's CRC will evaluate to
>>> zero.
>>>
>>> Payload data in EMonTX:
>>>
>>> EMonTX nodes simply pack a struct of 16 bit integer measurement values
>>> into the payload.
>>> There is nothing in the data to indicate what the values represent.
>>> Incoming measurements are
>>> assigned labels and their values processed into "real" units by input
>>> configuration in the EMonCMS software.
>>>
>>> Node firmware that I've looked into simply sleeps between updates, and
>>> there appears to be no attempt to
>>> synchronise reporting times or to mitigate against collisions between
>>> two
>>> nodes whose transmission schedule
>>> has become "synchronised".
>>>
>>> Forwarding to EMonCMS:
>>>
>>> The firmware in the RFM12Pi daughterboard for the raspberry Pi simply
>>> forwards received RFM12 messages to the
>>> serial port as a sequence of byte values in ASCII format, and
>>> facilitates
>>> transmission by a command that
>>> allows a byte sequence to be sent.
>>>
>>> An accompanying script running on the raspberry Pi listens for incoming
>>> RFM12 messages, formats the data within
>>> into JSON and sends them to the EMonCMS server via HTTP.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>