Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Puck]

Sorry for going OT, but I thought about these V572RF32 transceivers and want to know more in case my understanding is incorrect:

...the V572 can convert a particular DS10A signal to it's own powerline house/unit code which you could then use to trigger a macro as well.

...if you convert all your AHP security macros to execute off of regular X10 addresses, the chances of false alarms will increase....

Only if you transceive the X10 housecode to the one you assigned to the DS10As.

Sorry, but I'm confused with the suggestion (top) and then you saying to not transceiveing that house code (bottom). 

Can the suggestion be done without transceiving? I don't have a V572RF32 so I'm trying to understand how it works. I thought it just transceive the selected RF house codes to PLC, and converts your selected security RF signals like the DS10A to a user selected HC/UC and ends it out as a PLC signal. (?)

... Otherwise the signal would have to come thru the powerline.

If the DS10A is not set to transceive, how would it get to the powerline?

Would it not have to be converted to an standard X10 PLC signal via the V572RF32 in order for the DS10A to trigger a PLC macro as suggested? And if the macro was triggerable by a standard PLC X10 signal, then it would be easy to get a false trigger if a neighbour uses X10. A light coming on or going off falsely would not be that big of an issue, but an alarm firing off unexpectedly would have a very low WAF.

[KDR]

Puck, the V572RF32 has to be programed for what house codes it will respond to. Also you can program the house and unit codes up to 32 for security devices. It puts the HC/UC on the power line via a PSC05 that is included with the V572RF32. If you use AHP with OnAlert your door/window sensors, RF Security Remotes are assigned a House/Unit code and you would set the V572RF32 to match those. The V572RF32 allows better reception of the RF then the CM15A does. Just think of the V572RF32 as a more sensitive CM15A RF receiver.

I don't own one yet but will get one as soon as funds permit. I would guess it would setup just like the standard V572AB which I do have one of those. In AHP all of the House codes are turned off in Transceived House codes since the V572AB receives the RF and then puts it on the power line for the CM15A to receive the PLC. The only House codes that I have set to transceive are my security sensors since the old V572AB won't process the RF from them. Once I get the new V572RF32 I will set AHP to transceive no house codes (RF) and let the V572RF32 do all the work.

^{----------------KDR}

[Puck]

Puck, the V572RF32 has to be programed for what house codes it will respond to. Also you can program the house and unit codes up to 32 for security devices. It puts the HC/UC on the power line via a PSC05 that is included with the V572RF32.

Yes, that is what I though from reading the details on the WGL website. My confusion came when spam4us stated in his first post to use this device and transceive the DS10A to a PLC signal; then he stated that my concern was not an issue if you don't transceive the DS10A's house code. My confusion is how do you get the DS10A to a PLC signal for triggering a standard X10 Address macro if you don't transceive it with the V572RF32? Maybe it's a misunderstanding of what was said, but that's how I am reading it and was wondering if there was something about the V572RF32 that I did not pick up on.

If you use AHP with OnAlert your door/window sensors, RF Security Remotes are assigned a House/Unit code and you would set the V572RF32 to match those.

Highly recommended, but technically not required. It just makes sure you don't waste a second X10 address for each security device.

Here's why I say that (using a DS10A as an example):

- You have a DS10A on a Door and internal to AHP it is set to A1.
- You have a security macro to turn on a Lamp Module (B1) if the Door opens.
- Lets say you also have House Code A set to transceive.
- For the purpose of this example, you have a Lamp Module set to A1 as well.

When the door opens, the Lamp B1 comes on but not Lamp A1; the Activity Monitor just shows "Door - Sensor Triggered". It does not indicate A1 ON as being sent as a PLC signal, and because Lamp A1 did not come on, it did not transceive "A1 ON" when "Door- Sensor Triggered" was received.

If you use a mini-controller and send an A1 ON PLC signal directly, Lamp A1 will turn ON but the Door open macro will not trigger and thus Lamp B1 will not turn on. The only way to get that security macro to trigger is by the DS10A's RF security code; even if it does share X10 Address A1 internally.

The V572RF32 allows better reception of the RF then the CM15A does. Just think of the V572RF32 as a more sensitive CM15A RF receiver.

This is why I thought about it before, but was concerned about converting all security macros to trigger from a standard X10 PLC signal instead of an RF security signal. To me, it tends to take the Security out of Security Sensor

In AHP all of the House codes are turned off in Transceived House codes since the V572AB receives the RF and then puts it on the power line for the CM15A to receive the PLC.

Once I get the new V572RF32 I will set AHP to transceive no house codes (RF) and let the V572RF32 do all the work.

Just remember that (currently) even an un-transceived House Code's RF signal can still trigger a macro; so signal collisions can still occur but within the CM15A's processor.

