Fred,
Thanks for the tip.  Although I would have caught this on the CC statement,
I looked up the CC transactions online.  They charged my CC for the RCA
unit plus $5.90 shipping on Nov 3.  On Nov 5 they refunded the cost of the
RCA unit but not the shipping.  I just sent an email requesting refund
of the shipping.  We'll see what happens.

BTW, the X-10 sales people usually only know the party line, e.g., they
only sell the ActiveHome Pro unit now.  Whether or not an order is filled
depends on whether or not the people in their warehouse can find the stuff.

Regards,
Charles Sullivan

On Wed, 25 Nov 2009 03:59:39 -0000
"Fred" <fwfoss@...> wrote:

> Here is the info folks
> fred
>
> ( Fred ) I am looking for status on my order # 3518659 I have tried the link
twice over the last several hours but have gotten no response as of yet. my CC
has been charged so I assume that it as shipped?????
> ( Fred ) has rather
> ( Meia... ) Hello, Thank you for contacting X10.com. I would be more than
happy to assist you today. May I have your phone number so that I can contact
you in case we get disconnected?
> ( Fred ) 413 575 4944
> ( Meia... ) Yes you should see the refund in your account tomorrow. You
ordered Active Home which we no longer sale. X10.com sales Active Home Pro now
> ( Fred ) actually I ordered the rca controller, if you search your site it
still shows up
> ( Fred ) if you are not longer selling I would think that you would remove the
pages from your site I know several other people have ordered this also
> ( Meia... ) Right we no longer sell the units anymore
> ( Fred ) good grief. please see if you can get the web folks to clean up your
site. there are at least two pages offereing that for sale
> ( Meia... ) Yes I just sent the notice I apologize.
> ( Fred ) unfortunately I can not use the newer unit
> ( Fred ) thank you
> ( Meia... ) you're welcome
>
> --- In heyu_users@yahoogroups.com, "Fred" <fwfoss@...> wrote:
> >
> > Hmmmmm Charles, you better check your cc  they charged me for mine . . .  if
they charged me (via pay pal) I sure hope they send!!!!!!!!!!!!!
> >
> > Nov 23, 2009 Payment To X10 Wireless Technology, Inc Completed  Details
-$25.90 USD
> > Nov 23, 2009  Transfer From Credit Card Completed Details     $25.90 USD
> >
> > --- In heyu_users@yahoogroups.com, "Fred" <fwfoss@> wrote:
> > >
> > > don'tcha just LOVE x10.com???????????
> > >
> > > --- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@> wrote:
> > > >
> > > >
> > > > I found an RCA HC60CRX/CM11A promotion page for $10 + S&H which still
> > > > worked on the X-10 website, so placed an order to see what would happen.
> > > >
> > > > I received an email order confirmation shortly afterwards (on 3 Nov
2009)
> > > > but never got their normal followup shipping notice nor received
anything.
> > > > Given the elapsed time with no activity, I supect the X-10 warehouse
> > > > is really sold out.
> > > >
> > > > Maybe they are waiting for someone to return a defective unit they
> > > > can use to fill my order. :-)
> > > >
> > > > If I get any further information I'll post it here.
> > > >
> > > > Regards,
> > > > Charles Sullivan
> > > >
> > > >
> > > > On Tue, 24 Nov 2009 00:41:10 -0000
> > > > "Fred" <fwfoss@> wrote:
> > > >
> > > > > still there as of 11/23,  order went through, lets see if it ships :-/
> > > > >
> > > > > fred
> > > > >
> > > > > --- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@>
wrote:
> > > > > >
> > > > > >
> > > > > > It was previously reported that the buttons were dead on X-10's
> > > > > > web page for ordering the HC60RX (RCA-branded CM11A) for $10.
> > > > > >
> > > > > > I've come across a different but similar page where the buttons
> > > > > > are live, and clicking results in the HC60RX kit being added to
> > > > > > the shopping cart:
> > > > > >   http://www.x10.com/promotions/hc60rx_vt_kit_v2.html
> > > > > >
> > > > > > I don't know whether or not ordering from this page will result in
> > > > > > actual shipment of one or more HC60RX kits and I don't need any
> > > > > > more myself.  But someone needing a CM11A or two (one for a spare)
> > > > > > might give it a try.
> > > > > >
> > > > > > S&H is $5.90 total for 1 through 9 units, or free for 10 or more.
> > > > > >
> > > > > > (The current best price for the HC60RX (single quantity) from X10
> > > > > > resellers on eBay is about $23, S&H included.)
> > > > > >
> > > > > > Regards,
> > > > > > Charles Sullivan
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------------
> > > > >
> > > > > Yahoo! Groups Links
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > >
> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>


--

Here is the info folks
fred

( Fred ) I am looking for status on my order # 3518659 I have tried the link
twice over the last several hours but have gotten no response as of yet. my CC
has been charged so I assume that it as shipped?????
( Fred ) has rather
( Meia... ) Hello, Thank you for contacting X10.com. I would be more than happy
to assist you today. May I have your phone number so that I can contact you in
case we get disconnected?
( Fred ) 413 575 4944
( Meia... ) Yes you should see the refund in your account tomorrow. You ordered
Active Home which we no longer sale. X10.com sales Active Home Pro now
( Fred ) actually I ordered the rca controller, if you search your site it still
shows up
( Fred ) if you are not longer selling I would think that you would remove the
pages from your site I know several other people have ordered this also
( Meia... ) Right we no longer sell the units anymore
( Fred ) good grief. please see if you can get the web folks to clean up your
site. there are at least two pages offereing that for sale
( Meia... ) Yes I just sent the notice I apologize.
( Fred ) unfortunately I can not use the newer unit
( Fred ) thank you
( Meia... ) you're welcome

--- In heyu_users@yahoogroups.com, "Fred" <fwfoss@...> wrote:
>
> Hmmmmm Charles, you better check your cc  they charged me for mine . . .  if
they charged me (via pay pal) I sure hope they send!!!!!!!!!!!!!
>
> Nov 23, 2009 Payment To X10 Wireless Technology, Inc Completed  Details
-$25.90 USD
> Nov 23, 2009  Transfer From Credit Card Completed Details     $25.90 USD
>
> --- In heyu_users@yahoogroups.com, "Fred" <fwfoss@> wrote:
> >
> > don'tcha just LOVE x10.com???????????
> >
> > --- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@> wrote:
> > >
> > >
> > > I found an RCA HC60CRX/CM11A promotion page for $10 + S&H which still
> > > worked on the X-10 website, so placed an order to see what would happen.
> > >
> > > I received an email order confirmation shortly afterwards (on 3 Nov 2009)
> > > but never got their normal followup shipping notice nor received anything.
> > > Given the elapsed time with no activity, I supect the X-10 warehouse
> > > is really sold out.
> > >
> > > Maybe they are waiting for someone to return a defective unit they
> > > can use to fill my order. :-)
> > >
> > > If I get any further information I'll post it here.
> > >
> > > Regards,
> > > Charles Sullivan
> > >
> > >
> > > On Tue, 24 Nov 2009 00:41:10 -0000
> > > "Fred" <fwfoss@> wrote:
> > >
> > > > still there as of 11/23,  order went through, lets see if it ships :-/
> > > >
> > > > fred
> > > >
> > > > --- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@> wrote:
> > > > >
> > > > >
> > > > > It was previously reported that the buttons were dead on X-10's
> > > > > web page for ordering the HC60RX (RCA-branded CM11A) for $10.
> > > > >
> > > > > I've come across a different but similar page where the buttons
> > > > > are live, and clicking results in the HC60RX kit being added to
> > > > > the shopping cart:
> > > > >   http://www.x10.com/promotions/hc60rx_vt_kit_v2.html
> > > > >
> > > > > I don't know whether or not ordering from this page will result in
> > > > > actual shipment of one or more HC60RX kits and I don't need any
> > > > > more myself.  But someone needing a CM11A or two (one for a spare)
> > > > > might give it a try.
> > > > >
> > > > > S&H is $5.90 total for 1 through 9 units, or free for 10 or more.
> > > > >
> > > > > (The current best price for the HC60RX (single quantity) from X10
> > > > > resellers on eBay is about $23, S&H included.)
> > > > >
> > > > > Regards,
> > > > > Charles Sullivan
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > ------------------------------------
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > >
> >
>

