kclenden

I agree with both larryllix and sub-routine - you need the time range on your "Turn On From X10" program. It was only the two programs that didn't also include "X10 Received" in the IF that didn't need the time range. Also, sub-routine's comment about scenes will definitely make things look more coordinated. Simply create two scenes, maybe call them "Sconces at 30%" and "Sconces at 100%". Then drag all five switches into each scene and make them responders. Finally, select the 30% scenes and click each device in the scene table and set its ON level to 30%. Then do the same thing for the 100% scene, but obviously setting the ON level to 100%. Then in your programs you merely need to turn on the "Sconces at 30%" scene when you want the level to be 30% and turn on the "Sconces at 100%" when you want the level to be 100%. When you want the sconces to be off, you can turn off either the 30% or the 100% scene since they both contains the same devices.

Above is my analysis of your linking attempt. It appears that messages between the PLM and On/OFF Module are getting through without a problem. Here are the steps represented in the Event Viewer: ISY asks the Device about its INSTEON Engine Device replies that it doesn't recognize the address of the PLM ISY tells the device to enter linking mode Devices says OK ISY tells the device to add the PLM address to its DB Device says OK ISY tells device to exit linking mode ISY asks the Device about its INSTEON Engine Devices again replies that it doesn't recognize the address of the PLM ISY asks the Device about its INSTEON Engine Devices still replies that it doesn't recognize the address of the PLM ISY gives up I can't quite tell from your posts exactly what you've tried, but here's what I think you've tried: Bought a 2635-222 and it wouldn't link at house #1 (tried three different ways - with address & auto discover, with address & device type, without address but actually pressing SET on device - and you've tried plugging this device into outlets that worked before as well as the same outlet as the PLM) Bought a second 2635-222 and it also wouldn't link at house #1 Took the second 2635-222 to house #2 and it linked without problem Brought back a 2635-222 that has been working at house #2. What did you do with this device? Were you able to link it at house #1? I don't think the issue is with the ISY. It can only react to the messages that it receives and according to the Event Viewer it never receives a message that tells it the device's INSTEON Engine. So it would seem either the PLM or the On/Off Module are at fault. It can't hurt to try Sub-Routine's suggestion to try manually linking a Switch to the On/Off Module. But based on your experience having a new On/Off Module that won't link at house #1 but will link at house #2, my guess is that the Switch will successfully link to the On/Off Module. And if that's the case, then Smarthome won't let you return it. Then I guess your next move would be to contact UD support and have them look at your Event Viewer results.

It might also be helpful to know what version your PLM is at each house, as well as how old they are. Just use "Tools>Diagnostics>PLM Info/Status" to get the version.

That video doesn't apply to the OP's problem. You'll note early in the video, Steve mentions that the PLM is not receiving any SRX records. If you look at the OP's Event Viewer log, you'll see SRX records. The device is clearly talking to the PLM. The issue is that the ISY doesn't seem to understand the device's response. You can see the ISY try twice to link with the device, and each time the responses contain exactly the same data. If there were a communication problem, either there would be no responses, or you would expect the responses to be different because of line noise. That's not happening. So it seems like the ISY really can't determine the device's Insteon Engine from the response it's getting from the device.

Scenes do not respond to %'s. If you tell a scene to come on at 30% or 100%, the same thing happens - the scene comes on to whatever level it was defined. So if you turn a scene on at 30% and then later turn it on at 100%, you won't see any difference. You can setup a scene with the sconces set to come on at 30% and then setup another scene with the sconces setup to come on at 100% - then turn on the 30% scene followed later by turning on the 100% scene. Then you'll see a difference. Paulbates had you change the conditions in your two programs not because they would help the X10 issue, but because the time range was superfluous. The end of the time range does nothing. If you want programming efficiency, then make use of the ELSE clause for your OFF command like: If From Sunset To 11:00:10PM (same day) Then Set 'Sconce Lights' On Else Set 'Sconce Lights' Off That program would replace your two programs.

