brad77

kd7iyt- In the meantime, it is possible to do this using the Network module using the method outlined in this post. It's a bit technical, but once set it up, you can arm, disarm, and fire other ELK functions using programs. The CRC calculator has moved to the Support Tools section of Elk's owner portal and is now called the M1 Software Developer's Tool.

I'm picking up what you're putting down, fitzpatri8. I'm just not sure if I'm ready to start tearing apart my door jambs! At any rate, my point is moot. The feature doesn't exist, so your method is really the only viable option. It is a real need, though, in my opinion. With a troublesome door, I really can't lock it remotely with any degree of certainty as it is. It is a major shortcoming of this setup, IMO.

That's what I was thinking. In some cases, I have found that the deadbolt binds up in the door frame (usually when the door isn't properly/fully shut), causing it to retract. I have an ELK, so I know the door is closed. Positive lock confirmation from the MorningLinc would be the missing link in my scenario.

fitzpatri8 is right. The MorningLinc plug-in transmitter is basically just a fancy RF remote. Just like with the keyfobs, you must enroll it with your lock or it won't respond to it. You can link multiple locks to the same transmitter and they'll all respond if they're in range. Alternatively, you can set up multiple transmitters associated with multiple locks for discreet control. Now if we could just get confirmation that the lock has actually closed...

While there isn't any technical reason why the ISY can't send commands to control an X10 thermostat, the real question in my opinion is whether or not it is able to receive temperature and other status events and store this data as it would an INSTEON thermostat. Without knowing the thermostat's status, its utility is somewhat limited. The answer to that question appears to be no. Provided the thermostat supports it, you could still set up programs to send X10 commands to affect its programming. You just won't know whether those commands took. The ISY can receive X10 events, so I suppose that you could utilize programs to set variables based on the messages it receives. Admittedly, we're getting a bit kludgey here, but it could be useful for HVAC management. Bottom line: If you want full thermostat support in the ISY, you'll need an INSTEON thermostat.

Bob, you'll see VAR messages in the Event Viewer and subscription when the values for State variables change. They come across as event type Trigger, action type 6, which appears to be a new action type for "Variable Status." There's also action 7, which is "Variable Initialized." I presume that is only reported for State variables. The WSDL has been updated as well. Check /web/udiws30.ws for references to variables. There are new web methods to get and set variables in there!

And I apologize that my comment was unhelpful. It isn't clear what you are asking. If you are needing to assign your ISY a static IP address, then LeeG is on point.

Huh indeed!

I'm presuming that you are using a FilterLinc as your filter. Is your ISY powered by your INSTEON PLM or are you using a separate wall wart? If it's the former, you are doing yourself quite a disservice plugging your PLM into a FilterLinc! Presuming that your projector is plugged into the filtered outlet (not the pass through outlet) on your FilterLinc, there might be issues with attenuation that the FilterLinc isn't doing a good job stopping. I'm no electrician, but I have heard others on this forum talk about this. If I remember correctly, the FilterLinc is pretty good at filtering out noise, but is not so great when it comes to "signal sucking" devices/appliances. Perhaps one of them can chime in here.

My motion sensors are certainly not pet immune. My two small dogs set off the sensor all the time. Your mileage may vary. There's no way to configure sensitivity or "height" in the ISY or using programs, so you probably best served locating your sensor in such a way that your dog won't be seen by it.

