oberkc

Be aware, also, that what constitutes a "scene" is defined a bit different with the ISY that with the basis insteon devices. If you see "scene" used in the manuals of individual devices, that generally refers to a relationship between two devices. With the ISY, a scene can have practically unlimited number of devices. Are you suggesting that you have manually linked insteon devices without using the ISY...by putting one device into linking mode, and adding the responder manually. I generally find this a bad idea when one has an ISY in their system.

Perhaps, more importantly, do you know WHY this solved your problem? Understanding the difference between control and status is a key concept.

Xathros is correct, and I could have misunderstood your intentions. If you plan to initiate light levels at certain times, then I stand by my original assessment. If, however, your intention is to change the levels that your lights turn on in response to a local button press, then there would be a noticeable delay if using separate scenes and programs.

All my outdoor flood lights are LED. I have noticed no problems, though I make no attempt to dim them.

EricK beat me to it, but his is the approach I suggest, as well. Set up two scenes and invoke the proper scene based upon time.

This is all very doable. However, I am not sure what this has to do with a camera.

It also depends on what you mean by "integrate with insteon". What insteon function do you desire a camera to possess?

When you say that one is working locally but the other is not, are you saying that you the switch fails to respond to the button presses? If so, I tend to think wiring problems or failed device. Does the LED light stay on constantly, or does it ever go off? Which switch powers a fixture, if any? My first instinct is to check to make sure that I have the line (black) connected to the constant hot supply, and not the load (red).

I am in no position to check right now, but I thought the repeat could be defined for X number of times. Combined with a one-hour wait would , in my mind, accomplish your goals.

And that is the only reason I can think to have such a condition. Balance that with the possibility of comm error such that the ISY may believe a light to be on when not, causing a light not to turn on when I motion is sensed. I would prefer having higher confidence that the light goes on, rather than avoiding what (at least for me) would be inconsequential comm traffic. Still, it sounds as if your understanding of how things work is good.

Since you want to limit response to motion sensor between specific TIMES, this tends to suggest a program. Furthermore, I don't believe a Dakota Alert sensor, itself, can be set to respond only during certain conditions, which also re-enforces the idea of using a program rather than a scene. Bernman's example from his earlier post is probably more complicated than what you need, but there are some good ideas and concepts there. Because I don't own a Daokot Alert (not sure of the exact syntax), because I am unfamiliar with your current lighting devices and scenes, and because I think it is good to experiment around a bit, I will offer only a conceptual program as a suggestion: if control Dakota alert is set on and time is from sunset to sunrise (NEXT DAY) then turn on floodlights wait 5 minutes turn off floodlights else turn off floodlights This approach makes certain assumptions about what you want to happen if the Dakota alert is triggered when the lights are already on, and what you want to happen to the lights at dawn (regardless of any countdown in progress), but I suspect you will find it pretty close to what you want.

Program "porch light off" will shut off scene at midnight and sunrise+30. This seems straightforward and as you say you want. Program "Porch light on" will turn on scene at sunset and 0400. This seems straightforward and as you say you want. Program "Porch motion on" can, perhaps, be simplified, depending on your goals (and assumes 'Porch Light Switch Front Door' is part of scene 'Porch Light 3-Way'). What happens if you delete the second condition? What is your purpose for this second condition? Otherwise, I see nothing obviously wrong.

The only way that I can think would be to add the devices to the ISY, choosing: "add devices found in links and keep existing links" Still, I expect this to be problematic, in that it might try to add the smartlinc. Your best bet might be to factory reset the devices and recreate the scenes.

I think you are correct. It would work like you describe. I did not look close enough earlier, I guess.

I was unclear....I would probably include short wait periods for each keystroke, reverting back to the beginning if not executed on time.

My response would have been similar to KMan, but I would have included provisions for the sequence to time-out after a certain period. If that intersts you, and if you care to respond to my initial questions, I would be happy to offer a suggested set of commands.

