kclenden

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.

Insteon is a mesh network. This means that in theory the more devices you have the more reliable the network is. This reliability comes from the fact that most devices on the network repeat all commands on the network. For the devices to all repeat commands without talking over each other, there has to be some rules. That is where "Hops" come in. When a device sends out a command, it specifies how many "Hops" are allowed for the command. This tells all devices on the network how many times to repeat the command. When a device first receives a command, it subtracts one from the "Max Hops" and repeats the command. It continues repeating the command like this until the "Max Hops" becomes -1 at which point it stops repeating the command. While devices are repeating commands, they can't send out any commands of their own. Additionally, even devices that don't repeat commands (battery operated devices) aren't allowed to send out commands until the other devices are done repeating the original command. So a command sent out with "Max Hops" equal to 3 will use up four times as much of the network's time as a command sent out with "Max Hops" equal to 0. But that command will also be more likely to reach its intended target because each repeater adds a little power to the signal. What the Event Viewer log shows you is the earliest point that the device received a command. If it received the command when the originator initially sent it, the "Hops Left" will be 3. If it didn't hear the original command, but did hear it the first time other devices repeated the command then "Hops Left" will be 2. And so on. As larryllix says, a "Hops Left" of 0 means the device heard the command but not until the very last possible moment. Since you're seeing some "Hops Left" of 0, it means that there are likely times where commands are just lost and don't appear in the Event Viewer log at all. You definitely have communication issues. They could be the result of a failing PLM, but they also could be caused by noise or signal suckers on the powerline. The link (https://wiki.universal-devices.com/index.php?title=INSTEON:_Troubleshooting_Communications_Errors) posted by Techman is as good a place as any to start to understand some of the things that can hurt and help the powerline network.

Try opening the Event Viewer (Tools->Diagnostics->Event Viewer). Set it to Level 3. Then select one of your dimmers and perform a "Query". In the Event Viewer you should see a [Std-Direct Ack] record that displays "Max Hops" and "Hops Left". Are those two values the same? If not, what are they? Do the "Query" several times for several different devices. If the "Hops Left" is regularly less than the "Max Hops" it means that there are consistent communication issues.

As you found via your searching, the changed value in the device links table is because there are two bits that the device manages on its own to account for communication errors that it perceives. The ISY isn't informed about these changes so its copy of the link table remains as it was from the beginning. Since UD commented in the thread to which you linked, they may be filtering those bits out in V5, (I'm assuming you're on V4 since your screenshot are a little different than my screen) but I wasn't able to confirm that since I couldn't find any of my devices with a Controller record that had been changed in its link table. I did find some devices that had an extra record in the device link table but they were always for Responder records and changed "no clean-ups" to "Broadcast for a cleanup". They also changed a byte in the device link record that the developer documentation says is ignored, so I'm guessing they may be a later change to firmware that Smarthome hasn't documented to the public. As larryllix says, Insteon devices essentially contain mini CPUs and memory so it is possible for them to get corrupted via voltage spikes or line noise. Additionally, I'm led to believe that Smarthome does testing before devices leave the factory and sometimes the device doesn't get reinitialized correctly. So I always do a factory reset immediately after installing a new device. Learned that one the hard way.

Based on the model # and date purchased I think we can rule out a couple things: Spurious X-10 commands since this plug-in module does not support X10 Spurious local load changes since this plug-in module does not support load sensing Spurious All-On commands since this is a newer plug-in module and presumably doesn't support the All-On command That would leave a couple other things to consider: Corrupted link table - factory resetting and restoring the device should fix this. Activation by other programs - your search should have found any other programs. If you used "Your Devices" and selected the device when you did your search, you might try changing to "Raw Text" and typing just a portion of the device name, say "Theater", then click "Find". But keep in mind that "Raw Text" searching is case sensitive. I seem to recall some reports that searching by "Your Devices" didn't always find every instance. Accidental inclusion in a scene - you didn't specifically answer larryllix about whether the device was included in any scenes, but the fact that there were only three lines in the device link table seems to confirm it's not in a scene. Just to be sure you should select the device and look at its memberships. Local activation - is there any way something could occasionally bump the ON switch? Maybe a curious pet? Hardware issue - a defective ON button could cause spurious local ON commands

