The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Zoneminder



Hi James,

Quoting James (2/19/06 2:54 PM):
> Gregg,
>
> Could i add a request tothe next version.

Sure!

> In the VMI.AlarmEvent can you
> include the URL of the camera's live jpeg as in
> http://192.168.0.92/cgi-bin/zm/zms?mode=single&monitor=2&scale=100&rand=1140377507
>
> With this info I can get xAP Desktop and later windows MCE to popup on
> an event and show a liveish video of what is going on.
>
> Actually now i think on this it would be really ideal and better than
> the above suggestion for the ZM plugin to use this schema for events:
(
> in addition to the vmi one)
> http://www.mi4.biz/modules.php?name=Content&pa=showpage&pid=9

I think that's a much idea than "munging" the vmi schema.  Can
you
provide me (either on or off-list) a sample of which fields of the
Display schema are filled w/ what zone minder information?  As an
example, I could include the monitor's name as some text that goes into
"line1", etc.  Or, more powerfully, I could allow the text
inserted into
each Line to be a regular expression to include certain special
variables (e.g., <monitor_name>).

Just to clarify, the URL above is a "live view URL--not the URL for an
alarmed event.  That means that whatever caused the alarm may or may not
still be visible by the time that a user decides to look (and whatever
delays might be encountered by grabbing the images).  Since there are 2
URLs (a URL and a Link), maybe one could be used for live and the other
for the alarmed event?

Should anything be sent when the alarm ends (wrt Display)?

> I'm also getting further with my PTZ issues. Turns out most were down
to
> two things. Firstly the 'Return to' feature doesn't work for Preset1,
> does for Home. That left the camera in odd positions. Secondly the
> camera's pir was causing the camera to re-centre on each detection and
> then ZM re-moved the camera - a true CCTV yo-yo.

I had also thought that I had seen some reference to pre 1.22.0 being
somewhat buggy in this area.  However, this brings up a good point of
discussion--how to resolve control "master".  If I allow xAP
messages to
control camera positioning, then I would think that I should also force
zm to no longer control positioning--else you get a "fight" going
as
observed above.  I'm pretty sure that I can remote disable zm's control,
but that also implies that I will need to support a zm control
"resume"
command via xAP.  Unfortunately, there's nothing that I can do about
localized camera control (e.g., your cam's PIR).

I also plan to introduce additional support for temporary zm motion
event "suppressions" and "resume" so that the simple
act of moving a
camera doesn't introduce artificial alarms.  Initially, this would be
manual (i.e., the xAP "controller" would need to send out these
messages).  Later, I could add logic to automatically apply them on a
xAP-initiated "move".  This could also be useful to reduce false
alarms
if you know (from other HA-sensors) that a camera should be allowed to
create alarms for a brief period.

FWIW: I've now fully switched to the new 1.22.0 API and plan on some
sort of a next release by next weekend.  The implication is that all
future zmxap releases will require zm 1.22.x.

Gregg




xAP_Automation Main Index | xAP_Automation Thread Index | xAP_Automation Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.