Hmmmmm Charles, you better check your cc  they charged me for mine . . .  if
they charged me (via pay pal) I sure hope they send!!!!!!!!!!!!!

Nov 23, 2009 Payment To X10 Wireless Technology, Inc Completed  Details -$25.90
USD
Nov 23, 2009  Transfer From Credit Card Completed Details     $25.90 USD

--- In heyu_users@yahoogroups.com, "Fred" <fwfoss@...> wrote:
>
> don'tcha just LOVE x10.com???????????
>
> --- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@> wrote:
> >
> >
> > I found an RCA HC60CRX/CM11A promotion page for $10 + S&H which still
> > worked on the X-10 website, so placed an order to see what would happen.
> >
> > I received an email order confirmation shortly afterwards (on 3 Nov 2009)
> > but never got their normal followup shipping notice nor received anything.
> > Given the elapsed time with no activity, I supect the X-10 warehouse
> > is really sold out.
> >
> > Maybe they are waiting for someone to return a defective unit they
> > can use to fill my order. :-)
> >
> > If I get any further information I'll post it here.
> >
> > Regards,
> > Charles Sullivan
> >
> >
> > On Tue, 24 Nov 2009 00:41:10 -0000
> > "Fred" <fwfoss@> wrote:
> >
> > > still there as of 11/23,  order went through, lets see if it ships :-/
> > >
> > > fred
> > >
> > > --- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@> wrote:
> > > >
> > > >
> > > > It was previously reported that the buttons were dead on X-10's
> > > > web page for ordering the HC60RX (RCA-branded CM11A) for $10.
> > > >
> > > > I've come across a different but similar page where the buttons
> > > > are live, and clicking results in the HC60RX kit being added to
> > > > the shopping cart:
> > > >   http://www.x10.com/promotions/hc60rx_vt_kit_v2.html
> > > >
> > > > I don't know whether or not ordering from this page will result in
> > > > actual shipment of one or more HC60RX kits and I don't need any
> > > > more myself.  But someone needing a CM11A or two (one for a spare)
> > > > might give it a try.
> > > >
> > > > S&H is $5.90 total for 1 through 9 units, or free for 10 or more.
> > > >
> > > > (The current best price for the HC60RX (single quantity) from X10
> > > > resellers on eBay is about $23, S&H included.)
> > > >
> > > > Regards,
> > > > Charles Sullivan
> > > >
> > >
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> >
> >
> > --
> >
>

Heck THIS version has been working just fine for a few days at least,

Shortly after I posted this and "ordered" the ones from x10.com (I had forgotten
how much I HATE that site) my system locked up, which it has done a few times
since the upgrade. not sure if I got bad memory ( 8 hours of memory test didn't
flag anything) or problem with a usb port,  (have had a few logs, nothing to do
with CM11 which is in a serial port, no dongle) or what, when I rebooted cmlla
was working just fine . . .

I am working on getting a major upgrade on memory,

heyu seemed to work but would choke when trying to communicate with cmlla. the
cmlla was not totally brain dead cause the logs showed that it wanted to reset
its clock after I did the unplug/remove batteries bit.

fred

--- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@...> wrote:
>
> On Mon, 23 Nov 2009 16:57:12 -0000
> "Fred" <fwfoss@...> wrote:
>
> > I receive the message "upload_eeprom_image() failed to erase initiator
block." when I try to upload data to my unit.  Because I just rebuilt my system
and am still adding and updating software, I would suspect a software problem,
but I can find no logs to suggest that.
> >
> > I have unplugged and removed the battery, I'm not sure how long it is
necessary to leave them out, but 2+ minutes didn't help.
> >
> > I would love to upgrade to an Insteon controller, but since heyu doesn't
support . . .
> >
> > I hope some one has some ideas, I'm fresh out at this point
> >
> > fred
>
> Fred,
> From past messages, I understood Heyu was previously working
> satisfactorally on your old system.
>
> Have you tried reinstalling the same version of Heyu which
> was working before you rebuilt your system?
>
> Do any Heyu commands, like 'heyu info' or 'heyu on Hu', work?
>
> Regards,
> Charles Sullivan
>

don'tcha just LOVE x10.com???????????

--- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@...> wrote:
>
>
> I found an RCA HC60CRX/CM11A promotion page for $10 + S&H which still
> worked on the X-10 website, so placed an order to see what would happen.
>
> I received an email order confirmation shortly afterwards (on 3 Nov 2009)
> but never got their normal followup shipping notice nor received anything.
> Given the elapsed time with no activity, I supect the X-10 warehouse
> is really sold out.
>
> Maybe they are waiting for someone to return a defective unit they
> can use to fill my order. :-)
>
> If I get any further information I'll post it here.
>
> Regards,
> Charles Sullivan
>
>
> On Tue, 24 Nov 2009 00:41:10 -0000
> "Fred" <fwfoss@...> wrote:
>
> > still there as of 11/23,  order went through, lets see if it ships :-/
> >
> > fred
> >
> > --- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@> wrote:
> > >
> > >
> > > It was previously reported that the buttons were dead on X-10's
> > > web page for ordering the HC60RX (RCA-branded CM11A) for $10.
> > >
> > > I've come across a different but similar page where the buttons
> > > are live, and clicking results in the HC60RX kit being added to
> > > the shopping cart:
> > >   http://www.x10.com/promotions/hc60rx_vt_kit_v2.html
> > >
> > > I don't know whether or not ordering from this page will result in
> > > actual shipment of one or more HC60RX kits and I don't need any
> > > more myself.  But someone needing a CM11A or two (one for a spare)
> > > might give it a try.
> > >
> > > S&H is $5.90 total for 1 through 9 units, or free for 10 or more.
> > >
> > > (The current best price for the HC60RX (single quantity) from X10
> > > resellers on eBay is about $23, S&H included.)
> > >
> > > Regards,
> > > Charles Sullivan
> > >
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>
> --
>

On Monday 23 November 2009 06:41:10 pm Fred wrote:
> still there as of 11/23,  order went through, lets see if it ships :-/
>
> fred

I also ordered two -- got the confirmation, but no shipment notice.. Does not
really matter though -- I bought them for spares..  Thanks

Kenny

On Mon, 23 Nov 2009 16:57:12 -0000
"Fred" <fwfoss@...> wrote:

> I receive the message "upload_eeprom_image() failed to erase initiator block."
when I try to upload data to my unit.  Because I just rebuilt my system and am
still adding and updating software, I would suspect a software problem, but I
can find no logs to suggest that.
>
> I have unplugged and removed the battery, I'm not sure how long it is
necessary to leave them out, but 2+ minutes didn't help.
>
> I would love to upgrade to an Insteon controller, but since heyu doesn't
support . . .
>
> I hope some one has some ideas, I'm fresh out at this point
>
> fred

Fred,
From past messages, I understood Heyu was previously working
satisfactorally on your old system.

Have you tried reinstalling the same version of Heyu which
was working before you rebuilt your system?

Do any Heyu commands, like 'heyu info' or 'heyu on Hu', work?

Regards,
Charles Sullivan

I found an RCA HC60CRX/CM11A promotion page for $10 + S&H which still
worked on the X-10 website, so placed an order to see what would happen.

I received an email order confirmation shortly afterwards (on 3 Nov 2009)
but never got their normal followup shipping notice nor received anything.
Given the elapsed time with no activity, I supect the X-10 warehouse
is really sold out.

Maybe they are waiting for someone to return a defective unit they
can use to fill my order. :-)

If I get any further information I'll post it here.

Regards,
Charles Sullivan


On Tue, 24 Nov 2009 00:41:10 -0000
"Fred" <fwfoss@...> wrote:

