Texecom makes a nice range of alarm systems called Premier Elite, with products suited for everything from high-end domestic up to large commercial deployments. The range includes two IP-based communicator modules for wired (Com-IP) or wireless (Com-WiFi) operation.
Normally these communicators would be used with Texecom’s own alarm receiving service, or with a paid-for third-party monitoring service using proprietary software. I wanted to have a way to integrate the alarm with my own monitoring infrastructure, and with some other IoT projects I’ve got going on, so I spent some time reverse engineering the protocol.
The TI MSP430 Launchpad is a cheap MSP430 development board – about £3 when they first came out, although a bit more now. I think mine was a freebie from a distie. Although I quite like the MSP430 I do tend to use either AVR or some kind of ARM for most of my projects, so it hasn’t really seen much use.
The built-in emulator consists of a TUSB3410 and an MSP430F1612, pre-programmed with TI’s own MSP430 “FET” debugger. My aim here is to end up with a debugger that I can use with TI’s CC1110 chips used in the Ciseco SRF. The GoodFET project can talk to these using its Chipcon module, and this has at some point in the past been made to run on the Launchpad.
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.
I have an ongoing project to improve the performance and automation of the heating system in our house, given the ever-rising cost of energy. As part of this project I am planning to zone the central heating system to allow the temperature of each room to be controlled independently, and to do this I need a way of remotely controlling the radiators. Because of the level of integration I am looking for I’ve been unable to find an off-the-shelf solution that meets my needs at a price that is acceptable. Time to start hacking!
The Conrad FHT8V wireless thermostatic radiator valves (TRVs) are available for around £30, which is the sort of price I’m prepared to pay to get this project up and running. I would ideally like to talk directly to these valves from my own controller, so I bought one of the £60 starter kits which includes the remote thermostat and took a look at the on-air protocol using Gnuradio.
To receive the signal a cheap RTL SDR dongle was used. This has the Elonics E4000 tuner, which has almost continuous coverage from about 65 MHz to nearly 2 GHz. The TRVs operate in an ISM band on 868.35 MHz. Helpfully, the protocol has already been reverse engineered, making building a receiver a simple task. The modulation is on-off keying with the symbols encoded as mark and space times of two different lengths, so a custom block was needed in order to decode and frame the messages. This was written in C++ and integrated with the rest of the receiver in Python.
The code can be found here, and should serve as a simple introduction into writing custom Gnuradio blocks.
I had a dead motherboard that had been kicking around for a while after a failed BIOS update. The flash part on there was the Winbond W39V040B, which is 3.3V only and has an LPC interface. The device programmer I have access to wouldn’t touch it, so I put together some simple AVR code to handle the protocol and connected the device up to my STK500. Although reading the device posed no problems, it quickly became apparent that the flash chip was not responding properly to write transactions. This meant there was no way to erase or program it, and is presumably why the BIOS flash failed in the first place.
Searching through the junk box I managed to find a dual-mode LPC/FWH device of the same size (PMC Pm49FL004). This one was responding properly to write commands, but I needed a way of reliably transferring the new BIOS image down to the AVR. Continue reading