
oberkc
Members-
Posts
5857 -
Joined
-
Last visited
Everything posted by oberkc
-
I am with LeeG on this. I don't believe it is a programming issue. Look for link issues or communication issues or faulty devices. While in event viewer level three, turn your various devices on or off and see that you are getting these signals (you will see an event in the viewer). Also, from the admin panel, check the status of each of the devices to see if they are consistent with real world conditions. Additionally, try to control each of the three devices from the ISY. The point of this is to determine that you have good communication between the three devices in your progam, and the PLM. Look for evidence of errors or devices not responding or inconsistencies between the PLM status and device.
-
I suspect brad77 is correct about his observations about the triggerlinc. I have not used one, so I have no comment about that. I suggest avoiding this approach for different reasons. First, the wired sensor is not that hard to install. It is no more difficult than stapling a garage door button wire along the ceiling, which you have probably done. It probably takes less time than replacing a battery in a triggerlinc a few times. Second, the wired sensor can be placed high, also. Mine is near the top of the door. It works well. Third, the IOLinc has several modes, based upon sensor input. If you don't have a sensor, you may be limiting your options for garage door control. My suggestion is to go with the wired sensor that is part of the garage door kit.
-
This is my program, and it works great. Besides "or" versus "and", it is very similar to yours and the one I suggested earlier. My scene "bedroom control' has no device in it, other than the KPL button. The "if" condition is unaffected by execution of the "then" or "else" statements. I am looking forward to your response regarding the device content of your scene: "family-led"
-
I have a program that does this. I did not recall it being overly complicated. When I get the chance later today, I will post it. The only difference is that I have my KPL button on if at least one (as opposed to all) of the related devices is on. But wait....something just occured to me. (I should have asked this originally.) I am starting to think that the response (then or else) is affecting the conditions (if). Does the scene "family LED" include any of the devices in the "if" condition? That is, does this scene include any of: Family - front, family - main, or family - rear? If the scene includes these, then this could be forcing a re-evaluation of the conditions, restarting execution of the program.
-
Is it possible that the front switch is set as a controller in your scene "family-LED"? Make sure that the only controller is the keypad button. Those programs, by themselves, look reasonable to me. I wonder, however, if the two, together, are fighting each other. Instead of two, why don't you try one: If Status 'Family - Front' is not Off And Status 'Family - Main' is not Off And Status 'Family - Rear' is not Off Then Wait 3 seconds Set Scene 'Family - LED' On Else Wait 3 seconds Set Scene 'Family - LED' Off
-
Basic questions on motion sensor for night time use only
oberkc replied to theedudenator's topic in ISY994
If downstairs is already on, turning it on again will not hurt anything. No. For the same reason. Having said that, you did not specify if your intentions were also to turn them off after a certain period of time after sense of motion. If so, then there may be benefits to including one of those conditions in your program. Also, if someone has made a manual adjustment to the scene (dimmed, bright, etc...) then turning the scene "back on" will cause it to resort to the devault settings. This may or may not be a factor in your case. -
Wow. You don't ask an easy question. Are you prepared to reset and reprogram devices? How many devices are we talking about? Do you have any plug-in modules? Do you know what access points are and do you have any? How old do you believe is this installation? Do you have any whole-house controller of any type?
-
Does the PLM have a factory reset function? If so, how about: 1) remove PLM from ISY 2) factory reset PLM 3) restore PLM on ISY
-
This is what I have now for the sunset/sunrise but it is not working for some reason. It comes on during the day. This looks correct to me. I expect this to work, also (although it is unclear to me how these lights turn off. Is the motion sensor part of your 'backyard lighting' scene?) Have you checked the time on your ISY? Is it possible that the system settings got messed up? I am a little concerned that your manual backyard enable program includes actions in the "else" section that may trigger a re-evaluation of your program conditions. This violates one of my personal general programming rules for the ISY. As for the motion control program, is this constrained by sunset or sunrise anywhere? Is this program enabled along with your sunset/sunrise program, above?
-
Don't hesitate to post back. Also, check the universal devices wiki. There is an excellent example there. Perform a search on garage, and IOLinc. You will find explanations about many of your questions.
-
Be advised that most on this forum are Users with no affilitation with Insteon (Smarthome). A few are from Universal devices. As advised by LeeG, I believe that this can be done. However, I question if this what you really want. It sounds as if you are using a keypad to control your garage door. Is this true? If so, do you want your keypad to display status of the garage door?If not, how do you know the status of the door? What if the garage door is stopped mid-way or moving? How do you want the door to respond to commands? If mid-way, this will only respond to one command, depending on how you wire and position your sensor. If your original aspirations ("on" opens when closed, "off" closes when open) then my experience is consistent with LeeG. Create a scene with the relay as responder and your controlling device (whatever insteon device you desire to use to send on and off commands) as controller. Set the relay to momentary "C" mode. Keep in mind, also, that the sensor can be wired such that a garage door closed would give either "on" or "off" status. Additionally, there is no way to distinguish between a door being fully open or partially open.
-
I am impressed by your ambition. How does your site differ, in purpose, from the wiki?
-
I use programs to turn off scenes (including those with controller devices) all the time, without issues that I know about. In fact, I thought the response to scene commands was more robust than the response to individual devices. Like Sub-routine and gviliunas, I am having trouble understanding why you think this is a bad idea. Consider me to have spoken up. I believe this is not correct.
-
I think I would, then, perform an experiment. Remove one of your devices from the ISY. Re-add it, this time by automatically creating the link (choose the "start linking" button). Then see if you can get status. I'll bet that you can. My theory is based upon the possibility that the ISY does not accurately recognize the device sometimes when added manually. Furthermore, this can result in query and status problems. While I am not completely confident of this, it seems a simple enough experiment to try.
-
Added KPL and the buttons are not in a subtree, why?
oberkc replied to apostolakisl's topic in ISY994
I think I noticed this change in one of the recent updates. I recall, also, the option to expand (mouse click?) the primary button to show the links. -
I am by no means an expert on this, but I think it possible that the remotelinc shows OK because it cannot respond to queries as can the other devices. I suspect the query of a remotelinc to be much more limited. When you added your devices, did you do it manually (type the address) or automatically (start linking)?
-
I tend to agree that an accurate progress bar would be nice. However, I have also used the event viewer to get a sense of communication issues. Set it to level 3 and one can see if there are hangups. While not the most elegant, it is a functional solution for those of us who like to keep track of such things.
-
I guess we will all see what Chris confirms, but I can tell you that the wait statements in my programs resume at the next step in the program following the wait, not the beginning. If this were not true, programs such as: set light on wait 2 minutes set light off would never work. My programs are not re-evaluated, either. If this were done, several of my programs would never finish. I understood Chris to say that a program will only stop execution if something happens that affect the "if" conditions. This is consistent with my experience.
-
This is how I understood it. This is different, however, than saying that the "wait" statement itself causes a re-evaluation. While the syntax and programming structure may be unlike what one is used to, I remain unconvinced that this makes it wrong. In the case re-evaluation during program execution, I might even argue that this can offer advantages in certain situations (think motion sensors). Furthermore, there are ways to avoid the stopping-of-execution-in-the-middle-of wait-statements. Learning the ISY is like learning any other computer skill....computers, cell phones, calculators, Sony Dash, It takes a little time to be able to fully explit the available capability, but becomes pretty intuitive once learned. At least, that is how I find it. Maybe I am just weird.
-
I did not believe that the wait statement actually caused a re-evaluation. Rather, I understood that a re-evaluation COULD occur during a wait state, at which point, a program would be either halted or restarted.
-
Perhaps it would be better stated "ESPECIALLY for people like me..." I often wonder if it is easier for those of us without expectations or experience regarding how it should work and the ability to recognize that it is somehow different than other programming languages that I may know.