> still there as of 11/23,  order went through, lets see if it ships :-/
>
> fred
>
> --- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@...> wrote:
> >
> >
> > It was previously reported that the buttons were dead on X-10's
> > web page for ordering the HC60RX (RCA-branded CM11A) for $10.
> >
> > I've come across a different but similar page where the buttons
> > are live, and clicking results in the HC60RX kit being added to
> > the shopping cart:
> >   http://www.x10.com/promotions/hc60rx_vt_kit_v2.html
> >
> > I don't know whether or not ordering from this page will result in
> > actual shipment of one or more HC60RX kits and I don't need any
> > more myself.  But someone needing a CM11A or two (one for a spare)
> > might give it a try.
> >
> > S&H is $5.90 total for 1 through 9 units, or free for 10 or more.
> >
> > (The current best price for the HC60RX (single quantity) from X10
> > resellers on eBay is about $23, S&H included.)
> >
> > Regards,
> > Charles Sullivan
> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>


--

On Tue, 24 Nov 2009 00:28:57 -0000
"Fred" <fwfoss@...> wrote:

> Does this work ok with heyu? Since my unit has apparently died, I need to bite
the bullet and get a new one. in any event I should have a spare!
>

The RCA HR60CRX is just a rebranded CM11A and is perfectly compatible.

Regards,
Charles Sullivan

still there as of 11/23,  order went through, lets see if it ships :-/

fred

--- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@...> wrote:
>
>
> It was previously reported that the buttons were dead on X-10's
> web page for ordering the HC60RX (RCA-branded CM11A) for $10.
>
> I've come across a different but similar page where the buttons
> are live, and clicking results in the HC60RX kit being added to
> the shopping cart:
>   http://www.x10.com/promotions/hc60rx_vt_kit_v2.html
>
> I don't know whether or not ordering from this page will result in
> actual shipment of one or more HC60RX kits and I don't need any
> more myself.  But someone needing a CM11A or two (one for a spare)
> might give it a try.
>
> S&H is $5.90 total for 1 through 9 units, or free for 10 or more.
>
> (The current best price for the HC60RX (single quantity) from X10
> resellers on eBay is about $23, S&H included.)
>
> Regards,
> Charles Sullivan
>

Does this work ok with heyu? Since my unit has apparently died, I need to bite
the bullet and get a new one. in any event I should have a spare!

oops CM11!!!
--- In heyu_users@yahoogroups.com, "Fred" <fwfoss@...> wrote:

I receive the message "upload_eeprom_image() failed to erase initiator block."
when I try to upload data to my unit.  Because I just rebuilt my system and am
still adding and updating software, I would suspect a software problem, but I
can find no logs to suggest that.

I have unplugged and removed the battery, I'm not sure how long it is necessary
to leave them out, but 2+ minutes didn't help.

I would love to upgrade to an Insteon controller, but since heyu doesn't support
. . .

I hope some one has some ideas, I'm fresh out at this point

fred

On Fri, 20 Nov 2009 12:01:22 -0800 (PST)
Ed Dippold <etd607@...> wrote:

Charles Sullivan wrote:
> Note that some X10 testers and modules can be set to send repetitive
> signals, e.g., the (older) Smarthome "SignaLinc" Coupler/Repeater can be
> programmed to repeatedly send P1 On/ P1 Off signals at approximately
> 1 second intervals for testing purposes.

Edwin,
Whoops, I misspoke.  The unit I referred to above is actually the
Smarthome BoosterLinc 4827 which has the test mode, not the SignaLinc
Coupler/Repeater.

>
> Separate lines will usually still be coupled (although weakly) back
> at the power company's transformer, if not at your breaker box.
>
>
>   ==The 2 lines for the greenhouse come out of a satellite breaker
> box which ==only provides 120vac (single phase).  In looking
> at  my setup, there is a ==boosterlinc at the greenhouse and a
> coupler/repeater near the main ==breaker panel in the house.  I
> wonder if a signal loop could have been ==occurring between the
> two.  I had a similar situation with a bad PC power
> ==supply.  The PS was creating noise on the AC line which was
> picked by the ==coupler/repeater near the main breaker panel and was
> being  rebroadcast ==over both AC phases.  Heyu monitor did
> not show the noise but did ==indicate that there were many data
> collisions of the X10 signal at the ==CM11a interface.  It got so
> bad that x10 would not work at all.

I think it was probably your BoosterLinc which was responsible for
sending the P15 signals.  Maybe a glitch when the power was turned
back on.

Regards,
Charles Sullivan

Edwin Dippold

A+, Network+, Server+, Linux+.

--- On Fri, 11/20/09, Charles Sullivan <cwsulliv01@...> wrote:

From: Charles Sullivan <cwsulliv01@...>
Subject: Re: [heyu_users] Just a bunch of stupid question.
To: heyu_users@yahoogroups.com
Date: Friday, November 20, 2009, 1:29 PM







 









       On Fri, 20 Nov 2009 07:12:11 -0800 (PST)

Ed Dippold <etd607@yahoo. com> wrote:



> I have 2 questions and an observation to post:

>

>

>

> 1)  What is the purpose of the xPowerUp signal sent by some x10

> modules?  I have multiple PAM21's and a PAM22 appliance module

> that will transmit the xPowerUp on the power lines when they are

> initially plugged in and after a power failure.  Can scripts be

> launched for an xPowerUp signal and, if so, what could the scripts do?



Edwin,

Yes, a script can be launched with function xpowerup (synonym xpup).

Since the PAM21/22 forget their configuration after an AC power

interruption of somewhere around 10-30 seconds, the script can be

used to restore the configuration.


   == When you say configuration, are you talking about the last
state the relay ==was in or the HU?  The PAM21/22 have code wheels
to avoid the loss of the ==HU.  (Though, I have seen the PAM21/22
ignore the code wheel settings.)



The assumption of course is that your computer is on a UPS, otherwise

the xpowerup signal will be sent before the computer is rebooted and

ready to receive it.  But another option is to ignore the xpowerup

and restore the configurations with a "-powerfail" script, which will

work whenever Heyu gets the powerfail signal from the CM11A.


   == My server is not on a UPS so in a whole house power cycle, the
server ==would never see the xPowerUp signal.  In this case, the
server saw the ==xPowerUp after a power down and up was done by cycling
the circuit ==breaker.

Typical configuration options for the PAM21/22 (and LM14A) are

automatic status reporting (set with 'heyu xconfig ...') or extended

group membership (set with 'heyu xgrpXXX ...' commands).



> 2) This is an observation and I was wondering if anyone else has encountered
this. 

>

> I have 2 15 amp AC lines running into my greenhouse.  Line1 has 2

> PAM21 appliance modules (A5 and A7).  Line2 has a single PAM21

> (A9).  I turned the power off to Line1 to install a junction box

> with 2 power outlets.  I then turned on the power to Line1 and

> checked the outlets to ensure that they were okay with a line

> tester.  I then noticed that the X10 signals were working

> erratically or not at all.  A quick check using heyu monitor

> showed that about every second an X10 signal was being received by the

> CM11a.  An example line would be "11/18 15:44:03  rcvi addr

> unit         15  :: hu

> P15".  I turned off the power to Line1 but the signal

> continued.  I then started upplugging modules and discovered that

> the PAM21 (A9) on Line2 was the culprit.  How exactly could a

> module on a separate power line be affected by similar modules on other

> power lines?  Did the xPowerUp signal sent by A5 and A7 screw up

> A9?



That's a new one on me.  You may need to do some experimentation to

verify that the PAM21 is really doing it.  You can send the xpowerup

signal from the command line ('heyu xpowerup Hu') for testing purposes.



Note that some X10 testers and modules can be set to send repetitive

signals, e.g., the (older) Smarthome "SignaLinc" Coupler/Repeater can be

programmed to repeatedly send P1 On/ P1 Off signals at approximately

1 second intervals for testing purposes.



Separate lines will usually still be coupled (although weakly) back

