Zoneminder binding

The update is great :slight_smile:
I have found one quite odd thing while developing the trigger stuff…
The required user rights for performing a action in the ZM GUI and through the API isn’t the same. The API seems to require more user rights, and I am quite sure that my Binding doesn’t give a good / understandable error for that. I need to improve errorhandling. Until then I recommend giving Edit rights in the System section. Though it should be related to your problem (since a reboot has solved it).

I have looked into the possibilities of implementing a new Channel called TriggerReason on each monitor. The channel will be readonly, and it contains a strings which can be any of the following values (in bold):

  • None - Event for monitor not triggered right now.
  • Signal - Event for monitor not triggered because of signal loss
  • Motion - Event for monitor triggered because of motion detected in ZoneMinder
  • OpenHAB - Event for monitor triggered by OpenHAB.
  • Other - Event for monitor triggered by other reason (somebody hase written an unknown reason…)

I believe that should be possible, allthough I will need to move the text that can be set today from the Cause, to the Note section (which also should be more consistent of what ZoneMinder itself does).

I hope that this approach will be useable to you guys? at least you can then see if it is triggered by OpenHAB or by something else.

super useful - thanks

I just got the binding installed and added items for my ZoneMinder server and 1 camera. All appears to be working correctly, but should the binding be showing the video as well? Or is it to include a sitemap entry similar to the above?

I would love a Montage view within OH2 if ever possible. For now I think do something similar, would need multiple sitemap entrys?

1 Like

I haven’t implemented anything that shows video, the idea sounds great, but I am uncertain if OpenHAB supports this kind of Channel. I will take a closer look on that one.

Correct, that needs to be done in the Sitemap

According to this discussion Image url, it seems that the Image Url needs to be static, it can’t be picked up from an Item. The discussion seems to be with regards to OH1, so there might be some changes in OH2?

Today Kai has done an initial review of the pull request. Since work is going on Kai hasn’t reviewed most of the Java code (that would be waste of Kai’s time). On the other hand I would like to see ZoneMinder in a openHAB package :slight_smile:

My plan therefore is:

  1. Add a new channel containing Event Cause.
  2. See if the problems regarding missing update of CpuLoad and DiskUsage is easily fixed (which I think should be the case), else I will remove them for now.
  3. Do the changes requested by Kai. I see some changes in channel naming coming.
  4. Commit and freeze the source code, to let Kai do the final review.

Since Java isn’t my first language, I guess Kai will find a lot of things to be changed. Hopefully they are minor things like the initial review. But I wouldn’t be surprised if Kai finds something.

In other words, I will finsih what is going on, and then make sure ZoneMinder Binding is released.

excellent - if you could then fix the disconnect/reconnect bug at some later point then that would be splendid

Agreed. I will see if something obvious comes around.

Status right now is that I have manged to implement a text Channel that contains the cause of the Event. I have renamed a couple of the channels (according to Kai’s suggestions, and generally aligned the names). I need to go through it all again to verify my work.
I am quite sure I have found a “smoking gun” with regards to the problems with Disk usage and cpu load. I allthough have to dig into the log to understand exactly why it fails, but I know where to search.

Regarding the OFFLINE problem, here I might need some help from you. I am adding some debug logging so that I hopefully can verify the cause of this problem as well. I might need your help running the new binding with Debug logging enabled. I will give a status on that when I am ready :-).

I have unfortunately found that ZoneMidner seems to act a little bit different from what I thought it did.
It is all about the handling of events, especially the recording modes (Mocord and Record) shows this behaviour. I thought that a event could be translated to a recording in ZoneMinder. But not quite…
With regards to motion detection yes, but when we look at what happens when we switch to Record, we will see a short event (eg. a start and then a stop occurs), but recording continues. This means that using the event Switch in openHAB won’t give the true picture to determine if ZoneMinder is Recording or not. It tells the truth about the current state of the event, but that isn’t the same story. The only / best solution I see is to add a new readonly switch called “Recording” or something like that. ON whenever the monitor is recording and OFF when it is idle. The Event switch is kept as an indicator if the monitor has an active event.

If somebody has some points about this one, then speak up :slight_smile:

I have also been looking a bit into the disconnect problem. In my ZoneMinder setup it seems (from looking at the ZoneMinder log) that ZoneMinder has some kind of hickup at almost the same time. I am a little in doubt how I can safely determine if ZoneMidner is up and running.

thanks - can I ask what you see in the zoneminder logs during the “hiccups”?

I think I will withdraw that statement for now, I have looked a little bit into the code and have found a possible explanation. At least that explains why it is going off line at a quite predictable interval.

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…