Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pomonabill221]

I have looked for an answer to my question in these forums, and haven't found anything, so I thought I would ask.
1)Foscam FI8918w camera (IP pan and tilt).
2)ms14a's for motion outdoors.
3)macros that the ms14's trigger, turn on lights and (here's the meat of my question) run a small batch file that positions the cameras to a preset (camera preset) with a html string that is passed to a program named Lynx (free).
   The batch file is:
Lynx "http://192.168.1.75:8099/decoder_control.cgi?&user=MYUSERID&pwd=MYPASSWORD&command=31" -dump
  (I obviously didn't include my IPaddress, port, user and password... DUH!!!).  
  Lynx is a free command window browser that gets the "http://........ -dump passed to it and the camera goes to the position without having to keep a browser open.
  AHP works fine when I include this in a windows command box, but the time between the ms14 triggering the macro to when the camera command is run, is 3-5 SECONDS, and unless I put the command at the end of my macro, the other steps in the macro are delayed by the time it takes to run the windows command.
  Is there another way to make the windows command run faster or is this just to be expected?
  I know that Lynx has to load, run, process the http string, and exit before the macro can continue, but I wanted to know if there is a better way to run the "http://....." string?
  BTW... I tried calling the batch file by name in the windows command box, and specifying the LYNX.exe with the "hhtp://...." in the arguments box (two different methods), and the timing is about the same, so I gather that the time delay is opening a command box and loading Lynx??

[Tuicemen]

Have you tested the command from windows its self using the RUN?
3-5 seconds may be the load time for your PC!
A faster PC would speed it up.

[pomonabill221]

Hello T!  Thanks for the reply!
  Yes, I have tested JUST the command by double clicking on the batch file from windows explorer and the response from the camera is almost instant!  (less than 1 second, more like 0.25 seconds!)
  I double click the batch file, a command box opens and IMMEDIATLEY closes (it is just a flash), and the camera moves to the position that the batch file is set for.
  In AHP, there is a good 3-5 second delay BEFORE the command box opens, and the command box is just a flash like before, and the camera moves instantly.
  The delay comes from AHP opening the command box only.
 I tried "pre opening" Lynx in a minimized command box and that didn't improve things.
  The delay comes from having to run the macro from the pc rather than from the interface.
  I even added a step before the windows command, to turn on a light,and the delay was there also.
IE:
 receive B1 on  (side yard motion)
  B3 on  (porch light on)   <------ occurs 3-5 seconds after B1 is received!
  Windows command to execute the dos batch file <---- occurs less than 1 second later

If I shutdown AHP, the ONLY thing that WILL run is turning the light on, the windows command will NOT run... INTERESTING!
RATS!  wish there were another way to do this!
NOT ONLY does the pc have to be running, but AHP MUST be running also in order for the windows command to run!

Here is another thing...
 I have an existing macro that is triggered by the same B1 on (side yard motion) WITH a "it's nightime" condition so that the lights will only turn on at night.
B1 on (motion trigger)...
it's nightime condition...
B3 on (back porch light)
B4 ext dim (mud room light)
B5 ext dim (dining room down light)
  This has been running great for months and there is the typical 1 second delay before the first light turns on!

I made this new, separate macro to move the camera (windows command) 24 hrs. when B1 on is received.
Which means that B1 on triggers two different macros.
  This doesn't work because when "it's nighttime" is true (or the condition is removed for test), only one macro runs (the one that turns on the three lights), and the one with the windows command never runs.
  I guess the only way around this is to use a dummy module with a different UC that runs the "lighting" macro with the nighttime condition, and is "called" by the macro that runs the windows command that is triggered by the B1 ON directly so that it will always run.
IE
B10 (dummy module) that runs the lighting macro.

B1 on (motion) tirgger
B10 on (dummy that calls the lighting macro)
Windows command to move camera

  B10 on macro with ....
"it's nightime" condition...
B10 on (trigger)
B3 on (back porch light)
B4 ext dim (mud room light)
B5 ext dim (dining room down light)

  I will try this and see if the delays still exist for the lights.  I can live with the camera movement delay.

[pomonabill221]

Just tried a few things....
1) IF I have separate macros with the same trigger (IE B1 on), ONLY ONE of the macros will run (the macro that is stored in the interface... turning on lights).
  The other macro that runs the windows command (MUST be run from PC) never runs.
