-
-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eventserver only triggering for Monitor #1 #420
Comments
How long are the events on the other monitors? The ES Perl daemon scans SHM every 5 seconds. If an event is less than 5 seconds it may not be caught. |
I did think of that and dropped the check interval to 1 second to compensate, but with these being forced alarms I was making sure they stayed for a minute or more.
I am getting this for Monitor #1
Not sure what I'm missing at this point. |
Ok, so, wanted to upgrade things anyway, so setup a fresh install on a beefy physical server using Ubuntu 22.04. Same version of Zoneminder, and installed the event server. Now, not getting any triggers from monitors and getting this in the logs:
It is a slightly newer version of Perl5 in Ubuntu 22.04, 5.34.0 vice 5.30.0 under Ubuntu 20.04. I'm assuming the change in Perl5 is the cause because there was some breaking changes, I don't have to use Perl anymore so don't keep track of all that. |
Open zmeventnotification.pl in a text editor and the top line has a -T Remove the -T and try running it again. |
Looks the same to me
|
I don't use the Perl daemon myself anymore so it's a bit hard for me to debug. Remove the "strict" line as well, I think that may help. https://github.com/ZoneMinder/zmeventnotification/blob/master/zmeventnotification.pl#L37 |
So that didn't do much, but removing "use warnings" got rid of all the extra messages. Unfortunately, it's still not detecting the monitors that are in alarms, I had a forced alarm on Monitor 1 the entire time and nothing.
|
Can you print out your monitor table from DB? It's weird that you're the only person so far with the problem but it may have to do with some of the c structs being changed that the Perl daemon scans in SHM. I'm wondering what's different about monitor 1 than all the others and the 'Monitor' table in the db should be able to show the differences. |
Please test latest master. I never pushed my change to use Capturing instead of Function for ZM > 1.37.13. So now I have. Give it a try see if it fixes this. |
I was noticing in the database that all my monitors are set to Monitor instead of MoCord and Record, then I saw the feature list in 1.37 and this one stood out to me,
So it appears that the Function column in the Monitors table no longer is updated or looked at. I had set them manually to the appropriate function and things started working.
So as of right now, things seem to be working. I will test a bunch more over the weekend, but it looks like that change in 1.37 was the breaking item. |
I am still getting this though
Here's the entire run debug info. I do see the publish in my MQTT server, so not sure if there's a callback missing somewhere...
|
I'm going to close this out because really, the issues I'm facing are not the same and the original issue is resolved by @connortechnology with his push,
|
Event Server version
6.1.28
Hooks version (if you are using Object Detection)
app:6.1.28, pyzm:0.3.56
Are you using MLAPI? (Y/N)
No
The version of ZoneMinder you are using:
1.37.21
What is the nature of your issue
Only alarms on Monitor 1 are being seen by zmeventserver
Details
I have 6 cameras and using MQTT in ES to get notified when a monitor is in alarm. I can only seem to get events for Monitor #1, either when forcing the alarm or otherwise. I've reviewed the ini's and there's no skipped monitors anywhere enabled, so really confused. The logs (in debug mode) just don't show any event for anything but Monitor #1.
Default rules and tokens, only modification is the enablement of the MQTT using the secrets.ini and appropriate changes in the main ini. Also disabled FCM, since it's not working at the moment anyway.
Debug Logs (if applicable)
Thanks!
The text was updated successfully, but these errors were encountered: