X10 Community Forum

🖥️ActiveHome Pro => ActiveHome Pro General => Topic started by: Azeotrope on May 01, 2005, 08:21:20 PM

Title: Conditions Based on Module Status
Post by: Azeotrope on May 01, 2005, 08:21:20 PM
I purchased both the CM15a/AHP/SmartMacros
to use as a flexible irrigation controller.
I also purchased the Rain8II, an x10 based 2-
way irrigation controller.  I am trying to
figure out how, using the above software, to
fire off the sprinklers one by one checking
the module status before proceeding.
Something like this...

1 Turn on Zone 1
Check Status
If Zone 1 is not "on" go to 1
Delay 20 minutes
2 Turn off Zone 1
Check status
If Zone 1 is not "off" go to 2

...and so on through the remaining zones.

Is this doable using AHP/SM? I also have the
1132CUP, can it be done in SMP?  Or do I
need something heavier duty?

Thanks.
Title: Re: Conditions Based on Module Status
Post by: joe s. on May 01, 2005, 09:48:22 PM
1132CU/Smarthome Manager PLUS, is great at
monitoring module status and responding
correctly - but I've never done what you're
asking.  However I think I know what you need
and wrote a quick *.shl program (zipped) and
attached it so you can download it at:
http://www.accessx10.com/

It is specifically at:
http://forums.accessx10.com/showthread.php?s=&postid=2093#post2093
Title: Re: Conditions Based on Module Status
Post by: Mike C on May 01, 2005, 10:07:03 PM
I would not use the cm15a in its current
state to control anything important. Such
as your sprinklers. You would be better to
program the Rain8 to Automatic mode and use
the 1132cup to trigger the cycle.
Title: Re: Conditions Based on Module Status
Post by: Tony Olson on May 02, 2005, 05:10:00 PM
This person has a valid question
(Mudguppie). I would like to know the X10
Pro solution if there is one! One could use
this for many different types of tasks
(testing module status). Thanks.
Title: Re: Conditions Based on Module Status
Post by: X10 Pro on May 02, 2005, 05:36:05 PM
Mudguppie: ActiveHome Pro doesn't have quite
the level of logic you describe. You can
approach it using some timers, the Monitored
House Code conditions, and a complex set of if/else macros.

You could
use flags to track that commands that have
been sent, instead of tracking using the
monitored house code, but there isn't a way
in AHP to poll status and then respond, which
the Rain811 appeats to be able to handle.

You might be better off using the SDK to
write a script of events to do what you want
to do, since you can send status requests and
respond to them, and do all the logic you
want. That would take a little bit of
programming, however.
Title: Re: Conditions Based on Module Status
Post by: roger1818 on May 02, 2005, 05:42:04 PM
From what I have read this is not possible
with SmartMacros since it isn’t currently
able to perform status requests.  This
could be done with the SDK, but that would
require more advanced programming.  It
would also require the computer be on and
connected to the CM15A.
Title: Re: Conditions Based on Module Status
Post by: Ant on May 04, 2005, 10:10:40 AM
I'm confused as to why people are saying
that SmartMacros cannot perform status
requests.  There is a function to check
Module Status (as set in CM15a - not from
polling).  If the actual status of the
module always matches the CM15a status,
then shouldn't Mudguppies request be
possible?  When the rain sensor in each
zone is activated, does this not send an ON
signal to the CM15a from which his
conditions can function?
Title: Re: Conditions Based on Module Status
Post by: roger1818 on May 04, 2005, 10:55:49 AM
Part 2 of 2

Using a status request in this way does not
guarantee reliability, but it does improve
it.  There are basically four scenarios
after sending the command and status
request:

1. You receive the correct status response
(thus you know the status is correct)
2. You receive an incorrect status response
(thus you know the status is not correct)
3. You do not receive status notification
but the module’s status is correct (either
the status request or the status response
were lost)
4. You do not receive status notification
but the module’s status isn’t correct (both
the command and either the status request
or the status response were lost)

In scenario 1 you are happy.

In scenario 2 you will send the command and
status request again and hope it will work
next time.  There is a good chance it will
since it did receive the status response
correctly.

To the controller scenario 3 & 4 look the
same.  Either way you will send the command
again and hope you will get a response next
time.  If you do that is great, but if you
don’t ever receive the correct status, you
are in trouble.  In either scenario you
will start flooding the powerline with
commands and status requests and in
scenario 4 you will also be flooding your
grass/garden and maybe even your
basement ;).
Title: Re: Conditions Based on Module Status
Post by: roger1818 on May 04, 2005, 10:56:08 AM
Part 1 of 2

Ant:  The problem is the assumption
that “the actual status of the module
always matches the CM15a status” is not a
good one.  There are at least two
situations where the status of the module
does NOT match the status known by the
CM15a.  These are:

1. The status of the module was changed
locally on a module that does not have 2-
way capabilities.
2. The module did not receive (or correctly
process) the command for some reason.

In the first case, there isn’t much you can
do about it since the module is not capable
of telling the controller its status.

