Signal Binding [5.0.0.0;6.0.0.0)

Thank you very much for your two reports.
I’m glad it works for you, in the end at least :smiling_face_with_tear:

I think so too, and it matches what @Stepko experiences at first. I think I found my mistake, so a fix should be easy.

I encountered this one too, and didn’t understand it. I now know that it wasn’t a bad fluke. Testing the registration process is ‘tedious’ (to put it mildly), as we hit the rate limit very fast (and I have to provide one phone number and break my test env every time).

Oops, sorry, I didn’t have enough time to investigate a related issue and forgot to edit the related documentation.

I put this here in case a fellow openHAB developer can help:

I have an issue with the actions classes. As I transform the whole signal verification process into several actions, I had to split them (linked account and main account use distinct workflow). I initially tried to make three separate classes (with message related actions in one action class, common to the two thing types), but didn’t manage to make it work. So I made two classes, and had to duplicate the send message action in both (and so using different names).
I hope to fix this, so if someone has an idea and / or example of another binding doing this (i.e. different actions classes with at least one common action class to two different thing types), please tell me. If it works, I will rename it back to sendSignal (sorry for the inconvenience in the meantime).

Since the last OpenHab Update the Signal Binding doesn’t anymore. There are 2 red entries in the log-viewer:

  1. error message
09:33:32.085
Timestamp
Apr 23, 2026, 9:33:32 AM
Level
ERROR
Logger Class
org.openhab.binding.signal.internal.protocol.service.JsonRpcAbstractSignalService
Message
Fatal exception inside the signal receiving thread for. Will not try to start again,unless manually restarted.
Stack Trace
org.openhab.binding.signal.internal.protocol.service.UnrecoverableException: Cannot start process
at org.openhab.binding.signal.internal.protocol.service.JsonRpcStdioAbstractService.internalStart(JsonRpcStdioAbstractService.java:80)
at org.openhab.binding.signal.internal.protocol.service.JsonRpcAbstractSignalService$ReceivingThread.run(JsonRpcAbstractSignalService.java:215)
Caused by: java.io.IOException: Cannot run program "/var/lib/openhab": Exec failed, error: 13 (Keine Berechtigung)
at java.base/java.lang.ProcessBuilder.start(Unknown Source)
at java.base/java.lang.ProcessBuilder.start(Unknown Source)
at org.openhab.binding.signal.internal.protocol.service.JsonRpcStdioAbstractService.internalStart(JsonRpcStdioAbstractService.java:78)
... 1 more
Caused by: java.io.IOException: Exec failed, error: 13 (Keine Berechtigung)
at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
at java.base/java.lang.ProcessImpl.<init>(Unknown Source)
at java.base/java.lang.ProcessImpl.start(Unknown Source)
... 4 more

“Cannot run program “/var/lib/openhab”: Exec failed, error: 13 (Keine Berechtigung)” → /var/lib/openhab is a folder and no program. What are the expected access rights?

  1. error message
Time
09:33:42.081
Timestamp
Apr 23, 2026, 9:33:42 AM
Level
ERROR
Logger Class
org.openhab.binding.signal.internal.handler.SignalBridgeHandler
Message
Error during initialization
Stack Trace
java.io.IOException: Process not started, cannot write
at org.openhab.binding.signal.internal.protocol.service.JsonRpcStdioAbstractService.writeLine(JsonRpcStdioAbstractService.java:166)
at org.openhab.binding.signal.internal.protocol.service.JsonRpcAbstractSignalService.sendRequest(JsonRpcAbstractSignalService.java:414)
at org.openhab.binding.signal.internal.protocol.service.JsonRpcAbstractSignalService.exists(JsonRpcAbstractSignalService.java:67)
at org.openhab.binding.signal.internal.protocol.SignalAccount.check(SignalAccount.java:54)
at org.openhab.binding.signal.internal.handler.SignalBridgeHandler.checkAccount(SignalBridgeHandler.java:150)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)

“java.io.IOException: Process not started, cannot write” → Where to write?
(What are useless error message. At least for me.)

The cause of the 2nd error is probably the 1st error and therefore a “simple” access rights issue.

Can someone post the correct access rights?

On my rapberry pi 5 (openhabian, debian 12 based) it looks like this:

ls -l /var/lib/
...
drwxrwxr-x 17 openhab   openhab 4096 20. Apr 18:53 openhab


