GSM DCE to TCP - mocking a GSM modem

Question

I'm trying to interface a device (Opentherm thermostat) that actually supports to be controlled through SMS via a serial connection to a GSM modem.

I'd like however to control it through TCP rather than exchanging SMS.

I've thought to write a fake modem that obey GSM 07.07 specs (or probably reuse some existing code) but I've yet to get the whole picture. I know I'll need a level shifter like a MAX232 and then wire up an arduino to it, or maybe an esp8266 with Ser2Net and than write code from the comfort of a raspberry, but I don't know where to start!

Sorry for any missing detail, I'm a software engineer, just passionated with electronic

Follows connection specs, if useful the instruction manual in english is available here.

TECHNICAL DATA SERIAL COMMUNICATION

• protocol RS-232
• baud-rate 2400 bit/s
• use of AT commands according to standard GSM 07.07 and 07.05
• use of 5 conductors (TX, RX, GND, DSR, CTS)

EDIT: What should I use to shift levels from the RS232 level to TTL 3v3 ? How to deal with missing CTR and DTR ?

Note: I know that opentherm is a "kind of open" protocol and I've already put the wonderful opentherm gateway by Schelte Bron, but unfortunatley that device don't support "override", furthermore there are other interesting settings that the device support by SMS but are not part of opentherm spec.

Answer 1

My suggestion would be to start with a serial interface on your laptop or a Pi. You can easily find USB devices, my preference is normally the kind called usb cisco console cable on Ebay, which you will find many of, and which use the FTDI chips. Then you make an adaptor between an RJ-45 socket and the connector on your thermostat.

The thermostat device uses correct RS-232 naming, that is to say it is Data Terminal Equipment (DTE) -- a device where data originates or terminates. The GSM modem is Data Communications Equipment. In the "standard case" that the standard is based on, one end device speaks to one comms device, then through the telephone network (or something similar) to the other comms device to the other end device.

Thus TXD is an output from the thermostat. RXD, DSR and CTS are all inputs to the thermostat.

Your thermostat doesn't send DTR (Data Terminal Ready) or RTS (Request to Send) because it assumes your modem will always be listening. (If you had a real modem which required these, you would fake them by looping back the modem's DSR output to its own DTR input, and the modem's CTS output to its own RTS input: in effect when the modem says it's ready, it hears that the thermostat is ready.)

In modern RS-232 usage, we very often connect two DTE's through a swap cable (a "null modem", pretending to be the two modems) which is absolutely not what it was designed for. The fact that it works very well has led it to be practially universal now. But it leaves the terminology confusing.

If you're operating from a DTE (such as a laptop, a Pi, an Arudino) which is pretending to be a DCE, you cross the wires over. Laptop's TX is wired to thermostat's RXD. Laptop's RXD to thermostats TXD. And laptop's DTR, RTS to thermostat's DSR, CTS. At this level, it's really just a question of matching outputs to inputs.

In the first instance, once you have it wired up correctly, you use any terminal pemulator program that lets you connect. Most programs will drive the DTR and RTS outputs (wired to the DSR and CTS inputs of the thermostat) as "ready", but you may have to experiment.

You should see the thermostat interrogate the "modem" by sending some AT command. You then pretend to be the modem by hand.

Once you've got something out of the thermostate you'll find your way from there easily enough.

Then you'll be able to decide if you want to run it from a microcontroller, and be in good shape to know exactly what you need to output on the handshaking lines. You may well find you can just force them active. And then you'll know if the MAX-232 is any use to you (5V supply, only two lines in each direction) or if you need another.