Please login or register.

Login with username, password and session length

Author Topic: Conditions Based on Module Status (Part II)  (Read 5967 times)

Azeotrope

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 15
Conditions Based on Module Status (Part II)
« on: May 03, 2005, 09:09:55 PM »

I appreciate everyone's response,
(apparently my earlier response went into
the bit bucket)

To Joe S.  Thanks loads.  I will definitely
check it out and respond back to this
thread.

Logged

Azeotrope

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 15
Re: Conditions Based on Module Status (Part II)
« Reply #1 on: May 03, 2005, 09:11:51 PM »

>>>Looks like I'm going to have to respond
via the installment plan>>

To Mike C.--Unfortunately, the Rain8II
module has no automatic mode.  A fact of
which I became acutely aware after I
purchased it.  However, to WGL Designs'
credit, they offered an exchange and refund
of the difference even though I did not
purchase it from them.  The Rain8II does,
however, have a definable maximum time each
zone can stay on.

The reason I got the 2 way module was
precisely because what you had mentioned,
namely, the inherent unreliability  of the
x10 technology in general, not just x10's
products particularly.  With this
technology, I could, at least
theoretically, achieve some sort of "fail
safe" operation.
Logged

Azeotrope

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 15
Re: Conditions Based on Module Status (Part II)
« Reply #2 on: May 03, 2005, 09:12:20 PM »

To Tony Olson--Exactly.  Why have 2 way
modules if you can't poll them
programmatically and design macros around
their response?
Logged

Azeotrope

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 15
Re: Conditions Based on Module Status (Part II)
« Reply #3 on: May 03, 2005, 09:12:51 PM »

To x10 Pro--I understand that perhaps one
of the design goals of AHP was simplicity.
However, a suggestion for an improvement of
AHP would be to have the program handle the
hand shaking internally.  For example, if
you have specified a two way module and
sent it a command under Smart Macros, the
macro would not execute the next line until
it polled the correct status from the
module.  It would keep reissuing the
command (given some pre-defined
constraints) until such time as the
condition is satisfied.
Logged

Azeotrope

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 15
Re: Conditions Based on Module Status (Part II)
« Reply #4 on: May 03, 2005, 09:13:52 PM »

Sorry, I guess message size is limited...

To Roger H.--I don't mind taking a shot at
the SDK and I do have a battery backed up
computer that stays on 24/7 I can use.
However, rhetorically speaking, why would I
need the CM15a?

Thanks again for everyone's comments.

MG
Logged

roger1818

  • Hero Member
  • *****
  • Helpful Post Rating: 28
  • Posts: 1072
  • Roger H.
Re: Conditions Based on Module Status (Part II)
« Reply #5 on: May 04, 2005, 04:55:36 PM »

Mudguppie:  The primary purpose of 2-way
modules is not for reliable communication,
it is to allow the module to report a local
change in status.  This is most useful with
wall switches, but plug-in modules also can
be turned on locally.  For this reason I
don’t understand why X10 only makes plug-in
2-way modules.
Logged

joe s.

  • Hero Member
  • *****
  • Helpful Post Rating: 4
  • Posts: 194
Re: Conditions Based on Module Status (Part II)
« Reply #6 on: May 05, 2005, 08:28:26 AM »

Mudguppie - You're welcome.  It didn't take
very long to assemble.  Wow - funny way to
have to work with this forum.  I'm really
just posting this note so I will see email
notices as you progress.
Logged
 

X10.com | About X10 | X10 Security Systems | Cameras| Package Deals
© Copyright 2014-2016 X10.com All rights reserved.