Over the last few weeks I have been helping out the guys over at OpenTRV with an implementation of the FHT protocol for use with HopeRF RFM22B and RFM23B modules. My as-yet unreleased sensor modules (as seen in another post) make use of an RFM23B, and I have an interest in evaluating the Conrad/ELV FHT8V valve head as part of my own central heating upgrades, so this was a job that I needed to do anyway.
The FHT protocol is similar to FS20, but the receivers are battery powered and so use a timeslot technique to avoid the need for a permanently powered receiver. This necessitates a synchronisation procedure between the controller and its valve. Once completed, the controller will send a packet approximately every two minutes, keeping the valve in sync. This means that it can take up to two minutes for a change to take effect, but it does mean that the receiver remains un-powered for most of the time.
This example implements the protocol using the module’s FIFO mode, requiring minimal intervention from the host MCU. Source is available for ATMEGA328, so it should work on an Arduino, although I have not tested it yet.
The protocol is modulated using on-off-keying (OOK) with a zero represented as 400 us on then 400 us off, and a one as 600 us on, then same off. To generate this using the RFM2x a bitrate of 5000 bps was chosen. This gives a bit period of 200 us, which is the lowest common denominator for the required timings. A pre-processed bitstream can then be produced which results in the correct modulation for the message being sent.
The code also includes a proof-of-concept receiver, again using FIFO mode. To support this some additional preamble is sent outside of the normal FHT encoding. This does not affect the ability of a genuine FHT device to receive the packet, but makes it much easier for an RFM2x based receiver to participate in the network. At present the receiver implementation cannot receive packets from a real FHT transmitter, but there are a couple of approaches that I have in mind which could solve this limitation.
The firmware, for AVR ATMEGA328, has been tested on one of my sensor boards, but should run on an Arduino with minimal changes. The radio module is connected to the SPI bus, and a serial converter is required on the UART pins to access the embedded command line interface. Connection details can be found in board.h and comms parameters for the UART are 19200,8,n,1.
Before any command can be sent the sync process must first be completed. This defines the target house code. The command “fht sync <hc1> <hc2>” can be used to achieve this, where the house codes are given in decimal. This takes two minutes to complete. Afterwards, issue “fht set <setting 0-255>” to adjust the valve position. The receiver can only be invoked independently using the command “fhtrx”, so two devices running this code would be required to try this out.