ls -l /var/lib/openhab/
insgesamt 60
drwxrwsr-x  2 openhabian openhab  4096 25. Dez 11:12 backups
drwxrwxr-x  4 openhab    openhab  4096 20. Apr 18:26 cache
-rw-rw-r--  1 openhab    openhab  1712 18. Mär 2024  Californium.properties
drwxrwxr-x  5 openhab    openhab  4096 20. Apr 18:25 config
drwxrwxr-x  3 openhab    openhab 12288 20. Apr 18:25 etc
drwxrwxr-x  3 openhab    openhab  4096 25. Dez 10:43 jsondb
drwxrwxr-x  2 openhab    openhab  4096 20. Apr 18:25 kar
drwxrwxr-x  3 openhab    openhab  4096 20. Apr 18:53 marketplace
-rw-r--r--  1 root       root      615 20. Apr 2025  openhab_crt.pem
drwxrwxr-x  5 openhab    openhab  4096 18. Mär 2024  persistence
drwxrwxr-x  2 openhab    openhab  4096 18. Mär 2024  secrets
drwx-wx---  4 openhab    openhab  4096 18. Mär 2024  signal
drwxr-xr-x 10 openhab    openhab  4096 21. Apr 22:35 tmp


ls -l /var/lib/openhab/signal/
insgesamt 8
drwx-wx--- 2 openhab openhab 4096 29. Aug 2025  avatars
drwx-wx--- 4 openhab openhab 4096 18. Mär 2024  data

Update

Maybe this is related to

You configure this behavior at the binding level. Look at the documentation.
BUT, bad news, the managed version, unfortunately, is not completely autonomous. There is a caveat, as signal-cli 14+ works with Java25+ only. You have to provide the binding a path to the JDK25+ home. To do so, write, in the “configuration” parameter, the following :
JAVA_HOME=/your_path/to/the/jdk25/
(of course, adjust it to a valid path)

At which documentation should i look at? There is no hint or link!

It seems that signal-cli is not installed. ‘find / -name signal-cli’ doesn’t return any results.
So maybe i have to install signal-cli (and jre-25) and somehow configure the signal binding to use this. Am i right? Is there a documentation how to do this?

THX, Seb.

Hello,

The bundle is in an early alpha state, caused by a massive architectural rewrite needed by an upstream modification that I was not able to pinpoint. I released it only because it is better than the broken state we were all in.

There is actually three issues to compound with:

  • issue with the configuration initialization (I made a mistake with the default parameter). You need to go the settings page and do some modifications for the bundle to register the right parameter for the “kind” (i.e. you probably want MANAGED for an automated download). If you don’t do so, then you have the silly issue with the binding trying to execute a directory.
  • You need to download on your system a java 25 runtime, and provide a path to it in the settings page (Sorry for this, but signal-cli is not compatible anymore with java 21). Do not forget that the openHAB user needs to have access / exec right to it.
  • You may need to register again your number (Theoretically no, but several reports say so. I appreciate a feedback on this if you could). To do so, we must use the openHAB Actions available on the Signal Bridge Thing. You will probably encounter several error messages (again, sorry, alpha state). And you will need to start/restart to workaround issues, as stated by the previous messages from the users soenke and Stepko on this thread. Why didn’t I fix this ? because registering is rate limited on the Signal side, so debugging this is an annoyingly difficult process for me.

I think that you are the first Raspberry Pi user to test the rewrite. You may encounter additional issue, as each platform use different native code. I have good hope that it will work though.

The documentation link is at the end of the opening post. It is a pretty standard way of doing in the openHAB marketplace.
BUT the documentation is also not complete. It doesn’t mention all these caveats, and I forgot to mention that I temporary had to change the action method name to send message. I hope to revert the action name soon.

You also have the possibility to wait for me to update the binding to a more polished state :smiling_face_with_tear:

My thing config page looks like this. I don’t find anything you mentioned. Where can i find the mentioned “setting page”?

It this link, right? openhab-addons/bundles/org.openhab.binding.signal at 5.0.0-signal-ALPHA15 · dalgwen/openhab-addons · GitHub
There are no Install-Instructions you mentioned or did i simply not found them?

No, this is “binding-level” settings, not “thing-level” settings.

(sorry, french UI here. “Paramètres” = settings):


(great paint skills, isn’t it ? :smiling_face_with_sunglasses: :rofl: )