The Event Viewer indicates that the device is responding to the ISY. And those responses are consistently the same so I don't think this is a communication problem. The Event Viewer makes it look like you used the "Link Management>New INSTEON Device" menu option, and typed in the address of the device, but I can't tell if you used "Auto Discover" as the "Device Type". If you did, I'd suggest specifying the exact device type:

I don't have the zwave module, but I have been considering adding one. From reading the forum, the answer to your question is that it's not necessary for you to upgrade. However, if you want to take advantage of any of the Zwave+ features available in new devices, you'll need the 500 series or later. Additionally, it seems like there is some pain when converting from the 300 series to a new series so if you're going to use Zwave+ features it might be worth $40 (depending on the enjoyment, or lack thereof, that you get out of setting things up) to skip setting up under the 300 series and then later converting to the 500 or later series.

The username and password are reset to admin/admin.

Then perhaps the issue is communication related. The MS II is an RF device that depends on a powerline device to hear and pass on its communication (unless it's close enough to the PLM). What is the closest dual-band device to the MS II? If you start the Event Viewer and set it to Level 3, when you see communication from the MS II, how may "Hops Left" are there? If it's directly communicating with the PLM, it would be 3. If it's relying on another device to pass on its message then "Hops Left" would be 2. If they are consistently 1 or 0 then you have a communication issue. You also might try factory resetting the MS II. Remove the battery; hold the set button and reinstall the battery; continue holding the set button until the MS II stops beeping; when the reset is done the MS II will double-beep. Then put the MS II in set mode (hold the set button until the LED starts blinking) and perform a Device Restore from the ISY.

How long have you had the MS II? Any chance the battery is low? Assuming the section of video with you waving your hand is continuous, the LED is not acting like mine does. I have a "timeout" of 10 seconds. After the LED flashes once, it won't flash again for 10 seconds. According to the Options screenshot you posted, your "timeout" is set for 30 seconds. I wouldn't expect the LED to flash again for 30 seconds after it first detects motion. Though you said that the only thing you changed out of the box was Motion>Report, so it's possible that the ISY is just showing the default "timeout" and not how your MS II is actually set. Still, the minimum "timeout" is 10 seconds, so I wouldn't expect the LED to flash any more than every 10 seconds and yours definitely flashes more like every 3 seconds.

Well you could certainly use the poor man's method and just use a switch. If there's a switch next to the door that you usually leave through, simply look for a "Fast Off" (i.e. double-tap) coming from it. When you see that, toggle a state variable, say "$sVacation" from 0 to 1 or 1 to 0. Then have a program that checks the value of that state variable. If the value is greater than 0 set the LED brightness on that switch to 0 (that's your visual indicator that you've set vacation) via the THEN. Otherwise, set the LED brightness to its normal level via the ELSE. Use the "$sVacation" variable for any other programs you want to run while in vacation mode

Thanks, but I only set the timeout to 30 seconds to test whether the ISY kept track of the MS II status changes. Likewise, the third condition in the IF was merely added as a test. In normal operation, the timeout is set to 10 seconds (to keep sensing motion) and the MS II is not configured to send OFF commands. With that setup the program works just fine and the 2 minute wait resets when motion is detected so that the scene OFF command is only executed after 2 minutes of no motion.

I am able to add a STATUS event for my MS II into an IF statement. Since the MS II can be configured to send both ON and OFF commands, the ISY should have no trouble determining whether its status is ON or OFF. Edit: Just configured my MS II to send both ON and OFF commands with a 30 second timeout. Triggered it and looked at the Admin Console and its status was ON. Thirty seconds later without me doing anything, the status changed to OFF.

I don't think "Status" will work if you have the MS II setup to send ON commands only. If the MS II sends both ON and OFF commands, then perhaps "Status" would work since the ISY would see it go from OFF to ON and ON to OFF.

I think you'd want to expand on Michel's program since you want to start and stop based on different button pushes around the house, so maybe: If ( 'A-Keypad / Button A' is switched On Or 'B-Keypad / Button A' is switched On Or 'C-Keypad / Button A' is switched On ) And ( 'A-Keypad / Button A' is not switched Off Or 'B-Keypad / Button A' is not switched Off Or 'C-Keypad / Button A' is not switched Off ) Then Run Program 'Turn Device On' Else Run Program 'Turn Device Off' You'd still want to group the keypad buttons into a scene with each being a controller so that the LED on all of them stays in sync. The only real problem with this approach is that if you add or remove a button from the scene, you need to update the program by adding or removing that button. If that is a problem, I suppose you could use STATUS instead of CONTROL and then only look at one button you know will always be part of the scene. So something like this if you know 'A-Keypad / Button A' will always be part of the scene: If 'A-Keypad / Button A' Status is On And 'A-Keypad / Button A' Status is not Off Then Run Program 'Turn Device On' Else Run Program 'Turn Device Off'

I would think that 255 was just another way of representing 100% since the value for one byte would range from 0 to 255. Now why the ISY reported it as 255 instead of 100% is a question for @Michel Kohanim. Did the hidden door sensor send its status back to the ISY in a different way than normal? Or did something else cause the ISY to interpret 255 differently than normal?

Once you open the "Show PLM Links Table" dialog box, you do have to click "Start" to see the links. If the links in the PLM Links Table are corrupt or missing, you can restore them with a copy of what the ISY thinks should be in the table by using "File>Restore Modem (PLM)". Before executing a "Restore Modem (PLM)", I would do a full ISY Backup first.

I don't have any Zwave devices, so can't comment on actual experience, but as oberkc says, when the ISY sends direct Insteon commands to a device, it looks for an acknowledgement from the device and acts accordingly. When the ISY sends out an Insteon scene command it's done and doesn't look for acknowledgements from the device. So your symptoms could actually be pointing in the direction of a communication issues. One way to get a sense of whether there is a communication problem is to open the Event Viewer (Tools>Diagnostics>Event Viewer) and set it to Level 3. Then execute some programs that send commands to troublesome devices. Look for statements in the Event Viewer that include (Hops Left=). If there are consistently "Hops Left" that are less than 3, and especially if there are some equal to 1, then you likely have a communication issue.

Just to be sure, after you clicked "Show PLM Links Table", did you click the "Start" button? An empty PLM Links Table would certainly point to an issue with the PLM. The links in that table is how the PLM communicates with all devices.

From within the Administrative Console, what does it say when you choose "Tools>Diagnostics>PLM Info/Status"?

Thanks for posting this. I replaced my GDO a couple months ago and have noticed some degraded Insteon traffic. Not degraded enough to get me off my butt to do some troubleshooting, but enough to be annoying. I didn't even give it a thought when I replaced the old GDO with a battery backed up GDO that I was potentially introducing a signal sucker or noise maker. Guess that says something about how well my Insteon network has functioned that I don't even give a second thought when introducing ridiculously obvious electronic troublemakers. Anyway, I have an extra FilterLinc lying around so I think I'll use it for the GDO and see if the degradation is mitigated.

The point made by mwester is valid for any technology, since eventually all technology is replaced. But everyone defines "long-term" differently. Is it five years? Ten years? Longer? Should you still buy your music on CDs? Movies on DVD or BlueRay? Should you buy SATA devices? USB devices? How about a Tivo DVR? Everyone will answer those questions differently. The fact that mwester has concerns about Insteon is relevant. When there are enough mwesters, Insteon will go the way of IDE devices, but the same can eventually be said of all technology, whether home automation related or not.

This confuses me. Why have ON and OFF buttons for a device you plan to leave continuously powered? Just out of curiosity, why would you wire the fan this way as opposed to sending continuous power to the FanLinc and allowing the FanLinc to control the fan's ON/OFF? The latter is how I have my fan wired, but my fan has a light so I need continuous power to the FanLinc so that the light can be ON even when the fan is OFF.

I, too, was disappointed that the values weren't directly accessible. Having written a compiler and interpreter in college, it seems strange to me that the values aren't directly accessible, but I'm sure UDI had a good reason.

I used his programs in V4 and was very thankful that he put them together because there were a lot of them and they did EVERTHING! Just setting up all the variables had me in tears, let alone the actual programs. ? That is why I love the simplicity of V5 so much.