at the power company's transformer, if not at your breaker box.


   ==The 2 lines for the greenhouse come out of a satellite breaker
box which ==only provides 120vac (single phase).  In looking
at  my setup, there is a ==boosterlinc at the greenhouse and a
coupler/repeater near the main ==breaker panel in the house.  I
wonder if a signal loop could have been ==occurring between the
two.  I had a similar situation with a bad PC power
==supply.  The PS was creating noise on the AC line which was
picked by the ==coupler/repeater near the main breaker panel and was
being  rebroadcast ==over both AC phases.  Heyu monitor did
not show the noise but did ==indicate that there were many data
collisions of the X10 signal at the ==CM11a interface.  It got so
bad that x10 would not work at all.

> 3)  Are there any plans for incorporating more 2-way functionality

> into heyu?  I have keypads that I have programmed to verify if a

> command sent to an x10 module was performed.  If an Off command is

> sent, the keypad wil send a status request and wait a number of seconds

> for a reply.  If none is received the button that was pushed will

> not turn its LED off.  This gives me feedback that the x10 module

> is still on.  Is it possible that heyu could be modified or set up

> to do something similar to this?



The PAM21/22 and LM14A can be set for automatic status reporting - see

man page heyu(1) for 'heyu xconfig ...'.  There is also the status_pending

bit which is set when a 'heyu status ...' or 'heyu xstatus ...' command

is sent and reset when the status_on/off or xstatus_ack is received.

This bit can be tested with the 'heyu statusstate H[u]' command or

in a launched BASH script with (($X10_Hu & $isSpend)).


   ==I will take a look at the 'heyu statusstate Hu' command.  It may be what I
==could use in a BASH script.  Thanks.



Regards,

Charles Sullivan



>

>

> Thanking you in advance.

>

>

> Edwin Dippold

>

> A+, Network+, Server+, Linux+.

>

>

>

>

> [Non-text portions of this message have been removed]

>

>

>

> ------------ --------- --------- ------

>

> Yahoo! Groups Links

>

>

>



--


























[Non-text portions of this message have been removed]

On Fri, 20 Nov 2009 07:12:11 -0800 (PST)
Ed Dippold <etd607@...> wrote:

> I have 2 questions and an observation to post:
>
>
>
> 1)  What is the purpose of the xPowerUp signal sent by some x10
> modules?  I have multiple PAM21's and a PAM22 appliance module
> that will transmit the xPowerUp on the power lines when they are
> initially plugged in and after a power failure.  Can scripts be
> launched for an xPowerUp signal and, if so, what could the scripts do?

Edwin,
Yes, a script can be launched with function xpowerup (synonym xpup).
Since the PAM21/22 forget their configuration after an AC power
interruption of somewhere around 10-30 seconds, the script can be
used to restore the configuration.

The assumption of course is that your computer is on a UPS, otherwise
the xpowerup signal will be sent before the computer is rebooted and
ready to receive it.  But another option is to ignore the xpowerup
and restore the configurations with a "-powerfail" script, which will
work whenever Heyu gets the powerfail signal from the CM11A.

Typical configuration options for the PAM21/22 (and LM14A) are
automatic status reporting (set with 'heyu xconfig ...') or extended
group membership (set with 'heyu xgrpXXX ...' commands).

> 2) This is an observation and I was wondering if anyone else has encountered
this. 
>
> I have 2 15 amp AC lines running into my greenhouse.  Line1 has 2
> PAM21 appliance modules (A5 and A7).  Line2 has a single PAM21
> (A9).  I turned the power off to Line1 to install a junction box
> with 2 power outlets.  I then turned on the power to Line1 and
> checked the outlets to ensure that they were okay with a line
> tester.  I then noticed that the X10 signals were working
> erratically or not at all.  A quick check using heyu monitor
> showed that about every second an X10 signal was being received by the
> CM11a.  An example line would be "11/18 15:44:03  rcvi addr
> unit         15  :: hu
> P15".  I turned off the power to Line1 but the signal
> continued.  I then started upplugging modules and discovered that
> the PAM21 (A9) on Line2 was the culprit.  How exactly could a
> module on a separate power line be affected by similar modules on other
> power lines?  Did the xPowerUp signal sent by A5 and A7 screw up
> A9?

That's a new one on me.  You may need to do some experimentation to
verify that the PAM21 is really doing it.  You can send the xpowerup
signal from the command line ('heyu xpowerup Hu') for testing purposes.

Note that some X10 testers and modules can be set to send repetitive
signals, e.g., the (older) Smarthome "SignaLinc" Coupler/Repeater can be
programmed to repeatedly send P1 On/ P1 Off signals at approximately
1 second intervals for testing purposes.

Separate lines will usually still be coupled (although weakly) back
at the power company's transformer, if not at your breaker box.

> 3)  Are there any plans for incorporating more 2-way functionality
> into heyu?  I have keypads that I have programmed to verify if a
> command sent to an x10 module was performed.  If an Off command is
> sent, the keypad wil send a status request and wait a number of seconds
> for a reply.  If none is received the button that was pushed will
> not turn its LED off.  This gives me feedback that the x10 module
> is still on.  Is it possible that heyu could be modified or set up
> to do something similar to this?

The PAM21/22 and LM14A can be set for automatic status reporting - see
man page heyu(1) for 'heyu xconfig ...'.  There is also the status_pending
bit which is set when a 'heyu status ...' or 'heyu xstatus ...' command
is sent and reset when the status_on/off or xstatus_ack is received.
This bit can be tested with the 'heyu statusstate H[u]' command or
in a launched BASH script with (($X10_Hu & $isSpend)).

Regards,
Charles Sullivan

>
>
> Thanking you in advance.
>
>
> Edwin Dippold
>
> A+, Network+, Server+, Linux+.
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>


--

--- In heyu_users@yahoogroups.com, Ed Dippold <etd607@...> wrote:
>
> I have 2 questions and an observation to post:
>
>
>
> 1)  What is the purpose of the xPowerUp signal sent by some x10
> modules?  I have multiple PAM21's and a PAM22 appliance module
> that will transmit the xPowerUp on the power lines when they are
> initially plugged in and after a power failure.  Can scripts be
> launched for an xPowerUp signal and, if so, what could the scripts do?

I never played with xpowerup (don't have a sigle module that would send it), but
since "man x10scripts" mentions it, it should be possible to get scripts
launched, I guess.

If I was able to get such a signal, I could imagine I would use it for getting
my modules, that could likely had missed some latest commands, into a known
state, for example. Or query modules supporting status request in order to
verify if they were still in a state heyu remembered.

> 2) This is an observation and I was wondering if anyone else has encountered
this. 
>
> I have 2 15 amp AC lines running into my greenhouse.  Line1 has 2
> PAM21 appliance modules (A5 and A7).  Line2 has a single PAM21
> (A9).  I turned the power off to Line1 to install a junction box
> with 2 power outlets.  I then turned on the power to Line1 and
> checked the outlets to ensure that they were okay with a line
> tester.  I then noticed that the X10 signals were working
> erratically or not at all.  A quick check using heyu monitor
> showed that about every second an X10 signal was being received by the
> CM11a.  An example line would be "11/18 15:44:03  rcvi addr
> unit         15  :: hu
> P15".  I turned off the power to Line1 but the signal
> continued.  I then started upplugging modules and discovered that
> the PAM21 (A9) on Line2 was the culprit.  How exactly could a
> module on a separate power line be affected by similar modules on other
> power lines?  Did the xPowerUp signal sent by A5 and A7 screw up
> A9?

Personally, I would start from locating a source of noise, possibly wires not
coupled accurately enough. That happened to me many times.

> 3)  Are there any plans for incorporating more 2-way functionality
> into heyu?  I have keypads that I have programmed to verify if a
> command sent to an x10 module was performed.  If an Off command is
> sent, the keypad wil send a status request and wait a number of seconds
> for a reply.  If none is received the button that was pushed will
> not turn its LED off.  This gives me feedback that the x10 module
> is still on.  Is it possible that heyu could be modified or set up
> to do something similar to this?

