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).
Does your USB stick/chip work ? Does not work ?
Please tell me so I can make a list of compatible/not compatible devices (Theoretically, all USB modem supporting AT-SMS should work)
Known to work:
Huawei E180
Huawei E173
Huawei E1550
Huawei E272
Don’t work:
Huawei E303C
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.
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.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
5
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.
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
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…)
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
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.
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
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
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.
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…
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)
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.
