Just in case this helps debugging and improvingā¦
Today I upgraded from OH 4.0.4 to OH 4.1.1. Afterwards, the Signal account was broken (as before).
I found the /lib/ folder in /tmp/ including the .so file disappeared (probably in the process of the upgrade). So I did the following:
Copy the configuration data of the account into an editor
delete the Signal Account Thing, uninstall the binding, deleted the SQL stuff inside /lib/ which is copied there by the binding whenever an account is created.
You probably have issue with the binding right now.
**COMMUNICATION_ERROR**
IOException - org.asamk.signal.manager.api.AccountCheckException: signal-cli version is too old for the Signal-Server, please update.
This signal-cli issue shows that the upstream project signal-cli is aware and so should make a new version soon.
A new signal binding will of course follow as soon as possible, so stay tuned.
Great news !
I was also waiting and checking for a new release every day.
I will try to make a new binding release very soon.
Thanks for the information.
I uninstalled the binding and reinstalled without reboot. It immediately started working again
Big thanks for updating so quickly!
By the way, even better. On my RPi4 / 8GB, OpenHABian, OH 4.1.1, I first-time tried using this fix and deleted the .so library I added manually in the previous fix.
Itās perfectly working!
Iām really sorry but the binding doesnāt support openHAB 3.X anymore . In fact, I am surprised that you could use the 3.4.0 version so long, given that Signal likes to break compatibility for older version a couple time a year.
The reason is that the signal-cli project (that I use for the binding) needs java 17, and java 17 is available with openHAB 4 only.
I maintained in 2022/2023 a fork of signal-cli for java 11 but there was -literraly- thousands of modification and it was hell to maintain, so I dropped it as soon as openHAB 4 comes outā¦
Sorry, all I can do now is wishing you an upgrade without issue ?
THX for the update.
The signalaccountbridge thing is now online again.
But using val signalAction = getActions("signal", "signal:signalaccountbridge:SignalBinding_openHAB");
in a rule gives me the following error: 2024-02-08 10:55:00.949 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'Signal_Send' failed: Instance is not an SignalActions class.
I had this error message several times, but only when I remove the binding and reinstall it.
I think there is something wrong with the bundle reloading mechanism of openHAB.
But when I restart openHAB, the error goes away.
Let me know if it still happens after a restart ?
Itās on my wishlist !
Iām primarily driven by my own need, and as I donāt āneedā this, this is on the todo list here since the beginningā¦ By putting this here I hope to gain some help from contributorsā¦ but to no avail for now
I didnāt put examples because it is designed to be straightforward. But if you donāt get it to work then it seems that I failed my goal
āsignalconversationā Things are just a mean to use the binding directly with items, no code. A conversation Thing represent the exchange with one recipient. It has two channel, and those channels can be bound to text items : when the item linked to the āsendā channel is updated, the message is sent to the recipient. And when the binding receive a message from this recipient, the item linked to the āreceiveā channel is updated.
I have installed the Signal Binding for the first time and I configured everything according to the instructions. Everything seems fine, but there are problems sending and receiving messages.
Error message while receiving a message:
[gnal.internal.protocol.SignalService] - Signal get an exception while receiving message: org.signal.libsignal.protocol.InvalidKeyIdException: No such signed pre key record:
Error message while sending a message:
[gnal.internal.protocol.SignalService] - Cannot send message to +49151xxxxxxx, cause network
I have updated the binding to the new version 0.13, with tears and blood.
Why ātears and bloodā ? Because signal-cli 0.13 is coded for java 21ā¦ And openHAB for java 17 ! Looks like Iām back to my old friend, the backport maintenance mode
I finally have convinced myself that I need help from the forum
I have trouble understanding on how the registration should work with the binding.
Could you point me somewhere where there is something like a step by step guide?
My setup at the moment ist openHAB 4.1.2 running on a Xen virtualized Ubuntu 22.04.4 LTS.
I have made it through the various pitfalls (finding the right captcha generator, sms, wait one minute, voiceā¦) to register one of my German landline numbers wie the command line version ā signal cli
However, when trying to generate the signal account thing, I end up with the error
When I have entered the information upon thing creation, my code looks like this:
UID: signal:signalaccountbridge:13545dd3f1
label: Signal Account
thingTypeUID: signal:signalaccountbridge
configuration:
verificationCodeMethod: TextMessage
phoneNumber: "+4930555123123" (made up :upside_down_face:)
captcha: signalcaptcha://signal-hcaptcha.5f..blablacaptchagoesonforever
deviceName: rnet-signal
verificationCode: ""
channels:
- id: receivetrigger
channelTypeUID: signal:signalreceivetrigger
label: Message Received
description: Triggered when a message is received, in the form "<sender>|<text>"
configuration: {}
Of course I do not know the verification code before I got the call.
Do I also need the āText Message First, Wait 1 Minute, Voice Call requestā-strategy that I needed to perform with signal-cli?
First, Iām not really sure of what you did and what you think you need ?
You write about signal-cli. Just to be clear : did you use it, for test purpose, or did you think you need it for this binding ?
To be sure : this binding use the signal cli code internally, but is a stand alone (In fact, the binding and signal-cli cannot even work at the same time)
The documentation has a (very little) step by step. But I agree it can probably be better (Iām open for proposition).
The error message means that you captcha is either invalid or expired.
They are short lived, so if you generate it during your test with signal-cli, it probably wonāt be valid anymore.
They are only used during registration, so their short live is normally not an issue.
What you maybe miss is that it is a several step registration process, and so it needs your input. You need to edit and save your thing at least two times with the added information during your progress.
1- get a valid captcha (again, it is short lived, so get a fresh one)
2- Save your thing a first time, with the captcha inside. The binding will use your captcha to ask for a registration code. (You are at this step : the captcha is not OK.)
If itās OK, the thing will be in another state (donāt remember, maybe āverification code neededā, or something like that ?)
Anyway, next : If you choose a vocal validation, You donāt need the "Text Message First, Wait 1 Minute, Voice Call requestā-strategy because it is already hard-coded in the binding. The binding will ask for a SMS, wait one minute, and ask for a vocal confirmation code. So be patient.
3- Once you have the verification code, edit your thing again to add it and save.
Now everything should be OK.
UNLESSā¦ Several common pitfall are:
signal change their API (and sometimes, error messages may be wrong)
temporary error with signal server
Last pitfall : I never used the file configuration method (I used the GUI), and I donāt know if someone on this thread had. But it shouldnāt be any different.
So what I āneedā (i.e. want) is to use the signal binding with my landline number
I followed the signal-cli test only to make sure that in principle everything works and because I thought it would be easier to troubleshot in case of errors.
Is there a way to find out which captcha generator is the valid one without generating rate limitation issues?
I always used the one I put in the documentation (Signal)
But you now have an ExternalServiceFailureException 502. It may relate to anything
1- temporary error from signal
2- rate limitation
3- api mismatch or deeper issue
1 or 2 requires to wait and retry (maybe tomorrow ?)
I will investigate the 3 if it still donāt work tomorrow.
)
. In fact, I am surprised that you could use the 3.4.0 version so long, given that Signal likes to break compatibility for older version a couple time a year.