If I create the macro to position the camera that includes a dummy module that calls the lighting macro, the delay to process the "must run from PC" is added to the overall delay (about 3-5 seconds).
2) ANY macro that either MUST run from the PC, or is selected to run from the PC, has the 3-5 second delay before anything happens.
  My PC is a 2.4 Ghz AMD 2.5G ram (overclocked a bit to 2.4) with weather station software running also and a Davis weather station connected.  There is very little overhead (uploads every 3 seconds to weather underground and displays weather parameters using Virtual Weather software) with the weather station.
  I guess the bottleneck is the CM15a - USB - AHP processing the macro - USB - CM15a generating the PLC commands.
  The actual windows command takes less than 1 second to run so there is little added delay.
Just thought I would throw this out as to what I found out....
More to come if significant!

[Noam]

Just tried a few things....
1) IF I have separate macros with the same trigger (IE B1 on), ONLY ONE of the macros will run (the macro that is stored in the interface... turning on lights).
  The other macro that runs the windows command (MUST be run from PC) never runs.

From my experience, creating multiple macros with the same trigger address results iin an If-Then-Else setup.
AHP should "stack" them, and provide a tab at the top for each. You can re-arrange the order of the processing.
When the address is triggered, the first one starts. If the conditions are true (or there are no conditions), then it executes through, and stops. If the conditions are not met, then it goes to the second macro in the series, and tests the conditions there, etc.

It is my understanding that you have two macros with the same trigger, one which you want to run all the time, and the other one only at night. You won't be able to get both macros to run with the same trigger.
The workaround is to set the "all the time" actions in BOTH macros, and the "nighttime" action only in the one with the condition.
Move the one with the condition to be the left-most tab, and that should work for you.
Keep in mind that when  triggering macros from within AHP (by clicking on them), conditions are ignored (or assumed to be true).

[pomonabill221]

Hello Noam and thank you for the reply!   
A few things:

From my experience, creating multiple macros with the same trigger address results iin an If-Then-Else setup.
AHP should "stack" them, and provide a tab at the top for each.
Yes I am aware of this and AHP did create the tabs.

 You can re-arrange the order of the processing.
When the address is triggered, the first one starts. If the conditions are true (or there are no conditions), then it executes through, and stops. If the conditions are not met, then it goes to the second macro in the series, and tests the conditions there, etc.

I "thought" that I had the order correct, but during the day (NOT "it's nightime") the "camera" macro did not run. (I think) 
I will have to try that again though because I tried several things and don't remember if this is true or not... will let you know. (senior moment) 

It is my understanding that you have two macros with the same trigger, one which you want to run all the time, and the other one only at night. You won't be able to get both macros to run with the same trigger.
The workaround is to set the "all the time" actions in BOTH macros, and the "nighttime" action only in the one with the condition.  Move the one with the condition to be the left-most tab, and that should work for you.
 
So you are saying that the "all the time" macro and the "nighttime" macro would have the same "camera" steps, and the "nighttime" macro (in addition to the camera), would have the lighting control.
Also, the 'ITE"' tabs are processed in the order they are on the screen?  This is good to know!!!

Keep in mind that when  triggering macros from within AHP (by clicking on them), conditions are ignored (or assumed to be true).

Thanks, I am aware of that and realize this (thank you for reiterating this though!) , I use a wireless palmpad to "simulate" the motion detector (could use a wired console as well) rather than walking outside, plus I KNOW when the command is generated so I can test the timing.

Another thing that I thought of to overcome the processing delay when the macro "must run from pc" (timing of the lighting is rather critical)....
  I will create a dummy switch that is the camera macro.

  The "it''s nighttime" macro will run the lights and "turn on" the dummy which (run from interface since it does not contain the windows command), should run the camera macro.

  I will create another "all the time" macro that is triggered by the same motion (it is 24 hr.) but will ONLY "turn on" the camera macro.  This should also run from the interface.

  The "camera macro" will have to be run from the pc, and will have the longer delay.
  This should control the lights within 1 second, and the camera macro (run from the pc) will just have a 3-5 second delay that I can live with.

Thank you for your help and the workaround!  This just shows that there are other ways to do things that ONLY us geeks can find!