Please login or register.

Login with username, password and session length
Advanced search  

News:

The Buster PiX10Hub is here! Created by the Community, for the Community.:)% #:)

Pages: 1 [2] 3

Author Topic: Conditions Based on Module Status  (Read 10947 times)

paul k

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 14
Re: Conditions Based on Module Status
« Reply #15 on: May 05, 2005, 11:20:24 AM »

The SmartHome one I am using for the Rain8-II
does. I have tried using it with the
SmartHome controller and I have constructed a
command using the AHP SDK. I am not sure how
to make the CM15A store such a control though
(I do not know if there is a format for this
in the definition of modules for AHP).
Logged

roger1818

  • Hero Member
  • *****
  • Helpful Post Rating: 28
  • Posts: 1072
  • Roger H.
Re: Conditions Based on Module Status
« Reply #16 on: May 05, 2005, 02:22:14 PM »

Paul:  What SmartHome module are you
using?  From what I have read, the
PowerLink Serial (1132B) doesn’t do this.
It will receive extended code data (unlike
the TW523), but it won’t process it.
Instead it passes the raw data on to be
interpreted by the Rain8 (or whatever you
have connected to the PowerLinc).  I didn’t
see anything in the  Rain8-II’s
documentation about using secure addressing.
Logged

paul k

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 14
Re: Conditions Based on Module Status
« Reply #17 on: May 06, 2005, 12:27:14 AM »

Hi. I used the PowerLinc and connected it to
my computer via serial. It was getting the
extended address message. But, you are right
that this will not work if the Rain8 will not
accept it. I have checked that level 4
extended messages work with the SmartHome
inline module I have. This works and does
have a security "tag" (but I am not sure if
it is being checked). So, we get no special
protection unless things will use that
feature. I guess if you really want
protection, you can use an inline module (or
other device which supports extended address)
and use it to cut or enable power to the
underlying module. This would allow the macro
to 1st switch on that unit and then the
Rain8. At the end, the inline module would be
switched off and so the Rain8 could not
operate (no power). But, I am personally not
worried enough about the sprinklers. I do
have some other devices which are more of a
worry and I will look at using the inline
module for them if I can determine how to
address them from CM15A (or I may use the
SmartHome one which does have this).
Logged

Azeotrope

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 15
Re: Conditions Based on Module Status
« Reply #18 on: May 07, 2005, 07:42:18 AM »

After having spent a whole day going
through my options on how to implement this
sprinkler controller program, the following
are the conclusions I have drawn.

Note to Joe S.--Thank you for the example.
I used it to create the SHP program below.
I would have posted in the Accessx10 forum
but it won't allow me for some reason
although I have registered.

AHP--I downloaded the SDK to see if I could
use it to write my own routine.  However,
when you request device status it seems it
queries the activity log instead of the
device itself.  This is no different than
AHP itself.

Smarthome Manager Plus--I configured the
program as a sequence (per Joe S.'
suggestion) and it appears here...

http://home.swbell.net/robertab/Irrigation_S
equence.JPG

However, SHP chokes on it.  Something about
too many indentations.  I'll probably have
to break it up somehow.  Although I think
this gives some semblance of fault
tolerance, I'm not sure what happens if the
status request command "times out".
Logged

Azeotrope

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 15
Re: Conditions Based on Module Status
« Reply #19 on: May 07, 2005, 07:43:05 AM »

Part II

Home Control Assistant--This program has a
neat visual programmer and has the
conditional tests I need.  Here is part of
the program I assembled...

http://home.swbell.net/robertab/HCA_Irrigati
on_Program.JPG

Unfortunately, the software, when connected
to the 1132 CU, fails more often than it
succeeds in polling the device status.  I
tried polling both the Rain 8II and a
Switchlinc 2-way controller I have with
similar results.  At least the SHP software
successfully polled the devices without
fail.

In HCA you can define the path it takes if
the status request times out but given the
unreliability of the status request the
choices would either be an endless loop or
the sprinklers would never turn on.
Logged

Azeotrope

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 15
Re: Conditions Based on Module Status
« Reply #20 on: May 07, 2005, 07:43:50 AM »

Part III

Homeseer-  I didn't even bother downloading
the 74 MB trial version of Homeseer.  The
trial version requires that it be run from
a computer and I was uncertain about
support for the CM15a or 1132CU.  It seems
like it's way more than I need besides
being expensive.

Although I am loathe to use x10's forum
bandwidth discussing competing products the
truth is that all the products have
problems (given the context of what I am
trying to do).  I really like the AHP
software and wish I could use it for this
application...maybe by rev. 8.287663.

Thank for all the comments this thread has
generated.  I learned a lot.

MG
Logged

tcassio

  • Sr. Member
  • ****
  • Helpful Post Rating: 0
  • Posts: 131
Re: Conditions Based on Module Status
« Reply #21 on: May 07, 2005, 08:49:22 AM »

MudGuppie,
I use HCA and have found that there tech
support is execellent. If you email them
with your problems, they will respond with
an intelligent answer.  I have been running
it for about a month without any problems,
however I am not using any polling in my
application.
Give it a try, they may be able to solve
your problems.
T.
Logged