It is the second case that Mudguppie is
primarily concerned about.  If the command
he sends to turn off the sprinklers gets
lost for some reason (it happens), he could
end up with flooding.
Title: Re: Conditions Based on Module Status
Post by: paul k on May 04, 2005, 11:38:32 AM
Roger, two things:
1. The good news is that the Rain8-II has a
maximum watering time for each station. So,
you cannot truly flood anything (it defaults
to 20 minutes).
2. The normal model is that for modules
defined to have a status polling ability, the
software should try for some number of times
(say 10 or 20, perhaps using "polite polling"
so as not to lock up the power-line with
messages) and then fail the macro if things
go badly. One can define a macro failure
behavior, such as "ON" to a light and/or
all-off to that house code. Once could use
the on of a light (or beeper module or
whatever) to signal the user that something
has gone wrong. This would also be useful
since the opposite problem is that your lawn
is dead due to not getting water.
Title: Re: Conditions Based on Module Status
Post by: roger1818 on May 04, 2005, 02:03:54 PM
Paul:  I agree this theoretically would be
possible (and optimal).  The problem is
with the AHP software you currently cannot
pole the status of a module within a
macro.  Currently macros only know what
they think the status is (based on the last
command sent/received by the CM15A), not
what the status of the module actually is.
Title: Re: Conditions Based on Module Status
Post by: paul k on May 04, 2005, 02:28:37 PM
Hi Roger. I agree that their software is
wrong as it stands. I was arguing with
regards to your statement: Using a status
request in this way does not guarantee
reliability. If it is done as I suggest, then
you have reliability that either it does what
is wanted, or you are notified (assuming the
notification mechanism is not also
compromised). Since the sprinklers will be
remote and more likely to get powerline
errors, this is a good approach. The fact
that WGL though to have an auto-off is also a
very good thing, as it adds fail-safety.
My point is that X10 Pro should add this.
They can reprogram the MCU code as well as
the data, as far as I can tell. It does not
appear to be locked off. They are just
choosing to rewrite the data only
(reasonable). On the other hand, they have
little space for their app, so it may be they
could not fit polling in.
I have ordered the SmartHome module which
claims to do this (and let you choose how
aggressive in getting the message through
when polling shows not changed). I will see
if how well it works. If it does support this
polling, I will switch to their scheme, even
though the AHP software looks better.
Title: Re: Conditions Based on Module Status
Post by: carmine pacifico on May 04, 2005, 11:09:22 PM
Paul K

On the CM15a only data can be reprogrammed,
the MCU is a one time eeprom based, can not
be reprogrammed.
I would not risk to use X10 or any other
PLC based sprinkler controller; just
because the WGL has auto shutoff, it is
still possible to re-trigger several time a
day the same line due to a macro
malfunction or power line noise; you may
not have a flooding, but a large water bill
is still possible.
Title: Re: Conditions Based on Module Status
Post by: paul k on May 04, 2005, 11:47:41 PM
Yes, you are right. The enCoRe uses OTP EPROM
(so much for it being E-PROM).
As to running the sprinkler, I do not have
any problems, even with the CM15A. It has
always worked when it was supposed to and
never gone off when it was not supposed to. I
have a PalmPad to manually run them, and that
works perfectly as well.
The Rain8-II is connected to a SmartHome
linc. It seems to be very good about not
responding to noise. But, I agree that if
someone has problems with a lot of noise or
neighbors, this could be a problem. I used a
house code which I have verified has not been
used by anyone else in my area (everyone uses
A). You could also use the SmartHome extended
codes (added a huge set of additional
addresses) as that would make it very
unlikely to get noise.
Title: Re: Conditions Based on Module Status
Post by: roger1818 on May 05, 2005, 10:59:20 AM
Does anyone know if there are any modules
that use "Type 4 Extended Secure
Addressing?"  This would address any
concerns about it accidentally turning on
since in this mode an 8-bit security
address must match in addition to the house
and unit codes.
Title: Re: Conditions Based on Module Status
Post by: paul k 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).
Title: Re: Conditions Based on Module Status
Post by: roger1818 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.
Title: Re: Conditions Based on Module Status
Post by: paul k 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).
Title: Re: Conditions Based on Module Status
Post by: Azeotrope 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".
Title: Re: Conditions Based on Module Status
Post by: Azeotrope 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.
Title: Re: Conditions Based on Module Status
Post by: Azeotrope 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
Title: Re: Conditions Based on Module Status
Post by: tcassio 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.
Title: Re: Conditions Based on Module Status
Post by: Azeotrope 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
Title: Re: Conditions Based on Module Status
Post by: tcassio 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.
Title: Re: Conditions Based on Module Status
Post by: paul k 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.
Title: Re: Conditions Based on Module Status
Post by: roger1818 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.
Title: Re: Conditions Based on Module Status
Post by: joe s. 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.
Title: Re: Conditions Based on Module Status
Post by: X10 Pro 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.
Title: Re: Conditions Based on Module Status
Post by: Azeotrope 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.

Title: Re: Conditions Based on Module Status
Post by: Azeotrope 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
Title: Re: Conditions Based on Module Status
Post by: X10 Pro on May 10, 2005, 05:11:47 PM
Using QueryPLC access the X10 services
internal device status tracking, and it
doesn't send a command on the powerline.
You'll have to send a  status request command:

sendplc a1 statusrequest

Note that the standard X10 StatusRequest
command is not the same as the Extended Code
status request that is used by the LM14A,
AM15A, and some other devices -- you'd have
to send the right extended code bytes for that.

If you want to process the incoming command
yourself, you have to be monitoring receive
notifications. As I said before, the modules
response to a status request should update
the X10 Device Services internal status
tracking, so you might be able to use
QueryPLC if that's easier. I believe there
are samples of both in the SDK.
Title: Re: Conditions Based on Module Status
Post by: roger1818 on May 10, 2005, 11:53:47 PM
Mudguppie:  The documentation for the SDK
was not updated when the StatusRequest
command (along with others) was added.
Details about all of the new commands can
be found in the SDK forum in the thread
announcing a new version of the SDK.