Please login or register.

Login with username, password and session length

Author Topic: Socket Rocket now needs delay  (Read 5024 times)

thejfk

  • Full Member
  • ***
  • Helpful Post Rating: 1
  • Posts: 49
Socket Rocket now needs delay
« on: October 21, 2008, 10:08:35 AM »

I have an outdoor light with a Socket Rocket(A8), an Eagle eye(A13) triggering a simple macro, ON-20second delay-OFF with one-dusk to dawn condition.
It has been working fine for about a week. Last night at 8:00 it was working, by 9:00 it would not respond to the macro.
The activity monitor shows the RF trigger (A13) and the macro(7), but no light. I triggered(A13) the macro from a palm pad,it worked fine.
I checked for something different(TV on,etc.) nothing different.
I cleared the interface,deleted and reinstalled the macro,added an antenna to the eagle eye...still no light.
I added a 1 second delay before the  light (A8) on. and it works perfectly...???
There are no other macros using the A13 trigger
Any ideas?

Also, I will be replacing the socket rocket with a WS12 and, after reading several posts here, I'm gonna get a WGL V572
I have lots of X10 plans and ideas, and it sounds like the WGL will prevent a LOT of headaches as my system grows. Do you agree?
Thanks
Logged

Alan V

  • Hero Member
  • *****
  • Helpful Post Rating: 8
  • Posts: 171
Re: Socket Rocket now needs delay
« Reply #1 on: October 21, 2008, 12:00:40 PM »

There are several disussions in this forum about adding delays to fix macros.  Here's one link http://www.x10community.com/forums/index.php?topic=8507.0

I use the WGL V572RF32 and it works great.  I've  tried several antenna mods for the CM15A, but none of them worked well for me.  The WGL products have great range.  If you get one, I think you'll be happy (but keep in mind that YMMV).

Logged

Boiler

  • Guest
Re: Socket Rocket now needs delay
« Reply #2 on: October 21, 2008, 01:05:34 PM »

thejfk,

As indicated by the thread that AlanV provided, delays can be very helpful when using Bright/Dim commands.  These are actually a series of concatenated commands that can last for several seconds (3.67 seconds for a Bright 100% command).  This is both hard on repeaters (if you have one) and receivers.  A delay helps allow the devices recover from this onslaught and prepare for the next valid command.

Unfortunately, that's not the problem you are encountering since you're using a Socketrocket (simple on/off commands).

In this instance, I'd submit that the failure of your macro was due to an "improvement in atmospheric conditions".  Basically I believe your motion sensor began communicating "better" with the CM15a and you started to receive multiple RF on requests. 

I've experienced problems with this when using an RF repeater in remote areas of the house.  I would at times see as many as 5 RF on requests for a MS12a and macro's would execute, but not transmit PLC signals.  Adding flags to prevent re-triggering did not help.  The one second delay solved the problem.

What I attribute this to (purely conjecture on my part) is a documented problem with the PIC itself.  It seems that the processor has a problem with generating interrupts from the GPIO port.  As a result, the CM15a must "Poll" the port for information.  From what I have seen, the CM15a is unable to reliable transmit PLC data while trying to field RF commands (the RF may take precedence).  The 1 second delay may allow time for the RF to expire thereby allowing the CM15a to reliably transmit over the power line. 

Far from a "scientific explanation", this is pure conjecture.  Nonetheless, all of my RF triggered macros have at least a 1 second delay at the start (regardless of whether I use flags).

The following macro gave me fits after I had to add an RF repeater on the 2nd floor of my home.  After adding the repeater, I would register multiple RF on commands and the A10 on command would not be transmitted.  Prior to addition of the repeater, operation was 99%.  The addition of the 1 second delay fixed this macro (even though the macro was flag qualified). 


« Last Edit: October 25, 2009, 05:22:06 PM by Boiler »
Logged

thejfk

  • Full Member
  • ***
  • Helpful Post Rating: 1
  • Posts: 49
Re: Socket Rocket now needs delay
« Reply #3 on: October 21, 2008, 01:56:51 PM »

Thanks for the replies
So,it sounds like the WGL unit will help with range/reception issues, but the CM15A may still have processing issues?
Logged

Boiler

  • Guest
Re: Socket Rocket now needs delay
« Reply #4 on: October 21, 2008, 02:27:12 PM »

In this instance, you need to pick a RF receiver and then go with it.

In my opinion (questionable), the CM15a can have problems fielding RF transmissions and executing PLC communications at the same time.  As I indicated, this is based on observation only (opinions vary).  The 1 second delay at the start of the macro "helps" get around this issue (the macro I showed previously has been functioning reliably for 3 years now).

If you are planning on a V572 (excellent receiver) I would suggest disabling the receiver on the CM15a (I believe Puck can help you here).  This will prevent the CM15a from receiving both RF and PLC triggers.

