Texecom alarm system – first steps and installation

I’ve just upgraded the alarm system in my house. When we moved in several years ago there was an ancient ADT installed alarm system. This had been monitored by phone, but when we came we pulled out a lot of the wiring and more to the point didn’t want to pay any monitoring charges.

The system has been rather temperamental since then, and I’ve been keen to change it ever since. The reason for doing so is that I’ve wanted something more reliable and higher tech… and also I’m intrigued by the possibilties for tinkering that this offers.

I did quite a lot of research, and I ended up choosing a Texecom system. This seems to be a cut above the normal domestic brands and are clearly used in a lot of professional settings. I wanted to reuse as much of the existing wired infrastructure as possible, and so I needed at least 6 wired zones. I also wanted to option of using a wireless expansion for extra zones, plus as much options for connectivity as possible. I decided to replace all the sensors as well with modern equivalents.

I bought the following:

Texecom Premier Elite 48

Texecom Premier Elite LCDLP keypad

I was surprised how cheap they were – about £90 each. The keypad has a big display, and support proximity tags as well as some zone expansion. The keypads come in all shapes and sizes – you can get brass, metal, chrome and plastic versions, include a range which can be sunk into the wall. I ended up picking the plastic one because it was cheaper and I’m not quite ready to bash big holes in the wall.

Installation was pretty easy – just a question of stripping the old box out and rewiring the old zones to the new ones. Then the fun begins…

RTFM

An early opportunity to relearn the important principle of reading the manual.

I had installed one of the zones using a smoke detector, again a straight replacement for the old one. The manual said that it used a ‘normally closed’ relay which opened in an alarm or fault condition. So I wired it up (like the other sensors) to the alarm terminals.

For each zone there are two pairs of terminals – two marked ‘A’ for alarm sensing, and two marked ‘T’ for tamper returns. I had wired the detector up to the ‘A’ terminals, thinking ‘it’s a smoke alarm… why would it need a tamper circuit’. Also of course there are no tamper detectors in the smoke alarm anyway.

Cue a load of headscratching, as however I configured the detector in the software it always returned an alarm condition (it comes up as ‘active’). This is an issue because it stops the alarm setting and all I could do to start with was exclude it completely.

Eventually after a lot of searching I found a reference somewhere to using the ‘T’ terminal and this prompted me, finally, to read the manual. I found this:

wiring

D’oh!

One change of terminal later, and now everything works fine.

Life’s lessons learned once again

COM-USB alternative – DIY and cheap!

One of the things which really attracted me to the Texecom panels was the ability to interface them directly with the computer – and other things (to be described in a future post). However, in order to do this you need to buy a fairly expensive cable from Texecom – the COM-USB:

Texecom COM-USB

These seem to retail for about £40, although there are some cheaper 3rd party versions on ebay for rather less, which seem to do exactly the same job:

usb-com

However even this seems a bit steep for what looks a fairly simply USB cable, and the pins on the Premier Elite main board also appear fairly standard.

I then came across this extremely helpful post:

http://cybergibbons.com/alarms-2/programming-a-texecom-premier-elite-12-w-using-a-ftdi-cable/

In which the author has discovered that the connector on the board is no more than a straightforward serial connection, with three pins – TXD, RXD and GND – connected. Using a USB-serial converter he was able to get everything working with the official ‘Wintex’ software which is a free download from Texecom.

I took a slightly different approach and bought from ebay a very small board which converts a mini-USB plug into serial with pins and solder points as outputs. It was about £4 delivered.

I bought one of these

I then used an old motherboard header cable directly soldered to the TXD, RXD and GND points on the board above, and connected the other end to pins 3 (GND), 4 (TXD) and 5 (RXD) at the Texecom end. So in other words the data is received by the Texecom on pin 4, and transmitted from pin 5. Once this was all wired up I secured the board inside the casing with a cable tie and ran a USB lead outside the box.

The end result looks like this:

So a very cheap solution which is just as good as the £40 official alternative.

Texecom COM-IP controller – DIY and cheap too!

