ZoneMinder Binding in Marketplace (Beta)

Add-ons Bindings
1

There is now a new Beta release of the ZoneMinder Binding available in the marketplace. The most significant changes, since the Binding that ships along with openHAB:
• HttpClient has been changed to use Jetty. This should also address the connectivity issues.
• Performance has been addressed. Both frequency of calls to Zoneminder Server and number of calls pr. Iteration has been significantly reduced. It should now but significantly lower load on the openHAB server.
• Monitor Channels is only updated when something is linked to the channel.
• New channels has arrived: motion, image and `video-url’. The latter is only a string, containing the url to the live stream, and is considered experimental.
The motion channel works like a PIR sensor (eg. ON when there is an active alarm based on motion, else OFF).
The image channel exposes a still image . Update frequency is configurable in the settings. It is possible to configure different update frequencies for normal operation, and another when the monitor is alarmed. It should be possible to find some individual setting. Available settings for update in normal operation: ‘disabled’, ’low’, ‘normal’. Settings when alarmed: ‘disabled’, ‘low’, ‘normal’ and ‘alarm’
Where ‘low’ and ‘normal’ is configurable frequencies, ‘alarm’ means every cycle.
With the introduction of images and streams, the ZoneMinder Streaming server is used (zms). This site requires authentication through query parameters in the URL. For the sake of still images the URL isn’t exposed outside openHAB, but still user name and password would be in urlencoded clear text. To deal with that I have looked at the ZoneMinder Hash authentication. By now the following settings is supported
In the ZoneMinder settings dialog on the system tab:
AUTH_RELAY must be set to none. If AUTH_HASH_LOGINS is enabled, then a authentication hash will be generated and used in the URL instead of the password.
In the next build it will also be possible to enabled AUTH_HASH_IPS as long as openHAB server and ZoneMinder server is on the same LAN.
I also plan to allow the usage of a specific streaming user, since the user rights in ZoneMinder can be limited to only allow Streaming.
Since a ZoneMinder monitor can be configured differently. It can be enabled/disabled, function (modect, nodect, monitor,…), With the new channels and the huge amount of possible settings by combining all combinations on how a monitor can be configured, it has become clear to me that there is a ugernt need to update documentation. So this activity will get some attention.
Known problems / issues
• There is some disconnects in the log, but the Binding seems to reconnect again. The root cause needs to be addressed.
• A few exceptions in the log needs to be addressed. Nothing that should affect stability.
• Update of Server channels not omitted when nothing is linked.
• Some enhancements needed to control the channel update in the monitor (Some settings is disregarded right now).
• The scale setting for still images is omitted.

Possible improvements
• Integration PTZ controls
• Support for zmNinja EventServer
I think both of the above improvements will have to wait until a later release, so I will focus on the known problems / issues. The changes already done are so significant that I would like to see these changes ship with openHAB.

I would like to thank @captndelta for sharing code to fetch still images. I would also thank @rbausdorf for helping optimize performance by his testing.

2 Likes
2

I have just uploaded another build that fixes the problems with setting values for enabled and function channels.
Both chanels can now both be changed from openHAB as well as ZoneMinder.
As I wrote earlier, it also means that it now should be safe to enable AUTH_HASH_IPS setting in ZoneMinder - at least as long as you are on the same LAN.

3

I will try to explain a little more in depth how the significant channels is working.

In ZoneMinder the function of a monitor can be configured in five different ways. The explanation below is copy & paste from the ZoneMinder documenation. The corresponding channel in the binding is function

None
The monitor is currently disabled. No streams can be viewed or events generated. Nothing is recorded.

Monitor
The monitor is only available for live streaming. No image analysis is done so no alarms or events will be generated, and nothing will be recorded.

Modect
All captured images will be analysed and events generated with recorded video where motion is detected.

Record
The monitor will be continuously recorded. Events of a fixed-length will be generated regardless of motion, analogous to a conventional time-lapse video recorder. No motion detection takes place in this mode.

Mocord
The monitor will be continuously recorded, with any motion being highlighted within those events.
Nodect This is a special mode designed to be used with external triggers. In Nodect no motion detection takes place but events are recorded if external triggers require it.

This means that the state of some of the other channels is dependent on the state of the function channel. If the monitor is set to None the daemons will stop. I think the correct state would be Undefiend (since either On or Off is correct).
Also the force-alarm , alarm, recording and motion-event is affected of this setting.
I think Monitor, Modect and eventually None would be interesting in the openHAB context.

The channel detailed-status represents the status value shown under the stream in ZoneMinder. The foillowing values is possible:

Idle
As it says: Idle. No alarms, no recording, just running.

Pre-alarm
The monitor is warming up to an alarm.

Alarm
The Zone Minder monitor has an active (open) event.

Alert
The event is closing.

Recording
This value is only possible when function is set to either Record and Mocord. Means that the monitor is recording, but no active event.

The third channel of some interest is the channel event-cause. It is blank whenever the monitor is not have an active event. Possible values is:
None
No event active, or somebody has started an event without specific a cause (not tried, teoretically possible when using external events)

Forced Web
Means that the event was triggered from the ZoneMinder UI

Motion
The event was triggered by detected motion, the channel motion-event will be set to ON until the event is closed.

Signal
The monitor lost signal


It is possible to set any value when a external event is triggered (like the binding uses openHAB (configurable)

The above three channels is the channels that is used for “calculating”/ detrmining the value of these channels:

  • recording
  • alarm
  • motion-event

Recording
Undefined when function is None or Monitor.
On / Off when function is Modect or Nodect.
On when function is Record or Mocord

Recording
Undefined when function is None, Monitor or Record.
On / Off when function is Modect, Mocord or Nodect.

Motion-event
Undefined when function is None, Monitor, Record or Nodect.
On / Off when function is Modect or Mocord .

Force-alarm
Can be used as a On/Off switch when function is either Modect, Mocord or Nodect. When used in other modes it is ignored and an error is logged in the log.
For simplicity I will leave the state, since I else need to keep trace of previous state in the different modes.

The two other channels I have mentioned is used in combination with the function setting to determine the value of the four channels being calculated.

I know that the behaviour described above (at leat all the undefined state) is not implemented in the binding.

I hope this description is usefull. Please ask if it is unclear, This description should end end the documentation when it is understandable.

Security is another chapter, which I will only write about briefly.
I have some findings that points me in direction of some potential problems.
I have setup my server to generate a hash auth token that includes the ipaddress. The documentation states that a auth hash token is valid for approx. two hours.
I have tried to use the hash token generated using my internal Ip adresses (LAN) and then use from a external (WAN) 4 hours later. I would expect nothing to show up for two reasons:

  • Token should not be valid
  • The machines asking is obviously having two different ipaddresses

But - I do get an image :scream:
I need to spend some time to veryfy that my ZoneMinder server (1.30.4) is setup correct and also verify that the ip address is part of the generated hash token. I will also check my code to verify that there isn’t any problems on my side.

UPDATE: I just found some settings in my server that might explain this behaviour :-).

4

I have been investigating to find some facts in this case.
It turns out that the main problem was an wrong setting in my ZoneMinder server, more or less leaving ZoneMinder open for those knowning a username :scream:

The important setting here is the AUTH_RELAY setting. Mine was none. which means that either password nor authentication hash is used. Another setting is plain then user and password need to be given in the url - as the setting says in plain text. Last possibility is hashed. The problem here is that a hashed version password is part of the hash that is generated. I can generate a authentication key, but if i should get the password I need to access MySQL to do this query: Select PASSWORD("<PASSWORD>"); That will give me the password stored in the ZoneMinder Database. I really don’t think this is a way to go, I will wait until a hash key can be generated throuhg the API.
I looked in the development branch of ZoneMinder and saw that there is a pull request to solve this particular feature, so hopefully it will find its way to ZoneMinder 1.31.

I will instead suggest that the ZoneMinder Binding adds two optional configuration fields to allow a specific username and password for a streaming user. In ZoneMinder it is possible to create a user that can only stream. Not said it is a beatifull solution, but as I see it, the least ugly :slight_smile:

I will update the binding to allow both none and plain

5

A new version of the binindg has been released to marketplace. both none, plain and hashed will work, but the latter will NOT be supported (allthough it works)
An extra (optional) user for the streaming purpose has been added to the server configuration. If you use wither none or plain, the username (and password for plain) will be written in clear text in the url.
The last option hashed do work, but you have to find the users hashed password in the ZoneMinder database. The easiest way is to connect to the ZoneMinder database server and generated a MySQL hashed password (SELECT PASSWORD('<password to hash>'))

6

A dedicated user for the binding needs the following rights in the ZM server setup:

stream: view
events: edit
system: edit

7

I Think you need monitor edit as well. That should allow to edit monitor settings (Function and Enable channels).

8

Exactly these two are covered by “system”. I expected too that function and enable channel are bound to “monitor edit” but - at least for ZM 1.29 - this is not the case.

1 Like
9

Interesting, have you found anything about That in the dokumentation??

10

Not really:

" ‘Stream’ defines whether a user is allowed to view the ‘live’ video feeds coming from the cameras. You may wish to allow a user to view historical events only in which case this setting should be ‘none’. The ‘Events’ setting determines whether a user can view and modify or delete any retained historical events. The ‘Control’ setting allows you to indicate whether the user is able to control any Pan/Tilt/Zoom type cameras you may have on your system. The ‘Monitors’ setting specifies whether a user can see the current monitor settings and change them. Finally the ‘System’ setting determines whether a user can view or modify the system settings as a whole, such as options and users or controlling the running of the system as a whole."

It seems that the “monitor” right covers only the settings with in the monitor editing dialog such as source, buffers and so on.

11

I have now tried on my 1.30.4 setup. events: edit seems unnessary, I can lower it to view on my setup (and force event still works.
Both Monitor and System needs edit. System edit is needed for function to work (not that gives much sense to me, i’d expected monitor: edit).
So minimum required rights for a user (for everything to work is (in 1.30.4):

stream: view
events: view
monitor: edit
system: edit

It is possible to define a specific user for streaming, if that is done, that user only needs the streaming view.
Hashing of user credentials should also work.

12

Hi @mr_eskildsen I recently installed zoneminder v1.30.4. I’m new to zoneminder, so I’m (slowly) in the process of getting it configured… So far, I have 5 cameras set up as monitors, and I’m in the process of defining and tuning some zones. I’m running zoneminder on a dedicated 1U server that I just built (Core i5 7600K w/ 16 GB, OC to 4.2 GHz), so I have plenty of headroom to grow my installation.

I’m ready to start integrating zoneminder with my openHAB installation, but I’m not certain whether I should use the zoneminder binding in the OH2 distro, or the beta binding from the marketplace. I’m thinking that I should use the beta binding because:

  • I don’t mind working through issues with the binding (as long as they don’t cause my OH installation to become unstable). I’ve developed several bindings myself, so I’m pretty comfortable dealing with code that’s under development;
  • I assume the beta binding will at some point replace the binding currently in the OH distro, so it seems to make sense to start out with the beta version. That way I won’t have to switch down the road; and
  • I’m assuming the beta binding is a better choice since it was written for more recent versions of zoneminder.

What do you think of that approach? Are there any landmines you can help me avoid? :wink:

Thanks for your work on the zoneminder binding. I’m pretty excited to get my zoneminder platform integrated into openHAB.

13

Cool setup, more powerfull than what I have for ALL my virtual machines…

Where a lot of things has radically changed (hopefully to the better) in the marketplace version, it still has its problems. Mine seems to disconnect every now and then. I am trying to figure out what is the root cause, by improving error logging. In the old binding I just corrected the problem and never got a decent error logging… The path to success is allthough a bit longer, but I think the result is far better. I have had a good process with @rbausdorf, to optimize performance. I have removed a lot of the load on the ZoneMinder Server. He reports that it now runs quite well on his smaal ZoneMinder Server (I think it is a Banana Pi).

The distro binding has a lot issues in the connection process, it sometimes requires magic skills to get a connection to the ZoneMinder Server. The logon process has been changed radically, where the approach in the distro binding seems to work (in most cases), it has some serious flaws (it just scrapes the first page trying to figure out if it is the dashboard or a login page.In the market place edition that has been reworked, so that it now actually relies on http status codes and return messages instead. Still ZoneMinder isn’t reallyu consistent about return codes If API is disabled it returns Not Authorized, even if user name and password is correct.

I would like as many people to use the binding in the marketplace, because that is the best way to identify problems (and hopefully solve these problems).

:+1:

There are a lot, but 1.30.4 is far better than earlier, since APi is enabled by default now. Primarily you need to tweak the settings. But the log should tell you if you are missing some settings, so you should be able to get it running by using trial and error approach… Be aware that user rights can’t be checked, and missing userrights could cause things to fail.

I really recommend NOT to use the disk usage channel in the server. since it puts some decent load on the ZoneMinder Server (at least earlier it was implemented as a du command (from ‘/’ I think).If you don’t link anything to the channel in the marketplace edition, it won’t ever be called.

14

Thanks for the feedback. That seals it. I’ll definitely go with the marketplace binding. And, I’m happy to work with you on tracking down any issues. Have you pushed the code to a Github repo yet? It’s sometimes easier to help track things down if I can see what the code is doing…

Well, half the fun is actually doing the build. :wink: I had never built a 1U server from scratch, so this was a good learning experience. I wanted to start using 1U servers in my rack, and the commercially available stuff was just crazy expensive. Space (especially vertical space) is a premium, so you have to be really careful how you select motherboard, cpu fan, etc. I purposely overbuilt it. After I get zoneminder up and running, and can see what it consumes, I hope to move it to a VM.

Good to know. Thanks.

15

Another question… How do you want to handle feedback? Do you want it posted here on this thread, or somewhere else?

16

I have some initial feedback.

I installed the binding and added the Server thing. This message helped me find my issue quickly. :+1:

2018-02-23 17:33:00.426 [ERROR] [andler.ZoneMinderServerBridgeHandler] - [BRIDGE (zm)]: context='validateZoneMinderServerConfig' check='FAILED' - Bridge OFFLINE because ZoneMinder Server option 'OPT_TRIGGERS' not enabled

When I added a Monitor thing from the inbox, I got some errors.

2018-02-23 17:38:34.087 [ERROR] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: Exception occurred when calling 'onBridgeConencted()'. Exception='null'
2018-02-23 17:38:34.088 [ERROR] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: context='updateMonitorProperties' Unable to aquire session.

Edit: The above seems to be reproducible. I deleted I monitor and server thing. Then I added the server thing and monitor thing, and got the same errors.

After this I made a change to the .items file. I got one of these every time I edited the .items file, but I’m not sure why.

2018-02-23 17:50:38.591 [ERROR] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: context='updateChannel' Error when upating channelId='zoneminder:monitor:zm:monitor-1:online' state='UNDEF'

I enabled DEBUG logging and saw some of these. Not sure why it’s logging null instead of the bridge UID.

2018-02-23 18:04:36.364 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: context='updateAvailabilityStatus' ThingAvailability: Thing 'zoneminder:monitor:zm:monitor-1' has Bridge 'null' defined (Check PASSED)
2018-02-23 18:04:36.364 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: context='updateAvailabilityStatus' ThingAvailability: Bridge 'null' is ONLINE (Check PASSED)
2018-02-23 18:04:36.364 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: context='updateAvailabilityStatus' ThingAvailability: Thing 'zoneminder:monitor:zm:monitor-1' has valid configuration (Check PASSED)
2018-02-23 18:04:36.365 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: context='updateAvailabilityStatus' ThingAvailability: ZoneMinder Id for Thing 'zoneminder:monitor:zm:monitor-1' defined (Check PASSED)
2018-02-23 18:04:36.565 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: URL='http://zoneminder.XXXXXXXX/zm/api/monitors/daemonStatus/id:1/daemon:zmc.json' ResponseCode='200' ResponseMessage='OK'
2

The online and enabled channels were not updating, and the switches were non-functional. I saw a few of these when I tried to enable/disable the monitor.

2018-02-23 18:12:41.138 [ERROR] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: Exception in 'handleCommand' => 'CHANNEL_MONITOR_ENABLE' Exception='null'
2018-02-23 18:12:54.213 [ERROR] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: Exception in 'handleCommand' => 'CHANNEL_MONITOR_ENABLE' Exception='null'

I deleted and readded the Monitor thing, which seemed to fix things.

Then I stopped and started the binding, and saw some of these.

2018-02-23 18:24:48.841 [INFO ] [andler.ZoneMinderServerBridgeHandler] - [BRIDGE (zm)]: context='dispose' Stopping Discovery service
2018-02-23 18:24:48.843 [INFO ] [andler.ZoneMinderServerBridgeHandler] - [BRIDGE (zm)]: context='dispose' Stopping WatchDog task
2018-02-23 18:24:48.844 [INFO ] [andler.ZoneMinderServerBridgeHandler] - [BRIDGE (zm)]: context='dispose' Stopping refresh data task
2018-02-23 18:24:48.852 [INFO ] [andler.ZoneMinderServerBridgeHandler] - [BRIDGE (zm)]: context='updateBridgeStatus' Bridge status changed from 'UNINITIALIZED' to 'ONLINE'
2018-02-23 18:24:48.853 [ERROR] [andler.ZoneMinderServerBridgeHandler] - [BRIDGE (zm)]: context='updateAvailablilityStatus' Exception occurred in updateAvailabilityStatus Exception='Could not update status, because callback is missing'
2018-02-23 18:24:48.853 [INFO ] [andler.ZoneMinderServerBridgeHandler] - [BRIDGE (zm)]: context='updateBridgeStatus' Bridge status changed from 'UNINITIALIZED' to 'OFFLINE'
2018-02-23 18:24:48.856 [ERROR] [andler.ZoneMinderServerBridgeHandler] - [WATCHDOG]: Server run(): StackTrace: File='BaseThingHandler.java', Line='450', Method='updateStatus', Exception: Could not update status, because callback is missing
2018-02-23 18:26:16.099 [INFO ] [andler.ZoneMinderServerBridgeHandler] - [BRIDGE (zm)]: context='constructor' Starting ZoneMinder Server Bridge Handler (Bridge='null')
2018-02-23 18:26:16.100 [INFO ] [andler.ZoneMinderServerBridgeHandler] - [BRIDGE (zm)]: ZoneMinder Server Bridge Handler Initialized
2018-02-23 18:26:16.101 [INFO ] [andler.ZoneMinderThingMonitorHandler] - [MONITOR]: Starting ZoneMinder Server Thing Handler (Thing='zoneminder:monitor:zm:monitor-1')
2018-02-23 18:26:16.102 [ERROR] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: context='updateChannel' Error when upating channelId='zoneminder:monitor:zm:monitor-1:online' state='UNDEF'
2018-02-23 18:26:16.102 [INFO ] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: context='initialize' Monitor Handler Initialized
2018-02-23 18:26:16.102 [INFO ] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: context='channelLinked' - Unlinking from channel 'zoneminder:monitor:zm:monitor-1:online'
2018-02-23 18:26:16.103 [INFO ] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: context='channelLinked' - Unlinking from channel 'zoneminder:monitor:zm:monitor-1:enabled'
2018-02-23 18:26:22.014 [INFO ] [andler.ZoneMinderServerBridgeHandler] - [BRIDGE (zm)]: context='updateBridgeStatus' Bridge status changed from 'OFFLINE' to 'ONLINE'
2018-02-23 18:26:22.821 [INFO ] [andler.ZoneMinderThingMonitorHandler] - [MONITOR-1]: Add subsription for Monitor Events: zoneminder:server:zm

After all this, things seem to be running pretty smoothly.

Since I’ve added just 1 of my 5 monitors, I see lots of these in my openhab.log. I’d prefer that these be logged as DEBUG (or maybe even TRACE). If I have things in the inbox, I probably don’t need to see them logged repeatedly at INFO level in openhab.log.

2018-02-23 18:07:45.648 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='2' and Name='Living Room' added
2018-02-23 18:07:45.649 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='3' and Name='Patio' added
2018-02-23 18:07:45.651 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='4' and Name='Front Yard' added
2018-02-23 18:07:45.652 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='5' and Name='Basement' added
2018-02-23 18:07:58.978 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='2' and Name='Living Room' added
2018-02-23 18:07:58.978 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='3' and Name='Patio' added
2018-02-23 18:07:58.980 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='4' and Name='Front Yard' added
2018-02-23 18:07:58.981 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='5' and Name='Basement' added
2018-02-23 18:08:12.405 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='2' and Name='Living Room' added
2018-02-23 18:08:12.406 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='3' and Name='Patio' added
2018-02-23 18:08:12.407 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='4' and Name='Front Yard' added
2018-02-23 18:08:12.409 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='5' and Name='Basement' added
2018-02-23 18:08:25.640 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='2' and Name='Living Room' added
2018-02-23 18:08:25.641 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='3' and Name='Patio' added
2018-02-23 18:08:25.642 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='4' and Name='Front Yard' added
2018-02-23 18:08:25.644 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='5' and Name='Basement' added
2018-02-23 18:08:39.268 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='2' and Name='Living Room' added
2018-02-23 18:08:39.269 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='3' and Name='Patio' added
2018-02-23 18:08:39.270 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='4' and Name='Front Yard' added
2018-02-23 18:08:39.272 [INFO ] [discovery.ZoneMinderDiscoveryService] - [DISCOVERY]: Monitor with Id='5' and Name='Basement' added
17

It would be fine with your findings here (at least right now while trying to fix the problems)

I think you have found most of the problems that I haven’t fixed yet. My focus has primarily been on stability once initialised. I knew that there is a few exceptions when initilising. They also seems to be some kind of timing in it, which means different hardware (slow/fast) will give different results. The cause is allthough the same. I you look carefully in your log you will probaly see the exceptions before everything comes online, that is before this statement:

[BRIDGE (zm)]: context='updateBridgeStatus' Bridge status changed from 'OFFLINE' to 'ONLINE'

Regarding enable monitor, I have found some problem in my setup where disable/enable will cause ZoneMinder not to react on force-alarms for a while.

The discovery problem is also a well know problem. You can allthough go into advanced settings in the bridge and disabled background discovery. I have to look into the discovery process, since I think there is room for some improvement here also. I have changed the code according to your suggestion, so next build should reflect this :-). I will posty here when I have put something new in the marketplace.

18

Thanks for the quick feedback. I had a feeling I was being redundant with some of this, but I thought it best to be as complete as possible with my observations.

19

No problem, better twice than never. And I also got some hints of some logging that I have forgotten to update. So it wasn’t waste to report it :-).

20

I have just updated the Binding in the marketplace. It doesn’t contain any breaking changes, just changes I have made during the hunt for unstability in my own installation (which turned out to be a full disk :blush: :). The changes is:

  • Improved/changed error logging
  • Changed Discovery, so that it only adds things to inbox when they are not there already.
  • Fixed the errors thrown during startup.

Please notice that due to an error in the core Smarthome you might (still) see a lot of info loggings regarding discovery. This has although been fixed in Eclispe Smarthome 13. november 2017, so newer builds of openHAB shouldn’t have this problem.

1 Like