Sure it can be set up that way (assuming you mean a virtual LED :)). For
example:

ALIAS module A1 AMS # real module supporting status request/report
SCRIPT module on off changed rcvi :: @settimer 1 10
SCRIPT module status_on status_off rcvi :: @settimer 1 0
SCRIPT -timeout timer1 :: @settimer 1 10;heyu status module

Now, when you press your button and it sends its "module on/off", that fires up
the timer. Next, your keypad sends "module status" and waits for an answer.
After the answer has been recieved from the module (your button light turns
oposite), the timer is canceled. Both LEDs (the keypad one and heyu_engine
module state) are in sync.
If the answer is not recieved within 10 seconds (your button light stays
unchanged), the timer expires and heyu_engine can repeat the status request
until it gets an answer from the module. Or it can force module state back to
whatever it was before with "heyu module on/off" instead of arming a timer and
querying for status again.

Another use case:

ALIAS button A1 REMOTE2 # no real module that answers status request
SCRIPT button status rcvi :: \
   if [ $x10_button$isOn)) -ne 0 ]' \
   then heyu status_on button \
   else heyu status_off button \
   fi

After your keypad queries for the address status, heyu_engine answers based on
its knowledge on current module state, so your button light gets synchronized
with heyu.

Thanks,
Janusz

I have 2 questions and an observation to post:



1)  What is the purpose of the xPowerUp signal sent by some x10
modules?  I have multiple PAM21's and a PAM22 appliance module
that will transmit the xPowerUp on the power lines when they are
initially plugged in and after a power failure.  Can scripts be
launched for an xPowerUp signal and, if so, what could the scripts do?



2) This is an observation and I was wondering if anyone else has encountered
this. 

I have 2 15 amp AC lines running into my greenhouse.  Line1 has 2
PAM21 appliance modules (A5 and A7).  Line2 has a single PAM21
(A9).  I turned the power off to Line1 to install a junction box
with 2 power outlets.  I then turned on the power to Line1 and
checked the outlets to ensure that they were okay with a line
tester.  I then noticed that the X10 signals were working
erratically or not at all.  A quick check using heyu monitor
showed that about every second an X10 signal was being received by the
CM11a.  An example line would be "11/18 15:44:03  rcvi addr
unit         15  :: hu
P15".  I turned off the power to Line1 but the signal
continued.  I then started upplugging modules and discovered that
the PAM21 (A9) on Line2 was the culprit.  How exactly could a
module on a separate power line be affected by similar modules on other
power lines?  Did the xPowerUp signal sent by A5 and A7 screw up
A9?



3)  Are there any plans for incorporating more 2-way functionality
into heyu?  I have keypads that I have programmed to verify if a
command sent to an x10 module was performed.  If an Off command is
sent, the keypad wil send a status request and wait a number of seconds
for a reply.  If none is received the button that was pushed will
not turn its LED off.  This gives me feedback that the x10 module
is still on.  Is it possible that heyu could be modified or set up
to do something similar to this?


Thanking you in advance.


Edwin Dippold

A+, Network+, Server+, Linux+.




[Non-text portions of this message have been removed]

Never mind, I figured it out.

I had it in a directory that was *NOT* in the "default path" but was in MY path 
sbin was the first directory in my path, and presumably the first directory in
the default path. I put a symbolic link there to where it actually resides. it
is now spelled out in DOCUMENTAION so I won't spend 3 or 4 days chasing my tail
NEXT time!!!!!!!!!!!!!!!!

After figuring it out I looked in my back up copy of the old drive and low and
behold there it was.

Occasionally it is "/bin/sh: heyuhelper: command not found"

it is in my path. I can run it from the command line without specifying any
path. For some reason when I have activity that would like to trigger
heyuhelper, this is what I get in the log.

I had a problem with my Mandriva 2008 system and took the opportunity to upgrade
to 2010 a week later this seems to be the only critical hitch. I probably am
missing something stupid, but I will be darned If I can see it!

fred

Hi,

Has anyone ever used mudules of type RI223 made by ACT Solutions
(http://www.act-solutions.com/PCC/pdfs/PCCInst/ri223_instr.pdf)? Or similiar
models like RS210, RS310 or RB310? Or perhaps modules of similiar (ancient?)
design from other manufacturers?

I have bought several of those RI233 thingies on www.smarthomeusa.com for their
isolated contact feature and now have mechanical issues with still more amd more
of them. Did your items happen to break as well?

Thanks,
Janusz

I didn't want to wait for the polls to complete to load the page, which is
why the "refresh" buttons appear next to each parameter.  For each
refresh, it stores the results of the poll in a MySQL database which
caches the results of the poll.

I use the same PHP script from cron to poll the thermostat on a regular
basis, at the moment, once per hour -- the complete cycle takes about 10
seconds.  After updating anything (temperature, on/off, etc.) it polls the
thermostat for that parameter before refreshing.

It functions well, though if I were to put anything else into it, I'd
likely design a thermostat-like display and use AJAX to avoid waiting for
the screen to refresh.

If you (or anybody) is interested, I'm more than willing to provide it in
its current or future state.

> You are correct in thinking the interface is one way.  I only poll the
> actual temperature to help decide if I want to adjust a setting from the
> page.  I have a cron job that polls all the settings and updates a MRTG
> graph for historical purposes.  I used the project as a learning
> experiment, and have not really improved it since it is working.
>
> In my situation I was having collisions on the powerline due to multiple
> devices interacting at regular intervals, so I decided to leave the
> Bidirectional stuff off of my control page. it is not very elegant but I
> mainly created the page to control everything from a cellphone connection
> on edge.  The page took a considerable time to load when I tried to poll
> the 9 bi-directional devices I have, and the page looked incomplete with
> the 1 way devices sharing the same page.  Your idea looks nicer, and
> closer to commercial products like active home.  I could not get active
> home or indigo to work properly, so that is why I ended up with the
> solution I came up with.
>
> I am interested in what you learn from your experience, so I hope you
> continue to post your finds.  ;)
>
> --- In heyu_users@yahoogroups.com, "Michael Stowe" <mstowe@...> wrote:
>>
>>
>> I didn't, but from the looks of things, it's a uni-directional
>> interface,
>> and I wanted something bidirectional.  (I'm inferring from the protocol,
>> which is the non-preset style, and the fact that he only has one
>> temperature at the top, which therefore must be the preset.)
>>
>> I've attached a screen shot of what my whanged-together interface looks
>> like, to illustrate my point; I was kind of vaguely hoping that somebody
>> had put together something prettier.
>>
>> > --- In heyu_users@yahoogroups.com, "Michael Stowe" <mstowe@> wrote:
>> >>
>> >>
>> >> I (finally) got my bidirectional RCS thermostat control installed.
>> It's
>> >> the old TX10-B (the predecessor to the TX15-B) and uses much of the
>> same
>> >> protocol.
>> >>
>> >> Although I whanged together a php interface, I'm interested to know
>> if
>> >> anybody else has, or knows of, a web interface to heyu for
>> controlling a
>> >> thermostat?
>> >>
>> >
>> > Michael,
>> >
>> > I know nothing about RCS thermostats and heyu web interfaces, but have
>> you
>> > had a look at this one:
>> >
>> >
http://tech.groups.yahoo.com/group/heyu_users/message/916?threaded=1&var=1&p=1
>> >
>> > Thanks,
>> > Jaunusz
>> >
>> > PS. Sorry for misspelling your name once lately.
>> >
>> >
>>
>>
>> [Non-text portions of this message have been removed]
>>
>
>

You are correct in thinking the interface is one way.  I only poll the actual
temperature to help decide if I want to adjust a setting from the page.  I have
a cron job that polls all the settings and updates a MRTG graph for historical
purposes.  I used the project as a learning experiment, and have not really
improved it since it is working.

