Smsmodem : Binding for SMS on a GSM serial modem

sms

**PLEASE TAKE NOTE : **
If you use openHAB 3.4.x or above, then the binding is included in the official release. You don’t have to use this marketplace version.

This binding handles SMS with a serial modem (USB or network exposed), with no external dependencies.
This means (theoretically) an easier/faster integration than with an external tool (a.k.a gammu).

Changelog

Version 1.0 (BREAKING CHANGES)

Merged into the official distribution for the openHAB 3.4 version ! I will keep this marketplace addon for some time, for letting you time to upgrade.
Breaking changes in this final version : you will have to delete and recreate your bridge thing !
To clarify the behaviour of the two different modes (remote key exposed by ser2net, and local usb key), there is now two different bridge types (smsmodemremotebridge and smsmodembridge). See the documentation for more informations.

Version PR4

Allow other encoding for non latin characters.

Version PR3

Fix error with special characters in sender ID

Version PR2

Small fixes

Version PR1

Rewrite for code compliance

Version PR0

initial release for openHAB 3.3.0

Resources

5 Likes

Fantastic - look forward to trying it!

Hi

Sounds very interesting

Which GSM modem are you developing this with?

I have a GSM SMS & VoIP gateway that I use for sending SMS, but I can’t get it to pass incoming SMS back, so your solution is very interesting to me.

Hello,
Unfortunately, I don’t think your gateway is the kind of hardware this binding address.
It targets devices who supports “AT” command (old phone or USB dongle), either on the computer (as a serial tty), or on the network (BUT also exposed as a serial interface, see ser2net for example).
I use a Huawei E180 (a simple USB dongle) for the development of this binding.

Thanks, that was my understanding.

I’m quite happy to change to a different device.

USB GSM modems are far cheaper and look much better for this application.

I’ve just purchased a (cheap) USB GSM modem, I’ll let you know how I get on.

Oh, right !
I misunderstood your initial question :grinning:

I hope this modem supports AT command.
As the SMS is no more a “central” feature for this kind of device, I know that it is often advised to buy older model. I will try to keep an updated list of functional model on the first post, so please let me know the result of your test :slight_smile:

1 Like

Well this is excellent, thank you! Gammu always felt like a trip back to the 90s; this is so much better.

Works perfectly for me, but two minor bugs.

First, any error messages always refer to "/dev/ttyUSB0’ and not the actual device specified in the Thing (in my case, /dev/usb_modem).

Second, whenever a message is received I get this error in the logs: “ERROR] [way.modem.driver.AbstractModemDriver] - /dev/ttyUSB0:19200 ERR==> +CMS ERROR: 321”

I’m using a huawei E180 (so cheap on ebay these days…)

Dan

I’m glad it works for you !

  • the /dev/ttyUSB0 in your log is probably “normal”. Is “/dev/usb_modem” a symlink or an alias or something like that ? The underlying API (smslibv4) need the “real” tty to work with, so I translated symlink to real address. Your error happens too deeply in the code to remember something like a Thing name, which is kept on the openHAB side. Not perfect, I agree with you. But I prefer to let the smslib API handle naming and errors on its own (because it can recover from it, as it seems to do in your case)
  • Here we touch the arcanic world of AT messages…
    Which is a real mess, as manufacturers may have many ways of implementing it. This is even true INSIDE same name modems (I also have a E180 but I could bet it’s different from yours, as I don’t have your error)
    DISCLAIMER : I’m not involved with the smslibv4 api (the discontinued lib that handles the real communication with the modem). I don’t really understand how it works (didn’t try to, and in fact it was what I want : a black box to hide complexity). I patched it for one or two bugs I found with my own USB GSM modem, and also for using a serial library provided by openHAB and not an external dependancy, but that’s all… So, don’t be surprised if I’m not of great help here :sweat_smile:
    This message means we requested an incorrect memory address on the modem (to read or to delete or something else ?)
    If you can give me the full stack trace, I could at least see on what step it occured (on receiving the message, or after that on the delete from the SIM/phone part).
    And if you can put the org.smslib package on debug level I could have the whole exchange of commands and responses and maybe (a very small maybe) see what is wrong.

If this error proves to be not important, I will put this log on the warn level, so you would be able to suppress it without shushing everything else on the package.

Thank you!

How do I get a full stack trace?