On one of my 2 CM15A's I installed a flip switch for de-activating the RF Receiver for experiment purposes.

[KDR]

Dave_X10_L sorry that Puck and I hijacked your post with this.    Please feel free to do the same on the next topic either one of us start  

This is why I thought about it before, but was concerned about converting all security macros to trigger from a standard X10 PLC signal instead of an RF security signal. To me, it tends to take the Security out of Security Sensor

I believe that all security RF signals received by the CM15A are sent to AHP where the software converts it into a standard X10 HC/UC address. And then those addresses are used to trigger what ever security macro you create. This is one of the reasons using security macros have to run from the PC and not the interface. The CM15A can't do anything with the RF other then pass it on to AHP. AHP doesn't know what to do with it unless you have OnAlert. OnAlert gives it a House Unit code and now AHP can work with it. The only thing that can use the security RF is a security consol and I'm not so sure that the security consol doesn't convert the RF input into a usable House code. Thus creating the limit of 16 Units (security devices).

Just remember that (currently) even an un-transceived House Code's RF signal can still trigger a macro; so signal collisions can still occur but within the CM15A's processor.

Pure RF doesn't actually do the triggering for any macro does it? The RF is converted into a usable H/U code first. I do see how you could get signal collisions in the CM15A processor.

On one of my 2 CM15A's I installed a flip switch for de-activating the RF Receiver for experiment purposes.

Wouldn't it have been easier to just put a piece of paper in front of the antenna  

What you are saying is that with all house codes marked as None for transceived that a RF signal will still be converted into a HC/UC and then will trigger a macro? As a test I unplugged my V572AB and used my palmpad to turn on a hall light (A5) "A" being one of my un-transceived house codes and a macro set to A5. Neither one would respond until I plugged the V572AB back in or set "A" to be transceived.

Could it be we have CM15A's that are not the same or I am not testing something the same way you are?

^{----------------KDR}

[Boiler]

I believe that all security RF signals received by the CM15A are sent to AHP where the software converts it into a standard X10 HC/UC address. And then those addresses are used to trigger what ever security macro you create. This is one of the reasons using security macros have to run from the PC and not the interface. The CM15A can't do anything with the RF other then pass it on to AHP. AHP doesn't know what to do with it unless you have OnAlert. OnAlert gives it a House Unit code and now AHP can work with it. The only thing that can use the security RF is a security consol and I'm not so sure that the security consol doesn't convert the RF input into a usable House code. Thus creating the limit of 16 Units (security devices).

Just remember that (currently) even an un-transceived House Code's RF signal can still trigger a macro; so signal collisions can still occur but within the CM15A's processor.

Pure RF doesn't actually do the triggering for any macro does it? The RF is converted into a usable H/U code first. I do see how you could get signal collisions in the CM15A processor.

Boiler

KDR,
Sorry for jumping back in (and showing my ignorance), but if I could restate your description above -

• A RF security transmission can't trigger a CM15a macro that resides in the interface (the CM15a doesn't understand that protocol).
• Upon receipt of a RF security transmission, the CM15a will transfer to the PC which will interpret it with a PC resident Security Macro (OnAlert)
• The PC, after interpreting the security transmission, passes X10 commands to the CM15a to execute events

While I have the OnAlert package, I have not installed or tested it (please be gentle).


For the second half of your post...

...What you are saying is that with all house codes marked as None for transceived that a RF signal will still be converted into a HC/UC and then will trigger a macro? As a test I unplugged my V572AB and used my palmpad to turn on a hall light (A5) "A" being one of my un-transceived house codes and a macro set to A5. Neither one would respond until I plugged the V572AB back in or set "A" to be transceived.

Could it be we have CM15A's that are not the same or I am not testing something the same way you are?

It's very possible that your CM15a responds differently depending on the firmware.  On my '04 unit, if I disable the housecode everything is turned off (no transceived powerline commands, no RF, no macros, NADA).  My '06 and '07 units continue to receive RF (and execute macros), regaredless of what setting I use.

From our handy-dandy Firmware Revisions and Module History : LINK
it looks like you're using one of two '06 CM15a interfaces.  If these in fact do not execute macros with the housecode set "not" to transceive, we have an oddity on our hands.

[KDR]

Boiler, my CM15A's are 06A and 06C and i see your newer one is 06L. The change must have taken place sometime between A and L. I have not tested the one with date code C.

So both what I am saying and what Puck is saying is correct for the CM15A's we have. Puck what date code do you have on your CM15A?

^{----------------KDR}

[spam4us]

Alright. let me splain.....

I have no housecodes transceived on my CM15A.....none, nada, zip.  I have a DS7000 set to housecode F.  I have my V572RF32 set NOT to transceive Housecode F so collisions don't happen but it is set to receive other housecode like the ones I have my active eyes on.  I do have DS10As that are NOT assigned to the DS7000.  They are assigned to my V572RF32.

