oberkc

I dont use any portal, so I will refrain from offering second-hand knowledge. For remote access one can use one of the apps, with or without a portal subscription, or a web browser. Avoiding the portal requires a bit of extra work with router settings.

I use mobilinc on iOs and android for the limited times I desire remote access, but believe you can log into the native admin console or dashboard when away, just as if you are at home if you have access to a laptop or similar. Doing these things requires one to do a little port-forwarding magic with their router (a step rendered unnecessary when one uses the portal subscriptions) and a static IP address is always nice from you ISP (or using a service for this). There are also security certificates one must deal with if wanting to use a secure connection. If you have done all the port forwading and other stuff, you can also use a web browser and log into a web-based interface from a mobile device and access an interface that I think they call UDAjax, which is built into the ISY. Read about it here: http://wiki.universal-devices.com/index.php?title=ISY-994i_Initial_Browser_Screen For a discussion on the port forwading, IP addresses, and security, read: http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Remotely_Connect_to_Your_ISY I do not consider this stuff easy for the faint-of-heart or one unwilling to spend sme time figuring it all out. It seams there are a lot of posts about this topic.

For each controller device, there is an option to "copy scene attributes" if you want to make responder levels same as that for the scene (PLM) level. Perhaps this is the accident you found earlier?

I would think that removing the device from any folders then deleting the device would work. My recollection is that it is not necessary to remove a given device from scenes or programs prior to deleting it completely from the ISY. Once deleted, perform a factor reset on the device and re-add it.

My best guess is that responder levels are not correct for each of the KPL buttons. As a refresher, insteon devices can respond differently in response to different controller devices within a given scene. If your scene responds properly to control from the admin console or via program (basically, PLM is controller device), but the scene responds differently when activated by a different controller device, compare ON levels for each responder to the scene level versus the KPL button. To do this, select the scene and take note of the responder levels in the main window. Now select another controller device (such as the KPL button) and compare responder levels. Pay special attention in each scene to the responder levels of the other three KPL buttons. Are they zero? Full on? Different when the scene is selected versus the controller (red letters) KPL button?

I have had no trouble with my fanlincs, but this problem sounds similar to those posted by others. Yes, it sounds like a defective fanlinc.

I dont believe raising or lowering the number has any affect on sensitivity of the motion sensor. This number only affects the level of light needed for the dark sensor to trigger.

I can tell you that there are different configuration settings where one can specify that the sensor send signals only during periods of darkness, and settings that can set darkness level. I can think of no settings that would cause "false" readings or make them more likely.

Your 95 network resources are for insteon and z-wave devices? Tell me more.

Like mwester, I also use a lot of scenes. I also take it as a personal challenge to minimize the number of programs to accomplish a given task. My general impression, also, is that many use variables in cases where I would not find the need to do so. Still, i suspect the difference in the number of programs is due to the relative complexity of what each of us is trying to accomplish. I dont use moisture sensors. I dont attempt to automate bathroom fans with insteon. I dont use the isy to control thermostats or TVs. I dont use the portal or the echo.

I have a variation of this in one case, but normal use includes time between turning it off and sending the second off command. I do not run into the "racing" issue. Yes, it sounds asif it should be easy. Perhaps operator training ( wait a few seconds between off commands)?

I just use faston and fastoff to disable motion or door sensor programs.

Around 50 programs (maybe a few more), 10 network resources, and a half-dozen variables.

Have you tried moving the plm to different outlets and circuits? To the same outlet a the lamplinc? Have you confirmed that you have communication across legs of your electrical system?

So, atthis point your immediate concerns are limited to restoring the orignial functionality? Since your system was working before without the ISY, this suggests programs were NOT involved...only scenes Decide, or try to remember, what each switch did. What light or lights did each turn on before you added the ISY? I suspect you will find that Every fixture is currently controlled by one, and only one, switch and that the switches that currently do not control anything were "virtual" three ways with those insteon switches that DO control something. Once identified, creat a scene for each set of switches that you want to control a given fixture or fixtures. To each scene add all the switches that currently control those fixtures and those that you want to control those fixtures. Add all as controllers. To get beyond generalities, I suspect you will need to identify all the switches, what each currently does, what you want each to do, and post back the results.

If you are performing scene tests, be aware that programs that are triggered by the devices in the test can cause false results. Be sure to disable any such programs.

