Print

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

[JoKer]

This is the saga of my attempt to solve camera system problems using AHP/SmartMacros, but instead it seems that I have only made things (much) worse.  Although the ultimate question involves AHP issues, I thought it might be worthwhile telling how I got to this point, starting from a hardware-only system, because maybe someone has some better ideas, or can get me on the right track:

It all started when I bought a "simple" X10 bundle, consisting of four wireless cameras, four Ninja camera bases, four EagleEye motion sensors, a transceiver, and a VCR Commander II.  This package was supposed to produce a "quick and dirty" motion-activated surveillance and recording system.  Well, almost right out of the box, I ran into problems:

First off, the EagleEye motion sensors did not have the usable range to install them outdoors where I needed them.  I tried to get around this by adding some transceivers, but this wasn't really practical for a couple of the locations, plus the multiple transceivers did not "play nice" with each other.  Second, the cameras did not have enough light to work at night (even though they were supposedly low-light cameras).  So, I decided to try the floodlight sensors instead, thinking I could solve the range problem AND the nighttime lighting problem all at once.  Ooops!  The VCR Commander REQUIRES the wireless motion sensors to activate it.  Now what??

Anyway, I proceeded with the floodlight sensors because I simply could not find a way to make the EagleEyes work where I needed them.  The floodlights helped a little for getting the cameras to work at night (although the lights come on during the day, too, which is not really very desirable.  Oh, weeellll).  And I could now turn on the cameras via motion sensing.  Not out of the woods yet, though:  I still could not control the VCR Commander II (so there was no recording capability), and worse, the cameras had a much narrower field of view than the motion sensors, so half the time (or more) the cameras would not be looking where the motion actually was occuring.  Well, the Ninja mounts could take care of this, in theory at least.  But the Ninjas had to be positioned MANUALLY, so it was not much good for an automatic recording system (which still didn't work anyway), but even when I was watching "live", it was hard to get the cameras moved to view the action.  Not only were they slow to move, but most of the time, I had no clue WHERE to move them.  And worse, the range of the wireless position controls was less than the EagleEyes!  (I ultimately fixed that Ninja range problem, more or less, by adding a longer antenna wire to each of the Ninja receivers).

OK, overall the system was not shaping up very well.  And there were some problems apparently caused by the overlap of the floodlight sensors' base codes that was required in order to keep all four cameras on a contiguous block of four unit codes, so that the cameras would switch among themselves automatically.  But the biggest problem still was not being able to relate the camera positions to the actual location of detected motion.  This led me to try adding several fixed cameras, in an attempt to cover more of the area that the sensors would respond to, but more cameras meant loss of the automatic camera switching (that supports four cameras max), meaning that more than one camera could be on at a time.  Unfortunately, it did nothing to help figure out WHICH camera needed to be on in order to see the action that a motion detector was reacting to.  Ultimately, I tried adding more motion detectors and tried to arrange them to "zone in" on particular areas that corresponded to a given camera's view.  Still, no joy;  and, in fact, the system was nearly unusable this way, due to a bunch of new problems that had come up due to the addition of cameras and sensors.  These included the camera switching problems, apparent problems due to codes issued from the sensors causing malfunctions of other sensors, and, of course, still no recording capability.

Calling a "time out", I stepped back and tried to assess things;  it SEEMED like the idea of fine-tuning the sensed areas to correspond to the areas viewed by cameras might be workable IF there was a good way to manage all the issues with codes and such.  It also seemed like it would help if there was some way to have the system move the Ninja cameras automatically to view areas covered by particular sensors.  It also looked like more lighting was needed for several camera locations in order to get them to provide usable nighttime images.  And, of course, there still was the unresolved problem of the VCR control.

All things considered, it looked like adding a CM15A with AHP/SmartMacros would allow most of these problems to be addressed.  First off, it would allow most all the devices to be assigned independent codes, so all the code conflict/stomping issues SHOULD go away.  Second, AHP was supposed to handle automatic "bank-switching" of the cameras, so that more than four cameras could be managed automatically, keeping only one camera on at any given time.  (Unfortunately, it turned out that AHP did NOT automatically take care of camera switching.  Oh, weeelll).  Third, it would allow selective day/night control, which would be especially helpful for the camera lighting needs.  Fourth, it would allow automatic positioning control of the Ninja cameras.  And fifth, it would allow direct control of the VCR Commander II (or so I thought).  And, a bonus would be the ability to implement various "bells and whistles" that should enhance system operation, like automatically turning the TV monitor on or off as needed.  It all sounded like AHP would save the day, so I installed a CM15A and AHP/SmartMacros.

Well, after setting everything up, and implementing the new control scheme, things started falling apart from the outset:  First off, AHP did NOT control the multiple camera switching automatically (so I had to devise some clumsy work-arounds using macros).  Not a big deal - or so I THOUGHT.  Second, trying to control the positioning of the Ninjas using the limited "intelligence" available with the SmartMacros turned out to be a nightmare, and ultimately, I had to abandon any automatic camera positioning control.  (It was hard enough just to select the appropriate fixed camera, let alone try to jockey a movable camera to track the action).  Third, the macros run so slowly that by the time the camera, monitor, lights, etc. come on, the detected motion target is long gone!  Fourth, trying to design macros that will respond properly to real time motion events becomes a real problem, especially when a motion target may trigger two or more detectors in fairly quick succession.  (The behavior of multiple macros trying to execute concurrently appears to be totally unpredictable, and produces some bizarre results at times).  And fifth, the blasted VCR Commander II STILL can't be controlled!  (No idea why not).

So, that is where things are at right now.  The anticipated "fix all" of AHP/SmartMacros actually seems to have made matters WORSE.  Although the AHP-controlled system is somewhat well-behaved and usable if the motion target is docile, and does not move around too much, "real world" target behaviors regularly cause the system to get into a condition where very little works properly, and things can get REALLY screwed up without much effort.

As a result, I'm about at my wit's end.  It almost seems like it might be better to go back to a hardware-only system, because multiple macro behavior appears to be so uncontrollable/unpredicatable that it makes the system unstable, and often unusable.  At the very least, it is too slow to respond to real world motion targets.  Anyway, I'm thinking that I may have become so involved in this that I'm not seeing the forest due to the trees.  So, I'm hoping that someone may have some better perspective on this, and can offer some guidance about where to go from here, and about whether it is even POSSIBLE to create a camera system that resembles the expectations I was given when I purchased that "little" X10 camera system.  I still would like to achieve some reasonable semblence of those anticipated results, but I'm sure not seeing how to do it with the equipment and software at hand.  Any good ideas?

Thanks in advance!

[evadorev]

i think the first thing you have to do is to make a plan of all your stuff.

where`s each item is located, what is the unit/house code of each item and what do you want to do with each one.

Make a sketch and a board of each adress (ALL the adresses that belong to each thing (2 for motion sensors and 4 for each camera)).
You can group your address in different house codes too to avoid conflicts. it will help after to manage them with AHP.

AHP and smart macros can be a good thing to manage your stuff if you know IN DETAILS what you want to do. We can help you after  for precise details if you want.

Start little too !!  work to make your 4 cameras setup as reliable as you can first, then after you can add things ONE AT A TIME.

Be patient, it can be time consuming, but at the end, it worth the thing

Hope it will help. 

It`sure that X10 stuff had their limits, you have for what you pay.

[JoKer]

i think the first thing you have to do is to make a plan of all your stuff.

where`s each item is located, what is the unit/house code of each item and what do you want to do with each one.

Make a sketch and a board of each adress (ALL the adresses that belong to each thing (2 for motion sensors and 4 for each camera)).
You can group your address in different house codes too to avoid conflicts. it will help after to manage them with AHP.

AHP and smart macros can be a good thing to manage your stuff if you know IN DETAILS what you want to do. We can help you after  for precise details if you want.

I'm not sure it is what you are asking about, but here are a few specifics:

FUNCTIONAL REQUIREMENTS (both originally and now):

Minimum:  Provide 24/7 automatic motion-based surveillance of three sides of the house (driveway plus side yards) and the driveway alongside a barn.  This would include recording via VCR of audio & video from the activated camera during unattended operation, and live monitoring via a TV monitor during attended operation, with either on-demand camera movement control or selection among fixed camera views, as applicable.

Optional:  Provide the same functionality for two additional locations:  Backyard and rear side of barn.  Provide some sort of alarm or visual indication at the console station when either driveway sensor activates.

Auxiliary requirements:  To support camera operation at night, auxiliary flood lighting is required, but should be activated only as needed (to save energy).  Unfortunately, this prevents "stealth" observation at night.


As far as installation locations, the cameras and motion sensors are located at respective available spots having the best compromise of viewing coverage, weather protection, and accessibility.  Supporting components (camera receiver, TV Monitor, VCR, VCR Commander II, and CM15A) are located in the house at locations that are convenient for use and/or are centrally located as far as wireless signal distances, where applicable.

As for device address code assignments, there were basically two sets, one for the initial hardware-only scheme, and another for use with AHP.

For the basic four-zone hardware-only scheme, the codes for all devices were tightly-grouped across four contiguous Unit Codes on one House Code (in order to utilize the built-in automatic four-camera switching mechanism), specifically, the cameras were assigned codes M1, M2, M3, and M4.  The motion sensors were assigned base codes of M13, M14, M15, and M16 - allowing them to have independent base codes in case the lights needed to be turned on manually, while allowing them to issue the independent camera codes M1-M4, respectively.  (I never figured out how to control the VCR Commander II under this scheme, nor how to automatically turn the TV Monitor on/off in response to any one of the motion sensors).  The additional motion sensors and cameras that I added later were assigned a similar pattern of M5, M6, M7, & M8 for the motion sensors and M9, M10, M11, & M12 for the respective cameras.  This sort of worked but caused some camera-switching issues between the two "banks" of four cameras.

For the AHP-based control scheme, the device addresses were split up so that everything has its own discrete address, and it relies entirely on AHP to issue the appropriate response actions for each sensor input, via macros.  In this case, the cameras are on addresses C1 - C8, the motion sensors use base codes M1, M5, M9, M13, N1, N5, N9, & N13.  This allows them to "cleanly" issue up to the first three of their motion sensor output codes, although only one code from each is actually used in practice.  Several addresses on House Code K are used for modules that control the power to the TV monitor, VCR, camera receiver, and sundry devices, although the VCR has to be left on in order to be controlled by the VCR Commander II (which, unfortunately, does not yet work anyway).  Addresses on House Code O are used for the supplementary outdoor lighting required by the cameras for nighttime operation.  Addresses on House Codes E, F, G, J, and P are used for various macros needed to implement various special system operations, including the day/night control of the floodlights.  There are no overlaps, dual purposes, or other direct conflicts among any House/Unit Code addresses in this AHP "address map", and AHP must initiate all commands going to each "receiver" address.  (No hardware transmitter generates any direct commands for any receiver device).

The behaviors, limitations, etc. described in my original post occur under these respective configurations.

I hope this was the detailed information that you were seeking, although I'm not sure what relevence the specifics have on the general problem situations.