On the V572RF32 you can "Capture" a security device (DS10A/MS10A) and then set it to send a powerline command.  So let's say we take the storm door talked about earlier.  Install a DS10A on the door then "Capture" it on the V572RF32 and assign house/unit code to L1 using the V572RF32 software.  When the storm door gets opened, DS10A will send it's signal to the V572RF32 which will thensend a powerline signal of L1.  NOTE:  Housecode L is not transceived on the V572RF32.  This means if the V572RF32 receives a stray RF L1 On or RF L1 OFF or RF L anything, the V572RF32 will not transmit that onto the powerline. Also since no housecodes are transceived on the CM15A, they are ignored there as well.  So the only way your macro can be triggered is by the storm door DS10A being opened OR if someone physically plugs a hardwire X10 controller into your house wiring somewhere that is set to housecode L and presses "1 on".

AHP will receive a powerline L1 On and then your macro will be triggered.

You can download the V572RF32 software free of charge and install it on your PC without having to buy the hardware.  That way you can see what I'm talking about more clearly.

Hope this helps.

[Puck]

Short of manually disconnecting the CM15a antenna, how does one avoid intermittent conflicts?

Boiler: We all know how bad the reception of the CM15A is; that is until you do not want it to receive any signals. 

Another member, Marineau, tried a few methods here: Disable RF signal receiving on CM15A

The only way to 100% prevent the CM15A from receiving RF is to kill the front-end of the receiver.

I believe that all security RF signals received by the CM15A are sent to AHP where the software converts it into a standard X10 HC/UC address. And then those addresses are used to trigger what ever security macro you create. This is one of the reasons using security macros have to run from the PC and not the interface. The CM15A can't do anything with the RF other then pass it on to AHP. AHP doesn't know what to do with it unless you have On Alert.

I totally agree with you here.

Pure RF doesn't actually do the triggering for any macro does it? The RF is converted into a usable H/U code first.

The CM15A extracts the HC, UC and command data from the RF to make it usable.

What you are saying is that with all house codes marked as None for transceived that a RF signal will still be converted into a HC/UC and then will trigger a macro? As a test I unplugged my V572AB and used my palmpad to turn on a hall light (A5) "A" being one of my un-transceived house codes and a macro set to A5. Neither one would respond until I plugged the V572AB back in or set "A" to be transceived.

Stopping a HC from being transceived only stops RF signals from being sent out as a PLC signal; it does not stop the CM15A from receiving the RF signal nor does it stop AHP from acting on an RF signal. Disclaimer: at least on my 2 CM15As that are date-coded 06A02 & 06F26.

As I stated in other posts, all my RF remotes are each dedicated to their own UN-Transcieved HC. Those HC's in AHP just have macros to respond to each of the remotes buttons. This has been working for me since day one.

A macro stored in the CM15A will respond to an UN-Transceiver RF signal. A macro stored on the PC will not reliably respond to an RF signal if it is not transceived. I say "not reliably" because I seen it work sometimes and not others, and was unable to pinpoint the reason.

A couple of things about your test:

Is the macro stored in the interface?

I don't know how the CM15A and/or AHP responds to a module that has a macro that turns on that module. Theoretically it should start an endless loop.

Make a macro on another UN-Transceiver house code to turn on your A5 Lamp. Do not associate any modules to the macro, just a single stand-alone macro. Now try an RF remote set to that HC/UC and see if your A5 Lamp comes on.

I do have DS10As that are NOT assigned to the DS7000.  They are assigned to my V572RF32.

And that is understandable and fine. My concern is with someone who is not using a DS7000 and only AHP with OnAlert. If they choose to use the V572RF32 as a better receiver and convert all their security devices to a PLC signal, then they have a much less secure set-up.

NOTE:  Housecode L is not transceived on the V572RF32.  This means if the V572RF32 receives a stray RF L1 On or RF L1 OFF or RF L anything, the V572RF32 will not transmit that onto the powerline. Also since no housecodes are transceived on the CM15A, they are ignored there as well.

So the only way your macro can be triggered is by the storm door DS10A being opened OR if someone physically plugs a hardwire X10 controller into your house wiring somewhere that is set to housecode L and presses "1 on".

But the CM15A may still trigger a macro in AHP. So an unexpected RF signal can still cause unwanted results that a true DS10A OnAlert security macro wouldn't, because it does not respond to PLC signals or standard RF X10 address signals.

So to sum up what I am saying:

1) Using a V572RF32 to convert any security devices RF signal to a standard X10 PLC signal can open the door for possible unwanted results and definitely takes away the security of the original signal.

