[OpenTRV-dev] Possible basis of OpenTRV hub?

[Kevin Wood]

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.