Thanks for the information.
There is definitely something fishy with the serial provider.
This is a common functionnality provided by the openHAB core project to access serial port.
I just asked a question on the dedicated development forum to see if someone can help us.
How did you install openHAB?
If you don’t run openHABian, you’ll have to configure some permissions to get access to serial ports. It’s explained in https://www.openhab.org/docs/administration/serial.html#serial-port-configuration :
Depending on Linux distribution, you might need to add the user running openHAB to
dialoutuser group.With Debian openHAB installation:sudo usermod -a -G dialout openhab. The user will need to logout from all login instances and log back in to see their new group added. If the user added to this group still cannot get permission, rebooting the box to ensure the new group permission is attached to the user is suggested.
I’m running OpenHAB on the latest Raspbian OS. So i ran the steps described in the link, but problem stays the same 
What is the output of these commands:
ls -l /dev/ttyUSB0
groups <user>
Where you substitute the <user> with the user that runs openHAB.
Currently my modem has the port /dev/ttyUSB1, but i have a symbolic link to it. Output is as follows.
frank@raspberrypi:~ $ ls -l /dev/ttyUSB1
crw-rw---- 1 root users 188, 1 Dec 12 08:34 /dev/ttyUSB1
frank@raspberrypi:~ $ ls -l /dev/usb_modem
lrwxrwxrwx 1 root root 7 Dec 12 08:34 /dev/usb_modem -> ttyUSB1
frank@raspberrypi:~ $ groups openhab
openhab : openhab tty dialout audio bluetooth
Parameter EXTRA_JAVA_OPTS in /etc/default/openhab is set like so:
EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyUSB1:/dev/usb_modem"
OpenHAB is running under user openhab
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7484 openhab 20 0 656916 504940 13868 S 1.7 53.5 14:09.00 java
IIRC Raspberry Pi OS would normally assign the dialout group and not the users group to serial devices. Perhaps that is some kind of custom config?
So if the openhab user is not part of that group, try adding the openhab user to the users group.
As a test you can also change the group manually to dialout with:
sudo chown root:dialout /dev/ttyUSB1
or test by giving every user permission to use it:
sudo chmod o+rw /dev/ttyUSB1
Those changes will only last until the device is disconnected or the OS is restarted.
I would also first test by using /dev/ttyUSB1 in the openHAB Thing configuration and only try the symlink after that works.
BAM! This did the trick. Thank you so much!
1 Like
How could I miss to check this before ?!!!
Thank you @wborn
As wborn suggests, this change will not last after the next reboot. You have to either :
1- configure udev to set root:dialog ownership to /dev/ttyUSB1
2- add openhab to the users group
(2 is far more easier but less conventionnal)
Damn! Cheered too soon … after rebooting, the port is now /dev/ttyUSB0 … so I set the group of ttyUSB0 to dialout (sudo chown root:dialout /dev/ttyUSB0) but now the bridge says, that /dev/ttyUSB0 is no option for the serial port parameter . Right now im trying to set the port of the device back to /dev/ttyUSB1 by rebooting to check if the port is the problem.
EDIT: After rebooting several times the modem got the port /dev/ttyUSB1 again and now the bridge goes online with port set to /dev/ttyUSB1 as well as /dev/usb_modem … I’m absolutely clueless why …
On Linux, the ttyUSBx assigned is not guaranteed to be the same upon reboot.
Unless you set it with a udev rule.
You can find many tutorials on internet, like this one.
I’m working on a pull request that allow to use symbolic link (human readable brand + model, more stable) created by the kernel in many distribution under /dev/serial/by-id, to simplify thing. But it won’t make it, if accepted, in the next openHAB 3.4 version.
(The JAR bundle I made for you some post ago is able to handle this kind of symbolic link, but not the one currently on the market place)
I know. But I’m surprised, that it works when the modem gets assigned to the port /dev/ttyUSB1, but not when it gets assigned to the port /dev/ttyUSB0, although both ports are set in the EXTRA_JAVA_OPTS configuration and I assigned the group dialout to both ports …
I already defined a udev rule to generate a symbolic link /dev/usb_modem to the actual port and /dev/usb_modem works fine as a parameter in the bridge as long as the real port is /dev/ttyUSB1 … it doesn’t when the port is /dev/ttyUSB0 though …
Wow, OK ! I didn’t get it.
Indeed, it is very strange, and I have absolutely no clue…
I found out, that the connection to the modem does not work at all, when it is connected via ttyUSB0, so it’s not the fault of the binding. I will investigate further and report if I find the reason.
If you keep struggling with default serial port provider, its necessity to allocate other ports then please have a look on this: OH3.X Alternative Java serial provider
For re-assignment of USB identifiers I had another jar which worked with USB device identifiers to provide a reliable port identifiers on top of other serial port providers. I can look for it if you are in testing/fighting mood. 
The serial port provider does not seem to be the problem. Anyway I will try to use gammu again, because I also want to be able to send SMS from my Homematic CCU directly and therefore I need the gammu daemon anyways. Nonetheless I wil report here if I can find the root cause of the problems.
I don’t know if you are aware of this, but with the binding you can have an item linked to send a sms. And as you can send command to item by simple HTTP call, it becomes a one liner for any external system that can send a HTTP call or execute a command line.
(I don’t know if it is relevant and a valid option for the homematic system)
Anyway, gammu is a totally valid choice for your use case.
Sounds like an option, but I want to send SMS in case my smoke detectors signal an alarm. So I want the signaling chain to be as short as possible. In the beginning I didn’t know that I can send messages from the CCU directly. But for sending SMS out of OpenHab, this binding will definetly be my first choice.
I believe this binding is now part of the official 3.4 distribution.
If the version published in the marketplace adds no new features, please unpublish it by removing the appropriate tag,
1 Like
Indeed. I removed the “published” tag.
I have problem with Huawei E3131 on EL8
When I use minicom, modem answer OK. On OH3 I get this error:
2023-04-01 11:37:05.755 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘smsmodem:smsmodembridge:bb9e7b7987’ changed from UNKNOWN to OFFLINE (CONFIGURATION_ERROR): /dev/ttyUSB0 with 9600 is not a valid serial port | baud
user openhab is in group dialup which have permission to device file, baudrate is the same as in minicom
Some hints?