
oberkc
Members-
Posts
5857 -
Joined
-
Last visited
Everything posted by oberkc
-
http://wiki.universal-devices.com/index ... e_Door_Kit
-
You may indeed be looking at this wrong. Why would the lights shut off in two minutes? Is the motion sensor defined as a controller of any scene? If not , what program would turn off you lights in two minutes? I believe Xathros is correct, you lights will not go off, and "control" is a better approach if you want to use a program to control you motion lights. Or follow vyrolen suggestions... Not use a program and use the motion sensor as a scene controller based upon the built in funtion. The benefits of using a program are several. You have greater flexibility over time periods. You can introduce other condiotins, such as time, light status. You can make adjustments without having to open the motion sensor.
-
It would probably be easiest to check your actual program. Until then... Your original question was with regards to using a KPL button as an indicator without mentioning that you wanted to use that same KPL to control a scene. This definitely adds another layer of complication. In retrospect, two programs or one probably makes no difference. Given your latest set of requirements: I would keep the scenes as you have defined. I would then create a program: if control KPL3 is switched off or control KPL4 is switch off then set KPL1 off What you did not state was what, if anything, you want to happen to KPL1 if you separately turn both KPL3 and KPL4 on. You also did not mention how you define "on" with the outlet dimmers. Is this 100%? Do you expect KPL1 to go off when you DIM one or more of the lamps? Do you want KPL1 to go off ONLY when the lamps are full off? Answers to these questions will affect your program(s).
-
This cable is, in my estimation, the switched power to the fixture. Black is power, white is neutral. Good. White and red are, currently, the two travellers to the other three-way switch. Good. As LeeG states, red is hot. It is the unswitched power. I expect that you will find the red wire in the other box connected to the black (common) screw. You are in GREAT shape here. You have unswitched hot. You have a neutral. You know which cable goes to your fixture (cable 1). In this location, remove cable 2 red from the other blacks and cap. Connect cable 2 black to the blacks. Connect black of your new switch to these blacks, as well. Connect cable 2 white to the bundle of whites. Connect switch white to this bundle, as well. Connect switch red to cable 1 black. The only loose cable you should now have is cable 2 red. In the other switch location, you have red, black, and white. White is now neutral. Black is now unswitched hot. Red is nothing...cap it. Cap the red wire from the switch (it is not needed). Connect black to black and white to white. Your wiring is complete. Cross link the two switches. You are done.
-
When you say "Garage configuration has two black wires and one white", is that all!? Please describe entire garage configuration in terms such as: this is a single switch box. there are two cables entering the box. one cable has two conductors, black and white. the second cable has three conductors, black white and red.
-
Program I'm using: If Status OutletLinc Dimmer #1 is OFF OR Status OutletLinc Dimmer #2 is OFF Then Set KPL Button 1 Off. Else It's as if the ISY takes an instant before it recognizes both Outlets are on. I believe the problem is that when you turn on KPL1, the outletlincs respond with a change in status, triggering your program. I find it rarely to be good practice to have a program "then" condition that can trigger an evaluation of the "if" path. Perhaps it would be worth trying breaking that program into two: if: original conditions then run second program "then path" Second program: if then original path
-
The only problem with this approach is that it does not afford the ability to override the motion sensor by manually turning on the light
-
RichTJ99, Assuming garage3 is in scene garage 3-4-5, your program will NOT work as I believe you are expecting. As soon as the "then" path executes, the garage 3 light will come on, triggering a re-evaluation of your conditions, turning false, interrupting the "wait" statement, and running the else path. Furthermore, upon a second detection of motion, if the light is somehow on (even originally triggered by motion), your program will re-evaluate, interrupting the wait, and halting the countdown. It is to avoid problems like that that I suggested breaking this program into smaller pieces. You have several conditions to find a way to evaluate: are the garage lights on? If so, are they on from a manual control, or from an earlier motion detect? Is it 1100pm? Is the timer in progress when it is 1100? Your stated desires is a good little excercise in ISY programming. Make sure you check out the wiki on motion sensor programming. There is (or was the last time I checked) lots of good discussion on how to programmatically handle these decisions.
-
I believe that you need to create a single-device scene, and control the scene from the program.
-
Requires a program If Status light 1 is not off Or status of light is not off Or status...... Then Turn kpl button on Else Turn kpl button off Make this kpl button controller of the scene. Then, when the button is lit as a result of the program and you turn it off, the scene will go off.
-
Of course one can and an "or", or an "and". In the program, create a new conditon. In the condition window, choose "or" or "and". Select "add to "if"". Done.
-
There is a good discussion on motion sensor programs on the wiki. In addition, there are LOTS of threads on the forum on this topic. It is arguably the singlemost programming example brought up, in my estimation. RichTJ99, your program would work fine. Each receipt of an "on" command would halt any "wait" period, and restart the timer. Unfortunately, it did not include checking for the status of the lights. I am thinking we will have to check for three conditions: motion sensor, light status (no such thing as scene status), and program status. If Control 'Garage: Motion5-Sensor' is switched On and ( status 'one of the garage lights' is off (assumes relay on/off only) or status 'light timer program' is true ) Then Send Notification to 'Default' content 'Garage Bay #5 Motion' run 'light timer program' (then path) Else - No Actions - (To add one, press 'Action') I would create a second program "light timer program" if then Set Scene 'Scene: Garage 3 way' On Wait 20 minutes Set Scene 'Scene: Garage 3 way' Off run 'light timer program' (else path) else I would add a third program: if time is 1100pm and 'light timer program' is false then set scene 'scene: garage 3 way' off else I would configure the motion sensor to have a relatively short time-out period. If you give this a try, let me know how it works.
-
My first inclination would be to make sure I had the latest version of ISY software
-
Yes, you may be right. I think I misunderstood.
-
I believe that this fails to meet the requirement of his initially-stated desire to be able to go from 45% to full on when his wife enters the room. I thought we were setting up a scheme where, if the wife enters the room with the 45% scene (and button D) on and presses the main button, the lights go to full bright? Maybe I misunderstand.
-
I don't believe old christmas lights are a problem. They are, I assume, incandescent, which is almost certainly not an issue. More likely it is another cause.
-
I am also intrigued by the fact that every other "ON" command appears to be followed by the log note: "Process Message: Ignored" Is this related to that yet-to-be-discovered unidentified activity?
-
Scene test is an option under tools>diagnostics (from memory...if not exactly correct, it is not too hard to find). The scene test gives one a clue as to the quality of communication between and among the various devices within a given scene, I understand. Like much of insteon troubleshooting techniques, I have not found it to be conclusive, but it does provide useful clues and can act as a common standard by which you may judge your communication environment.
-
Do you have any scenes? Can you perform a scene test?
-
I intend to try it out, someday. I must confess that I fear that I will like it, and compulsively spend the next months-worth of evenings and weekends learning a new hobby. Given one with my lack of experience with HTML and REST and stuff like that, I expect a steep learning curve. You seem to confirm my perception that iRule is king if one is looking for customization and flexibility. I have too many hobbies already.
-
When programs and commands appear to work SOME OF THE TIME, I tend to suspect communications. My experience suggests that computers, programs, PLMs, either work always or not at all. The intermittent part of insteon tends to be the electrical system and communication between devices.
-
The way I understand that this would work is that if the "status" of your two sensors would change during the three-minute wait period, the program would trigger an evaluation, halt execution of the wait period, and start fresh down a new path, based upon results of the evaluation. Wow! I think I just created a 100-word sentence to say "no".
-
Unfortunately, I am not familiar with the REST interface. What I can say with a certain confidence, however, is that if your choice of status is between "scenes" and "variables", you will have to choose variables. There is no such thing as scene status from an ISY, or perhaps insteon, viewpoint. Yes, it would. I assume that it is, but you would have to convince universal devices to do so. I also suspect that this is more complicated than many give credit. How does one define when a scene is on? Any given scene can have multiple "on" levels, based on each controller. Regardless, I think there is a "product feature request" place to put such requests if you are inclined to do so.. I continue to look for that ultimate remote and find myself focused on iRule/android/ipenabledirblaster as a potential solution. While I don't want to hijack your topic, I am definitely interested in your thoughts on this.
-
No I believe you will need a program for this. if status device 1 is on and status of device 2 is on and status of device 3 is on then else You could then use the state of the program (true or false) as indication of scene status. If you prefer, you could create a variable and set it to some value based on "then" or "else" path execution.
-
Yes, a variable could work. Alternatively, one could use one of the scene responders as a surrogate indicator of scene status. This is one of those cases, I believe, where the requirements are not fully examined and will result in unexpected complications. On the other hand, this would be a good excuse to improve one's ISY programming skills.