Having had some success in building a DIY equivalent to the USB-COM cable, I started to think about the COM-IP controller. Texecom sell this at great expense. It provides an Ethernet interface from the panel, which allows you to configure the panel over the network rather than having to connect directly to the panel. It also allows you to connect other things in to the panel to provide remote control or get status information from it. The first problem is the price. CTS-Direct have it for just over £90 plus delivery and this seems to be about right. Numerous other retailers have it for the same price although there are some second hand deals on ebay which are a bit better. However this still costs more than the panel did which seems a bit much for such a tiny device: COMIP I have been investigating linking the panel up with other home automation kit (more later) and someone suggested to me that you could use ser2net running on a Raspberry Pi or similar in conjunction with the USB serial connection I already had in order to give the same results. First thing was to see what the serial connection is actually doing, and establish what the parameters for the serial connection are. I used a serial port sniffer to identify this. I tried a few but eventually found ‘Free Device Monitoring Studio‘ which is massive overkill, but does provide the basic functions needed. I ran this whilst connecting to the panel with Wintex. I was hoping to see some comprehensible data but in fact it is clearly encoded. However, I was able to get the serial parameters out which are:

19200 baud, 8 data bits, no parity, 2 stop bits

This is the first time I have ever seen a serial link which uses 2 stop bits – so maybe this is a sneaky trick by Texecom to get you to buy their product. If so then it is fairly easy to get around. The next thing to do is to set up ser2net. It forms part of most Linux repositories, and the Raspberry Pi is no exception. I’ve started with a fairly basic and clean install, booting to the command line. Then I have installed ser2net like so:

apt-get install ser2net

Then plug in the serial cable and it should be recognised and appear as a serial device. You can use the ‘dmesg’ command in Linux to check. I’m using a FTDI 232R device:

[166583.359561] usb 5-1: new full-speed USB device number 2 using ohci-pci
[166583.821660] usb 5-1: New USB device found, idVendor=0403, idProduct=6001
[166583.821673] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[166583.821680] usb 5-1: Product: FT232R USB UART
[166583.821685] usb 5-1: Manufacturer: FTDI
[166583.821690] usb 5-1: SerialNumber: A9C3JDH1
[166583.927074] usbcore: registered new interface driver usbserial
[166583.927109] usbcore: registered new interface driver usbserial_generic
[166583.927136] usbserial: USB Serial support registered for generic
[166583.936455] usbcore: registered new interface driver ftdi_sio
[166583.936482] usbserial: USB Serial support registered for FTDI USB Serial Device
[166583.936601] ftdi_sio 5-1:1.0: FTDI USB Serial Device converter detected
[166583.936658] usb 5-1: Detected FT232RL
[166583.936662] usb 5-1: Number of endpoints 2
[166583.936665] usb 5-1: Endpoint 1 MaxPacketSize 64
[166583.936669] usb 5-1: Endpoint 2 MaxPacketSize 64
[166583.936672] usb 5-1: Setting MaxPacketSize 64
[166583.939669] usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB0

The next step is to set up ser2net to connect to the USB serial port and convert it to network frames. This is done by putting a line in the configuration file – held in /etc/ser2net.conf. I’ve used this line:

10001:raw:0:/dev/ttyUSB0:19200 8DATABITS NONE 2STOPBITS

‘10001’ is the port number (used later); ‘raw’ means that there is no further processing of the frames; ‘/dev/ttyUSB0’ is the name of the serial device as above; the rest of the line contains the serial parameters we found above. Restart ser2net to re-read the config file, and then you will have in effect a working equivalent of the COM-IP. To make use of it you will need to IP address of the server running ser2net and the port number as above. The most obvious use of this is to use Wintex (the Texecom configuration tool) over the network. Configuring this is the same as for the genuine COM-IP although it is a little obscure. You need to go into ‘Edit Account’ in Wintex: Screenshot 2015-04-16 19.45.22 And then select the ‘Panel Details’ tab: Screenshot 2015-04-16 19.45.54 It’s hidden away in the bottom right hand corner under ‘Network Details’ – here you need to enter the IP address of the server, and the port configured in ser2net. Once you’ve done this, you can connect to the panel using the ‘Connect’ button in the Wintex main screen and proceed as normal. So far as I can tell this approach exactly replicates the function of the real COM-IP but at a fraction of the price, or indeed free if you already have a Raspberry Pi or a server lying around. There are some other interesting ideas for making use of this which I’ll come to in future posts.

Possible DIY alternative to ComGSM?