I don't believe that the log actually shows command actions, but merely status changes. There's clearly no Web line associated with the 12:09 status line, but depending on what kind of plug in module you have there are other things that could cause it to come on that wouldn't appear in the log. Is the module Insteon? Z-wave? X-10?

I'm running v5 of the firmware, and under Action->Your Devices there is a "Write Changes" option. I'm not sure if this is available in V4. I think the only reason you need to press the SET button on wireless devices is to wake them up so that they can receive the updates. Whenever a motion sensor senses motion it wakes itself up to send an "On" command. It remains awake for a little bit of time after that. So all you have to do is look for the motion sensor to switch on and then write updates. Something like: If 'Motion Sensor' is switched On Then Set 'Motion Sensor' Write Changes Else You could do something similar for your leak sensors, but instead of looking for it to switch on, you could look for the heartbeat, though I'm only guessing that a leak sensor wakes itself up to send a heartbeat.

I don't know what the timeout is on the older motion sensor, but my guess is that the motion sensor timeout is kicking in after 1 minute, turning the motion sensor off. This would cause the IF to be reevaluated and the ELSE being run. I think you want to use IF 'Mouv. Garage - Sensor' is switched On instead of IF 'Mouv. Garage - Sensor' Status is On. Edit: Just noticed the "3.0" in the Timeout dropdown. While this would seem to indicate that the timeout on the MS should be 3 minutes, I'm not sure the ISY always knows the internal values of sensors. You could try waking the MS up and then setting the timeout value to something longer to ensure that what the ISY is displaying for Timeout matches what has been set internally in the MS. Then your program above should allow a longer WAIT. Even if that works, I'd use "switched On" instead of "Status".

A little late to the party since Michel has said the current behavior in V5 is a bug, but yes in V4 when you set the backlight level for a device, the ISY remembers that value and displays it for you when you next look at the device's backlight level - even when the Admin Console is restarted. Though I'm on V5 now, I know V4 acts that way because I routinely used that capability when I installed new devices so that I could set their backlight level to match other devices near them.

What TrojanHorse is referring to is that your IF statement checks the status of the thermostat, and your third line has the potential to change the status of the thermostat. However, I don't think it's correct that the fourth line won't ever be executed. My understanding is that the IF statement won't be reevaluated unless a WAIT statement is running (which happened earlier, but not after you change the set point) or a REPEAT is executed or the program concludes normally (i.e. runs out of line to execute).

When I had a light mysteriously turning itself on, I eventually discovered that it had an X10 address set, even though I never set one. A factory reset and ISY "device restore" solved the problem. A factory reset and device restore may not help you, but takes little effort as a hail mary.

Thanks. That has removed my need to use the Themes option to change the Admin Console font size so whatever causes the Admin Console to reset back to default settings shouldn't impact me any more.

I have similar issues with Themes. I have a 4k monitor and need the font size set at 18 to make it readable. I can't pinpoint exactly what makes it revert to default, but it mostly happens when the computer is rebooted as opposed to the Admin Console merely being closed and reopened. Edit: I'm also running 5.0.14.

Having the write icon next to the buttons implies that the ISY needs to save information to the 2334-2. It could be that information is the links that would include each button in the scenes that you have configured. That would explain why nothing happens when you press each button. As Techman indicated, it seems like there could be a communication problem between the 2334-2 and the PLM. Have you tried opening the Event Viewer and the executing the write commands? That would allow you to see whether the 2334-2 is responding to the ISY when it tries to execute a write.

I'm glad Michel chimed in because it made me look at the Log. In doing so, I realized my post above wasn't correct because although I think of the Event Viewer as the Log, it's not what the Admin Console calls the Log. So I edited my post above to refer to the Event Viewer instead of the Log.

I don't have a thermostat so can't really provide any ideas based on experience, but wonder if maybe the thermostat doesn't push data to the ISY but instead needs to be queried. Perhaps querying the thermostat on a regular basis (e.g. every 30 minutes) would resolve the need to login to the ISY or use Mobilinc.