kclenden

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.

I think that's open for interpretation. The nodelink program make you dependent on another device adding an additional point of failure. Using system variables is really easy. Here's what I use: Set Date Variables - [ID 00A0][Parent 004D] If Time is 12:00:00AM Then // Determine Day of Week $sISY.DayOfWeek = [Current Day of Week] $sISY.DayOfWeek Init To $sISY.DayOfWeek $iISY.DayOfWeek = $sISY.DayOfWeek // Determine Day of Month $sISY.DayOfMonth = [Current Day of Month] $sISY.DayOfMonth Init To $sISY.DayOfMonth $iISY.DayOfMonth = $sISY.DayOfMonth // Determine Month Of Year $sISY.MonthOfYear = [Current Month (Jan=1, Feb=2, etc.)] $sISY.MonthOfYear Init To $sISY.MonthOfYear $iISY.MonthOfYear = $sISY.MonthOfYear // Determine Week of Month $sISY.WeekOfMonth = $sISY.DayOfMonth $sISY.WeekOfMonth -= 1 $sISY.WeekOfMonth /= 7 $sISY.WeekOfMonth += 1 $sISY.WeekOfMonth Init To $sISY.WeekOfMonth $iISY.WeekOfMonth = $sISY.WeekOfMonth // Create Month.Day Combo $iISY.Date_Scratchpad = [Current Day of Month] $iISY.Date_Scratchpad /= 100 $iISY.Date_Scratchpad += [Current Month (Jan=1, Feb=2, etc.)] $sISY.MMDD = $iISY.Date_Scratchpad $sISY.MMDD Init To $sISY.MMDD $iISY.MMDD = $sISY.MMDD // Determine if it's a holiday Run Program 'Holiday reset' (Then Path) Else - No Actions - (To add one, press 'Action')

When I first got my MS II, I tried playing with the sensitivity level and it didn't seem to make much difference. However, I was only testing the sensitivity as I walked directly toward the MS since I was trying to use one sensor to cover two long hallways that could be seen from a particular MS position. My understanding is that detecting something coming directly at it is the most difficult case for a MS. So it's entirely possible that changing the sensitivity level could have more impact on detecting things crossing the path of the MS. By the way, I ended up using two MS II instead of just one.

@Michel Kohanim, At my age I can rarely be 100% sure of anything. But I'm 99.9% sure I saved before the export. I've attached the ISY file that was created from the export, and consistently imports incorrectly, if that would help. You could try importing it to see if you get the same results as me. Or perhaps look at it and tell me why my import results are exactly as they should be. Z.v5.0.14__Mon 2019.01.21 08.50.47 PM.isy Edit: I just tried importing the file into a folder besides "My Programs". I get the same results. The "Z" folder is created, and everything appears below it except for program "1b" which appears at the same level as the "Z" folder when it should appear within "Z->1".

If you right-click on a folder, you have the option to either import to or export from that folder. So I've been right-clicking on a folder below "My Programs" to export and then right-clicking on the "My Programs" folder to import.

I wasn't willing to risk my entire set of programs by deleting everything under "My Programs", so I created a folder underneath "My Programs" called "Z" and then created three folders beneath it and put three (empty) programs within those folders. Then I saved, exported the new folder, deleted the new folder, saved, imported the recently created export file and saved programs. What I ended up with was not what I started with. The folder structure was correct, and two of the programs were in the correct folder, but the third program appeared at the root level (i.e. under "My Programs" not under "My Programs->Z"). I've looked at the export file (it's simple XML) and don't see anything in it that would cause the one program to appear at the root level, but not the other two. It has the same parent as another program, and both programs appear earlier in the file than the actual parent folder, so I would expect that either both of them would appear in the wrong folder or both of them would appear in the correct folder. So I got even more detailed and created a more complicated folder structure (11 folders and 11 programs), and instead of totally empty programs, I added "last run time" to four of the programs, with one of the programs having every other program's run time within its IF (including its own last run time). Then I saved, exported, deleted, saved, imported and saved. This time everything imported 100% correctly. Including the program with every other program's run time as a reference. So I can't tell you why your process didn't work the way you expected, but I can tell you that I was able to duplicate (on a small scale) an import error, but wasn't able to duplicate (on a slightly larger scale) an import error. I am curious, however, what you were trying to accomplish with your process? Based on my experiment, exporting, deleting and importing shouldn't give you a flat program structure. It seems like it is supposed to give the same structure you started with (assuming no error). If you simply want to count the number of programs you have, open the export file with Chrome, Internet Explorer or Edge and do a find (Ctrl F). First search for "<id>". You should see something like "1 of 4" telling you which occurrence is displayed. That will tell you how many programs + folders you have. Then do a search for "<folder />". That will tell you how many folders you have. Then simply subtract to get the number of programs.

Yep. The MS II works like a charm for me. You should post your programs. And maybe even a screen shot of your MS II options.

Configured with a short motion sensor "Timeout", say 10 seconds, and a longer program timer, say 2 minutes, the light should stay on if you continue to move around. Assuming the MS sees you, it will send an ON command every 10 seconds, restarting the program timer. That's how my MS II sensors functions.

I think you're right, $sVacation won't ever become TRUE because the WAIT 48 hours will be interrupted whenever the time is not in one of the four periods you've specified. I think you could, however, use that program to accumulated time of non-demand and then use another program to set $sVacation to TRUE. Something like: No Hot Water Demand Count If ( On Mon, Tue, Wed, Thu From 10:00:05AM To 5:48:55AM (next day) Or On Fri From 10:00:05AM To 5:48:58AM (next day) Or On Sat From 10:11:05AM To 5:48:58AM (next day) Or On Sun From 10:11:05AM To 5:48:55AM (next day) ) Then Repeat Every 1 minute $sNonDemandCount += 1 Else - No Actions - HW Schedule Ctrl If $sNonDemandCount >= 2880 Then Set $sVacation = $cTRUE Else - No Actions - Now the only other thing you would need to do is to reset $sNonDemandCount to 0 whenever something you consider to be non-Pet Sitter caused demand occurs. You could also use $sNonDemandCount for your 72 hour recirculation program. I chose one minute intervals because the count accumulation is going to be interrupted whenever the time period shifts outside the four periods you defined. If an hour interval were used, then you'd miss some time from 5AM (next day) to 5:48AM (next day) when the REPEAT was interrupted.

Select the motion sensor and click "Options". Under Motion there should be a setting for "Timeout". That's how long the motion sensor will wait before it starts sensing motion again after it detects motion. That value should be less than the length of time you set your program timer. The lower you set the "Timeout" the more often the motion sensor will have to detect motion, but I presume that will also make it use battery quicker. Another issue can be if you configure the motion sensor to turn on a light only at night. Once the light comes on, the motion sensor no longer thinks it's night, so doesn't send any more "On" commands, even if it senses you moving, until the light goes out and it again thinks it's night.

Simple answer - Yes, you can use the ISY to program keypad buttons so that they control things even if the ISY is powered down. First you create a scene in the ISY. Next you drag the devices you want to be controlled to that scene and add them as "responders". Finally you drag the devices you want to control the responders to the scene and add them as "Controllers". The ISY writes the necessary "links" to each device's memory so that even when the ISY is powered off, the responders will react when the controllers command them. After you've added the responders and controllers to the scene, you can go back and edit what happens when the scene is activated. So if you have some responders that are dimmers, you can configure them to come up at 50% instead of 100%. This information is also written to the devices so that even without the ISY present, they will react accordingly.