Your comments

In my projects, the "Persist" paramater only works during server-reboots, NOT after loading a new project version. So every time I change something, the values get lost.   If I read your answer correct, this is not what should happen ?????

In my opinion, the persistent variables should keep their values also after loading  new project version, at least when the variable is still used in that new project version.

Only when the variable is not in the new project version anymore, it should be erased from persistent server memory.

In our current project we have updated the server-project many times to implement all requests by our client.

We have seen every time we upload a new server project to the UMC server, all virtual tags are reset to 0.000000, including the ones we have set to persist.    Why is this happening and what can we do to fix it?

In this project it means every time we change sometime on the server-project the client has to set openingtimes of the parking-lot and he loses the current car-count. Of course this is unwanted behavior of the software.

iRidium Studio: (64 bit)
Server: 1.3.26

So after an afternoon of debugging, I finally got some of the PTZ working

First, I had to replace this.AuthTemplate with the correct template.  You probably once have inserted a different template containing the quality_h264 token and other body contents for testing? Only you forgot to take it out, causing many problems for me.

Then PTZ was still not working, so I started comparing with Wireshark de messages from ODM to the ones from Iridium.

Again I came to the same conclusion as my comments of 2 months ago : the "tptz:" and "tt:" namespaces are not correct!

Also I found the xmls were in the wrong places.

I corrected ContinuesMove to the following:

this.PTZContinuousMove = function (in_oAuthData, in_sToken, in_x, in_y)


var Xml = getAuthHeader(in_oAuthData);

// IR.Log("Header : " + Xml.toXMLString());

// Xml["s:Envelope"]["@xmlns:tptz"] = "";

//Xml["s:Envelope"]["@xmlns:tt"] = "";

Xml["s:Envelope"]["s:Body"]["ContinuousMove"] = {};

Xml["s:Envelope"]["s:Body"]["ContinuousMove"]["@xmlns"] = "";

Xml["s:Envelope"]["s:Body"]["ContinuousMove"]["ProfileToken"] = in_sToken;

Xml["s:Envelope"]["s:Body"]["ContinuousMove"]["Velocity"] = {};

Xml["s:Envelope"]["s:Body"]["ContinuousMove"]["Velocity"]["PanTilt"] = {};

Xml["s:Envelope"]["s:Body"]["ContinuousMove"]["Velocity"]["PanTilt"]["@xmlns"] = "";

Xml["s:Envelope"]["s:Body"]["ContinuousMove"]["Velocity"]["PanTilt"]["@x"] = in_x;

Xml["s:Envelope"]["s:Body"]["ContinuousMove"]["Velocity"]["PanTilt"]["@y"] = in_y;

//Xml["s:Envelope"]["s:Body"]["tptz:ContinuousMove"]["tptz:Velocity"]["tt:Zoom"] = {};

//Xml["s:Envelope"]["s:Body"]["tptz:ContinuousMove"]["tptz:Velocity"]["tt:Zoom"]["@x"] = 0;

return Xml.toXMLString();


And yesssssssssssss, finally some PTZ is working !!!!!

Later I will check the other functions.

OMG!   2 months ago I reported a problem with a hardcoded "quality_h264" profile. Did you read that comment above and do something about it ?

I guess not, since the error coming back from the camera says : "The requested profile token quality_h264 does not exist."

I finally found out why the above flooding of GetStreamURI calls happened.

The camera returned timeout = PT0H0M3S, which is a valid ISO duration

But, there is an error in your function parseTimout that makes l_nTimeOfTimeOut = 0 !

So, I have replaced parseTimout with this:

function parseTimout(in_sTiomout)


var reptms = /^PT(?:(\d+)H)?(?:(\d+)M)?(?:(\d+)S)?$/;

var hours = 0, minutes = 0, seconds = 0, totalseconds;

if (reptms.test(in_sTiomout))


var matches = reptms.exec(in_sTiomout);

if (matches[1]) hours = Number(matches[1]);

if (matches[2]) minutes = Number(matches[2]);

if (matches[3]) seconds = Number(matches[3]);

totalseconds = hours * 3600 + minutes * 60 + seconds;


return (totalseconds*1000);


Now, the timeout is parsed correct to milliseconds and the GetStreamURI functions normal.

Still PTZ is not working ......

I have put in extra logging in the Send function.

Now I see massive amounts of GetStreamUri calls being send to the camera.  

Why so many? They get send in a rate of 30 calls per second !!!

Whenever an answer from the camera is the received, it is always the same:


I guess the camera is flooded with the GetStreamUri calls, so it does not even have time to respond to PTZ calls?

So in an effort to get thing working .....

First I wiresharked the traffic from ODM to the remote PTZ camera. And I think I found the namespaces:

"NS":{"S":"SOAP-ENV", "D":"wsse", "A":"wsa"}

I have manually put in all known data in GUImain:


* Файл графической части, пересоздания объектов камер    (again: could you please put all comments in English?)


