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.
There’s no shortage of good Software Defined Radio (SDR) apps for RTL2382-based dongles, but wouldn’t it be nice if they could be driven remotely? WebRadio is a project I have been working on which aims to be a fully functional SDR with a user interface that runs in a browser.
The front-end is separated cleanly from the signal processing server by a (fairly) RESTful JSON API, so alternative GUIs are also an option (smartphone apps being the obvious one).
A key feature of the design is server-side decoding of data modes. Since the original impetus for WebRadio was my involvement with a local school’s high altitude balloon project, initial focus will be on making it decode RTTY, but the modular design makes it easy to add other decoders.
Currently the project builds and runs on a Linux PC, but with only basic functionality (tuning for a single receiver and selection of AM and FM). Channel filtering also needs some improvement, after which SSB will work as well – this is next on the list. The GUI is known to work properly in Chrome; for other browsers, for now, YMMV. Take a look.
The design has optimisations for sensor applications, where a single device may report multiple data items at each time point. These can be submitted in one go, but queried as separate series for display. The modular architecture will enable alternative access methods to be added; MQTT being an obvious one which I intend to look into for data submission.
Code and documentation can be found on the project’s github page. There are some hosted examples to play with, including the graph embedded above, which is real temperature data and can be zoomed by dragging a box around a range. Double-click to zoom back out. The software is released under GNU AGPLv3.
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.