Cool, I have looked at the code, it seems that things is done differently.It lives in eclipse smarthome, so it is newer and thus I guess it uses newer features. I will let me “inspire” (Copy / Paste) of what is done there…
I think it is important to optimize for this kind of hardware, I guess your setup allows is to identify problems.
I can confirm that the 15sec refresh rate adds a load factor of 0.6 to my ZM server running mostly idle. No more race conditions on alarms. Now switching to 30sec refresh rate.
On thing I noticed is that on “normal” alarms the forcedAlarm channel triggers. But maybe this is due to the intermediate development state the binding is currently in. Just a side note.
That has been behaving that way always, not said that this is the correct behaviour…
I think it is most correct that it triggers on forceAlarms, both from openHAB and from elsewhere (ZoneMinder Web UI).
I also plan to add a readonly channel that triggers solely on motion events, if you want to use the camera as PIR Sensor.
In my thinking I would expect the “forcedAlarm” channel to behave as a switch which can be triggered by the force alarm functions from ZM UI or openHAB as you mentioned. The existing “alarm” channel I think as contact when a recognized (not forced) alarm fires.
Cool - currently I’ve wired one cam’s physical trigger output to a GPIO pin of an RPi. For the other cams I would appreciate that feature. 
Isn’t the motionEvent channel already existing, or does this one have an other intention ?
https://github.com/openhab/openhab2-addons/tree/master/addons/binding/org.openhab.binding.zoneminder
As far as I remember the alarm channel is following the monitor state (Idle, Prealarm, Alarm). So it will be triggered whenever the monitor is in alarm state, both if it is because of a force alarm as well as a motion alarm.
Yes, that is the channel (I have cerated it a couple of days ago), but it doesn’t do much right now…
I’ve seen this and experienced this in other bindings likely. The point is that - in OH 1.x - it was possible to use Switch or Contact items with a bindings binary datapoint or channel (there was no common naming for that). In OH 2.x that has changed. If you link a Contact item to a switch channel, the item is never updated.
Many bindings use Switch channels (perhaps from historical reasons) even if the switch state can only be changed by the thing. Changing the switch state in OH will never have an effect on the thing. In my understanding the Contact abstraction is a more appropriate approach.
It seems that a 30sec refresh lowers the load addition only marginally. I will try to quantify that later. But alarms, even from more than one monitor, do no longer harm at all. Very well done!
So do you see any chances to further reduce the “base load” ? I think a lower refresh rate raises the risk of missing alarms ?!
Thats the one thing about openHAB 2.x that is irritating me. I really loved the feature you describe.
I suggest that we go and drink a beer (or more) and discuss that!
I am using Z-Wave and as far as I see both types of PIR sensors is reporting On/Off State (Everspring and Fibaro).
If I implement it as a Switch somebody will need it as a Contact.
I would like to see some easy mechanishm to do this conversion, without having to make rules for that…
Thanks
Short answer: YES!!!
I see a few things that could be done. Right now each “normal” update loop has five queries:
zm/api/monitors/1.jsonzm/api/monitors/daemonStatus/id:1/daemon:zmc.json)I am uncertain if the last query runs every time, if it does it doesn’t have too when idle. Also I found a better way of finding the last event for a monitor. Right now I am quering the monitor for events I get a list of more pages, so eventually I need to go to last page and look at the last record. TThis result is potentialy rather big.I have an idea that I could at least persist the event id when an event is active. This would reduces this quite a bit.
That should not happen,because I have set up a telnet connection to the ZoneMinder Server listening for events, eg. I am not polling events. Whenever an event comes, I put the refresh rate into alarmstate, causing refresh every second.
Right now I am cleaning the monitor handler, as a spinoff of this discussion I have also moved the conversion between ZoneMinder raw data to openHAB states into its own class. This means I can easily setup unittesting for that particular class. Therefore I also will create a unittest project. It would be so easy to maintain stuff afterwards.
The main problem is that when I started with the binding, I really didn’t know much about ZoneMinder API, which is also constantly evolving, most of the documentation has I found by reading tons of post and others code (especially the zmNinja project has been to great help). Right now I am trying to get rid of the last part of POC code.
A very good idea ! 
Fantastic - so I will continue load measurement on lower refresh rates.
Well, that is often the nasty part.
But another thing:
When I got back home today I just had an “out of Java heapspace” error. This occured first time ever on my system.
After killing an restarting openHAB, the Zoneminder bridge thing did not initialize (“Credentials not valid”) during restart.
Even removing and re-adding the things did not help. Only switching the protocol config param to https and back fixed that.
Could you please keep an eye on the still image handling for accumulating memory leakage ? I’m suggesting (better guessing) this because of “lessons learned” from other projects. 
Btw: It’s not important if a monitor is ignored in the inbox or not - even if it is visible the “added” log message appears every few minutes.
I have a vague idea of what could be the problem. I have seen something similar in my environment. It could possibly be the logging that causes the problem (I think I have some hardcoded debug stuff in the zoneminder4j. library. That needs to be removed.
Since the still image seems to work, that should be possible. I plan to either implement a config setting controlling if images are fetched. Or alternatively I think I can programatically check if and item is linkedto a channel. But I am unsure if this is good practice. But solution will be one of those two possible solutions…
OutOfMemoryError again, after 5 hours of operation. This seems really to be a problem.
That onlky makes me more certain that I know where to look.
I will look into that as soon as I have something that runs again 
I pushed an updated to jar to the market place late last evening. It has been running in my environment an memory usage seems to be stable.
The problem was some code added for debug purpose, which I have forgotten all about, if it takes short or long time to get the OutOfMemoryError depends on your refresh rate…
I will monitor my setup and check that memory usage doesn’t grow.
Martin, are these builds only available through the Marketplace, or are these also in the latest OH snapshot builds? If so, I am willing to help test.
Only marketplace. Be aware that it is marked as alpha right now, which seems reasonable when reading the above discussion 
I hope that it now has become more stable and hopefully can mark it as beta in a couple of days
OK, thank you… I’m not using the Marketplace (running version 2.3.0.201801092213 from snapshot 1177). Load and memory levels seem high, so I’m interested in what you’ve been able to do. But I’ll wait until your changes are in the 2.3 snapshot.
What you describe about load is exactly the problem discussed above. The memory problem was intruduced in the development branch. If you are interested I can provide a direct download link for the JAR in the marketplace. But wait until it is a bit more stable. Right now it is not recomenable…
Thank you for the offer, but I will wait until your updates are being distributed in the snapshot builds.
No problem, if you change your mind you can send a PM
Just installed it. The “common” initializing problems (HTTP/HTTPS to fix “invalid credentials”, double change needed to change a config param value). getByteArrayExceptions are gone.
I will later report on load addition.
That one is fund and execute to be fixe in Next build latter this weekend.