Using Soap onvif to listen for camera motion detection

AK, I am hoping you can shed some light on whether an extended SOAP subscription effects program execution in openLuup. There is a short thread on similar here: http://forum.micasaverde.com/index.php/topic,14664.msg111226.html#msg111226 but there did not seem to be any resolution over how program flow is effected by a daemon listening for an http response. I’ll outline what I am doing below as I am sure there are many people who are interested in using listeners/onvif commands for soap events.

Here is the background of what I am doing. I have an onvif enabled camera that has internal motion detection. I can get the capabilities of the camera using the SOAP call:

<s:Envelope
    xmlns:s="http://www.w3.org/2003/05/soap-envelope">
    <s:Body
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <GetCapabilities
        xmlns="http://www.onvif.org/ver10/device/wsdl"/>
   </s:Body>
</s:Envelope>

I place the XML in a post command after right click opening the “show request editor” in SOAPUI: https://www.soapui.org/ SOAPUI takes care of authentication, headers and encoding.

Using the WSDLs embedded in the return XML, I then send a pullmessages request:

<SOAP-ENV:Envelope 
  xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" 
  xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" 
  xmlns:wsdd="http://schemas.xmlsoap.org/ws/2005/04/discovery" 
  xmlns:chan="http://schemas.microsoft.com/ws/2005/02/duplex" 
  xmlns:wsa5="http://www.w3.org/2005/08/addressing" 
  xmlns:xmime="http://www.w3.org/2005/05/xmlmime" 
  xmlns:xop="http://www.w3.org/2004/08/xop/include" 
  xmlns:wsrfbf="http://docs.oasis-open.org/wsrf/bf-2" 
  xmlns:tt="http://www.onvif.org/ver10/schema" 
  xmlns:wstop="http://docs.oasis-open.org/wsn/t-1" 
  xmlns:wsrfr="http://docs.oasis-open.org/wsrf/r-2" 
  xmlns:ns1="http://www.onvif.org/ver10/actionengine/wsdl" 
  xmlns:tad="http://www.onvif.org/ver10/analyticsdevice/wsdl" 
  xmlns:tan="http://www.onvif.org/ver20/analytics/wsdl" 
  xmlns:tdn="http://www.onvif.org/ver10/network/wsdl" 
  xmlns:tds="http://www.onvif.org/ver10/device/wsdl" 
  xmlns:tev="http://www.onvif.org/ver10/events/wsdl" 
  xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" 
  xmlns:c14n="http://www.w3.org/2001/10/xml-exc-c14n#" 
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
  xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc" 
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 
  xmlns:timg="http://www.onvif.org/ver20/imaging/wsdl" 
  xmlns:tls="http://www.onvif.org/ver10/display/wsdl" 
  xmlns:tmd="http://www.onvif.org/ver10/deviceIO/wsdl" 
  xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl" 
  xmlns:trc="http://www.onvif.org/ver10/recording/wsdl" 
  xmlns:trp="http://www.onvif.org/ver10/replay/wsdl" 
  xmlns:trt="http://www.onvif.org/ver10/media/wsdl" 
  xmlns:trv="http://www.onvif.org/ver10/receiver/wsdl" 
  xmlns:ter="http://www.onvif.org/ver10/error" 
  xmlns:tse="http://www.onvif.org/ver10/search/wsdl" 
  xmlns:tns1="http://www.onvif.org/ver10/topics">
  <SOAP-ENV:Header>
    <wsa:Action>http://www.onvif.org/ver10/events/wsdl/PullPointSubscription/PullMessagesRequest</wsa:Action>
    <wsa:To>http://10.17.4.25/onvif/subscription?idx=4</wsa:To>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <tev:PullMessages>
      <tev:Timeout>PT59S</tev:Timeout> 
      <tev:MessageLimit>100</tev:MessageLimit> 
    </tev:PullMessages> 
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

