Everything posted by oberkc
-
competing commands
Yes, good point. I missed that. So your program, as is, with the shutoff program at 6:31, will simply leave the lights on for 1/2 hour at most. No big deal.
-
Using keypadlinc 5 (prob got the name wrong)
I believe scenes are more than the "preferred" approach to controlling secondary buttons. I believe secondary buttons respond ONLY to scene commands. If you want to change the status of a keypad through mobilinc, or a program, or the admin panel, I believe you MUST use a scene. Regarding a program to activate only after a combination of buttons is pressed, I am near certain that is within the abilities of an ISY. Consider button combination B-A-C. Consider making the buttons non-toggle off, and adding programs such as: If Control keypad button B is off then wait 3 seconds run this program (else path) else nothing If Control keypad button A is off and first program is true then wait 3 seconds run this program (else path) else nothing if control keypad button C is off and second program is true then arm/disarm This example is a quick idea, but could be made more robust and secure with the addition of other conditions, timers, whatever. This was just a quick idea to get your mind rolling.
-
Motion Sensor with light
What is the configuration of your motion sensor. Is it possible it is not sending ON commands before the 3 minute timer? The program, to me looks fine. Yes you need jumpers set in a specific way. Instructions will describe purpose of each. Check out jumper 5...I believe this allows software control, allowing ISY to set parameters. Once enabled, make sure you sensor is in occupancy mode (triggering ON command at every sensed motion, no time-out periods.) Another possibility...is the light and sensor part of a scene together?
-
Using keypadlinc 5 (prob got the name wrong)
If I can assume you have found a way to reliably define and know phone "status" (are you using a variable?), the logic is pretty much as you have it: If Status keypad A is on <<<are you using status or control? And status keypad B is on And status phone is 0 And status phone2 is 0 Then Do something The obvious things to look for....are you using congrol or status as a program condition? What are you telling it to do in the THEN path? Is the ISY SEEING THE status changes correctly? The logic is near bulletproof. Yes you can control buttons remotely. You may need to create a scene, add the button as the sole device in the scene, then control the scene remotely.
-
Method to Reset/Update Keypad Button LEDs to Correct Status
If all you want is to ensure that controllers for kitchen scene come on when you press dinner scene, then including as responder to dinner scene is likely best option. If, in retrospect, your interests are broader and you want the kitchen scene controller button to come on when any individual light within the kitchen scene is on for any reason, I would tend to favor the programmatic approach described by erick. As with many cases, it all depends on what you are trying to achieve.
-
competing commands
Yes. I noticed that you did no have any automatic light shutoff when triggered on weekday mornings. Rather than adding a new program, why not simply put a 5 minute timer in the morning ramp up program?
-
Using keypadlinc 5 (prob got the name wrong)
1. Almost a certainty. 2. Yes. To offer more specific advice, you may need to describe what combinations of the four buttons drive which programs. For example -If button A and B are on, and C and D are off, then run program X. -If button C is on, regardless of state of other buttons, run program Y only. At risk of embarrassing myself, I believe that there are 16 combinations that can be made from those four keypad buttons. If one is not careful here, it will be easy to create conditions where more than one program might fire. Is this acceptable?
-
Method to Reset/Update Keypad Button LEDs to Correct Status
Are those "other buttons" assigned as responders to "dinner time" (they should be, if you want them to come on in response to dinner time). The fact that one scene turns on lights that are also part of another scene does not automatically cause controllers of the other scene to come on.
-
Need advice on controlling RF devices
I see that there is a universal interface available for the rollertrol blinds. It seems that would interface will with an insteon IOlinc. I see also a usb dongle RF controller available and claims that this can be accessed via a vera controller. Based on my own experience, I assume that this dongle would be available to the ISY through the network module, but may require abilities to communicate via some REST or HTML or other interface with which I have yet to personally use. I don't believe that there is a plug-and-play solution here.
-
Good Programming Practices in ISY
All other things being equal, they violate my KISS principles. Otherwise, nothing.
-
Good Programming Practices in ISY
I am like teken...simple is good. Use scenes when possible. Minimize number of programs. Minimize lines of code. Don't use variables when other options are available. Consolidate programs. Spend some time thinking about what you want to accomplish. Think about unintended consequences. Plan. If your requirement is to turn off the light 2 minutes after motion is detected, dont complain when the light turns off 2 minutes after motion is detected. (..but I turned it on manually!)
-
Programming Away Status with Exit Home Delay
In addition to stusviews points... CONTROL conditions also trigger only upon receipt of anticipated command. "Control On" will trigger only upon receipt of an ON command. Thus, when such is the sole condition for a program, it can never run false. On the other hand, status conditions will trigger upon ANY change in status and can run true or false by themselves.
-
Programming Away Status with Exit Home Delay
Perhaps the question is whether the programs are ever DISABLED. My guess is not. Your first program will never run FALSE, unfortunately. Perhaps if you change CONTROL to STATUS, you may have better luck. In the end, I think the wait period is happening, but the programs were never disabled, so waiting a period of time to enable a program that is already enabled will appear to have no effect. It is easy enough to check. In the program status, do you see any of these programs being disabled?
-
competing commands
Yes. Every time motion is sensed, it will initiate something. In your case, however, the morning program first turns on one light at 40%, then turns a scene ON. So, margies closet light will go to 40% each time motion is sensed. Unfortunately, I don't recall whether that closet light is part of the bigger scene, so I don't know if that is a noticable change in ON level for margies closet light.
-
competing commands
Yes, indeed. Disable simply deactivates the self trigger. If another program calls the IF condition, the condition will be evaluated and send it down the next path, based on whether true or false. Other than the lack of a self trigger, a disabled program will behave normally.
-
Poor communication
Sorry. Just responding to one of your comments. I will cease trying to help further.
-
competing commands
Our responses crossed in the mail. I agree, the IF condition in the "anytime" program is a potential problem, especially if the program is not disabled.
-
competing commands
Yes. When a program is "disabled", it does not mean that it will not run when called from another program...only that it will not self-initiate from its own conditions. I did (and do not) want that program to be triggered by it's own conditions. In your set of programs, the ONLY thing that you want to initiate some sort of action is the motion sensors. Everything else should be initiated exclusively from other programs. So...given your programs, I would disable ALL but the first. Furthermore, I don't think you need a condition in "closet anytime on". What I suspect is happening in yours is that some of the ELSE paths are triggering the parent program, halting any WAIT state.
-
Poor communication
??? Just because a secondary service circuit is protected by a 40amp breaker does not mean every device installed within must be capable of withstanding 40amps. What is the service breaker for your house...200amps? 400amps? Are all your electrical devices designed to handle this much current? Very few outlets and switches can handle 40 amps. I suspect most of the individual devices connected to your 40amp leg cannot individually handle 40amps. Is that 40amp service further broken into smaller circuits, protected by smaller breakers? Am I missing something.
-
Strange behaviour with scenes & keypadlinc
I am not sure that I follow the trail here, but scene commands don't propogate beyond the original. If button x is controller for button y, which is controller for button z, pressing button x does not cause scene y or z to initiate. If 'keypad main' is controlling a load that you want to come on, then is MUST be in the scene definition, as responder. Being triggered by buttons A or B will not cause the main scene to come on. That is not the way insteon works. BTW, this is the same reason why directly controlling button A or B from mobilinc will not cause their respective scenes to come on. I remain suspicious of a rogue program somewhere. As suggested earlier, I would watch the program listing and see if any program responds to presses of buttons A or B. If so, review that program content to see if that explains the strange behavior.
-
Strange behaviour with scenes & keypadlinc
Further thoughts... controlling all this from a single scene is an efficient approach, in my mind. You mentioned trying to control these scenes via mobilinc, however. If you want to be able to choose any of the responder level options from mobilinc, you may need to keep this in multiple scenes. The only way to control a scene via mobilinc is through the scene level. Controlling a scene controller via mobilinc will not initiate the scene.
-
Strange behaviour with scenes & keypadlinc
Non toggle DOES work with scenes. I use it in a couple of mine. Unfortunately, you can only define a button in non-toggle mode as always turn on, or always turn off. But...the scene WILL respond. Regarding your new problem, the only thing I can think to do would be check your program log to see if there is some other program that is responding for some reason. The scene definition would not do this.
-
Strange behaviour with scenes & keypadlinc
To follow up with Jimbos comments.... You mentioned you have your buttons in NON-TOGGLE mode. Are they in non-toggle ON, or OFF? In the end, what I assume you want is as Jimbo suggests. Both buttons in both scenes. Button A will be responder only to button B, and button B responder only to button A. On levels will be zero. Button A and B should be set to Non-toggle ON mode. Pressing button A would turn on scene A and turn off button B. Pressing button B will turn ON scene B and turn OFF button B. You will need a third scene to turn OFF everything. Depending on whether you want this button lit or not, it would be set to non-toggle ON, or OFF. You may need to include this button as responder in the scenes A and B. You will also need to include buttons A and B as responder in scene C.
-
competing commands
let me know how it works.
-
Strange behaviour with scenes & keypadlinc
The fact that both buttons, when turning them off, also turn off the scene makes me conclude that they are, in fact, part of the scene. Given this, if turning the buttons ON do not cause the scene to react, and levels are confirmed good, I would start looking at things such as scene settings did not get written to device. Have you tried restoring any of the devices in the scene? Comm errors? Any reason to suspect? Scene commands are not repeated nor acknowledged, so I assume they can be a little less robust than direct commands. Jimbos thoughts were ones I had earlier. This would be a way to set up such that pressing button A would cause button B to extinguish. Depending on the level of control and options you desire from Mobilinc, you could actually do all this via a single scene.