Using a standalone bridge, by sending messages to my cellphone the signal account seems not to be provisioning some kind of ID for identification.
Indeed, it is a known bug that several others have reported.
I’m still trying to upload some “profile” by using similar code from the signal-cli project but didn’t manage to make it work yet. I’m not even sure it will fix the issue but it could be related.
In fact, I’m more and more thinking that I should, maybe, completely include the signal-cli code in the binding and let it manage everything instead of copying some part. It didn’t seem very clean when I think about it the first time, but by seeing the little bugs you are all getting it seems more and more appealing.
EDIT : nevermind, signal-cli is not available for java 11… So impossible to include it for now, even for openHAB 3.4
Binding stopped working about 14 hours ago while giving error:
PushNetworkException - javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Thanks for the warning and for providing the link to the correlated signal-cli issue
I made a new version with an updated certificate and updated the open post (and so the marketplace)
As usual, to update from the marketplace, please remove it and reinstall it.
You may have to restart openHAB (I had to, but don"t know why)
Hi Gwendal,
sorry for the delay in answering your reply.
For my opinion it is proberbaly better to in clude the signal-cli code then to maintain your copy every time they change it.
Anyway you will suffer from bad code either it is copied our inbound.
But to use the complete framework reduces your efford.
It is for shure a lot of work anyway
Appreciate your woirk.
Lot’s of liuck
Your’s Timm
This is what I’m currently working on. But I needed to backport the latest release from java 17 to java 11, and it was a lot of work and I’m not even sure it works everywhere (still testing). And it’s not very easy for maintainance either, because the codebase is now diverging. It will be easier when openHAB will switch to java 17, but according to what I read, it seems difficult and not for the next release.
No easy solution but I hope to achieve something in the next weeks, maybe.
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.
) 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.