This gets me a return XML file with an embedded motion detection message.

   <SOAP-ENV:Header>
      <wsa:To SOAP-ENV:mustUnderstand="true">http://10.17.4.25/onvif/subscription?idx=4</wsa:To>
      <wsa:Action SOAP-ENV:mustUnderstand="true">http://www.onvif.org/ver10/events/wsdl/PullPointSubscription/PullMessagesRequest</wsa:Action>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
      <tev:PullMessagesResponse>
         <tev:CurrentTime>2018-11-08T13:39:08Z</tev:CurrentTime>
         <tev:TerminationTime>2018-11-09T00:25:06Z</tev:TerminationTime>
         <wsnt:NotificationMessage>
            <wsnt:SubscriptionReference>
               <wsa5:Address>urn:uuid:1419d68a-1dd2-11b2-a105-00023EB2006A</wsa5:Address>
            </wsnt:SubscriptionReference>
            <wsnt:Topic Dialect="http://www.onvif.org/ver10/tev/topicExpression/ConcreteSet">tns1:RuleEngine/CellMotionDetector/Motion//.</wsnt:Topic>
            <wsnt:ProducerReference>
               <wsa5:Address>urn:uuid:1419d68a-1dd2-11b2-a105-00023EB2006A</wsa5:Address>
            </wsnt:ProducerReference>
            <wsnt:Message>
               <tt:Message UtcTime="2018-11-08T13:39:08">
                  <tt:Source>
                     <tt:SimpleItem Name="VideoSourceConfigurationToken" Value="VideoSourceMain"/>
                     <tt:SimpleItem Name="VideoAnalyticsConfigurationToken" Value="VideoAnalyticsToken"/>
                     <tt:SimpleItem Name="Rule" Value="MotionInDefinedCells"/>
                  </tt:Source>
                  <tt:Data>
                     <tt:SimpleItem Name="IsMotion" Value="true"/>
                  </tt:Data>
               </tt:Message>
            </wsnt:Message>
         </wsnt:NotificationMessage>
      </tev:PullMessagesResponse>
   </SOAP-ENV:Body>

I can change the tev:TimeoutPT59S</tev:Timeout> setting of 59 seconds in the pullmessages request to tev:TimeoutPT4H</tev:Timeout> four hours where the camera will wait for 4 hours for a motion event. If a motion event occurs, the soap subscription is terminated after sending its motion message, and I then have to resend the pullrequest to reestablish the connection.

In general, my question concerns two things: Will openluup deadlock on a long wait–say several hours. If yes, I can shorten the wait for another pullrequest to 30 seconds or less, but then the daemon must send a new pullrequest every 30 seconds and I’m not confident that frequent messaging won’t crash the camera.

Is an http listener in openluup the right way to go. If so, do you have any suggestions on implementation/callback routines.

As always, thx in advance for your time here.

I really know very little about SOAP, but I certainly understand the issue outlined in the (very old) thread that you mention. In particular, @futzle is really THE authority here on such things and, as she says:

However, the openLuup HTTP server does, to some extent, do that.

Will openluup deadlock on a long wait--say several hours.

It obviously depends how you implement it. If you try simply to use luup.request() or http.request() it will deadlock or time out. However, the TCP server code in the IO module can open sockets and listen on them for as long as you want, but the initial request has to be incoming, not started by openLuup.

What’s missing is something that I’ve been wanting to implement for several years, which is simply (or possibly not) an asynchronous TCP request with multiple callbacks on incoming messages. With that, I could make the VeraBridge plugin much more performant, and also do other magic along the lines you require.

Is an http listener in openluup the right way to go. If so, do you have any suggestions on implementation/callback routines.

So, not as it stands, but, again as @futzle pointed out:

I’d love to do this, I intend to do this, …but I need to take some time out again quite soon for some recuperation.

I had a suspicion that this would be the case, but I thought I’d ask just in case. It’s odd that the ability to open, and then maintain an async connection is not part of the vera engine. It seems like it should be a core feature of HA (if not vera UPnP). But I don’t know enough about the SOAP protocol to understand the implications.

Is Futzle refering to this library: GitHub - daurnimator/lua-http: HTTP Library for Lua. Supports HTTP(S) 1.0, 1.1 and 2.0; client and server. ? Regardless, I imagine there would be a lot of housekeeping involved in tracking job status etc so most likely, I would find myself in the weeds in short order. :slight_smile:

Anyway thanks for taking a look and by all means health comes first.

No, this one:

It’s part of the LuaSocket library.