To me, changing the default port from 443 falls into the "security through obscurity" category. It may help the casual surfer, but it's still pretty easy to scan ports to find servers. In my opinion, always use SSL when connecting from the Internet. That'll keep your communications with your ISY encrypted, even if you're on an open WiFi without a firewall (which is not something I'd recommend). The ISY can generate 1024 bit SSL certs, but the extra overhead to handle the additional encryption will slow things down a bit. If you're using a phone to connect, SSL will affect its performance too. You are on the right track in using a strong password, in my opinion. The rest probably falls into just staying safe on the 'net (be wary of public terminals, don't leave your computer logged in while unattended, password/PIN protect your phone, etc.) I suppose that if you wanted to be really careful, you could set up a VPN. That'll encrypt everything and generally works on most computers and smartphones. You may find that to be a bit overkill, though.

Thanks for the quick reply, Chris. That's exactly what I'm looking for. I was unaware that you could select the controller as the "scene" in the program. If anyone else comes across this thread in the future, here's my setup using the names matching the programs listed above with descriptions in parens: HallwayMotion (scene) | +--- Hallway Motion-Sensor (motion sensor) +--- Hallway Light (load controlling SwitchLinc 1) +--- Hallway Light Secondary (dummy SwitchLinc 2) After changing my programs as follows, the scene does what I want. Motion PM: If Time is 9:00:00PM Then In Scene 'Hallway / Hallway Motion-Sensor' Set 'Hallway / Hallway Light' 2.0 Sec (Ramp Rate) In Scene 'Hallway / Hallway Motion-Sensor' Set 'Hallway / Hallway Light' 67% (On Level) In Scene 'Hallway / Hallway Motion-Sensor' Set 'Hallway / Hallway Light Secondary' 2.0 Sec (Ramp Rate) In Scene 'Hallway / Hallway Motion-Sensor' Set 'Hallway / Hallway Light Secondary' 67% (On Level) Else - No Actions - (To add one, press 'Action') Motion Normal: If Time is Sunrise Then In Scene 'Hallway / Hallway Motion-Sensor' Set 'Hallway / Hallway Light' 0.3 Sec (Ramp Rate) In Scene 'Hallway / Hallway Motion-Sensor' Set 'Hallway / Hallway Light' 100% (On Level) In Scene 'Hallway / Hallway Motion-Sensor' Set 'Hallway / Hallway Light Secondary' 0.3 Sec (Ramp Rate) In Scene 'Hallway / Hallway Motion-Sensor' Set 'Hallway / Hallway Light Secondary' 100% (On Level) Else - No Actions - (To add one, press 'Action')

This is related to this post, but I didn't want to hijack that thread, so I'm starting a new one. In two separate installations, I have tried to implement a couple programs with the aim to change the ramp rate and on-level of two SwitchLincs that are responders to a scene in which a motion sensor is the controller. Basically, the motion sensor turns the lights on an off. Simple enough. I desire that the lights come up to a lower light level at night and ramp up more slowly than they would during the day. I have tried to accomplish this with two programs: Motion PM: If Time is 9:00:00PM Then In Scene 'Hallway / Hallway Motion' Set 'Hallway / Hallway Light' 2.0 Sec (Ramp Rate) In Scene 'Hallway / Hallway Motion' Set 'Hallway / Hallway Light' 67% (On Level) In Scene 'Hallway / Hallway Motion' Set 'Hallway / Hallway Light Secondary' 2.0 Sec (Ramp Rate) In Scene 'Hallway / Hallway Motion' Set 'Hallway / Hallway Light Secondary' 67% (On Level) Else - No Actions - (To add one, press 'Action') Motion Normal: If Time is Sunrise Then In Scene 'Hallway / Hallway Motion' Set 'Hallway / Hallway Light' 0.3 Sec (Ramp Rate) In Scene 'Hallway / Hallway Motion' Set 'Hallway / Hallway Light' 100% (On Level) In Scene 'Hallway / Hallway Motion' Set 'Hallway / Hallway Light Secondary' 0.3 Sec (Ramp Rate) In Scene 'Hallway / Hallway Motion' Set 'Hallway / Hallway Light Secondary' 100% (On Level) Else - No Actions - (To add one, press 'Action') The programs seem to run correctly, but the on-level and ramp rates do not change when that scene is activated by the motion sensor. When I manually change the on-level and ramp rates with the scene node selected in the Admin Console's device tree, I find that the on-levels ramp rates remain unaffected when the scene is activated. However, when I select the controller of the scene (the motion sensor) and subsequently change the on-levels and ramp rates, the lighting then does what I want it to do. So in this case, it appears that the program is changing the former rather than the latter, and doesn't impact the lighting the way that I would like (and would expect it to do) when the controller (motion sensor) activates the scene. Am I doing things incorrectly? Is this a bug or is there no mechanism to do this via programs? Thanks!

I have experienced similar behavior in which you cannot change a scene's on level and ramp rate programmatically. I solved this by creating multiple scenes and triggering them via programs based on time of day. It isn't ideal in cases like motion sensors, but I couldn't get programs to change these scene parameters reliably. Perhaps that's by design or a limitation of INSTEON?

Does the reed switch in the sensor work when it is mounted perpendicular to the magnet on the door? If so, you could mount it somewhere along the door track (possibly even near the top of the door when it's closed). This would capture movement much in the same way a sensor mounted on the floor would, but wouldn't require running as much wire and would be less likely to be kicked or tripped over (though I have to admit that I haven't really found that to be much of a problem).