In my situation I was having collisions on the powerline due to multiple devices
interacting at regular intervals, so I decided to leave the Bidirectional stuff
off of my control page. it is not very elegant but I mainly created the page to
control everything from a cellphone connection on edge.  The page took a
considerable time to load when I tried to poll the 9 bi-directional devices I
have, and the page looked incomplete with the 1 way devices sharing the same
page.  Your idea looks nicer, and closer to commercial products like active
home.  I could not get active home or indigo to work properly, so that is why I
ended up with the solution I came up with.

I am interested in what you learn from your experience, so I hope you continue
to post your finds.  ;)

--- In heyu_users@yahoogroups.com, "Michael Stowe" <mstowe@...> wrote:
>
>
> I didn't, but from the looks of things, it's a uni-directional interface,
> and I wanted something bidirectional.  (I'm inferring from the protocol,
> which is the non-preset style, and the fact that he only has one
> temperature at the top, which therefore must be the preset.)
>
> I've attached a screen shot of what my whanged-together interface looks
> like, to illustrate my point; I was kind of vaguely hoping that somebody
> had put together something prettier.
>
> > --- In heyu_users@yahoogroups.com, "Michael Stowe" <mstowe@> wrote:
> >>
> >>
> >> I (finally) got my bidirectional RCS thermostat control installed.  It's
> >> the old TX10-B (the predecessor to the TX15-B) and uses much of the same
> >> protocol.
> >>
> >> Although I whanged together a php interface, I'm interested to know if
> >> anybody else has, or knows of, a web interface to heyu for controlling a
> >> thermostat?
> >>
> >
> > Michael,
> >
> > I know nothing about RCS thermostats and heyu web interfaces, but have you
> > had a look at this one:
> >
> >
http://tech.groups.yahoo.com/group/heyu_users/message/916?threaded=1&var=1&p=1
> >
> > Thanks,
> > Jaunusz
> >
> > PS. Sorry for misspelling your name once lately.
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

On Thu, Nov 12, 2009 at 7:07 AM, kroon040 <kroon040@...> wrote:

> Hi,
>
> Has anybody already a script for graphing with gnuplot an oregon temp
> sensor from the log of heyu, from the last 24 hours for example?
>
> regards
>
> Richard
>
>
>
You might want to look at thermd by Dan Klein.  It collects and plots
temperature sensors for any time period you care to give it.

He also has a very good overview of all the temperature sensors out there.


[Non-text portions of this message have been removed]

Hi,

Has anybody already a script for graphing with gnuplot an oregon temp sensor
from the log of heyu, from the last 24 hours for example?

regards

Richard

On Tue, 10 Nov 2009 22:59:22 -0000
"jkrzysz" <jkrzyszt@...> wrote:

>
>
> --- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@...> wrote:
> >
> > On Wed, 04 Nov 2009 22:12:45 -0000
> > "jkrzysz" <jkrzyszt@...> wrote:
> >
> > >
> > >
> > > --- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@> wrote:
> > > >
> > > > On Wed, 04 Nov 2009 19:30:42 -0000
> > > > "jkrzysz" <jkrzyszt@> wrote:
> > > >
> > > > >
> > > > >
> > > > > --- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@>
wrote:
> > > > > >
> > > > > > On Wed, 04 Nov 2009 16:52:22 -0000
> > > > > > "jkrzysz" <jkrzyszt@> wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --- In heyu_users@yahoogroups.com, Charles Sullivan <cwsulliv01@>
wrote:
> > > > > > > >
> > > > > > > > On Wed, 04 Nov 2009 15:26:02 -0000
> > > > > > > > "jkrzysz" <jkrzyszt@> wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --- In heyu_users@yahoogroups.com, Charles Sullivan
<cwsulliv01@> wrote:
> > > > > > > > > >
> > > > > > > > > > On Wed, 04 Nov 2009 04:03:50 -0000
> > > > > > > > > > "jkrzysz" <jkrzyszt@> wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --- In heyu_users@yahoogroups.com, Charles Sullivan
<cwsulliv01@> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, 04 Nov 2009 00:12:57 -0000
> > > > > > > > > > > > "jkrzysz" <jkrzyszt@> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > --- In heyu_users@yahoogroups.com, Charles Sullivan
<cwsulliv01@> wrote:
> > > > > > > > > > > > > > On Tue, 03 Nov 2009 11:18:26 -0000
> > > > > > > > > > > > > > "jkrzysz" <jkrzyszt@> wrote:
> > > > > > > > > > > > > > > --- In heyu_users@yahoogroups.com, "jkrzysz"
<jkrzyszt@> wrote:
> > > > > > > > > > > > > > > > --- In heyu_users@yahoogroups.com, Charles
Sullivan
> > > > > > > > > > > > > > > > <cwsulliv01@> wrote:
> > > > > > > > > > > > > > > > > On Tue, 03 Nov 2009 01:21:07 -0000
> > > > > > > > > > > > > > > > > "jkrzysz" <jkrzyszt@> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Charles,
> > > > > > > > > > > > > > > > > > As you have remarked, there is no sense in
testing a
> > > > > > > > > > > > > > > > > > variable that has just been set with a
precommand, since
> > > > > > > > > > > > > > > > > > its value is already known and always the
same. But if
> > > > > > > > > > > > > > > > > > precommands were executed after, not befor
the environment
> > > > > > > > > > > > > > > > > > is created, such tests would make sense and
provide us with
> > > > > > > > > > > > > > > > > > additional capability that could be fonud
quite usefull.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > What was the rationale for creating the
environment that contains results of precommands just executed? Could this order
be reverted?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Example use case:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > /etc/heyu/0/x10.conf:
> > > > > > > > > > > > > > > > > > TTY /dev/ttyS0
> > > > > > > > > > > > > > > > > > ...
> > > > > > > > > > > > > > > > > > ALIAS radiator A1 AM
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > /etc/heyu/1/x10.conf:
> > > > > > > > > > > > > > > > > > TTY dummy
> > > > > > > > > > > > > > > > > > TTY_AUX /dev/ttyS1 RFXCOM
> > > > > > > > > > > > > > > > > > ...
> > > > > > > > > > > > > > > > > > ALIAS window A1 DS10A 0x1234
> > > > > > > > > > > > > > > > > > SCRIPT window alert changed rcva swmax ::
@settimer 1 30
> > > > > > > > > > > > > > > > > > SCRIPT -timeout timer1 :: heyu -0 turn
radiator off
> > > > > > > > > > > > > > > > > > SCRIPT window clear changed rcva swmax ::
@settimer 1 0; \
> > > > > > > > > > > > > > > > > >         [ $X10_Timer1 -ne 0 ]||heyu -0 turn
radiator on
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Janusz,
> > > > > > > > > > > > > > > > > The precommands set flags, timers, etc. within
the memory
> > > > > > > > > > > > > > > > > space of
> > > > > > > > > > > > > > > > > heyu_engine so there's no need to spawn
another Heyu
> > > > > > > > > > > > > > > > > process.
> > > > > > > > > > > > > > > > > The environment is created after forking in
preparation
> > > > > > > > > > > > > > > > > for executing
> > > > > > > > > > > > > > > > > the new Heyu process.  If the "precommands"
operated
> > > > > > > > > > > > > > > > > after creation
> > > > > > > > > > > > > > > > > of the environment, they would modify only the
memory
> > > > > > > > > > > > > > > > > space of the
> > > > > > > > > > > > > > > > > new process and heyu_engine wouldn't know
about the
> > > > > > > > > > > > > > > > > changes.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > For the information to get back to
heyu_engine, the @<command>
> > > > > > > > > > > > > > > > > would have to operate the same as 'heyu
<command>', so it
> > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > no longer be any more efficient than 'heyu
<command>'.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Does that make sense?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Sure.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > ... but not quite yet ;-). What about applying
direct commads
> > > > > > > > > > > > > > > after forking?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Sorry, I didn't have "direct" in mind. I was trying to
say: applying
> > > > > > > > > > > > > _internal_ commands after forking, ie. processing them
inside
> > > > > > > > > > > > > heyu_engine, like usually, but only after a shell
script process has
> > > > > > > > > > > > > already been forked.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > I guess it would be possible, but then, skipping
shell scripts
> > > > > > > > > > > > > > > with @decskpz/@decskpnz functionality would be
lost.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So, would it be reasonable to add a new feature -
postcommands?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Let's review how this all works.  The heyu_engine
process runs in
> > > > > > > > > > > > > > a continuous loop.  It reads and processes message
packets from the
> > > > > > > > > > > > > > spoolfile.  In addition, when the system time rolls
over to the next
> > > > > > > > > > > > > > whole second in the loop it decrements the timeout
values in its own
> > > > > > > > > > > > > > memory space and then looks for a -timeout script
for any timer
> > > > > > > > > > > > > > which
> > > > > > > > > > > > > > decrement to 0.  When 'heyu settimer ...' is
executed from the
> > > > > > > > > > > > > > command
> > > > > > > > > > > > > > line or from a launched script, a message is sent to
heyu_engine to
> > > > > > > > > > > > > > load the timeout value into that memory space.  When
'@settimer
> > > > > > > > > > > > > > ...' is
> > > > > > > > > > > > > > executed by heyu_engine, there's no need to send a
message as
> > > > > > > > > > > > > > heyu_engine
> > > > > > > > > > > > > > already knows what to do.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Now suppose a "postcommand", say '@postsettimer
...', is executed in
> > > > > > > > > > > > > > the memory space of a forked heyu process.  The
timeout value would
> > > > > > > > > > > > > > be
> > > > > > > > > > > > > > loaded in the memory space of the forked process. 
But there's no
> > > > > > > > > > > > > > engine
> > > > > > > > > > > > > > loop running in the forked process so the timeout
value would never
> > > > > > > > > > > > > > be decremented.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Similarly for a '@postvdata ...' command, the vdata
value would be
> > > > > > > > > > > > > > loaded in the memory space of the forked process but
there would be
> > > > > > > > > > > > > > no
> > > > > > > > > > > > > > way to do anything with it.  E.g., if the launched
script executes
> > > > > > > > > > > > > > 'heyu chgstate ...' or 'heyu rawlevel ...', a
message is sent to
> > > > > > > > > > > > > > heyu_engine and the previous state or value would be
returned.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > When a direct command is executed in a launched
script, it sends a
> > > > > > > > > > > > > > message to heyu_engine.  The latter updates the
state tables in its
> > > > > > > > > > > > > > own memory space and does whatever else is required,
e.g., launching
> > > > > > > > > > > > > > another script which has source SNDS in its launch
conditions.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Does that make more sense now?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Absolutely yes, but unfortunately that doesn't answer
my concern that
> > > > > > > > > > > > > I just happened to misname. Could you please have a
look at it once
> > > > > > > > > > > > > again?
> > > > > > > > > > > > >
> > > > > > > > > > > > Janusz,
> > > > > > > > > > > > Right now we can do this:
> > > > > > > > > > > >   SCRIPT <L.C.> :: -r @vdata A1 10; <command line tail>
> > > > > > > > > > > > whereupon the environment for <command line tail> is
that as modified
> > > > > > > > > > > > by the @vdata precommand.
> > > > > > > > > > > >
> > > > > > > > > > > > Or we can do this:
> > > > > > > > > > > >   SCRIPT <L.C.> :: -r heyu vdata A1 10; <command line
tail>
> > > > > > > > > > > > where the environment for <command line tail> is not
changed by the
> > > > > > > > > > > > 'heyu vdata' command.
> > > > > > > > > > > >
> > > > > > > > > > > > In both the above cases, <command line tail> will get
the same value of
> > > > > > > > > > > > vdata by running 'heyu rawlevel A1', but the values
obtained from
> > > > > > > > > > > > $(($X10_A1 & $whatLevel)) in the two cases will be
different
> > > > > > > > > > > >
> > > > > > > > > > > > How do you see the effect of your proposed "postcommand"
as being any
> > > > > > > > > > > > different from that using 'heyu vdata'?
> > > > > > > > > > >
> > > > > > > > > > > Charles,
> > > > > > > > > > >
> > > > > > > > > > > Most important difference: avoid or limit concurrency
hazard, or race condition. When a change is done using an internal command, than
next event gets a new value immediately, even if already waiting in the
spoolfile. In contrast, when done with a direct command, the change is appended
to the end of the spoolfile and processed after all already pending events.
> > > > > > > > > > >
> > > > > > > > > > > Less important: internal commands are more efficient, so
less resources used.
> > > > > > > > > > >
> > > > > > > > > > > Otherwise, no differences :).
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Janusz
> > > > > > > > > >
> > > > > > > > > > Janusz,
> > > > > > > > > > But the "postcommand" would have to be be executed in the
forked process
> > > > > > > > > > (following creation of the Heyu environment) and would
therefore require
> > > > > > > > > > sending a message to heyu_engine, the same as 'heyu
<command>'.  So it
> > > > > > > > > > wouldn't have any of the advantages you cite for the
precommand.
> > > > > > > > >
> > > > > > > > > Charles,
> > > > > > > > > I'm not able to understand why you say that postcommands would
have to be executed in the forked process. I though it could be possible to
execute them inside heyu engine _after_ fork(), or strictly speaking after
checking for a positive return value of fork(). Is there anything that would
prevent this from working as expected?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Janusz
> > > > > > > >
> > > > > > > > Janusz,
> > > > > > > > Since the intention is to execute the postcommands after
creation of
> > > > > > > > the Heyu environment and prior to exec() of the command line, we
would
> > > > > > > > need to know that creation of the Heyu environment has been
completed
> > > > > > > > and that the command line has not yet been exec'd.
> > > > > > >
> > > > > > > Now I see what you mean, but that's not exactly what I have in
mind.
> > > > > > >
> > > > > > > Regarding environment creation before postcommands execution
requirement, I think it is not valid. AFAIK, no internal command, be it existing
pre- or proposed postcommand, can make use of any variables, so creating
enviroment before postcommand execution is not relevant for the postcommand
itself. Environment creation can be left where it sits now - in a subprocess,
where internal (post)commands are no longer able to modify it.
> > > > > > >
> > > > > > > Regarding execution order requirement, I still can't see why it
would be necessary to run postcommands prior to exec(). I'd rather try to run
them in parallel.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Janusz
> > > > > >
> > > > > > Janusz,
> > > > > > If they were to run "in parallel" as you put it, how would you know
> > > > > > which task was completed first?  In repeated launchings of the same
> > > > > > script, sometimes the command line process would see the state
changes
> > > > > > made by the postcommand while other times it wouldn't.  That would
be
> > > > > > a major bug.
> > > > >
> > > > > Charles,
> > > > > I didn't mean running a series of postcommands from one script in
parallel with another series of postcommands from another script, same or
different. Saying "in parallel" I meant executing them inside heyu_engine, in
the foreground, after forking a background subprocess supposed to spwan a shell
script, and before checking and possibly waiting for it to exit. After that,
next script could be precessed if already pending. That way, any command line
process would see the state changes made by all previous internal commands and
current precommands, but not necessarily all previous shell commands that may
still run in the background, like before.
> > > > >
> > > > > Am I still missing somethimg?
> > > > >
> > > > > Thanks,
> > > > > Janusz
> > > >
> > > > Janusz,
> > > > Consider the flow:
> > > >
> > > >   In heyu_engine     In forked process
> > > >   --------------     -----------------
> > > >    precommands
> > > >        |
> > > >      fork  ------->   forked process
> > > >        |                    |
> > > >    postcommands       create Heyu environment
> > > >        |                    |
> > > >        |               exec command line
> > >
> > > Charles,
> > > Thanks for this artwork. That's exactly what I have in mind, and can see
no problem with it.
> > >
> > > > We have no way of knowing the order in which the postcommands are
> > > > completed with respect to the creation of the environment and
> > > > the exec of the command line. We could just as likely have:
> > > >    postcommands, creation, exec
> > > >    creation, postcommands, exec
> > > >    creation, exec, postcommands
> > > >
> > > > or even some mishmash like
> > > >    crea-, postcommands, -tion, exec.
> > >
> > > Where do we get the state data from while creating Heyu environment? From
x10state file? Or form a shared memory? I guess not, we just get them from the
forked process' private memory that has been initialized during fork as a
snapshot of heyu_engine memory, hasn't it? Then, postcommands, whenever they run
with respect to creation of the environment, are no longer able to modify that
snapshot. Our command line already got a stable state data, taken in a well
known moment. No need to wait with postcommands execution.
> > >
> > > > What we'd have to do is something like this:
> > > >
> > > >    precommands
> > > >        |
> > > >      fork --------->  forked process
> > > >        |                   |
> > > >       wait            create Heyu environment
> > > >        |                   |
> > > >        | <----------  notify heyu_engine
> > > >    postcommands            |
> > > >        |                 wait
> > > >    notify forked proc -->  |
> > > >        |              exec command line
> > > >        |                   |
> > >
> > > Internal commands modify heyu_engine in-memory state date, than a backup
copy is made to the x10state file, right?
> > >
> > > Our command line, running in parallel, doesn't, or has no reason to,
refere heyu_engine memory nor x10state file. It makes decisions based on
environment already created. Then, there is no need to wait for postcommands to
finish.
> > >
> > > The command line may invoke several heyu direct commands. None of them
need to refere nor may modify heyu_engine memory nor x10state file, they just
store their patterns in the spool file, don't they? Those patterns will be read
and processed by heyu_engine in following loops, as usually. I can see no reason
to wait for postcommands to finish.
> > >
> > > The command line may invoke several heyu state commands if it happens that
environment variables do not provide enough information. But why could they
check for data modified by postcommands running in parallel? I think we can
safely assume those values are well known to the script author (he put them
there), so there is no need to check for them. Again, no reason to wait for
postcommands get finished.
> > >
> > > What else can I be missing?
> > >
> > > Thanks,
> > > Janusz
> >
> > Janusz,
> > You are correct.  It would work so long as you don't assume that the
information from state commands executed by the forked process will match that
obtained from the environment.
>
> Charles,
>
> Before you ever get into implementation, let me tell you about another issue
that could be solved in a similiar way maybe, if at all.
>
> After a command line subprocess has been forked, the actual state of a
> module that caused the launch, and related flags, can be derived or
> obtained from two sources:
>
> 1. From launch conditions themselves and/or from applicable
> variables representing launch conditions just met:
> $X10_Function, $X10_PresetLevel, $X10_Xfunc, $X10_Xdata, $X10_RawVal,
> $X10_DimVal, $X10_BrightVal, $X10_swHome, $X10_swAway, $X10_swMin,
> $X10_swMax, $X10_Vident, $X10_Vdata, $X10_ore*, $X10_elsCurr,
> $X10_owl*, $X10_dmx*, probably more.
>
> 2. From examining $X10_Hu/$x10_<Hu_alias> and/or
> $X10_Hu_*/$x10_<Hu_alias>_* variables, using masks where applicable.
>
> I found that in many cases it would be much more usefull if those
> $X10_Hu*/$x10_<Hu_alias>* variables still represent PREVIOUS state,
> from before the event that launched the script occured, instead of
> duplicating data available elsewhere, and results of applying all pending
changes could be made available to scripts with those event related variables.
>
> To achieve this goal, command line subprocess ought to be forked
> before any state changes related to an event just processed are
> applied in memory. The only exception should probably be precommands,
> since some of them (@decskpz and @decskpnz) can result in command
> line process not being forked at all.
>
> If you ever try to implement postcommands, please consider if that second case
could be addressed as well.
>
> Thanks,
> Janusz