I don’t remember mentioning “install” instructions ? Anyway, yes, the link is the right one.

AFAIK you can only register a single Thing action class per Thing, but IIRC inheritance works, so you can define a base class for the shared stuff and extend it with the specifics. I think I had that running at some point for the Bluelink EU support, but ultimately didn’t need it.

Yes, somehow :slight_smile:

I was recently there, but it’s empty:

Do you know why?

I removed the signal binding and installed it again. Now it looks like your screenshot and the parameters are there.

Dear dalgwen

i was able to get this update working on a raspberrypi 4 with openHAB 5.1.4. Thank you very much for this. It simplifies my life and reminds us again on the open windows and the finished washing machine.

I tried “local” and “Managed”. With local i was not succesful. I was able to install signal-cli, register and send messages. But with this approach i had a new local registration and not the one from openHAB.

I switched to “Managed” and this worked. Hint: only unzip the package. If you install it, the path switches to JDK25 and openHAB does not work anymore.

wget https://github.com/adoptium/temurin25-binaries/releases/download/jdk-25.0.2%2B10/OpenJDK25U-jdk_aarch64_linux_hotspot_25.0.2_10.tar.gz
sudo tar -xzf OpenJDK25*.tar.gz -C /opt/jdk25 --strip-components=1
/opt/jdk25/bin/java -version
sudo update-alternatives --install /usr/bin/java java /opt/jdk25/bin/java 25
sudo update-alternatives --install /usr/bin/javac javac /opt/jdk25/bin/javac 25
sudo update-alternatives --config java
sudo update-alternatives --config javac

I can send messages again (my only usecase so far). I tried receiving. This was not possible, but i never tested it before with the old beta version. So i do not know whether this does not work due to alpha or due to raspberrypi.

One “bug” i recognize is like described from sebstaeubert: the configuration option vanishes. The binding is still working (i can send messages), but you cannot change the configuration on binding level and, more critical, you cannot add bridges or clients. The screen to select a signal element is just empty:

The only solution i found, is to uninstall and re-install the binding. Then everything is ok for a certain time. somewhen it disappears again.

A second “bug” is, that i can only send messages to hardcoded phonenumbers. I cannot anymore send it to a clients UUID. This crashes signal-cli:

