It looks like she forgot a semicolon at the end of the first one (fixed)… but you caught that. Try again… the formatting was getting mixed up because it was not posted as preformatted text (apostrophes were being converted to right and left single quotes). Same problem with the PHP code. Sorry about that!
That did it. Thanks to you and your lovely wife 
I figured it was something to do with that, but got reading about curly quotes, smart quotes, apostrophes, etc, etc and figured I would ask for a little help!
1 Like
Just in case anyone’s interested, after a couple of years I have finally given up on zoneminder. A frustrating experience trying to recover video from an event did it for me. That and monitors occasionally stopping working for no bloody reason at all.
Quite hard to find linux alternatives - the other open source ones all have their own problems (mostly rubbish motion detection). I ended up with Xeoma.
Downsides: not open source, costs £, made by a Russian company nobody has ever heard of, has server/client model but client has to run their software rather than just accessing through the web, very few resources to help if you run into trouble.
Upsides: works reliably, decent support from company, has robust motion detection, takes up 1/3 the CPU and 1/10th the disk space of zoneminder, whilst recording in higher resolution and including audio. Client runs on just about anything. Integrates easily with OH2.
Happy to give more details if anyone is interested.
(Full disclosure: Xeoma apparently has the very naughty habit of giving free licenses to people in exchange for favourable reviews. I paid for my licence!)
1 Like
Looks like it doesn’t work for ZM 1.32.0 
This has been reported in Github too. I plan to look into another workaround, but I’ve been focused on JSR223-Jython modules.
@mr_eskildsen With the latest ESH changes to how the inbox works (I’m on build 1374), my openhab.log now is being spammed with messages like this every 10-15 seconds. Is there any way to disable discovery? Alternatively, would you consider reducing some of the INFO level logging to DEBUG?
I can change my logging level to WARN in the meantime, but that’s probably not a good long term solution.
2018-09-28 07:00:19.070 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='1' and Name='AAAA' added to Inbox with ThingUID='zoneminder:monitor:zm:monitor-1'
2018-09-28 07:00:19.071 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='2' and Name='BBBB' added to Inbox with ThingUID='zoneminder:monitor:zm:monitor-2'
2018-09-28 07:00:19.072 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='3' and Name='CCCC' added to Inbox with ThingUID='zoneminder:monitor:zm:monitor-3'
2018-09-28 07:00:19.072 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='4' and Name='DDDD' added to Inbox with ThingUID='zoneminder:monitor:zm:monitor-4'
2018-09-28 07:00:19.073 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='7' and Name='EEEE' added to Inbox with ThingUID='zoneminder:monitor:zm:monitor-7'
Sounds like a good idea. Unfortunately I am bit stucked with the Binding. I haven’t looked at it lately, I hope to get the time to finish the pullrequest soon, this one would be obvious to handle
@mr_eskildsen Not sure of you are still maintaining the binding…
When forcing an alarm, I see this error in the log file.
2018-12-13 11:53:54.209 [ERROR] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-3]: context='onTrippedForceAlarm' Exception occurred inTrippedForceAlarm() Exception='null'
In debug mode, this is what I see leading up to the error.
2018-12-13 11:53:53.100 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-3]: Channel 'zoneminder:monitor:zm:monitor-3:force-alarm' in monitor '3' received command='ON'
2018-12-13 11:53:53.100 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-3]: 'handleCommand' => CHANNEL_MONITOR_FORCE_ALARM: Command 'ON' received for monitor 'force-alarm'
2018-12-13 11:53:53.100 [DEBUG] [der.internal.state.MonitorThingState] - : Recalculate channel states based on Function: Function='Nodect' -> alarmState='false', recordingState='true'
2018-12-13 11:53:53.100 [DEBUG] [der.internal.state.MonitorThingState] - : Recalculate channel states based on Detailed State: DetailedState='IDLE' -> alarmState='false', recordingState='false'
2018-12-13 11:53:53.100 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-3]: context='onStateChanged' channel='zoneminder:monitor:zm:monitor-3:force-alarm' - State changed to 'ON'
2018-12-13 11:53:53.100 [INFO ] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-3]: Activate 'ForceAlarm' to 'ON' (Reason='openHAB', Timeout='60')
2018-12-13 11:53:53.101 [DEBUG] [r.handler.ZoneMinderBaseThingHandler] - [MONITOR-3]: context='startAlarmRefresh' Starting ALARM refresh...
2018-12-13 11:53:53.201 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-3]: context='onFetchData' tag='monitorData' URL='http://hostname/zm/api/monitors/3.json' ResponseCode='200' ResponseMessage='OK'
2018-12-13 11:53:53.302 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-3]: context='onFetchData' tag='detailedStatus' URL='http://hostname/zm/api/monitors/alarm/id:3/command:status.json' ResponseCode='200' ResponseMessage='OK'
2018-12-13 11:53:53.302 [DEBUG] [der.internal.state.MonitorThingState] - : Recalculate channel states based on Function: Function='Nodect' -> alarmState='false', recordingState='true'
2018-12-13 11:53:53.303 [DEBUG] [der.internal.state.MonitorThingState] - : Recalculate channel states based on Detailed State: DetailedState='PRE_ALARM' -> alarmState='true', recordingState='true'
2018-12-13 11:53:53.303 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-3]: context='onStateChanged' channel='zoneminder:monitor:zm:monitor-3:recording' - State changed to 'ON'
2018-12-13 11:53:53.304 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-3]: context='onStateChanged' channel='zoneminder:monitor:zm:monitor-3:detailed-status' - State changed to 'Pre-Alarm'
2018-12-13 11:53:54.107 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-3]: context='onTrippedForceAlarm' Received forceAlarm for monitor 3
2018-12-13 11:53:54.135 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-7]: context='onFetchData' tag='monitorData' URL='http://hostname/zm/api/monitors/7.json' ResponseCode='200' ResponseMessage='OK'
2018-12-13 11:53:54.208 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-3]: URL='http://hostname/zm/api/events/index/Id:3494.json?page=1' ResponseCode='200' ResponseMessage='OK'
2018-12-13 11:53:54.209 [ERROR] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-3]: context='onTrippedForceAlarm' Exception occurred inTrippedForceAlarm() Exception='null'
It also would be great to get these discovery messages set to debug mode to eliminate the log spamming.
Another thing I noticed…
If I try to change the ForceAlarm timeout config parameter to 0 to disable the timeout, the change is not applied. In fact, setting it to any value has no effect. It remains at the default of 60.
You’re not alone. I get these whenever the alarm channel is triggered. I don’t use force alarm.
2018-12-13 12:00:33.543 [ERROR] [org.openhab.binding.zoneminder.handler.ZoneMinderThingMonitorHandler] - [MONITOR-11]: context='onTrippedForceAlarm' Exception occurred inTrippedForceAlarm() Exception='null'
Yeah, I started to use my motion detectors to trigger rules that use the force alarm channel to turn recording ON and OFF. I got disenchanted with the quality of Zoneminder’s motion detection. I know it’s quite powerful, but no amount of tuning and tweaking would prevent lighting changes, rain, snow, etc. from triggering the motion detection. I was starting to hate waking up to dozens of bogus events just because it rained heavily during the night. I suppose it can be done, but it’s beyond me. 
If I could figure out how to pull the PR into my local openhab2-addons repo, I’d make a few changes to reduce the logging level, fix the config changes, and handle some of these exceptions differently.
I would be glad if somebody could help finishing the pull request. Right now I don’t have the time for finalising it. I also see the need for a major rework, first of all since ZM API seems to change, but also to make the Binding more clean.
Yes… I know what you mean. I’ve got mine close to not annoying, but still a battle, especially on sunny days with clouds. Couple weeks ago a blustery snow storm made me disable one of the cameras. Setting brightness and contrast levels helped me a bit with motion detection, but reduced the quality of the images. There’s still more to tweak, but hard to get all scenarios to work with one set of settings. I haven’t tried automating them yet…
I’ve been tempted to jump in, but I have a few other OH related things in the queue. If nobody has snatched it when I get done, then I’ll gladly help out!
I pulled the PR into my local repo. I’m going to take a look at what’s necessary to wrap it up.
2 Likes
Here is another error that often comes up…
2018-12-14 05:19:42.359 [ERROR] [org.openhab.binding.zoneminder.handler.ZoneMinderServerBridgeHandler] - [BRIDGE (99ec8cf6)]: context='validateConnection' check='FAILED' - General error when creating ConnectionInfo. Retrying next cycle...
com.google.gson.JsonSyntaxException: com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 12 path $
at com.google.gson.JsonParser.parse(JsonParser.java:65) ~[21:com.google.gson:2.7.0.v20170129-0911]
at com.google.gson.JsonParser.parse(JsonParser.java:45) ~[21:com.google.gson:2.7.0.v20170129-0911]
at name.eskildsen.zoneminder.jetty.JettyConnectionInfo.fetchContentResponse(JettyConnectionInfo.java:159) ~[200:org.openhab.binding.zoneminder:2.3.0.201805211219]
at name.eskildsen.zoneminder.jetty.JettyConnectionInfo.doItSync(JettyConnectionInfo.java:75) ~[200:org.openhab.binding.zoneminder:2.3.0.201805211219]
at name.eskildsen.zoneminder.jetty.JettyConnectionInfo.onConnect(JettyConnectionInfo.java:227) ~[200:org.openhab.binding.zoneminder:2.3.0.201805211219]
at name.eskildsen.zoneminder.internal.GenericConnectionHandler.connect(GenericConnectionHandler.java:141) ~[200:org.openhab.binding.zoneminder:2.3.0.201805211219]
at name.eskildsen.zoneminder.ZoneMinderFactory.CreateConnection(ZoneMinderFactory.java:34) ~[200:org.openhab.binding.zoneminder:2.3.0.201805211219]
at org.openhab.binding.zoneminder.handler.ZoneMinderServerBridgeHandler.validateConnection(ZoneMinderServerBridgeHandler.java:801) [200:org.openhab.binding.zoneminder:2.3.0.201805211219]
at org.openhab.binding.zoneminder.handler.ZoneMinderServerBridgeHandler.initializeAvaliabilityStatus(ZoneMinderServerBridgeHandler.java:1036) [200:org.openhab.binding.zoneminder:2.3.0.201805211219]
at org.openhab.binding.zoneminder.handler.ZoneMinderServerBridgeHandler.updateAvaliabilityStatus(ZoneMinderServerBridgeHandler.java:1197) [200:org.openhab.binding.zoneminder:2.3.0.201805211219]
at org.openhab.binding.zoneminder.handler.ZoneMinderServerBridgeHandler$1.run(ZoneMinderServerBridgeHandler.java:114) [200:org.openhab.binding.zoneminder:2.3.0.201805211219]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 12 path $
at com.google.gson.stream.JsonReader.syntaxError(JsonReader.java:1559) ~[?:?]
at com.google.gson.stream.JsonReader.checkLenient(JsonReader.java:1401) ~[?:?]
at com.google.gson.stream.JsonReader.doPeek(JsonReader.java:542) ~[?:?]
at com.google.gson.stream.JsonReader.peek(JsonReader.java:425) ~[?:?]
at com.google.gson.JsonParser.parse(JsonParser.java:60) ~[?:?]
... 17 moreThis evening, I did some maintenance on our server that runs Zoneminder and did a DNF update. I had forgotten that the binding wasn’t working with the updated ZM. You can guess what happened . Since my wife fixed it last time…
… she looked at it again. Good news! Using the previous changes, the binding works and the fix is simple. If you update ZM, the configuration files are dropped into /etc/zm/zm.conf.rpmnew so that they do not overwrite your existing configuration. Included in the updated configuration is a fix to remove a deprecation warning in the JSON response that is causing the error in the binding. Apply the new conf and you’ll be working again.
So, if you upgrade (we’re on 1.32.3) and see this, update your configuration…
2019-05-23 19:20:05.365 [ERROR] [org.openhab.binding.zoneminder.internal.handler.ZoneMinderServerBridgeHandler] - [BRIDGE (99ec8cf6)]: context='validateConnection' check='FAILED' - Error creating ConnectionInfo. Retrying next cycle...
name.eskildsen.zoneminder.exception.ZoneMinderInvalidData: Error occurred when converting response to class.
at name.eskildsen.zoneminder.jetty.JettyConnectionInfo.fetchDataAsJson(JettyConnectionInfo.java:355) ~[205:org.openhab.binding.zoneminder:2.4.0.201812161831]
at name.eskildsen.zoneminder.jetty.JettyConnectionInfo.onConnect(JettyConnectionInfo.java:288) ~[205:org.openhab.binding.zoneminder:2.4.0.201812161831]
at name.eskildsen.zoneminder.internal.GenericConnectionHandler.connect(GenericConnectionHandler.java:141) ~[205:org.openhab.binding.zoneminder:2.4.0.201812161831]
at name.eskildsen.zoneminder.ZoneMinderFactory.CreateConnection(ZoneMinderFactory.java:34) ~[205:org.openhab.binding.zoneminder:2.4.0.201812161831]
at org.openhab.binding.zoneminder.internal.handler.ZoneMinderServerBridgeHandler.validateConnection(ZoneMinderServerBridgeHandler.java:782) [205:org.openhab.binding.zoneminder:2.4.0.201812161831]
at org.openhab.binding.zoneminder.internal.handler.ZoneMinderServerBridgeHandler.initializeAvaliabilityStatus(ZoneMinderServerBridgeHandler.java:998) [205:org.openhab.binding.zoneminder:2.4.0.201812161831]
at org.openhab.binding.zoneminder.internal.handler.ZoneMinderServerBridgeHandler.updateAvaliabilityStatus(ZoneMinderServerBridgeHandler.java:1139) [205:org.openhab.binding.zoneminder:2.4.0.201812161831]
at org.openhab.binding.zoneminder.internal.handler.ZoneMinderServerBridgeHandler$1.run(ZoneMinderServerBridgeHandler.java:117) [205:org.openhab.binding.zoneminder:2.4.0.201812161831]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 7 path $
at com.google.gson.stream.JsonReader.syntaxError(JsonReader.java:1568) ~[?:?]
at com.google.gson.stream.JsonReader.checkLenient(JsonReader.java:1409) ~[?:?]
at com.google.gson.stream.JsonReader.doPeek(JsonReader.java:542) ~[?:?]
at com.google.gson.stream.JsonReader.peek(JsonReader.java:425) ~[?:?]
at com.google.gson.JsonParser.parse(JsonParser.java:60) ~[?:?]
at com.google.gson.JsonParser.parse(JsonParser.java:45) ~[?:?]
at name.eskildsen.zoneminder.jetty.JettyConnectionInfo.fetchDataAsJson(JettyConnectionInfo.java:352) ~[?:?]
... 14 more
Scott
Thanks for updating on this thread. I have completed the sql inserts and updated the config as described in the fix and I’m still seeing the same “Error occurred when converting response to class” being logged. I was using the 2.4 release of the binding and switched to the market version which appears to be the 2.3 version binding.
I’m unsure if I had actually updated zoneminder to 1.32.3 or if it was fresh reinstall. In either case I’m not seeing a difference in the rpm.save file for the zm.conf so I’m not sure which config item I would look for to supress the json warning.
If anyone has had luck getting the binding to work with 1.32.3 please enlighten me. I know a rewrite is likely necessary long term but I’d love to try to use this with my current set up.
I’m using a version from @mhilbush. I thought this was the same as the version in the marketplace, with some minor fixes that Mark had done, but it looks like there’s more to it than that!
Mark, do you plan on taking this further, or maybe you could post the jar?
I dunno. I back-burned it in order to work on some other things. I need to assess how much work it will be to bring it to conclusion. Posting the jar would suggest I’m ready to support it, and I haven’t made that decision yet…
That’s unfortunate. Could you help refresh my memory… you forked mr_eskildsen’s branch with the changes from the PR that never got merged, right? I guess I could start there, but it would be missing the additional fixes you’ve made. Could you at least please put your fork in GH so that we don’t lose those fixes? I’m still completely immersed in automation, but I’ll put that down to get the official ZM binding working again.