Re: Occupancy detection

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

"Dave Houston" <nobody@xxxxxxxxxxxx> wrote in message
news:46b5987c.2135518656@xxxxxxxxxxxxxxxx
> "Robert Green" <ROBERT_GREEN1963@xxxxxxxxx> wrote:
>
> >The problem becomes how to integrate the critical lights into the X-10
> >system while maintaining isolation from some of the typical X-10 problems
of
> >collisions, inadvertent activations and lost commands.  I'd like to still
be
> >able to turn all the houselights out with a single button press but that
> >feature makes the stairway lights vulnerable to someone pressing the ALL
> >LIGHTS OFF switch while someone else is descending the stairs.  The
> >stairways lights should only respond to X-10 commands if no one is using
> >the stairs.
>
> You need to learn how to program your CPU-XA/Ocelot for use with
> hardwired sensors.

If only it were that simple.  This a primarily a reliability issue, at least
for me, so there are a number of reasons not to use ADI gear.  I don't want
to knock ADI too hard because lots of people seem to use their equipment
quite successfully.  However, in this specific case, putting a novice ladder
logic programmer (me!) who really dislikes unstructured languages like CMAX
in as a "keyman" is NOT likely to enhance the system reliability index.  (-:
The few times I've worked with CMAX have been less than optimal and, in
fact, very disappointing.  I wanted to use the CPU-XA as an IR translator
but the latency was completely unacceptable. To get good reads required
changing operator behavior.  In reading through their forum it turned out
that reliable reads meant the user had to press buttons on the remote for at
least 1 second.  That had zero SAF.

If I were to struggle with CMAX and "drip down" ladder logic, all that would
likely happen would be the reliability "demon" will simply move from the
X-10 gear into my CMAX code.  If I were to add a PC to the mix so that I
could use a more structured language like HomeSeer, that would merely move
the reliability demon to a Windows-based PC.  But there are other reasons
for me to find another solution. I just checked the ADI forum again and it's
pretty clear the Ocelot line is on life support.  Under new products there's
only the one message and it's just a code update, not a new product:

New ADI Products  --- As new products are released, we will spotlight them
here.
   Posts=1  Threads=1

Release C-Max 2.00e3 / Executive 3.18  #189683 - 02/09/07 08:36 AM
Changes:
   Daylight Savings Time Schedules changed for 2007
   ASCII Bobcat RX Compare added  (must use Version 8 or greater Bobcat)
   Fixed "Need to Load New Exec" message
   Fixed Manual TX Ascii Message for C-Max window bug

It's the same old crap but at least they are still patching the code!  But
they're also still listing meetings for 2005.  When Dan Boone left, ADI's
interests obviously went elsewhere.  I had to embarrass the heck out of them
to even get them to update their BBS, which was years out of date.  I recall
at the time being assured that new products were in the wings.  That was two
years ago.  Still nothing.

Even though I own more than enough ADI gear to solve the problem, I'm
unwilling to invest the considerable time in learning how to program a
"throwback" language on a dying product line.  I'd have to feel I had
mastered CMAX to be assured the problem was solved.  I'm guessing that it
will take at least the same amount of time it took to learn FORTRAN or COBOL
or Pascal or BASIC.  I *had* to learn those to get my degree;  there's no
such motivation with CMAX.

I'll have to throw out most of what I learned about structured coding and
embrace a programming language that's based on now-obsolete "ladders" of
mechanical relays.  Worse, still, it's a language that flies in the face of
what I was taught were good coding techniques, which inevitably means "hard
to maintain" even for the original coder.  It's just too much effort to
expend in order to solve a light switch problem that could, in all truth, be
solved by either manually operating the switch or using a dedicated motion
sensing light switch that can't be interfered with by X-10 demons.

But before I even begin to think about choosing a HW platform, good coding
technique dictate I do a requirements analysis that fully describes what I
want the system to do.  The stairway problem breaks down fairly simply:
Reliably sense entries and exits and occupancy via multiple sensors as well
as motion and light output (so that I know if the light's burned out or
really ON or OFF).  Then I need to put the entries in a state table with
some simple rules and act accordingly.  It probably doesn't even need a
microprocessor as the logic would be simple enough to implement with some
TTL devices on a perf board once the proper inputs and outputs had been
established.

I hope other CHA'ers can add their insight as to what that logic should look
like.  Ben P. and Frank have already given me some things to think about.
By writing this message, I've come up with some of my own, including a
provision for ALL LIGHTS OFF to be ignored in a occupied room if the command
was fired remotely.  That means no more shouts of "who turned off the
lights!!!???" from my wife whom I have occasionally plunged into sudden
darkness via an ALL OFF.  The programming is beginning to show similarities
to game code.  Create a data structure of all the rooms in the house and
increment and decrement counters as people move around.  Too bad I can't
program a "god mode" to turn clipping off that allows me to walk through
walls like I can in Doom!

In any event, even if I were to go the microprocessor route to solve the
problem, I'd probably opt for something newer and more powerful than the
CPU-XA or Ocelot.  Most critically, I would choose something that could be
programmed in a higher-level language than CMAX without requiring a PC
running 24/7.  The Basic Stamp series looks interesting, as do a number of
other controllers.  The Maxbotic site

http://www.maxbotix.com/MaxSonar-EZ1__FAQ.html

described some of the platforms people are using for their sensors (BasicX,
BX24p, Basic Micro, Atom, Wright Hobbies DevBoard-M32, AVR using Bascom,
Parallax, Basic Stamp BS2).  Not one was an ADI platform.  Learning how to
program a newer, more powerful microprocessor would probably have payoffs in
other areas of automation that will need microprocessor control.  Ladder
logic and leisure suits both had their day, but that day is gone, at least
for me.

--
Bobby G.