I’m feeling on a bit of a roll now… and I think I might have found another DIY means of adding functionality to the Texecom Premiere Elite panel. I’ve always been interested in the idea of adding a mobile phone dialler to the panel to send a text message when the alarm sounds.

First thought was to buy the genuine Texecom add-on, called (predictably) the ComGSM. However, once again there were a few difficulties with this. The unit itself is readily available from the usual sources (eg www.cts-direct.co.uk):

COMGsm

Firstly, you won’t be surprised to learn that I think that this is quite expensive. Secondly, I didn’t really like the way that it was an external box when there is lots of space inside the existing alarm housing.

I looked at some alternatives. You can get on ebay some boxes which take a SIM card, and when triggered send a standard text message to a list of numbers. These are cheaper, and smaller and so easier to install. However, they looked awkward to configure and did feel like a bit of a clumsy solution. It would have been straightforward to trigger it using one of the panel’s outputs though.

Once I started reading the instruction manual for the panel a bit more I preferred the Texecom solution. This was partly because of being able to configure everything easily through Wintex, and also because when it is triggered it sends a much more detailed text message with details of which zone is triggered etc. It also allows a limited control, so you can disarm the alarm and get some status reports by sending text messages as well.

After having some success at getting the serial interface to the panel working (see earlier posts) I decided to investigate a bit further what the panel was doing when the ComGSM was installed, and how it was communicating. The genuine unit is installed by connecting to one of the two serial ports inside the panel, and as I learned when doing the USB interface these are operating as entirely standard ports.

My first thought was that the panel  would send some kind of encoded commands to the ComGSM which were then translated into control of a phone dialler. I thought that it might be possible to use the Raspberry Pi as a ‘man in the middle’ to translate the commands from the panel and then get the Pi to control a dialler. This seemed a tall order, but worth investigating as it would cut the cost down.

As a start, I configured the panel to have a ComGSM installed on the second port, and plugged in the USB-serial adaptor to listen to what it was doing. This is another setting which is buried in Wintex, this time in the ‘Communicator Options’ screen under the ‘Programming’ menu:

CommsMenu CommsOptions

You can set a whole range of different options for either of the built in com ports as Texecom make a whole lot of different ones. For the purpose of this experiment I set it to ‘GSM module’ which is the one for the ComGSM.

I then ran a simple serial terminal program to see what was coming back. At first, I got a series of garbled characters but they repeated regularly. I tried a few differnet combinations at random, sticking to 8 bits, no parity and one stop bit (aka 8N1, the most common configuration) and eventually on selecting 9600 baud, and to my great surpise, I saw the following coming from the panel:

+++

ATZ

ATZ

ATZ

ATH0

These commands were sent in a repeating sequence. These commands form part of the very well known AT command set, which has been used for modems since the 1980s. It used to be known as the ‘Hayes AT’ command set, named after the pioneering modem company which first developed it. I remember using this myself back in late 80s and early 90s, at which time it was not uncommon to control the modem manually using AT commands rather than having it done automatically through comms software. You would send the command ‘AT’ to the modem (short for ATtention) and get back the response ‘OK’. Other commands could be appended to the AT – so ATDT0123123123 would cause the modem to Dial with Tones (rather than pulses) the number. Over the intervening years, the command set has been developed to include a whole range of other commands, and this includes for dealing with mobile phone connections and text messages.

The commands above – +++, ATZ and ATH0 are fairly standard initialisation commands, to reset the modem (ATZ) and hang up any calls (ATH0). I tried sending back the expected repsonse – ‘OK’ – and was pleased see the panel respond with more commands including some newer ones which were for listing out and retrieving stored text messages. This shows some of them:

Realterm

The formatting is a bit strange, but you can see the first commands towards the bottom, and then some more wrapping round including AT +CSQ which is a request for signal strength, and AT +CMGL=”REC UNREAD” which lists out unread text messages. There is a function

So from all this, my conclusion is that the panel is sending out entirely standard messages, so there is no need for any translation at all. I now think that it should simply be a question of finding a GSM modem module and connecting it directly to the panel.

There are quite a few of these to choose from, but in order to keep costs down I decided to order one directly from China via ebay. Many seem to be based on a Siemens module, and they come in all shapes and sizes with various interfaces. However i settled on this one:

