c/o Kevin Wood 2014/04/09 (Also see: http://jeelabs.org/2011/01/14/nodes-addresses-and-interference/ ) 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, 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 (configurable - default is 210 decimal)
- Combined node ID and flags: bit 7: CTL bit 6: DST bit 5: ACK bit 4-0: - Number of bytes in payload - 66 bytes maximum ... - Initialised to 0xffff for each packet. Calculated on group byte onwards. {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. Well, the changes to the OpenTRV node shouldn't be too onerous. I guess you'd need to reconfigure the RFM to talk OpenTRV mode, send your packet of data to the hub, optionally listen for any response / acknowledgement and retry as required, then revert back to OOK mode for next time you access the radiator valve. The hub could be a standard RFM12Pi on a raspberry Pi running OpenCMS, initially, at least. You'd need some changes to the script that drives the RFM12Pi if you want to send messages back to change settings on the OpenTRV rather than just log what's going on, but for simple logging, everything's already in place.