var temp_data_json = {




"Hardware":"88", "Adress":"",




"NS":{"S":"SOAP-ENV", "D":"wsse", "A":"wsa"}





This far, it will give me the authentication error because of the failing synctime.

So I had to change SOAP unit and UNITOnvifCam (see how in my comment 2 months agao).

After that it will connect and authenticate and I can see it reports PTZ support.

But I cannot see the image. This is because the image is set to local IP of the camera and not to the URL I have provided.

So I have to connect to the remote network to get the image to work.

Then I can go to the PTZ controls, but when I hit the controls nothing happens.

In the logfile I see your logging of the PTZ controls.

To see what the camera's response is, I added extra logging myself:

function PTZStopResponse(in_sText)


IR.Log("PTZ response: " + in_sText)


function PTZContinuousMoveResponse(in_sText)


IR.Log("PTZ response: " + in_sText)


See the logfile below. There is no response from the camera.

[30-04-2021 09:58:41.329] DEBUG DIALOGSYSTEM CDialogSystem::ShowPage(Home)
[30-04-2021 09:58:41.410] INFO CORE *** The client started to work, version ***
[30-04-2021 09:58:41.426] DEBUG DIALOGSYSTEM CDialogSystem::ShowPage(Home)
[30-04-2021 09:58:41.757] INFO SCRIPT tag_change, tag = StateConnected value = true
[30-04-2021 09:58:42.032] INFO SCRIPT tag_change, tag = PTZSupport value = true
[30-04-2021 09:58:42.506] INFO SCRIPT tag_change, tag = StateAuth value = true
[30-04-2021 09:58:42.982] INFO SCRIPT tag_change, tag = SetImage value = rtsp://login:password@
[30-04-2021 09:58:43.012] INFO SCRIPT tag_change, tag = StateLoading value = false
[30-04-2021 10:00:38.667] INFO SCRIPT Value Left
[30-04-2021 10:00:38.671] INFO SCRIPT in_x = -0.5 in_y 0
[30-04-2021 10:00:39.048] INFO SCRIPT Value Stop
[30-04-2021 10:00:39.478] INFO SCRIPT Value TopLeft
[30-04-2021 10:00:39.482] INFO SCRIPT in_x = -0.5 in_y 0.5
[30-04-2021 10:00:39.799] INFO SCRIPT Value Stop
[30-04-2021 10:00:40.507] INFO SCRIPT Value Right
[30-04-2021 10:00:40.523] INFO SCRIPT in_x = 0.5 in_y 0
[30-04-2021 10:00:40.612] INFO SCRIPT Value Stop
[30-04-2021 10:00:41.020] INFO SCRIPT Value Right
[30-04-2021 10:00:41.026] INFO SCRIPT in_x = 0.5 in_y 0
[30-04-2021 10:00:41.160] INFO SCRIPT Value Stop

Yes Vladimir, I have tried the ONVIF scanner without VPN.  It does NOT work, because I see no UDP traffic coming from Iridium with Wireshark.

But: when I start ODM at the same time,ODM will start sending the correct UDP discovery packets and then Iridium can receive the responses from my local ONVIF devices.

I already told you: the 2 PTZ camera's are remote.  And even if I can arrange Anydesk access to a computer in the remote network, the ONVIF scanner does not work ......

The problems with current ONVIF module are:

- There is no easy way to manually add camera. Why should this be so difficult? Normally it would be enough to know the address (URL or IP) and login+password. The ONVIF module should do the rest.

- Current ONVIF module needs the scanner to find the N,D,S namespaces.   Why is this needed?  Other ONVIF-libraries just remove namespaces. This makes everything much easier.  Also: scanner depends on UDP, so this does only work for local cameras. The ONVIF module should not depend on the scanner.

- Many cameras need authentication for the GetSystemDateAndTime action. See my comment about this 2 months ago.  Current ONVIF module does not provide this, so I had to put this in myself.

- Current ONVIF module sets the image-stream to the URL provided by the ONVIF camera. This means for a remote camera it will try to use the local IP-address of that camera. Of course this will not work, because normally remote cameras are behind NAT.   So there should be an option to enforce the address that the user has provided. See how the Node.js does this, or how ODM does this.

Thanks Vladimir, good to see you working on Onvif again.

About the Onvifscanner: this is still broken.   

But I found something interesting: when I'm using your Onvifmodule to scan, there is nothing happening but the spinning circle of dots ....

At that time I decided to start ODM to see if my Onvif camera's can still be found and at the same time: tada!  The onvifmodule still running in Iridium started to show my current 3 Onvif devices.

My guess was: OnvifScanner is not sending out the right discovery messages, but it is still listening to responses.

To prove this I compared with Wireshark ODM to Onvifscanner.

With ODM I see UDP/XML packets going to port 3702

With Onvifscanner I see no UDP/XML packets at all. So I think Onvifscanner is not sending them at all.

Next I will try to get the remote PTZ-camera's working ......

Yes, it still is relevant.   2 clients want to control their PTZ camera from their Iridium based security panels.

I have asked them if I can give you access, but they are bound by their privacy-contracts and therefore cannot give access to third parties.

I myself have access to the cameras via VPN, so if you want me to test something I can do it.

Both cameras are working fine in ODM.

They also work with the node.js ONVIF library (, so I think that implementation could be a good startingpoint for the Iridium implementation.