2015-04-25 20_32_24-GSM SIEMENS TC35 SMS Board LM2596 UART Wireless With Antenna Voice Module _ eBay

It has a simple serial UART interface so should be able to speak directly to the panel. It also had the advantage of being pretty cheap, although I did have to wait a few weeks to be delivered. It’s only just arrived, and once I’ve had a chance to play with it will post an update. I am hoping that if if works I can mount it inside the casing with the antenna bolted to the top. For me this will be a much neater and more elegant solution than the real one!

ComGSM update

After writing back in April about my ideas of using an off-the-shelf mobile phone module as a ComGSM I’ve not made much progress since. I did order a suitable unit from ebay direct from China, and after a few weeks it arrived.

I eventually got one of these:

TC35

http://www.lctech-inc.com/Hardware/Detail.aspx?id=a0678f46-a020-46ab-b02e-2d799eecdf1e

I took a few photos myself but the light is a bit odd and it looks exactly the same. Predictably, there are no useful instructions with it at all, so I’ve had to make a few guesses.

It has a standard pin header on the side, which is labelled on the board from left to right as VCC, Tx, Rx and GND. There is also a power supply connector block with two screw terminals labelld + and -. This is on the left of the picture. I did find reference in the brief information I could find to its standard settings being 9600baud, 8 bits, no parity and one stop bit. This is a pretty standard configuration and the same as I used for my tests described in earlier posts.

So in the end I thought the best thing to do was take the plunge and connect it up, and see what happened. I made a link cable up out of another old motherboard cable, and wired the power into the Aux 12v supply available on the main board. This isn’t a great picture but shows everything lashed up. The antenna is out of shot but just dangling on the antenna wire at the moment.

gsm2Here I learned some more important lessons which unfortunately cost me some time. After wiring it in I tried to connect using Wintex but I couldn’t make it work. I was really worried that I’d blown something up by connecting the GSM unit and after a lot of fiddling around I finally realised that I had simply got Wintex configured for the wrong type of panel (Premier 48 rather than Elite 48)!

Once I’d got this working, I then found that all of my sensors were dead and thus I once again worried that I’d broken something. Looking closely at the board I saw a new red light beneath one of the PCB fuses for the Aux 12v supply. I had obviously shorted out the supply when wiring the GSM board at some point. I was quite impressed with the attention to detail in the design, as having a red light under the fuse immediately showed me what was wrong. After replacing the fuse all was well again. There are several very bright red lights on the GSM board itself as well.

I’ve not been able to do much more testing as I’ve not yet put a SIM with credit into it. However, I did configure COM2 for the GSM module and on running Wintex saw the following:

GSM

So it does appear that the unit is recognising the GSM unit – hence GSM status ‘Online’ in the bottom right. The signal strength is effectively non-existent but that’s not surprising given that there is no working SIM in it. Also I’m not getting any errors that the COM port won’t initialise, which you do you get if you try to configure the module with nothing actually present.

So this all looks good… next thing is to get some credit on the SIM and try sending some messages!

ComGSM – not so easy as I thought

Unfortunately things haven’t gone quite as I had hoped, although I’m hoping this is more of a hiccup than anything else.

I have learned a few things about this GSM module:

Once you have installed a SIM you need to power cycle it before it will register

There are several LEDs on it – one of which is for power, and other for signal. This blinks very slowly before the SIM is registered, and then rapidly once it is registered.

I am not quite sure whether the pins are labelled properly

Having done a lot of fiddling around I have not been able to get any response out of the GSM unit by connecting it to the alarm panel. It should be showing a signal strength which it reads out from the module but it’s not showing. Similarly I can’t get it to send any kind of messages so there’s obviously something up.

My instinct is that it is not communicating at all, and there is something wrong with the interface between the panel and the module. The next thing to do is to try and interface with the module itself. I didn’t have anything suitable so looking on ebay I found this:

 usb (2)

I liked this partly because it was cheap (£2.70) and also because it came with a short cable as shown to connect up the individual pins. It has arrived, and so the next thing to do is hook it up to the GSM module and see if I can get any communication going. This will let me confirm that the pinout is correct, and also what the baud rate etc should be because the alarm panel is expecting 9600 8-N-1.

I’ll post again once I’ve had a chance to test it.