My bad, you can’t, I checked the code and there is no stack trace logged in this case.
The debug level on org.smslib should be sufficient though.

Hi, just wondered if you were close to getting this merged? It is excellent!

Due to the code quality requirements in openHAB, I still have some work to do.
In the beta version you tested, I took the smslibv4 code and put it “raw” in the binding.
in order to get the binding merged, I must make many small adjustement for this code to be compliant and of adequate quality. I’m in this process right now, and this is something I clearly haven’t anticipated when I wrote the open post of this topic :sweat_smile:
I’d like to create the merge request in one or two weeks, maybe ? And after this, it could be long, or short if this binding is of any interest to a core maintainer, so I have basically no clue :sweat_smile:

1 Like

cool - thank you!

I took one additional month, but I finally made the necessary changes and the pull request.

I uploaded a new snapshot binary version.

There is a new functionnality : a delivery report channel, to be able to know if the SMS has been delivered (see the documentation).
I’m not sure, but to use it, you could need to delete and recreate the Things.

1 Like

thanks again for all your work on this.

I’m sorry to provide feedback that’s so vague, but at some point in the last few months the binding has stopped working. I can still send SMSs, but they don’t receive - the two receiving channels are linked to items (as they always have been), but they never receive any commands or updates. Nothing at all in the logs…

Any help would be appreciated!

Hello,

You didn’t change anything and it stops working ? Very strange.
As I made a big rewrite and some modifications since the first publication, I suggest you take the last version and try it.
I updated the link in the open post.

Did you also try to use the trigger event, instead of the channel with the conversation thing ? Does it work ?

When you reinstall the new binding version, could you try to recreate the “conversation” thing ? Preferably with the Autodiscovery method.
I made some changes in ID and it could be necessary (not sure but I don’t remember everything).
(Also, be careful, if you used the Rule Action I change the name to “sendSMS”)

If nothing works, could you please post log in the debug level when you should receive a message ?
(for the package org.openhab.binding.smsmodem.internal and org.smslib)

Thanks

Hi,

I think I’ve found the problem. I get the occasional message from my service provider, giffgaff, and they appear to come from the sender ‘giffgaff.’. Looking at the logs, I wonder if the ‘.’ at the end of the sender ID is blowing up the binding?

2022-06-07 14:37:09.966 [WARN ] [rg.smslib.driver.AbstractModemDriver] - /dev/ttyUSB2:19200 ERR==> +CMS ERROR: 321
2022-06-07 14:37:09.967 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.IllegalArgumentException: ID segment 'giffgaff.' contains invalid characters. Each segment of the ID must match the pattern [\w-]*.
	at org.openhab.core.common.AbstractUID.validateSegment(AbstractUID.java:101) ~[?:?]
	at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:76) ~[?:?]
	at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:59) ~[?:?]
	at org.openhab.core.thing.UID.<init>(UID.java:57) ~[?:?]
	at org.openhab.core.thing.ThingUID.<init>(ThingUID.java:69) ~[?:?]
	at org.openhab.binding.smsmodem.internal.SMSModemHandlerFactory.getSMSConversationUID(SMSModemHandlerFactory.java:99) ~[?:?]
	at org.openhab.binding.smsmodem.internal.SMSConversationDiscoveryService.buildDiscovery(SMSConversationDiscoveryService.java:59) ~[?:?]
	at org.openhab.binding.smsmodem.internal.SMSConversationDiscoveryService.buildByAutoDiscovery(SMSConversationDiscoveryService.java:70) ~[?:?]
	at org.openhab.binding.smsmodem.internal.handler.SMSModemBridgeHandler.messageReceived(SMSModemBridgeHandler.java:252) ~[?:?]
	at org.smslib.Modem.processMessage(Modem.java:407) ~[?:?]
	at org.smslib.MessageReader.processMessage(MessageReader.java:382) ~[?:?]
	at org.smslib.MessageReader.run(MessageReader.java:69) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]

Interesting.
Oops, look like I didn’t manage the special characters in sender ID.
A sender ID like “giffgaff.” (the ‘.’) can indeed mess up the receiving of this SMS, but the binding should recover and keep working after that.
Anyway, I didn’t handle this case and I will try to provide a fix soon.
I’m not 100% sure it is your issue, but it worth a try.

I will inform you when a snapshot is ready.

fantastic - thank you!

Awesome! Thank you. I installed a binding, one of these days I will test!