AnonymousMay 10, 2008 at 5:02 amPost count: 3
I am an utter newbie to home automation (but I’m a programmer, so ability to follow geeky instructions is generally high).
I have an EZSnsRF, 2 Dakota IR-3000 PIRs, a PowerLinc USB Controller (2414U), and a single ApplianceLinc V2 #2456S3.
My desired outcome is home security — when the PIRs detect motion, I want a light to go on and an SMS to be sent to my cell. (Ultimately, I’d like more, but for now…)
I bought mControl S/W with the components and have managed to control the ApplianceLinc-plugged light from that. Unfortunately, it’s not obvious how to use mControl to react to signals from the EZSnsRF.
I’ve also downloaded Smarthome Device Manager and the Simplehomenet Utility Suite (1.75). I can use that to read the EZSnsRF — more or less. If I hit the “read” button with the Code Number spinner set to 1, I get Linked: false (unchecked) InUse: t/f (see below) In use: f, Timer 0, Code 0, Group 1, Cmd1 11, Cmd2 0, Cmd1 13, Cmd2 0.
If the linking of the EZSnsRF with the PLC and ApplianceLinc can be done using the utility, I could really use a walkthrough (if it’s the “Manage Device Links” tab, it’s very unclear what the values should be — whether the EZSnsRF goes in the top Device ID field or the “Add Link Record” Device ID field, what the value of the Link Data should be, etc.).
If I try to follow the instructions to manually link the EZSnsRF with the ApplianceLinc, the initial link to the Dakota PIR goes well (and if I read the value subsequently, I’ll see InUse = true (checked)). Then (and perhaps I’m just not understanding the precise device-button sequence, how many times, and how sensitive they are to timing …) I go over to the ApplianceLinc, press the “set” button until the LED starts flashing about 1 / sec. The EZSnsRF is still flashing about 1 / sec. I don’t know what to do at that point — if I come back over to the EZSnsRF and press the “set” button for 4-5 seconds(per instructions on included sheet), the LED on the EZSnsRF goes solid, the LED on the ApplianceLinc goes solid, but (a) I get the same values if I “read” from the EZSnsRF from the Simplehomenet Utility Suite (i.e., “Linked” is false but “In Use” is true) and (b) in the “Insteon Traffic” tab of the Utility Suite I see no traffic coming from the EZSnsRF when I wave my hand over the PIR (LED comes on inside the PIR).
Ideally, I’d like the link from the EZSnsRF to trigger a s/w event inside the computer (because that’s the only way I’ll ever get email), but for the moment, I’ll be satisfied if I can just get it to turn on the light. I’m willing to install different software if that’s an issue.
Windows XP SP2, Firmware on the PLC is 2.13, don’t know how to read firmware on the EZSnsRF or ApplianceLinc.
Any help _greatly_ appreciated. We had an attempted break in last week and are leaving town shortly, and I’m pretty anxious to take things a step beyond mechanical timers…
LarryAnonymousMay 10, 2008 at 8:50 amPost count: 1001
The Insteon Traffic tab is not a generalized Insteon message trace. That tab displays commands issued by the SHN Utility on the left side of the screen and the response received by that command on the right side of the screen. After “Connecting” the SHN Utility to the PLC, a blue T shaped icon appears in the system tray. This icon represents the Smarthome Device Manager, generally referred to as sdm3 (name of the .exe file). Double click on the blue T icon to open the sdm3 trace window to observe Insteon traffic.
I would start by doing a Restore Factory Configuration (Factory Reset) using the SHN Utility. That way you are starting off with a clean device. Put the EZSnsRF into linking mode by pressing the Set button for 4 seconds. The LED is blinking once per second while it is listening for the RF signal from the Dakota Alert device. Trigger the Dakota Alert device to cause it to send the RF signal. Now the EZSnsRF LED is blinking faster, about twice per second. At this point it is listening for an Insteon device to link with. Press the Set button on the ApplianceLinc for approximately 3-4 seconds. I linked with a LampLinc to do this test, the lamp connected to the LampLinc blinked twice while holding the Set button on the LampLinc for 3-4 seconds. The lamp blinking twice indicates the LampLinc is linked with the EZSnsRF. End the linking process at the EZSnsRF by holding its Set button for 3-4 seconds. From your description it sounds like the EZSnsRF is blinking once per second which puts it in the “listening for RF signal” part of the link process rather than listening for an Insteon device where the LED is blinking at approximately twice per second. Do not query the EZSnsRF with the SHN Utility while in the linking process.
At this point each time I trigger the Dakota Alert motion sensor, the lamp turns on for 1-2 seconds, reflecting the signal received from the motion sensor.
EDIT: the link records created are as follows…..
Link Record 1 – Controller of Device: 4.93.BF; Group 6; Data: 1,0,28
Link Record 1 – Responder to Device: 8.9B.4B; Group 6; Data: FE,1F,0
EDIT: fixed text reference to EZSrvRF which should have been EZSnsRF and used the words in the factory reset button, Restore Factory ConfigurationAnonymousMay 10, 2008 at 10:03 pmPost count: 3
Awesome! I managed to get manual linking between the EZSnsRF and the ApplianceLinc to work (the difficulty went away when I moved the EZSnsRF to a dedicated light switch rather than have it plugged in to the power strip associated with my computer).
I also managed to get a s/w reaction by adding a rule to mControl that reacted to the status change of the ApplianceLinc. But I would rather receive the notification / event initially in software via my PLC — is that possible with an EZSnsRF?
I added a link to my PLC using the “Manage Device Links” tab of the Utility Suite; I cloned the record to the ApplianceLinc, simply switching addresses. This results in simple messages (01, 03) appearing in the SDM trace. Ought I to change the “Device Link Data” values to something else?
Can I access the EZSnsRF in mControl by editing the values of mserver.exe.xml? If so, what would be appropriate values?AnonymousMay 10, 2008 at 10:52 pmPost count: 192
Both the power strip or the computer maybe the problem.
Many power strips have a noise filter in them that can absorbe both X10 and Insteon signals. Also many computer power supplies have a filter in them or generate powerline noise that can make the module miss data.
I had to add a FilterLinc to my APC BX1000 UPS to correct signals being messed up.AnonymousMay 10, 2008 at 11:40 pmPost count: 1001
Do not change the PLC link database with the SHN Utility. The utility does not support the type of “linked” record database used in a PLC. See ….
I have used inhomefre software to reload my PLC application but have not used it to manage links. It is free so give it a try.
Normally a responder link record is required in the responding device (the PLC in your case), to cause an ACK to be issued in response to the Group Cleanup Direct message issued by the EZSnsRF. I don’t believe the data in the new “Controller of” link record you added to the EZSnsRF with the PLC address as the controlled device, makes any difference. I think you need the “responder to” link record in the PLC. If you can copy the trace records from the sdm3 trace window when you trigger the motion sensor, and put them in a post, I will see what messages the EZSnsRF is generating and what responses are seen.
EDIT: I found the following in the mcontrol user guide …..
Macro Triggering and Real-time Status Changes from SwitchLinc Paddle Presses
As shipped from the factory, the PowerLinc 2414x/2814x adapter can not “hear” paddle press
messages originating from SwitchLinc. As a result, mControl can not show any status changes
initiated by paddle presses on SwitchLinc devices.
To enable this, the PowerLinc 2414x/2814x and SwitchLinc must be linked to each other.
1. Link the SwitchLinc to the PowerLinc
As part of mControl normal operation, mControl will automatically create a link within the
PowerLinc 2414x/2814x link database upon entry of the SwitchLinc device.
2. Link the PowerLinc to the SwitchLinc
SwitchLinc devices will only send paddle press changes to devices linked to it. As shipped
from the factory, PowerLinc 2414x/2814x does not allow for “slave” links from other
devices, like SwitchLincs, due to limitations in the “SALad core application”, a software
application, which manages the interface between the INSTEON connection and the
computer. To enable this functionality, a new SALad core application must be downloaded
to the PowerLinc. Ensure the PowerLinc 2414x/2814x is using the TimerCoreApp (v1.06)
Once these steps have been completed, it is possible to receive real-time information (<2 seconds)
from SwitchLinc devices. In addition, it is possible to use SwitchLinc On or Off paddle presses for
For more detailed information, please refer to mControl Application Note 06-0001-A.
A SwitchLinc is like an EZSnsRF in that they both control other devices. I do not use mcontrol so I have no experience with the details that are mentioned above. If mcontrol has a forum perhaps they can provide the information specific to mcontrols recognition and use of an EZSnsRF device.AnonymousMay 11, 2008 at 1:31 pmPost count: 1001
The SwitchLinc is a bad example when comparing to an EZSnsRF. You do not cross link an EZSnsRF because it has no output function.
EZSnsRF ______________________ PLC
SwitchLinc _____________________ PLC
ControllerAnonymousMay 12, 2008 at 8:27 pmPost count: 3
Well, in the end I used SDM and a small C# program I wrote to catch the Insteon messages from the EZSnsRF.
Is there any way to identify the specific Dakota Alert PIR that sent the signal? The Utility Suite has a function for “Last Received RF Code” but that seems to always be 0 (in my case).
The PIRs I’m using (Dakota Alert IR-3000) have dip switches that apparently control the chime that ought to be played — if I set the dip switches differently on my two detectors, is there something that I can pick up from the EZSnsRF?AnonymousMay 12, 2008 at 9:30 pmPost count: 1001
There is nothing in the Insteon message that identifies the RF Code. However, if each motion detector is assigned a unique code and each RF Code Record for those codes has been assigned a unique Group number, the Group number is in the Insteon message. The first Insteon message is an ON (0x11) command for group 6. The second message is an OFF (0x13) command for group 6.
02 08 9B 4B 04 93 BF 41 11 06 – Insteon ON command for group 6
08 9B 4B from device address
04 93 BF to device address
4x flag byte – Group Cleanup Direct message
11 CMD1 ON command
06 CMD2 Group number
02 08 9B 4B 04 93 BF 41 13 06 – Insteon OFF command for group 6
I think each of the 4 zones (chimes) is considered part of the RF Code. You can verify that by changing the zone (chime) number on one of the motion detectors and see if it does or does not control the ApplianceLinc. If it no longer controls the ApplianceLinc, the zone is part of the RF Code. You will have to register the new code with the EZSnsRF just as you did with the first code, being sure a different group number is used. If a different zone continues to control the ApplianceLinc, then you will have to change the base code number (first 8 bits of the DIP switch) before assigning the new RF Code.
- You must be logged in to reply to this topic.