First let me say I'm happy to do some scripting so this is not just a question of the type: can it be done via the web interface. I'm happy to write whatever extra functionality, but I'd prefer not to modify ZM itself.
So to the point. Ideally I'd like to be able to see different types of stuff in montage review. For example, I'm setting up object recognition and I'd like to track my cats, but at the same time I need to alert on humans/vehicles for security. It would be great if I could differentiate somehow these two kinds of alerts in Montage Review. I know zmtrigger can overlay text on video feed, but this requires scrolling to the event and viewing it.
Is there any trick one can think of to mark different types of events/alerts on the timeline? One idea I have is perhaps additional monitors can be set up for each camera, for each event/alert type.
For example there is a 4K camera called "Entrance"4K on Mocord with no ZM motion detection. There is a script that listens for the push motion alerts from the camera and when it receives one the plan is to trigger ZM alert, but also do object recognition and somehow include that information about the objects in the type of the alert.
So lets say I want to separate general motion, from "human/vehicle" and cats. I create two additional monitors EntranceSecurity and EntranceCats. I set both to Nodect and source is empty for both(or is set to file, pointing to a 1x1px image if necessary). I trigger them as required. Then in montage review I see additional highlighted bars for Security alerts and Cats.
What do you think? Is there a better way? Perhaps the dev version has some extra features that can help?
Separate alert types. Can this be done with ZM and how?
Re: Separate alert types. Can this be done with ZM and how?
In 1.37, this is doable.
We have filters at the top now with which you can tell it to show only events with either something in the notes column, or now we have a new Tags feature.
We have filters at the top now with which you can tell it to show only events with either something in the notes column, or now we have a new Tags feature.
Re: Separate alert types. Can this be done with ZM and how?
This is very cool. Do you think it would be difficult to backport the feature to 1.36.33? (For someone who knows sql, C, perl and PHP, but haven't touched two last ones for a very long time).
Alternatively, do you think the dev version is stable enough to be run in production (assuming the user if fairly technical). For example do you, or anyone else run 1.37 on a real system 24/7?
I was planning to go to 1.37 for the onvif alerts, but it turned out my cameras don't support onvif Pull Point and ZM doesn't support BaseSubscription. So I decided to stay with 1.36.33 for now.
Alternatively, do you think the dev version is stable enough to be run in production (assuming the user if fairly technical). For example do you, or anyone else run 1.37 on a real system 24/7?
I was planning to go to 1.37 for the onvif alerts, but it turned out my cameras don't support onvif Pull Point and ZM doesn't support BaseSubscription. So I decided to stay with 1.36.33 for now.
Re: Separate alert types. Can this be done with ZM and how?
1.36 is stable. Meaning it gets no new features, only bug fixes. Just run 1.37.
Re: Separate alert types. Can this be done with ZM and how?
Do you(or anyone else) know how many people might be running it?(latest 1.37) A few, a dozen, hundreds? If its into at least a couple hundreds, looking at the issues on github I'd say it is pretty stable. If it's less than a dozen people... I'm not sure.
Re: Separate alert types. Can this be done with ZM and how?
I run it in production on over 50 servers. In general it is stable. Occasionally we break things but fix them quickly.
You can always just revert to last week's version if something breaks.
You can always just revert to last week's version if something breaks.
Re: Separate alert types. Can this be done with ZM and how?
Cool. I'll give it another go then.
Previously I had issues upgrading (there is another thread about it here, essentially zmc would just crash on start with very little info logged after upgrade). This time instead of upgrading the container image I'll use a new one and I'll try to just upgrade the DB. Hopefully that will work better for me.
Previously I had issues upgrading (there is another thread about it here, essentially zmc would just crash on start with very little info logged after upgrade). This time instead of upgrading the container image I'll use a new one and I'll try to just upgrade the DB. Hopefully that will work better for me.