Zoneminder binding

Does anybody know what the most secure zoneminder user settings would be and still let the Zoneminder binding communicate properly with it?

Stream: view or none
Events:	none, view or edit
Control: none , view or edit 
Monitors: none, view or edit
Groups: none, view or edit
System: none, view or edit

I just started using the zmNinja app and decided to setup 3 separate users (admin, one for Zoneminder bindings and one for zmNinja). .

Time to a little update on how things is progressing:

I believe I have found and solved the issue with IsAlive going OFF.I my test setup it has been running for 1,5 hour without turning OFF :slight_smile:

I have been investigating how the binding should act when running the monitor in a continous recording mode (eg. Mocord or Record). Currently my approach has been to connect to listen to port 6802 for events being published there, so that I don’t have to poll the API for changes. It turns out that this approach, doesn’t allow me to show correct state at all times.
The problem is, that when starting continous recording, a start event is sent, but right away two stop events is being sent. If I query the API, an event is still active until I stop recording. whenever I stop recording I receive another stop event, which is just fine. When reading the documentation it seems to be the expected/described behaviour.

The problem is that I solely uses the event on port 6802 to trigger start / stop of an event, which I obviously can’t. I have looked at how zmNinja deals with this, and it seems that the API is being polled. I would really like to avoid polling, but I don’t see any possibility for avoiding it. I will add a new channel that contains the state as shown in both ZoneMinder and zmNinja (five states 0=Idle, 1=pre-alarm, 2=alarm, 3=alert, 4=recording)

I have also looked a the channels that is currently defined in the monitor, especially because Kai pin pointed that static information shouldn’t be in an channnel / item, that should be moved to a property. With that in mind I have looked at my channels an I will remove channels:that has static or almost static information, for the monitor this is name and sourcetype.

channels will be renamed to reflect the contents of the channel. I suggest the following channel lineup for a monitor thing:

  • is-alive (switch)
  • enabled (switch)
  • alarmed (switch) (previously trigger-event)
  • recording (switch)

Advanced channels

  • function (String) (None, Modect, Monitor, Mocord, Record, Nodect)
  • event-status (Number) (Either 0: idle, 1: pre-alarm, 2: alarm, 3: alert, 4: recording)
  • event-cause (String: , Signal, Motion, Continous, openHAB, Other)
  • status-capture-daemon (Switch) - previously daemon-capture-state
  • status-analysis-daemon (Switch) - previously daemon-analysis-state
  • status-frame-daemon (Switch) - previously daemon-frame-state

The following channels will be removed, as I think they contain amore or less useless text string:
daemon-capture-statustext
daemon-analysis-statustext
daemon-frame-statustext

With the above changes it should be possible to get the same information as displayed in ZoneMinder /zmNinja, as well as a indication of the event cause (signal, motion etc).

Hopefully this channel lineup would be satisfactory for most of you? At least I believe that I are getting enough information.
Unfortunately this reuires some rework in the code, but I think this will be needed for things to work properly.

Stream: I have view, but I believe none might/should be sufficient (isn’t tested)
Events: edit
Control: none
Monitors: edit
Groups: none
System: edit (Not obvious, but neccesary)

I will also have to warn you that the Binding won’t probably give you any usefull error when user rights is missing. Still on todo list.

Thanks mr_eskildsen!!!

No Problem, Whenever the Binding becomes a bit more stable I will see if Stream end Events can be set to something less than now, theoretically this should be possible. .

well I’m happy already (save for the IsAlive niggle that you’ve fixed). But this all sounds great.

Finally I got something working after the refactoring.
https://github.com/openhab/openhab2-addons/files/692314/zoneminder.zip

Please notice that it is a major refactoring. It is completely incompatible with previous version, make sure it is uninstalled from openHAB before adding this.

It might introduce all kinds of issues (including blowing things up), so don’t use it in your production environment! (Now you have been warned
).
Since I haven’t changed the documentation, please use the atatched configuration


Many thanks. Seems to work fine, with alarms triggering perfectly. Still have the six second IsAlive flicker, though


Weird, I will look into it. I might have reintroced the error while changing other things.
I am aware of the Binding behaving weird (not initialising correctly) after discovery. openHAB has to be restarted for things to start correctly. Obviously it is a bug


I have a new version on its way, Here I have improved how the scheduled task that polls ZoneMinder API not to bombard ZoneMinder, thus not creating a load. I will continue to work on that one in the next couple of days, because I think it is important that the Binding is not creating a load by querying all the time - at least for me since I don’t want big servers around


