Signal binding

Hello,

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

Hi, i forgot to post that i now can send messages to my self, but i don’t know why. The only thing i did was a rstart of the openhab docker container.

1 Like

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

Looks like signal server use new certificate. https://github.com/AsamK/signal-cli/issues/1067

Thanks for the warning and for providing the link to the correlated signal-cli issue :+1:
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 :wink:
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:

2022-12-05 08:30:55.944 [DEBUG] [gnal.internal.protocol.SignalService] - Connection state change: CONNECTED → DISCONNECTED
2022-12-05 08:30:55.946 [DEBUG] [gnal.internal.protocol.SignalService] - websocket unexpectedly unavailable: Connection closed!
2022-12-05 08:30:55.947 [DEBUG] [gnal.internal.protocol.SignalService] - Waiting for messages…
2022-12-05 08:30:55.959 [DEBUG] [gnal.internal.protocol.SignalService] - Connection state change: CONNECTED → CONNECTING
SKIPPED: 57
2022-12-05 08:31:52.227 [DEBUG] [gnal.internal.protocol.SignalService] - Network error, retrying
2022-12-05 08:31:53.442 [DEBUG] [gnal.internal.protocol.SignalService] - Network error, retrying
2022-12-05 08:31:54.628 [DEBUG] [gnal.internal.protocol.SignalService] - Network error, retrying
2022-12-05 08:31:55.821 [DEBUG] [gnal.internal.protocol.SignalService] - Network error, retrying
2022-12-05 08:31:56.823 [WARN ] [gnal.internal.protocol.SignalService] - Cannot send message, stop trying

I have already changed the network connection to the Internet as a test. Unfortunately without success. Do you have any idea? Many Thanks.
Markus

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. :sweat_smile:

Ok, thank you very much! Then I can stop looking for the error :wink:

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 :joy: ) 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.