Along the top is a tab "programs". Below that are three (i think) options...details, summary, and something else. (Dont quote me, this is all from memory.). Ibelieve the summary tab is the one showing the status of all the programs.

Sorry I missed some of the details of your original post. If running "then" portion of program works as expected, i wonder about entire program, or other programs that may be accidentally triggered. I am unaware of "timing" issues that would cause this. However, I could envision a couple of programming problems that might cause this. I certainly encourage you to post the actual program. Perhaps there is an issue that someone might catch. Short of that, open the program log which shows program run times and current state (true or false). Initiate the event or events that you believe would trigger this program. Does it? Does it trigger any other programs? Does this program end up true or false?

It appears to me that your understaning is completely accurate across the board. I expect that when you command the scene containing only the button to be off, the button should, in fact, turn off. The qyuestion becomes why it does not turn off. Were this me, I would select the single-button scene from the admin console and manually tell it to turn off. Once done, confirm whether it is actually off. If not, my best guess is a communication problem. If so, manually turn the button on, and select the prgram at the admin panel. Right click and run the "then" clause. Did the button turn off? If not, your "then" clause has an error. If it turned off after running "then", my best guess is a problem with the "if" clause.

Larrylix and mwester have offered good advice. My only concern with proceeding much further and offering more detailed advice is that I prefer to better understand WHAT you want to accomplish before advising on the HOW part. I dont believe you will have any problems putting things back in order...nothing is physically broken. I see nothing here to get overly-concerned about. If all you want to do is get back to where you were, this would be a ten minute task once you get past the learning curve about scenes, controllers, and responders.

It sounds to me that, prior to your introduction of the ISY, the existing switches had some scenes and links already established. Then, when you added the devices to the ISY and chose the "remove existing links" option, those existing scenes were wiped out. I dont think anything is broken, but you will have to recreate the scenes that existed before, or create different ones if you prefer things that way. Most likely, some of your switches are wired directly to a fixture and some are not. If you have a switch that used to control a light but now does not, that switch is probably not directly connected to anything. My guess is that those switches, before ISY, were linked to other insteon switches that WERE connected directly to a fixture. Lets start with one of your examples...the 8-button keypadand dimmer switches. If the dimmer switches befor ISY controlled the same light as does the keypad, then they were linked together (and got wiped when you added them to the ISY). To recreate what was there, you would most likley create a scene in the ISY admin panel, and add the keypad main button, and the dimmer switches, all as "controllers". There is a learning process one must go through with the ISY. Be sure to check out the wiki and user manuals. I am curious, however. If everything was working, why did you feel the need to add an ISY? Did you have something you wanted to accomplish or change?

Personally, I don't think it much matters directly whether the LED is on or off when the door is open or closed. I believe the issue most people have is when they link some insteon device (such as a keypad button) as an indicator that the door is open or closed. Most, myself included, want the indicator ON when the door is OPEN. This eventually leads such people to believe that a "Normally Closed" switch is the best option, since it would be ON when the door is open (based also on how the sensor is mounted). You could, of course, mount the switch such that the magnet and switch are engaged when the door is fully open, but this does not seem to suit most' ideas about what is the definition of a closed (fully?) or open (full, partial?) door. Unfortunately, this is not the type of switch that comes with the garage kit. If you are not using the relay in any particular scene, I don't think the type of magnetic switch matters much at all. Certainly, the ISY works just fine with either.

Assuming that I understand your intentions, I suppose you could try something like: if status bath entry is On and status fan is off and control sensor is on then run next program (then path) Next program (disabled): if nothing then set fan on wait 15 minutes set fan off If you want to define a time other than 15 minutes to wait for the next fan trigger, a few other steps may be needed.

Most likely it is the condition "And 'Outside / Outside Lights' Status is Off" That is retriggering the first program. Despite common usage, I dont believe it serves much purpose in most cases and I would remove it. Unless you want an excuse to play around with variables, none are required here and, in my estimation, simply add complesity.

To larryllix' accurate observations, I add: - get rid of first condition (Status 'Back porch motion-Sensor' is Off) from second program. If the motion sensor fires, you want this program to run, regardless. Neither do you want this program to trigger itself at each change of status. -get rid of third condition from second program. The first program is already constrained by this time period, and will only call it between those times. Neither do you want this program to trigger itself at sunset and sunrise. Also, in this case, there is no value to using a variable here. Instead, you can simply call the second program from the first, at the correct moment.