i tried to install the Binding from the community marketplace. Installtion worked well, but OpenHab logs following error on startup:
2022-12-09 10:45:03.579 [ERROR] [Events.Framework ] - FrameworkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.smsmodem [264]
Unresolved requirement: Import-Package: org.openhab.core.io.transport.serial
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1847) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1840) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1783) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1745) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1667) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) [org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345) [org.eclipse.osgi-3.17.200.jar:?]
I heard that there are issues with dependencies installation when using the marketplace.
Do you have another binding using a serial component ?
If not, then I suggest you install one, such as the zwave or zigbee binding.
It could install the serial dependencies and with luck unlock the smsbinding (do not hesitate to stop / start openHAB)
I also saw an old suggestion. You could use this command on the openHAB console :
Installing the ZigBee binding first helped. But now the binding doesn’t let me configure a modem. My modem has serial port /dev/ttyUSB0 or /dev/usb_modem (linked). If I try to set the Serial Port to either of these ports, the binding says
{serialPort=Der Wert /dev/ttyUSB0 ist nicht in den erlaubten Optionen enthalten. Erlaubte Optionen sind: [ParameterOption [value=“/dev/ttyS0”, label=“/dev/ttyS0”]]}
which means “The value /dev/ttyUSB0 is not one of the permitted options. Permitted options are: [ParameterOption [value=”/dev/ttyS0", label=“/dev/ttyS0”]]
It seems that the openhab serial provider doesn’t recognize your /dev/ttyUSB0 as a serial device. Strange.
So, I just made for you a release that doesn’t enforce the serial property to be a recognized one. The text is now a simple text with no further verification. It will allow you to create the thing. Could you please test it ?
You can download it here and install it in your addon repository. Warning : you have to remove the smsmodem binding installed from the marketplace, otherwise behavior is unknown.
But I’m not very optimistic, if you system doesn’t recognize it as a serial port, it seems dubious that the serial provider can work with it. But it is worth a try anyway.
What is the model of your device ?
Does it work with other similar software, like gammu ?
Sending SMS via gammu works fine and the device is a Huawei E169:
frank@raspberrypi:/usr/share/openhab/addons $ lsusb
Bus 001 Device 005: ID 12d1:1001 Huawei Technologies Co., Ltd. E161/E169/E620/E800 HSDPA Modem
Bus 001 Device 003: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Microchip Technology, Inc. (formerly SMSC) SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
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.
If you don’t run openHABian, you’ll have to configure some permissions to get access to serial ports. It’s explained in Serial Port Configuration | openHAB :
Depending on Linux distribution, you might need to add the user running openHAB to dialout user 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.
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
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 …
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.
