Excellent! Thanks for the info, I’ll take a look at that tonight 
Hi guys, is there any easy way of getting the ZM binding working with a ZM instance running on the root URL?
My ZM instance is running on http://IP:PORT/ (without the /zm). In OH, there is no way to define an empty URL path, but at least a ‘/’ must be added. And this is them causing the issues.
I can open the following URL in browser:
http://IP:PORT/api/host/getVersion.json
and getting the correct results:
{“version”:“1.37.11”,“apiversion”:“2.0”}
But, when OH tries to connect, it fails with the following error:
Can’t get version information
Software version is null
In ZM container log, I see the following logs from nginx:
[nginx] 192.168.1.90 - - [21/Feb/2022:23:41:28 +0100] “GET //api/host/getVersion.json HTTP/1.1” 404 114 “-” “Jetty/9.4.43.v20210629” “-”
there are two slashes, which are causing the problem.
Any suggestion is highly appreciated!
Thanks!
I think this is a bug in the binding. I thought this scenario was tested, but maybe not.
I’ll take a look at it and post back here.
I have a version that might fix this. But you will need to uninstall the current version, then add this version to the addons directory.
1 Like
@mhilbush really appreciate your superfast reaction! I will test it and will let you know the results soon.
When you try this new version, just put a “/” in the path field.
The ultimate fix will be to make the path field not required, but I wanted to first build a version that should work around the problem.
@mhilbush, I can confirm, that the fix is working well, I was able to connect the bridge and get camera screen in OH. A BIG thank you for your quick help!
Ok, great.
After I have a proper fix, I’ll ask you to try it out. In that version, you’ll just leave the path config parameter empty.
@abal Could you please try the version I just posted? Same link as above. With this version, please leave the path field empty.
@mhilbush It is not working, it seems to me, that it is taking the default /zm prefix, if it does not have a value:
OH log:
2022-02-22 14:31:08.991 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zoneminder:server:73a51f49b3' changed from INITIALIZING to UNINITIALIZED (HANDLER_INITIALIZING_ERROR): java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $
==> /var/log/openhab/openhab.log <==
2022-02-22 14:31:08.972 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.zoneminder.internal.handler.ZmBridgeHandler@18a1757': java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $
com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:226) ~[bundleFile:?]
ZM log:
[nginx] 2022/02/22 14:33:01 [error] 1243#1243: *2739 open() "/var/www/html/zm/api/host/login.json" failed (2: No such file or directory), client: 192.168.1.90, server: localhost, request: "POST /zm/api/host/login.json HTTP/1.1", host: "192.168.1.90:8040"
[nginx] 192.168.1.90 - - [22/Feb/2022:14:33:01 +0100] "POST /zm/api/host/login.json HTTP/1.1" 404 153 "-" "Jetty/9.4.43.v20210629" "-"
Hmm. Let me look into it.
And you get this after you deleted the contents of the path parameter in the bridge thing config?
Ok. I see what I did wrong. Hang on…
Ok, try again. With this version, you need to put a / in the path field.
Ok, good.
I’ll submit the fix for inclusion in an upcoming snapshot build.
Edit: Submitted
The change was merged last night, so the next snapshot build should contain the fix.
Thanks for pointing out the error, and for testing the fix.
@mhilbush, thank you for the binding, it works great! One question, do you have plans to add support of ZM run states in the binding? The run states are useful for example, when you want to turn off in the night analysing on all cameras and reactivate it in the day. The API function for activation of a new state is
http://{{host}}/zm/api/states/change/{{new_state}}.json
Looks like that API lets you start/stop/restart the entire Zoneminder service through the API? I hadn’t considered adding that to the binding. Can’t you accomplish what you want by disabling each of the monitors using the enable channel? Although, admittedly, if you have a bunch of monitors it can be a bit clumsy.
This feature is a little bit confusing, because it combines 2 different logical functions:
- Start/Stop/Restart of the ZM service
- A kind of “preset” for monitor activities
I agree that the first option is not needed in the binding, as it belongs more or less to the system maintenance. But the second one is quite a useful function for automation. In the ZM faq there are a couple of scenarios, where it can be applied. The function was also mentioned in this topic. These “presets” are available in the main UI page:
From the technical perspective, the function can be implemented as a string channel, which contains current value of the “run state” (GET /api/states.json) and can receive commands with a new state. The only one thing to check: if a new state is the same as the current one, it should be ignored, as ZM has no such check. It tries to set the new status even if it is the same, which leads to a needless restart of monitors and a pause in the capturing.