oberkc

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.

Very likely, yes. May be triggering fine, though, but always evaluating false.

The only thing I see funny is the "same day" condiition for sunrise. Perhap you should try sunrise on the "next day"?

As I go back and re-look at all this hue stuff I am reminded, too, that it would be valuable to assign one's hue hub with a static address. (I assume most would do this through the router.) The static address would help ensure things keep working after power failures or other reboots.

Well. OK, then... here is my network resource to turn ON a hue light.

Is the only way to add pictures being via URL? Can one not simply past a jpg-type file directly? I would past a couple of shots of my resources, but am not feeling overly ambitious enough to load them to some file sharing site.

Yes. Double check everything. Missing commas, extra spaces. Computers are not tolerant of anything outside of the expected.

"You must have put them there." It has been long enough ago that I would have to refresh my memory of the details, but I assume it is the login credentials for the hue hub, or something like that. Once it worked, I stopped caring.

When I compare my hue resources to Larryllix' screenshots, I see a long string of characters (that hold no meaning for me) in place of "ISY994use".