2026-04-26 18:33:24.278 [ERROR] [service.JsonRpcAbstractSignalService] - Fatal exception inside the signal receiving thread for. Will not try to start again,unless manually restarted.
com.google.gson.JsonIOException: Abstract classes can't be instantiated! Adjust the R8 configuration or register an InstanceCreator or a TypeAdapter for this type. Class name: com.fasterxml.jackson.databind.JsonNode
See https://github.com/google/gson/blob/main/Troubleshooting.md#r8-abstract-class
        at com.google.gson.internal.ConstructorConstructor.lambda$get$2(ConstructorConstructor.java:147) ~[bundleFile:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$FieldReflectionAdapter.createAccumulator(ReflectiveTypeAdapterFactory.java:555) ~[bundleFile:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:508) ~[bundleFile:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$2.readIntoField(ReflectiveTypeAdapterFactory.java:271) ~[bundleFile:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$FieldReflectionAdapter.readField(ReflectiveTypeAdapterFactory.java:561) ~[bundleFile:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:519) ~[bundleFile:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$2.readIntoField(ReflectiveTypeAdapterFactory.java:271) ~[bundleFile:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$FieldReflectionAdapter.readField(ReflectiveTypeAdapterFactory.java:561) ~[bundleFile:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:519) ~[bundleFile:?]
        at com.google.gson.Gson.fromJson(Gson.java:1359) ~[bundleFile:?]
        at com.google.gson.Gson.fromJson(Gson.java:1260) ~[bundleFile:?]
        at com.google.gson.Gson.fromJson(Gson.java:1170) ~[bundleFile:?]
        at com.google.gson.Gson.fromJson(Gson.java:1107) ~[bundleFile:?]
        at org.openhab.binding.signal.internal.protocol.service.JsonRpcAbstractSignalService.handleResponse(JsonRpcAbstractSignalService.java:360) ~[bundleFile:?]
        at org.openhab.binding.signal.internal.protocol.service.JsonRpcAbstractSignalService$ReceivingThread.run(JsonRpcAbstractSignalService.java:224) [bundleFile:?]
2026-04-26 18:33:24.279 [INFO ] [service.JsonRpcAbstractSignalService] - Receiving thread stopped...
2026-04-26 18:33:52.373 [WARN ] [service.JsonRpcAbstractSignalService] - Cannot send message to b70ad6995d
java.io.IOException: Timeout while waiting for response
        at org.openhab.binding.signal.internal.protocol.service.JsonRpcAbstractSignalService.sendRequest(JsonRpcAbstractSignalService.java:429) ~[?:?]
        at org.openhab.binding.signal.internal.protocol.service.JsonRpcAbstractSignalService.send(JsonRpcAbstractSignalService.java:102) ~[?:?]
        at org.openhab.binding.signal.internal.protocol.SignalAccount.send(SignalAccount.java:166) ~[?:?]
        at org.openhab.binding.signal.internal.handler.SignalBridgeHandler.send(SignalBridgeHandler.java:256) ~[?:?]
        at org.openhab.binding.signal.internal.actions.SignalActionsMain.sendSignalMain(SignalActionsMain.java:136) ~[?:?]
        at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source) ~[?:?]
        at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
        at org.openhab.core.automation.internal.module.handler.AnnotationActionHandler.execute(AnnotationActionHandler.java:127) ~[?:?]
        at org.openhab.core.automation.rest.internal.ThingActionsResource.executeThingAction(ThingActionsResource.java:258) ~[?:?]
        at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source) ~[?:?]
        at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
        at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) ~[bundleFile:3.6.8]
        at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[bundleFile:3.6.8]
        at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:201) ~[bundleFile:3.6.8]
        at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:104) ~[bundleFile:3.6.8]
        at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[bundleFile:3.6.8]
        at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[bundleFile:3.6.8]
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) ~[bundleFile:3.6.8]
        at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[bundleFile:3.6.8]
        at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267) ~[bundleFile:3.6.8]
        at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) ~[bundleFile:3.6.8]
        at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) ~[bundleFile:3.6.8]
        at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) ~[bundleFile:3.6.8]
        at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225) ~[bundleFile:3.6.8]
        at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:304) ~[bundleFile:3.6.8]
        at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:217) ~[bundleFile:3.6.8]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:517) ~[bundleFile:4.0.4]
        at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:279) ~[bundleFile:3.6.8]
        at org.ops4j.pax.web.service.spi.servlet.OsgiInitializedServlet.service(OsgiInitializedServlet.java:102) ~[bundleFile:?]
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656) ~[bundleFile:9.4.57.v20241219]
        at org.ops4j.pax.web.service.spi.servlet.OsgiFilterChain.doFilter(OsgiFilterChain.java:113) ~[bundleFile:?]
        at org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler.doHandle(PaxWebServletHandler.java:334) ~[bundleFile:?]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234) ~[bundleFile:9.4.57.v20241219]
        at org.ops4j.pax.web.service.jetty.internal.PrioritizedHandlerCollection.handle(PrioritizedHandlerCollection.java:96) ~[bundleFile:?]
        at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:722) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) ~[bundleFile:9.4.57.v20241219]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) ~[bundleFile:9.4.57.v20241219]
        at java.lang.Thread.run(Unknown Source) [?:?]

Best regards

Christian

@dalgwen Merci and Thanks a lot for your work!! Now my Signal-Binding is back up and working again.

I configured the JAVA25 within the signal-cli Startup-Script.
How can I configure it using the “environment”-Configuration? What is the separator between JAVA_HOME=/xxx/yyy and /full/path/to/Signal-CLI ?

Having to manage a separate java version is a burden I wish to alleviate. I hope to make use of the native GraalVM version (I managed to auto-build an arm64 version but windows and macos version will not be as easy). Again, if a knowledgeable people is reading this, your help is welcome :wink:

Strange ! But thanks for the report. If you ever want to receive messages, feel free to give me debug/log messages.

Wow, I actually reproduce this. But I think it’s not related to the signal binding. All the marketplace addon I installed have this issue. (honestly, it’s kind of a relief, not my fault :rofl: )

Oops, I didn’t test it. Thanks, I will look into it.

The separator is a space (AFAIK, it mimics the usual way to add environment variable when launching something from CLI). But if you ask, then it means that I should add it to the documentation.
Thanks for your report, I’m glad to see more and more people can use it despite the remaining issues.