FYI: The signal-cli-rest-api project provides a Dockerized version of signal-cli that is exposed with a Rest API. The Docker container doesn‘t really require configuration. The Docker container is available for all common platforms.
I know that Docker is an extra step for the user, but the setup could be covered in the README.
Working with the Rest API of the Dockerized signal-cli could simplify the binding development IMO and you wouldn‘t need to work with the signal-cli binaries and the bad signal-cli docs.
If you are interested in such a solution, please let me know, because I‘d like to ask the addon maintainers a few questions before somebody starts working on my idea.
Hi Gwendall, I’ve been using the signal binding for a few days in without any problems and all messages have been sent. Now I have the problem that no more messages can be sent. I set the log level to trace and get the following log entries:
2022-12-05 08:19:37.330 [DEBUG] [gnal.internal.protocol.SignalService] - Connection state change: DISCONNECTED → DISCONNECTED 2022-12-05 08:19:37.331 [INFO ] [gnal.internal.protocol.SignalService] - Receiving thread stopped… 2022-12-05 08:19:37.356 [DEBUG] [gnal.internal.protocol.SignalService] - Connection state change: DISCONNECTED → CONNECTING 2022-12-05 08:19:37.381 [DEBUG] [gnal.internal.protocol.SignalService] - Waiting for messages… 2022-12-05 08:19:37.463 [INFO ] [internal.handler.SignalBridgeHandler] - Signal +49XXXXXXXXXXX started 2022-12-05 08:19:37.863 [DEBUG] [gnal.internal.protocol.SignalService] - Connection state change: CONNECTING → DISCONNECTED 2022-12-05 08:19:37.873 [DEBUG] [gnal.internal.protocol.SignalService] - Connection state change: DISCONNECTED → CONNECTED 2022-12-05 08:19:37.878 [DEBUG] [gnal.internal.protocol.SignalService] - Connection state change: CONNECTED → DISCONNECTED 2022-12-05 08:19:37.884 [DEBUG] [gnal.internal.protocol.SignalService] - Received indicator that server queue is empty 2022-12-05 08:19:37.895 [DEBUG] [gnal.internal.protocol.SignalService] - Waiting for messages… 2022-12-05 08:19:52.465 [DEBUG] [internal.handler.SignalBridgeHandler] - Initializing signal 2022-12-05 08:19:52.469 [WARN ] [gnal.internal.protocol.SignalService] - Unrecoverable error or interruption while trying to process message
2022-12-05 08:19:52.471 [DEBUG] [internal.handler.SignalBridgeHandler] - Now trying to start Signal for account +49XXXXXXXXXXX
2022-12-05 08:19:52.470 [DEBUG] [gnal.internal.protocol.SignalService] - Exception details :
java.lang.InterruptedException: null
at java.lang.Object.wait(Native Method) ~[?:?]
at org.whispersystems.signalservice.internal.util.Util.wait(Util.java:136) ~[bundleFile:?]
at org.whispersystems.signalservice.internal.websocket.WebSocketConnection.readRequest(WebSocketConnection.java:195) ~[bundleFile:?]
at org.whispersystems.signalservice.api.SignalWebSocket.readOrEmpty(SignalWebSocket.java:244) ~[bundleFile:?]
at org.openhab.binding.signal.internal.protocol.SignalService$ReceivingThread.run(SignalService.java:427) [bundleFile:?]
When I want to send a message I get the following log entries:
It seems that I have the same issue (I didn’t set my log to trace but I cannot send message anymore).
I guess signal / whispersystem changed something. I will have a look as soon as possible.
It is another hint that I have to use signal-cli as raw as possible.
I know that Docker is an extra step for the user, but the setup could be covered in the README.
Thank you for your suggestion !
As you said, it is an extra step for the user, and the purpose of this binding (my pride ) is to be as easy as possible. But you are right, as it, the custom code I made seems not viable (the last messages in this discussion is another proof). Which is why I’m working on the rewrite discussed earlier, using signal-cli code inside the binding.
The signal-cli project is divided in two part : the “lib” which handle the core communication with the whispersystem server, and the “cli” which implement all the cli / rest / dbus interface.
I think that by using the “lib” part only I will be able to keep it maintainable (thanks to git, merging new dev and fixes is not the pain I thought it would be : it is in fact pretty easy).
I already backported the “lib” it to java 11. There is still work to do but it is manageable. (Of course the backport is open source and published in my git repo)
So, I will try with this path before thinking about some other implementation such as the one you suggest.
I put it on the top of my priority list.
I’m using OpenHAB 3.2 on a Raspberry Pi and installed the Signal binding. I tried to use a dedicated Signal account, the binding seems to work after entering the verification code. Screenshot of log:
2022-12-18 17:53:26.782 [INFO ] [gnal.internal.protocol.store.Context] - Verifying user +4xxxxxxxxxx with code XXXXXX ...
2022-12-18 17:53:27.905 [INFO ] [gnal.internal.protocol.SignalService] - Generating keys for +4xxxxxxxxxx ...
2022-12-18 17:53:28.620 [INFO ] [internal.handler.SignalBridgeHandler] - Signal +4xxxxxxxxxx started
I used the this example to send a Signal message to my mobile with an active Signal app:
val signalAction = getActions("signal","signal:signalaccountbridge:mysignal")
signalAction.sendSignal("+4xxxxxxxxxxx", "Hello World!")
As I didn’t reveive the Signal message, I saw this warning in the log: 2022-12-18 17:56:34.479 [WARN ] [gnal.internal.protocol.SignalService] - Cannot send message, stop trying
Hello,
No you have not done anything wrong. Unfortunately, the binding is broken since two weeks ago.
I updated the open post with more informations (I should have done it before, sorry !)
I will make a message here when I finish the rewrite/fix (soon, I hope)
I finally managed to make the rewrite needed.
A new version is available in the open post, hopefully resolving for all of you the connection issue we face for several weeks.
If you use the marketplace, as usual, you have to delete and reinstall.
Please make sure to read the following notes :
The binding is now based on the signal-cli project.
Good side effects from this rewrite :
fix the issue with the the sender phone number / name not shown.
sending message to yourself in linked mode is OK
you can now send “note to yourself”. If you use your full number, you get notification. If you use the special “self” recipient, you don’t get notification.
delivery and read status is now working (both ways)
development for other function will be easier (group messaging, sending message soon ?)
Bad potential side effects :
you have to register again !! The data model is completely rewrited and not compatible. You also needs to recreate your linked things, as a new parameter is mandatory (the phone number is now needed)
the jar is heavier
the bundle resolution is capricious, because it depends on many new libs (it means that I’m not very comfortable with OSGI development and I’m not sure it will works everywhere ?)
Newer version, means newer lib. And as the rasberry libraries are no longer distributed in the source I used before, the build for raspberry pi is probably broken. The lib I managed to find and included in the jar is for systems with libc6 version 2.33. I don’t know if any raspberry OS has this version (mine is an old one, 2.28). I will try to get a jar compatible with older version. Is somebody here competent with (cross)compiling ?
Hello Gwendal,
thank you for the work you do for us!
I reinstalled the binding via the marketplace and re-registered the bridge.
Unfortunately I get the following error message when I send a message from OpenHAB:
2022-12-30 10:48:55.113 [WARN ] [gnal.internal.protocol.SignalService] - Cannot send message to +49175xxxxxxx, cause : no manager running/initialized
The error occurs both with the function via SignalAccount and when sending via SignalConversation. Receiving messages works. I currently have no idea what it is.
My OpenHab runs on a Synology Disk Station in the Docker container.
Regards
Ulf
I don’t understand how it can happen.
The manager is the same for receiving and sending message. The fact that it could be missing for one and not the other is very strange.
Did you try to stop and restart the bridge thing ?
I would like to get other feedbacks ? Did other users here, beside me, manage to get it working ?
Remove and new install of the binding changed nothing.
So I will try to delete all (Items, Things, Binding) and install and re-register from scratch. For you may be interesting that I use an german fixnet not a mobile number.
Thanks to a user from a gitlab project, I can now include in the release a new library for armv7, builded with an old libc6, enabling the raspberry os based on debian 10 in 32 bits version (so, I suppose, openhabian is OK ?).
The version in the open post is updated.
The last missing part is the lib for raspberry pi os in 64 bits version (the one I have is for libc6 v33, so not even bulseye debian version ?)
As usual, feedback welcome : I would be glad if someone using openhabian can confirm me that it works.
java.lang.RuntimeException: Failed to get driver instance for jdbcUrl=jdbc:sqlite:/opt/openhab/userdata/signal/data/460340.d/account.db
at com.zaxxer.hikari.util.DriverDataSource.<init>(DriverDataSource.java:114) ~[?:?]
at com.zaxxer.hikari.pool.PoolBase.initializeDataSource(PoolBase.java:326) ~[?:?]
at com.zaxxer.hikari.pool.PoolBase.<init>(PoolBase.java:112) ~[?:?]
at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:93) ~[?:?]
at com.zaxxer.hikari.HikariDataSource.<init>(HikariDataSource.java:81) ~[?:?]
at org.asamk.signal.manager.storage.Database.getHikariDataSource(Database.java:101) ~[?:?]
at org.asamk.signal.manager.storage.Database.initDatabase(Database.java:32) ~[?:?]
at org.asamk.signal.manager.storage.AccountDatabase.init(AccountDatabase.java:32) ~[?:?]
at org.asamk.signal.manager.storage.SignalAccount.lambda$48(SignalAccount.java:1114) ~[?:?]
at org.asamk.signal.manager.storage.SignalAccount.getOrCreate(SignalAccount.java:1523) ~[?:?]
at org.asamk.signal.manager.storage.SignalAccount.getAccountDatabase(SignalAccount.java:1112) ~[?:?]
at org.asamk.signal.manager.storage.SignalAccount.lambda$38(SignalAccount.java:1087) ~[?:?]
at org.asamk.signal.manager.storage.SignalAccount.getOrCreate(SignalAccount.java:1523) ~[?:?]
at org.asamk.signal.manager.storage.SignalAccount.getRecipientStore(SignalAccount.java:1086) ~[?:?]
at org.asamk.signal.manager.storage.SignalAccount.getProfileStore(SignalAccount.java:1091) ~[?:?]
at org.asamk.signal.manager.storage.SignalAccount.migrateLegacyConfigs(SignalAccount.java:335) ~[?:?]
at org.asamk.signal.manager.storage.SignalAccount.load(SignalAccount.java:182) ~[?:?]
at org.asamk.signal.manager.SignalAccountFiles.initManager(SignalAccountFiles.java:92) ~[?:?]
at org.asamk.signal.manager.SignalAccountFiles.initManager(SignalAccountFiles.java:80) ~[?:?]
at org.openhab.binding.signal.internal.protocol.SignalService.start(SignalService.java:145) ~[?:?]
at org.openhab.binding.signal.internal.handler.SignalBridgeHandler.checkAndStartServiceIfNeeded(SignalBridgeHandler.java:153) ~[?:?]
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) [?:?]
Caused by: java.sql.SQLException: No suitable driver
at java.sql.DriverManager.getDriver(DriverManager.java:298) ~[java.sql:?]
at com.zaxxer.hikari.util.DriverDataSource.<init>(DriverDataSource.java:106) ~[?:?]
... 26 more
Interesting, I had seen this issue a couple of time without putting my finger on it.
Usually, I saw this when the account start to fast and the bundle is not fully ready (or maybe it’s just an impression). I don’t know exactly what causes this.
Did you try disabling / enabling the thing ? When I have this error it is usually sufficient to fix the issue.
I will also try to update the dependencies for the next beta release.
i have configured a Thing of type signalconversation with my main Recipient, but how do i use this in my rules???
i can send via:
var signalAction = actions.get("signal", "signal:signalaccountbridge:FestNetzSignalAccount");
signalAction.sendSignal("+43xxxxxxxxx", "Hello world! from openhab")
but i do not want to hardcode my phone numbers in rules code…
I think I now understand why. You have the jdbc persistence addon ?
I use the sqlite 3.40 version, but this persistence addon uses the sqlite feature provided by openHAB (which is the version 3.16.1 for openHAB 3.3) → conflict !
When you switch to openHAB 3.4, the issue disappears, because openHAB 3.4 use the same sqlite version as me (3.40)
I should also use the version provided by openHAB, I will provide a new release soon to fix this.
) is to be as easy as possible. But you are right, as it, the custom code I made seems not viable (the last messages in this discussion is another proof). Which is why I’m working on the rewrite discussed earlier, using signal-cli code inside the binding.