No, I dont find this overly difficult. One must, however, pay attention to things beyond ISY programs, to include the relationships to sceces and configuration of the motion sensor. Your panic exit, however, seems a bit more complicated. I suspect this will take a combination of several programs. The use of a variable may be the most viable approach. In what status do you expect master.light c to be after panic is initiated? How long do you want to wait between the individual toggles of button c before failing to recognize the sequence?

When was the last time the program ran, according to the log? Was it more than a day ago? Do you see any mismatches between light status as shown by the ISY and actual light status? In my experience, programs fire when conditions are met. Sometimes, the ISY can miss certain conditions if there is comm problems present. Somethimes, a program can run but comm problems prevent devices reacting. If this were me, I would be looking for clues to narrow down the cause to one of these possibilities. Without seeing the program in question, I would be unable to even speculate on possible programmatic issues, but feel free to post if you want second opinions on this possibility.

I think I would create a new party scene also, with the proper levels predefined.

How confident are you that the switches are wired properly? In three way white cannot be counted on to be a neutral. Does any switche loose power when another is toggled? If wiring is good, add all switches (for a given fixture) to a scene, all as controllers.

Not that I have seen

From a program, one may initiate another program. There are three parts of a program: if, then, else. When one invokes a second program from the first, one must specify which, of the three parts, is being invoked. In this, case I proposed invoking the "then path". In this case, in the second program, notice that there are NO commands in the IF or ELSE paths...only in the THEN path. I am always unsure of how familiar people are with programming the ISY, so I don't take a lot of time in early responses worrying about exact phrases. Beware, my proposed program wording is VERY approximate. The ISY will create the proper syntax for you. You must simply select the commands from various drop-down boxes. I takes a little practice, but you will get good at it soon enough.

I suspect you may need to refine your requirements a bit. Let me see if I can restate: a) you want a notification when motion is sensed. after any notification you want a 15 minute wait period before any subsequent notifications, regardless of whether motion is sensed. c) Once a 15 minute wait is over, you would like notifications to be enabled again. without thinking too hard, my initial temptation would be to break this into two programs program 1: if motion is sensed (in your case, if X-10 command is recieved) and if program 2 is false then send notification run program 2 (then path) else nothing program 2: if nothing then wait 15 minutes run program 2 (else path) else nothing see if something like this works for you. Let me know if you have questions about any of the concepts behind this approach.

When you press C or D, this sounds as if it is what you expected. Unfortunately, I missed where you stated your expectations with regards to whether the button stays on or off. Did you want the button to turn off after flashing a few times? When you press E or F, I also am failing to see your stated expectations with regards to whether the button stays on or off. Do you expect it to go off? I am drawing a blank on "SLD". Sorry. While I find mutually exclusive relationships to have a place in this world, I am not sure that you need to have a mutually exclusive relationship AND the scenes you describe with responders set to zero. In a mutually-exclusive relationship, pressing one button would cause that button to come on and the others to go off. The behavior you desire sounds to me like a button in "non-toggle off" mode. IN this mode, pressing the button always transmits an OFF command, causes the button to blink, then the button to turn off. Unfortunately, any scene responders linked to that button would all turn off as well (since the button is sending the OFF command). I see a couple of options. In both options, you should eliminate the mutually exclusive relationships. One option would be to put all buttons C-F in a non-toggle OFF mode, resulting the the blinking and condition behavior you want. Buttons C-D would NOT be scene controllers (since you cannot turn ON a scene by sending an OFF command). Instead, use a program to turn on the scene containing the affected devices triggered by the button OFF command. The second option would be to leave the scenes as they are, put buttons C and D in non-toggle ON configuration, but add a program to turn off thees two buttons after a few seconds, in response to an ON command from the buttons. Hopefully, you can see the concepts and fill in whatever gaps I have left.

The ISY itself has no insteon RF capability. Some PLMs at dual band, but I cannot imagine why their range would be any better than the hub. I understand theoretically that ISY devices can communicate with each other via commands through the network module, but this is something that I have never attempted.