For the Initial Binding I will support modect, monitor. The other function modes is there but they are unsupported - but they will probably work.

If you have any points regarding something that should obviously be there, then please speak up, as I am beginning to stop further development for now.

I think I’ve found your “behaving weird (not initialising correctly)” bug. It was working fine. Then I restarted openHAB and now get a bunch of “no handler defined” errors. Paper UI shows everything okay but the binding doesn’t work


Errors look like:

2017-01-09 23:00:43.631 [WARN ] [andler.ZoneMinderThingMonitorHandler] - updateChannel(): Monitor 'FireEscape': No handler defined for channel='zoneminder:monitor:c178e3bf:monitor-3:daemon-frame-statustext'
2017-01-09 23:00:43.631 [ERROR] [r.handler.ZoneMinderBaseThingHandler] - updateChannel() in base class, called for an unknown channel 'daemon-frame-statustext', this channel must be handled in super class.
2017-01-09 23:00:43.631 [INFO ] [r.handler.ZoneMinderBaseThingHandler] - refreshThing(): Thing Refreshed - zoneminder:monitor:c178e3bf:monitor-3
2017-01-09 23:00:43.672 [ERROR] [andler.ZoneMinderServerBridgeHandler] - Method 'refreshThing()' for Bridge zoneminder:server:c178e3bf failed for thing='zoneminder:monitor:c178e3bf:monitor-4' - Exception='null'

thank you!

Dan

It seems like openHAB hasn’t uninstalled the old binding coreectly, at least it is referring to channel names that has been removed.
Try to start openHAB from command line and in the console enter

list | grep ZoneMinder

Iguess it will either refer to more bindings (one or more old and a new).
Foreach id you should execute this command

bundle:uninstall <Id>

Replace <Id> with the Id (Integer value) of the ZoneMinder Binding you want to get rid of.
When all Bindings is removed, then restart openHAB and check if it does pick up the right Binding.
At that time you will then see the problem I was calling weird, to fix this you will have to restart openHAB once more, and finally everything should be looking allright


I am working on a fix for this problem. I have found some problems that the Binding seems to hang when things get heated up. It is most obvious a synchronization issue, I can easily reproduce it, and the fix will also address the above mentioned “weird problem”.

You were right - two binding installs. I removed both and restarted, but unfortunately that doesn’t seem to help. No matter how many times I restart I get a bunch of errors, starting:

2017-01-10 10:12:47.658 [ERROR] [andler.ZoneMinderServerBridgeHandler] - Server WatchDog::run(): Exception: java.lang.ArrayIndexOutOfBoundsException: -1

and then lots like:

2017-01-10 10:14:55.545 [ERROR] [andler.ZoneMinderServerBridgeHandler] - Method 'refreshThing()' for Bridge zoneminder:server:zm failed for thing='zoneminder:monitor:zm:monitor-2' - Exception='null'
2017-01-10 10:15:06.490 [INFO ] [r.handler.ZoneMinderBaseThingHandler] - refreshThing(): Thing Refreshed - zoneminder:monitor:zm:monitor-5
2017-01-10 10:15:06.836 [INFO ] [r.handler.ZoneMinderBaseThingHandler] - refreshThing(): Thing Refreshed - zoneminder:monitor:zm:monitor-3
2017-01-10 10:15:06.874 [ERROR] [andler.ZoneMinderServerBridgeHandler] - Method 'refreshThing()' for Bridge zoneminder:server:zm failed for thing='zoneminder:monitor:zm:monitor-4' - Exception='null'
2017-01-10 10:15:06.874 [ERROR] [andler.ZoneMinderServerBridgeHandler] - Method 'refreshThing()' for Bridge zoneminder:server:zm failed for thing='zoneminder:monitor:zm:monitor-2' - Exception='null'
2017-01-10 10:15:17.806 [INFO ] [r.handler.ZoneMinderBaseThingHandler] - refreshThing(): Thing Refreshed - zoneminder:monitor:zm:monitor-5
2017-01-10 10:15:18.151 [INFO ] [r.handler.ZoneMinderBaseThingHandler] - refreshThing(): Thing Refreshed - zoneminder:monitor:zm:monitor-3
2017-01-10 10:15:18.193 [ERROR] [andler.ZoneMinderServerBridgeHandler] - Method 'refreshThing()' for Bridge zoneminder:server:zm failed for thing='zoneminder:monitor:zm:monitor-4' - Exception='null'
2017-01-10 10:15:18.194 [ERROR] [andler.ZoneMinderServerBridgeHandler] - Method 'refreshThing()' for Bridge zoneminder:server:zm failed for thing='zoneminder:monitor:zm:monitor-2' - Exception='null'