The one problem that I know of with the V572 is using a motion sensor in a "high activity" area.  In this instance the continual RF triggers (converted to PLC) can overwhelm your system and not allow scheduled events to get though.

I've gone a different route.  I have three motion sensors in both my kitchen and dinette area (very high activity).  Using 1 CM15a, the senors would quickly overload the unit and no PLC commands would be transmitted.  My solution was to dedicate one CM15a that I use as a RF receiver/filter (antenna modified for reception).  It signals a second CM15a (via filtered RF) to execute PLC commands.  The second CM15a has had the RF reception "degraded" (I'm probably the only person who has degraded the RF reception of a CM15a).

I would not propose the 2-cm15a solution for most people.  It's definitely a "hobiest" solution to the problem and requires tuning.

Unless you are using motion sensors in a high activity area, the V572 is most likely the way to go.

Boiler




Logged

PajamaGuy

  • Hero Member
  • *****
  • Helpful Post Rating: 32
  • Posts: 522
Re: Socket Rocket now needs delay
« Reply #5 on: October 21, 2008, 03:15:01 PM »

Boiler is very correct.  I intentionally do NOT transceive my MS14A's with my V572 because of the traffic.  Those little things throw an "ON" every 10 seconds or so.  At least the MS10A's wait about 45 seconds (sometimes).

Logged
PajamaGuy
Win-7 - Dell XPS -Automation
VA12a on a dedicated desktop - Video
XTB-IIR & V572RF32

Remote via LogMeIn (FREE) and Ignition

thejfk

  • Full Member
  • ***
  • Helpful Post Rating: 1
  • Posts: 49
Re: Socket Rocket now needs delay
« Reply #6 on: October 23, 2008, 11:05:53 AM »

OK,so is this correct?
If  I use a V572:   
V572 for RF reception into a computer running AHP, X10 signals out through a CM15A
The CMA should be set to transceive "None".

If I do have "high activity" motion sensors (within range) of the CM15A, could I set the V572 to NOT transceive on one House code(A), and set the CM15 TO transceive just on the H/C (A) with the high traffic?...and would this help with the "high activity issue?

Also you mention different V572s... V572...V572 RF...Which is the better choice, if I'm planning on expanding my system to include security sensors?
Thanks
Logged

Boiler

  • Guest
Re: Socket Rocket now needs delay
« Reply #7 on: October 23, 2008, 04:14:17 PM »

OK,so is this correct?
If  I use a V572:   
V572 for RF reception into a computer running AHP, X10 signals out through a CM15A
The CMA should be set to transceive "None".

This I would concur with. 

If I do have "high activity" motion sensors (within range) of the CM15A, could I set the V572 to NOT transceive on one House code(A), and set the CM15 TO transceive just on the H/C (A) with the high traffic?...and would this help with the "high activity issue?
I would not transceive the RF.  Use a macro to "filter" the RF inputs (with delays and flags to prevent re-starting the macro) to prevent excessive powerline activity.

Also you mention different V572s... V572...V572 RF...Which is the better choice, if I'm planning on expanding my system to include security sensors?

I'll defer to those with first hand WGL experience.
Logged

PajamaGuy

  • Hero Member
  • *****
  • Helpful Post Rating: 32
  • Posts: 522
Re: Socket Rocket now needs delay
« Reply #8 on: October 23, 2008, 04:29:25 PM »

The V572RF32 is te model number for the version of V572's that also transceive the 32 bit security device rf signals.

From WGLDesigns.com:
28000
V572RF32

 New 32 bit version of V572. Up to 32 security devices like the DS10A may be mapped to any desired conventional X10 address and transmitted over the power line.

Includes 12 ft coax cable, PSC05 power line interface, external quarter wave whip antenna, mounting bracket and RS232 computer cable
Logged
PajamaGuy
Win-7 - Dell XPS -Automation
VA12a on a dedicated desktop - Video
XTB-IIR & V572RF32

Remote via LogMeIn (FREE) and Ignition

BaBaLou.

  • Hero Member
  • *****
  • Helpful Post Rating: 16
  • Posts: 244
Re: Socket Rocket now needs delay
« Reply #9 on: October 23, 2008, 05:20:47 PM »

Hi thejfk,
The best bang for your buck, you wont regret the investment of the V572RF32. It does an outstanding job on the rang for all your remotes and sensors. Forget any MOD to the CM15A. The RF32 for the security devices are a wonderful addition, not only can you use it to setup your security system, it just can be easily set up to simply set up the  DS10As and using them just to trigger lights and such. Any motions sensors you have can be easily set to any HC/UC you want and use an Appliance module in its place. With the addition of the XTB-IIR, it has left me with little headaches and an awesome running system.
BaBaLou.
Logged
 

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