Janusz,
Your suggestion would add a lot of complexity in the Heyu code.  But
more important, I think it would utterly confuse a lot of users.

Regards,
Charles Sullivan

--- In heyu_users@yahoogroups.com, "Michael Stowe" <mstowe@...> wrote:
>
>
> I just realized I can't send attachments, but a link to the image is here:
> http://www.michaelstowe.com/x10/RCS_Thermostat.PNG
>
> I'm leveraging the "rcs_request" series of heyu commands to poll the
> thermostat, and to set it, a tiny bit of php:
>
> if (($tset < 100) && ($tset >= 4))
> {
>    $unit = floor(($tset-4) / 32)+1;
>    $pset = ($tset-4) % 32 +1;
>    exec(heyu.' rcs_req preset a'.$unit.' '.$pset);
> }
>
> I found the protocol document here:
> http://www.goodjobsucking.com/?p=196

Michael,

Thanks for sharing this link. Now I know that RCS thermostats, each one eating
up almost full housecode address space, would not be a good solution for me :-).

Janusz

> > I think that only works with the decode table "B". If I remember
> > correctly, you have to use a different decode table for the
> > bi-directional models. These tables use presets, so a simple on/off
> > interface like the one described in your link wouldn't work.
> >
> > I ended up writing a script to set the temp, mode, etc which translated
> > commands like "set temp 78" and "mode cool" to the proper preset
> > command. While this wouldn't provide web control, it might make it
> > easier to issue commands from a web script. I'll be happy to share, but
> > I must warn you in advance, I'm a bash script newbie and a hack, so
> > you'll probably want to review/refine the code.
> >
> > Tom
>

On Wed, 2009-11-11 at 15:37 -0600, Michael Stowe wrote:
>
>
> I just realized I can't send attachments, but a link to the image is
> here:
> http://www.michaelstowe.com/x10/RCS_Thermostat.PNG
>
> I'm leveraging the "rcs_request" series of heyu commands to poll the
> thermostat, and to set it, a tiny bit of php:
>
> if (($tset < 100) && ($tset >= 4))
> {
> $unit = floor(($tset-4) / 32)+1;
> $pset = ($tset-4) % 32 +1;
> exec(heyu.' rcs_req preset a'.$unit.' '.$pset);
> }
>
> I found the protocol document here:
> http://www.goodjobsucking.com/?p=196
>

Your code already looks nicer than mine. :-)

I just realized I can't send attachments, but a link to the image is here:
http://www.michaelstowe.com/x10/RCS_Thermostat.PNG

I'm leveraging the "rcs_request" series of heyu commands to poll the
thermostat, and to set it, a tiny bit of php:

if (($tset < 100) && ($tset >= 4))
{
    $unit = floor(($tset-4) / 32)+1;
    $pset = ($tset-4) % 32 +1;
    exec(heyu.' rcs_req preset a'.$unit.' '.$pset);
}

I found the protocol document here:
http://www.goodjobsucking.com/?p=196

> I think that only works with the decode table "B". If I remember
> correctly, you have to use a different decode table for the
> bi-directional models. These tables use presets, so a simple on/off
> interface like the one described in your link wouldn't work.
>
> I ended up writing a script to set the temp, mode, etc which translated
> commands like "set temp 78" and "mode cool" to the proper preset
> command. While this wouldn't provide web control, it might make it
> easier to issue commands from a web script. I'll be happy to share, but
> I must warn you in advance, I'm a bash script newbie and a hack, so
> you'll probably want to review/refine the code.
>
> Tom

>
> Michael,
>
> I know nothing about RCS thermostats and heyu web interfaces, but have
> you had a look at this one:
>
> http://tech.groups.yahoo.com/group/heyu_users/message/916?threaded=1&var=1&p=1
>
> Thanks,
> Jaunusz
>

I think that only works with the decode table "B". If I remember
correctly, you have to use a different decode table for the
bi-directional models. These tables use presets, so a simple on/off
interface like the one described in your link wouldn't work.

I ended up writing a script to set the temp, mode, etc which translated
commands like "set temp 78" and "mode cool" to the proper preset
command. While this wouldn't provide web control, it might make it
easier to issue commands from a web script. I'll be happy to share, but
I must warn you in advance, I'm a bash script newbie and a hack, so
you'll probably want to review/refine the code.

Tom