Oddly everything looks fine in PaperUI


Dan

Hmmm, doesn’t look like something I have seen before. Can you provide debug logs?
Alternatively it seems like monitor 3 and 5 is running allright, where 2 and 4 is throwing an exception.
Is there a difference in how your monitors is defined in ZoneMinder?

I think that was just the particular log I sent you - all four monitors are misbehaving in the same way

I removed all the monitors and the binding works fine with the server itself. I then added back in monitor-2, with the following debug log:

2017-01-10 13:27:59.776 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zoneminder:monitor:zm:monitor-2' to inbox.
2017-01-10 13:29:31.601 [INFO ] [andler.ZoneMinderThingMonitorHandler] - Starting ZoneMinder Server Thing Handler (Thing='zoneminder:monitor:zm:monitor-2')
2017-01-10 13:29:31.617 [DEBUG] [r.handler.ZoneMinderBaseThingHandler] - Initializing ZoneMinder Thing handler - Thing Type: monitor; Thing ID: zoneminder:monitor:zm:monitor-2.
2017-01-10 13:29:31.618 [ERROR] [andler.ZoneMinderThingMonitorHandler] - Configuration for Thing 'zoneminder:monitor:zm:monitor-2' is not loaded correctly.
2017-01-10 13:29:31.618 [DEBUG] [andler.ZoneMinderThingMonitorHandler] - Channel 'zoneminder:monitor:zm:monitor-2:event-state' in monitor '' received command='REFRESH'
2017-01-10 13:29:34.916 [DEBUG] [r.handler.ZoneMinderBaseThingHandler] - getZoneMinderBridgeHandler(): Bridge for 'zoneminder:monitor:zm:monitor-2' - 'zoneminder:server:zm'
2017-01-10 13:29:34.916 [DEBUG] [r.handler.ZoneMinderBaseThingHandler] - refreshThing(): Bridge 'zoneminder:server:zm' Found for Thing 'zoneminder:monitor:zm:monitor-2'!
2017-01-10 13:29:34.917 [ERROR] [andler.ZoneMinderServerBridgeHandler] - Method 'refreshThing()' for Bridge zoneminder:server:zm failed for thing='zoneminder:monitor:zm:monitor-2' - Exception='null'
2017-01-10 13:29:45.487 [DEBUG] [r.handler.ZoneMinderBaseThingHandler] - refreshThing(): Bridge 'zoneminder:server:zm' Found for Thing 'zoneminder:monitor:zm:monitor-2'!

(and then the last two logs repeat)

Sure, but I didn’t see any DEBUG entries in the first one.

Seems like it doesn’t catch the monitor configuration correctly.
The problem above might be this problem I was referring earlier, since it doesn’t seems that the Monitor Handler gets properly initialized. Can you try to restart, that should invoke initialize, which should also write the Binding configuration for that monitor.

I’m having quite inconsistent behaviour.

What I was doing before was adding all four monitors and restarting - then it fails every time.

But if I delete all the monitors, add one, and restart, then that one gets initialised correctly and works fine (and it doesn’t matter which one I add - they all work okay at this point).

I can then add another, and restart, and the second works okay some of the time.

However no matter what I do I can’t get all four working - when I add the third or fourth then, invariably, all four monitors fail, and continue to fail if I restart.

Oops, I spoke too soon. So it starts running fine with just one monitor, but after a few minutes it stops refreshing, with no debug messages - just silence from the binding.

Hmmm, sems like the problem I am struglling with right now was already introduced in the Binding you have. I would really recommend that you revert back to what was working for now. It would be waste of time to test further on that, The problem is that the conenction just stops, it could be after 5 minutes or after three hours. When that happends everything gets silent

It tend to be worse at high refreshrates, what refresh rates are you using?

1 Like

thanks - will revert to the 2 January version.

Was using default refresh rates

really appreciate all your work on this

Dan

I have build a new JAR:
https://github.com/openhab/openhab2-addons/files/709531/org.openhab.binding.zoneminder-2.0.0-SNAPSHOT.zip

I really hope this one is better than the previous one.:flushed:

It is really important that you make sure that the old one is uninstalled (eg. bundle:uninstall from karaf).
Check the readme page for the new/changed channels. Comments are welcome :slight_smile:

1 Like