Sorry, now I understand
It is the ZoneMinder Binding that does this. Hard to deny when presented for facts like âit stops when I stop the Bindingâ
You have just found one the reasons why I still categorize it as alpha.I recently had to change the whole data fetch process, while I was (actually is) facing some issues with that, I have just used the old channel update mechanishm - causing the Binding to update the channels in each loop no matter if something changed or not.
Shortly before your writing I have actually pushed an update to the market place, which will only update channels if some changes is there. But it is not quite there, since it will update all channels if one of them changed.
I plan to rework this to use the publisher/subscriber pattern, before making it beta.
If you are using the expire binding to turn off the force alarm, you should be aware that:
This feature is already supported by the binding
You should also be aware that any event in the ZoneMinder monitor will change this to ON (eg. If you go to your ZoneMinder UI and force an alarm there, it is reflected in the binding).
I have pushed an updated Binding to the marketplace:
223 | Active | 80 | 2.3.0.201801231912 | ZoneMinder Binding
The changes are minor, but most important is that the data fetch for each monitor now is more robust, which means that if one call to ZoneMinder fails, the other calls is done.
Logging has also been slightly improved.
I am using âtriggerTimeout=120â but I am seeing a lot of â00:00:00â event times. I also would think that events that overlap should be one event. Like the one at 10:13:01 and 10:13:22 for the same camera.
From your log it is obvious that it is events that has been triggered from openHAB.
The channel force-event can be controlled both from openHAB as well as inputs from external ZoneMinder triggers, it simply just tells the state of the force alarm option in ZoneMinder. So if you manually turn on and off force alam the timeout value will be disregarded. The timeout will first have any effect after 120 seconds.
With that in mind, I guess that the alarm is triggered from openHAB. It is unclear if it is stopped from openHAB or another external system. You might find answers in your event.log for openHAB.
Do you a script or something that controls your monitors by using external triggers i ZoneMinder?
The way events is organized is controlled by ZoneMinder, I think that there is some settings in ZoneMinder but I am uncertain how it works
Hmm, interesting, so this is why I was using the expire binding before. Motion sensors are fast on / off devices and can trigger several times during a single event. However, my rule just sends ON commands so not sure what can be turning them OFF.
rule "Camera motion sensor trip"
when
Item Motion_02 changed from CLOSED to OPEN or
Item Motion_03 changed from CLOSED to OPEN or
Item Motion_25 changed from CLOSED to OPEN or
Item Motion_26 changed from CLOSED to OPEN or
Item Motion_27 changed from CLOSED to OPEN
then
val cameraNum = triggeringItem.name.split("_").get(1)
logInfo("Motion", "Motion Detected in zone " + cameraNum)
sendCommand("Camera_"+cameraNum, "ON")
end
The âproblemâ here is that motion causes an event in ZoneMinder, and that would also trigger the force-event channel.
Could it be that the items Motion_xx is linked to the motion channel? That would explain, since Motion is just a subset of events.
Right from the begining I have spent quite some time and experiments to figure out which behaviour is preferable - not said that the above behaviour is good or even logic :-).
If you are using the binding from the marketplace you should be aware that there has just been identified a problem.
The problem is that if you change enabled and/or function it can cause the monitor to lock, eg. not receiving any more updates from ZoneMinder. At the moment it is unclear if it also has impact on other monitors (I suspect that it has). The problem has been there for some time (at least 10 days, maybe much longerâŠ). It has been reported by @rbausdorf, and finally today I have found a way to reproduce the issue.
Over the last couple of days a lot have been done to identify/solve the problem, including improved logging, improved errorhandling, performance optimizations.
I will look at the specific problem tonight.
I have pushed a new Binding to the marketplace. In my setup it runs without spitting out errors.
The big news is the event driven update of monitor channels (not done for server channels yet)
Another thing is that if nothing is linked to the channel, then data will not be fetched from the server.
Logging in Debug is quite high, I will lower that and do some general cleaning and improve errorhandling (in the new section the messages is pretty useless now). Also the startup phase needs some improvements, to make sure that it can reconnect or even just connect.
I would like to hear reports on what your experience is.
Above has now been fixed and a Binding is pushed to the marketplace.
There is still need for minor adjustments, but there shouldnât be any breaking change.
Just a little status update on the work with the binding. @rbausdorf has reported connectivity issues in his setup. I have been trying to figure out what was the root cause of the problem.After spinning up a ZoneMinder 1.29 environment, I was finally able to reproduce the reported problem. Unfortunately I couldnât find any stable solution, and it all seems to end in the Http Client I was using. Yesterday I then tried to write a small test application where the problem could be reproduced, and then I changed the Http Client to Apache. An then suddenly I get predictable results. Next step would be to do some burn in test in my test setup, verifying that the same results is also seen under load.
Given a positive result, I will change the Http client in the binding. That is a significant change and I would thus need to keep it as an unstable binding in the marketplace for a little while.
Hi, just wondering if youâd had a chance to look at this further. The binding generally works great, but there is sometimes instability with the connection (as you have noticed).
One other point - I am getting errors like this in my logs:
Interestingly not - I just added the item. If I leave the item OFF, it gets tripped when the alarm is tripped by zoneminder, and then generates that error. On the other hand if I turn the item ON in Openhab, it seems to have no effect on zoneminderâŠ
A reboot fixed the last point. Changing the openhab trigger item does indeed trigger an alarm in ZM. But a ZM triggered alarm generates the OH error (whilst also correctly changing the item).
