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).
Unfortunately it seems that ZoneMinder API has changed since version 1.30. The good news is that it seems it is changing to the better. The API has some issues in 1.30 and below …
The bad news is that I am looking at something different than ZoneMinder, or at least I am considering. I might end up with ZoneMinder, but I need to see a better API before I rewrite anything.
Meanwhile I will evaluate Shinobi (see other threads).
If somebody feels like updating the binding you should be more than welcome