2) "Do Not Transceive" does not mean "Do Not Receive". This is a bigger concern if someone uses the V572RF32 for better reception of all their security devices and uses just standard X10 addressable macros instead of the secure OnAlert macros.

3) To use the V572RF32 for non-security uses of devices such as a DS10A (like spam4us said he does) is OK because it's no different than any other X10 RF device (like an ActiveEye motion sensor).

[-Bill- (of wgjohns.com)]

I just spent the last 45 minutes repling to KDR and Boiler... when I hit Post it told me the Thread was off limits and it would not let me go back to the edit screen of my post. I'm not too happy about that right now and don't really feel like re-doing that post again tonight.

I will replace this post with the one that will require another 45 minutes of work... tomorrow.

Sorry Puck,

I was asked by KDR & Dave_X10_L to move the posts from Dave_X10_L's thread to this one.  Guess it messed you up!

Sorry again!   

[KDR]

spam4us the way you splain it is how I see it working. The twist here is that at some point between CM15A date code 06A and 06L X10 changed it and now the RF is seen by the CM15A even when the transceived is turned off.

^{----------------KDR}

[Puck]

Sorry Puck,

I was asked by KDR & Dave_X10_L to move the posts from Dave_X10_L's thread to this one.  Guess it messed you up!

Sorry again!   

That's OK Bill. I'm just very surprised it would not allow me to go back to my edit screen where I could have copied my replies.

Thanks for moving all the posts from Dave's thread.

[-Bill- (of wgjohns.com)]

Sorry Puck,

I was asked by KDR & Dave_X10_L to move the posts from Dave_X10_L's thread to this one.  Guess it messed you up!

Sorry again!   

That's OK Bill. I'm just very surprised it would not allow me to go back to my edit screen where I could have copied my replies.

Thanks for moving all the posts from Dave's thread.

I had a similar problem when I tried to review the thread... I think the merge somehow changed the "thread Id".

[spam4us]

KDR I believe the RF is seen by the CM15A too. Although it does not show on my Activity Monitor when viewing on the PC, if I do a "Save As" from the Activity Monitor screen & then open the saved file, the file shows that the CM15A receives all of my DS10As which I do not have installed in AHP as
41 10/17/2007 3:30:29 pm Receive RF Security Module - Sensor Closed
42 10/17/2007 3:30:30 pm Receive RF Security Module - Sensor Closed
43 10/17/2007 3:30:30 pm Receive RF Security Module - Sensor Closed
44 10/17/2007 3:30:30 pm Receive RF Security Module - Sensor Closed
285 10/17/2007 5:17:26 pm Macro N11 (Chime Basement SC546A)
286 10/17/2007 5:17:26 pm Macro N On (Chime Basement SC546A)
287 10/17/2007 5:17:26 pm Macro D16 (Flood Disposition D16)
288 10/17/2007 5:17:26 pm Macro D On (Flood Disposition D16)
289 10/17/2007 5:18:23 pm Receive RF Security Module - Sensor Closed
290 10/17/2007 5:18:23 pm Receive RF Security Module - Sensor Closed
291 10/17/2007 5:18:23 pm Receive RF Security Module - Sensor Closed
292 10/17/2007 5:18:23 pm Receive RF Security Module - Sensor Closed
293 10/17/2007 5:18:24 pm Receive RF Security Module - Sensor Closed
294 10/17/2007 5:22:48 pm Receive E5 (ActEye Front Porch MS16A)
295 10/17/2007 5:22:48 pm Receive E On (ActEye Front Porch MS16A)
296 10/17/2007 5:22:49 pm Macro P3 (Dummy Module 1 AM486)
297 10/17/2007 5:22:49 pm Macro P Off (Dummy Module 1 AM486)
298 10/17/2007 5:22:51 pm Macro D7 (Front Porch Chime D7)

So the RF IS being received by the CM15A but in my case, it is not acted upon because I don't have them ALL installed in AHP.  Therefore, getting back to the "Storm Door", if you define a DS10A to the V572RF32 and then assign a house/unit code in the V572RF32 software, the V572RF32 will transmit that house/unit code over the powerline, the CM15A will receive it as a powerline command and you can trigger a macro from it. The CM15A will also receive the DS10A RF and as long as it's not defined to AHP nothing happens with it.

Now, the questions is......If you have a DS10A defined to AHP and you have it set to a house/unit code, will it trigger a macro based on the house/unit code associated behind the scenes with the DS10A?

[Puck]

Now, the questions is......If you have a DS10A defined to AHP and you have it set to a house/unit code, will it trigger a macro based on the house/unit code associated behind the scenes with the DS10A?

No. See my post above.

[KDR]

Puck, thanks for the detailed reply. I will give the test you suggested a try tonight when I get home. I'm anxious to see how it goes since my CM15A is also dated 06A... can't remeber the last part of the date code