How to send SMS via 3G modem

Developer's Corner General Dev Discussions
#1

Well, and again
everybody wondering how we can send SMS over 3G modems in Vera, and maybe i have a decision.
Here is my modem:
Vendor=12d1 ProdID=1436 Rev= 0.00
S: Manufacturer=HUAWEI Technology
S: Product=HUAWEI Mobile
And i can send SMS over it with this LUA code:

function wait(seconds) local _start = os.time() local _end = _start+seconds while (_end ~= os.time()) do end end wait(1) wserial=io.open("/dev/ttyUSB0","w") wserial:write("AT+CMGF=1\r\n") wserial:write("AT+CMGS=\"+###########\"\r\n") wait(1) wserial:write("VHODNAYA DVER OTKRYTA\r\n\026") wserial:flush()

But if you will try it, you can met some troubles:

  1. Modem must be connected directly to vera USB port (not via USB-hub)
  2. modem port somtimes can be changed to /dev/USB*
  3. sometimes SMS messages came empty and in debug output in vera i recive:
AT+CMGF=1
OK
AT+CMG=1
COMMAND NOT SUPPORT
AT+CMGS="+79241815373"
> AT+CMG7924T+CMG7924T+CMG7924T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG74T+CMG7
> VHODNAYA DVER OTKRYTA
> 
+CMS ERROR: 305

a added delays as you can see (wait function), sometimes it didn’t help but it makes code more stable

so maybe anyone can help to resolve this problems

#2

A few quick comments:
a) You don’t appear to be closing the file handle after using it
b) You’ve implemented a “sleep” equivalent, instead of using the one that’s built in.
c) What does the AT command for SMS require for a termination string?
You’re using a 0-term string, with “26” after it currently.
d) From memory, AT commands are term’d with CR, not CR-LF

Item (a) is the one you should address first. The rest of the commands and error codes you can lookup.

Some of these may be “extensions” to the AT Command set, so it’s often easier to start with the Vendor doc, and then work towards the standard (if it’s missing from the Vendor doc)

EDIT: Item (c) is the ^Z at the end of the SMS.

#3

Also, I’d eliminate the wait, and just look for the “>” response on the IO channel, before sending the SMS Text.

If you don’t get that char, after waiting a limited amount of time, then the code should bail/error out as the SMS Device may not be ready or may have run into an issue.

Where possible, avoid timing-based handling for low level drivers like these… the delays can be long for some of the AT Commands, depending upon what they’re doing (like the ones that enum the local providers/towers, for example)

Longer term, if you turn it into a plugin, the specific TTY/USB to bind to would be specified in Vera’s Plugin/Device/Serial Port config, so that would be done differently (although you may have to teach serproxy about your USB Vendor ID (via the standard means on Vera)

#4

[quote=“guessed, post:2, topic:177313”]A few quick comments:
a) You don’t appear to be closing the file handle after using it
b) You’ve implemented a “sleep” equivalent, instead of using the one that’s built in.
c) What does the AT command for SMS require for a termination string?
You’re using a 0-term string, with “26” after it currently.
d) From memory, AT commands are term’d with CR, not CR-LF

Item (a) is the one you should address first. The rest of the commands and error codes you can lookup.

Some of these may be “extensions” to the AT Command set, so it’s often easier to start with the Vendor doc, and then work towards the standard (if it’s missing from the Vendor doc)

EDIT: Item (c) is the ^Z at the end of the SMS.[/quote]
a) we don’t need to close file handle, as commands are already sent at the end of script, but i did as you suggest… it didn’t help, or may be helped, it’s hard to say
d) yes, you’re right. i corrected code

#5

[quote=“guessed, post:3, topic:177313”]Also, I’d eliminate the wait, and just look for the “>” response on the IO channel, before sending the SMS Text.

If you don’t get that char, after waiting a limited amount of time, then the code should bail/error out as the SMS Device may not be ready or may have run into an issue.

Where possible, avoid timing-based handling for low level drivers like these… the delays can be long for some of the AT Commands, depending upon what they’re doing (like the ones that enum the local providers/towers, for example)

Longer term, if you turn it into a plugin, the specific TTY/USB to bind to would be specified in Vera’s Plugin/Device/Serial Port config, so that would be done differently (although you may have to teach serproxy about your USB Vendor ID (via the standard means on Vera)[/quote]
and that’s the main problem, to bind 3G modem to specific USB port, when you connect 3g dongle vera don’t see it
How i can do this with serproxy?

#6

Do these usb 3g modems need drivers to work with Vera or can i just plug the modem and try the script?

#7

In vera works only Huawei E173 or E175, somewhat like that

#8

[quote=“simonnet, post:5, topic:177313”]and that’s the main problem, to bind 3G modem to specific USB port, when you connect 3g dongle vera don’t see it
How i can do this with serproxy?[/quote]

When you write a Plugin, and it’s deployed as a Device, there’s a UI in Vera that allows you to “bind” a specific Serial port to it. This binding is persisted, so it’ll be remembered over time. The list of serial ports understood/presented in the binding UI is derived from a static list, built into serproxy itself, as well as any user-added “extensions”, in the form of a VID:PID pair list in /etc/cmh/serproxy.ports

See the precise format in this post:
http://forum.micasaverde.com/index.php/topic,1471.msg5512.html#msg5512

From a Plugin author standpoint, you don’t end up dealing with either /dev/tty* or serproxy/ser2net. Instead, you write against a virtual IO Device (of sorts), where you end up being delivered “data” (in the form of calls on the block of your Plugin) and you have a handle to be able to “write” stuff back out as well.

Several of the Plugins on code.mios.com do exactly this. You do have to change your style somewhat, since “interactive” communications (read-write-read-write-read-…) need to be broken up into the evented style that MiOS uses. In some cases, this causes you to maintain a mini state system within your plugin.

… that said, whilst you’re familiarizing yourself with the overall interaction GRPS interaction/AT Commands, it’ll be better as a free-standing Lua program, without the complexities of Vera integration. Once you have the basics going, then we can help you layer atop the necessary “plugin” bits.

You will need to close it. You might not see the issue on the first use, or the second, but eventually you’ll run out of fd’s and it (and a lot more) will start misbehaving :wink:

See ulimit -p to see where you’d hit that limit (per process)

Anyhow, it’s been a while since we chatted, so you’ve probably gotten further along with this. Let us know how you’re going.