Azeotrope

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 15
Re: Conditions Based on Module Status
« Reply #22 on: May 07, 2005, 09:48:02 AM »

TCassio:  I like their program, however, I
just read in their notes, that HCA, like
AHP, only tests the recorded status of the
module in the 1132 CU controller, not the
module itself.

Oh well, the search goes on...

MG
Logged

tcassio

  • Sr. Member
  • ****
  • Helpful Post Rating: 0
  • Posts: 131
Re: Conditions Based on Module Status
« Reply #23 on: May 07, 2005, 10:03:27 AM »

MudGuppie,
I am not familiar with the Rain8, I just
went to smarthome and read that all it is a
bunch of relays controlled by X10
addresses.  Why not wire a door/window
sensor to the contacts of the zone you wish
to monitor. Then you will get alerts when
the relay is opened or closed. You will
need the WGL w800 transciever to recieve
the rf from the door/window sensor.
T.
Logged

paul k

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 14
Re: Conditions Based on Module Status
« Reply #24 on: May 07, 2005, 12:59:03 PM »

Mudguppie, I have tried sending an actual
status request from the PC (using the AHPSDK)
and the Rain8 does respond correctly. I had
heard that the SHMP software always polls
devices it is told can be polled. That is, if
you tell it "ON", it will check if it is on
and then try some number of times to make it
on (uses polite mode perhaps, so signal
congestion clears). But, it may not have any
"out" if things go badly (never gets
through). On the other hand, I have had no
problems in my house, but then I use a
crossover/booster (repater) and I use house
codes like E and F and G, so no overlap with
a neighbor. Also, the only real transmitter
is the one I control, so not likely to have
competing messages. Thanks.
Logged

roger1818

  • Hero Member
  • *****
  • Helpful Post Rating: 28
  • Posts: 1072
  • Roger H.
Re: Conditions Based on Module Status
« Reply #25 on: May 07, 2005, 11:16:11 PM »

Mudguppie: With regards to using AHP SDK,
you are correct and the “request device
status” function in the SDK will query the
activity log.  The way to do it would be to
manually send a “status request” command
and then manually read the response from
the module.  Not the easiest solution to
implement, but it should work if you do it
this way.
Logged

joe s.

  • Hero Member
  • *****
  • Helpful Post Rating: 4
  • Posts: 194
Re: Conditions Based on Module Status
« Reply #26 on: May 09, 2005, 10:24:35 PM »

Mudguppie - sorry for the radio silence -
I've been away (in fact, I still am).
You're right - I think 8 "indentations" is
the limit (now that I think of it) and yes,
you can break it up.  Sorry, I should have
tried a download before posting.
Logged

X10 Pro

  • Hero Member
  • *****
  • Helpful Post Rating: 23
  • Posts: 1416
Re: Conditions Based on Module Status
« Reply #27 on: May 10, 2005, 01:21:19 PM »

Mudguppie: I've been out of town, or would
have replied sooner (sorry I didn't leave you
guys a notice about that before I left).
Roger H is right: if you send a status
request command and process the response
yourself, you'll get what you want. If you
send the status request, the internal
tracking in the X10 service is updated by the
module response, so that should work as well.
Logged

Azeotrope

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 15
Re: Conditions Based on Module Status
« Reply #28 on: May 10, 2005, 03:57:19 PM »

Sorry for the delay in getting back with
everyone who responded, but I had to take
care of some RL issues.

TCassio:  I was hoping I would be able to
keep it simple; however, it looks more and
more like that's not going to be possible.

Paul K: I am encouraged by the fact that
you have the same hardware as I (insofar as
the Rain8II, 1132CU and repeater coupler
are concerned) and that it's working well.

Also, I tried your theory out about whether
the SHMP will stop or proceed depending on
the status of the 2 way modules and I got
inconsistent results.  I started the macro
manually then after it issued the "on"
command to one of the modules, I removed
the connection between the Rain8II and the
PSC05. When I initially tried it, it seemed
to hang.  However, when I tried it later
that day it continued through the macro
regardless.  I am going to retry this
experiment later this week since the
inconsistencies were probably due to a
cockpit error.

Logged

Azeotrope

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 15
Re: Conditions Based on Module Status
« Reply #29 on: May 10, 2005, 03:59:01 PM »

Roger H.:  I can successfully turn on and
off my module from the SDK, but I guess I
haven't figured out how to issue a status
request.  After poring over
the "voluminous" documentation supplied
with the sdk, I still can't figure that
command out. When I issue the queryplc
command, I get nothing returned whether the
module is on or not.  Does it return the
value to the command line?

Joe S.:  That's O.K. I think I'm going to
use your framework as the production macro
until I can get this 2 way stuff figured
out.

x10 Pro: Quite all right.  I had RL get in
the way of my response, too.  As I
mentioned to Roger, I haven't figured out
the format of the status request command,
yet.  Let me make sure I understand this...
first you have to issue a status request to
the module (format??) and then issue a
queryplc command to check the status?

If my zone 1 is P2 and I P2 is on, what
should queryplc "p2 on" return?

Thanks again for everyone’s help.  Getting
this to work as 2 way handshaking is no
longer a "nice to have" feature; it is now
my mission in life to get this working
correctly.

MG
Logged
Pages: 1 [2] 3
 

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