oberkc

Mu suggestions were very general in nature. If you decide to adopt the approach, and later find a specific detail to be unclear, feel free to post more specific questions. If this is a real concern, perhaps there are options to mitigate this risk. One that comes to mind is to send yourself an EMail notification anytime this button is pressed. Another might be to locate a keypad switch in some out-of-the-way location, perhaps even in a desktop enclosure under the bed. You could even use one of the android or ipod/pad apps to make access a bit more convenient.

How I (and, I dare say, most) do this is to use a Keypad button as the designation for home or vacation modes. Your first decision is how you want to designate the vacation mode. Assuming you want to use some type of insteon switch (on=vacation, off=home), you can approach this a couple of ways. One would be to create two program folders. One folder would have the condition: if status 'vacation switch' is on then run the programs in this folder The other would be: if status 'vacation switch' is off then run the programs in this folder In each folder you would place the programs you want to run when away (switch on) and home (switch off), respectively. Alternatively, you could simply place a condition in each program who's execution you want to be based on the condition of the vacation switch. The condition would be identical to those above.

While not stated, do you not want your lights to turn off at sunrise? If so, try: If From Sunset To Sunrise (next day) Then Set 'Front Porch Lights' 50% Else Set 'Front Porch Lights' off

I will start it off (conceptual approach only): if status "sensor" is off then wait 5 minutes send notification to .... else This will send an EMail notification to your account of choice.

here is the link to the wiki instructions: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Garage_Door_Kit This assumes you want the KPL button illuminated if the door is open, and off if the door is closed. The keypad button must be in non-toggle "ON" (not "off"). I have not found this to be an inherent problem with the wiki approach (barring communication errors), but perhaps there is this possibility out there lurking that I have just not experienced. Maybe this could happen if the door was open a couple of inches, and you press the button, and the sensor sends an "off" signal while the keypad button is flashing? Who knows? With this approach, the only way a keypad button can be "off" (door closed) is for the sensor to have commanded it to be so. Given this, there is high confidence in the "off" status, with any ambiguity only possible with a lit button.

Your speed and reliability issues instantly make me wonder if you are having a communication problem across your powerlines. Do you have: -surge suppressors? -ups? Is your ISY/PLM plugged into, or nearby, any of the above devices? Do you use any access points or other dual band devices to communicate between legs of your electrical system. As leeG suggested, programs will necessarily be slower than direct commands, but the time frames you describe, along with the lack of reliability, makes me suspect you have other issues.

You may (a good idea, in my mind) perform a factory reset prior to adding to the ISY-99. The instructions for this, from the wiki: Resetting KeypadLinc to Its Factory Default Settings "The factory reset procedure can be used to clear the KeypadLinc memory and restore its factory default settings. This procedure will clear the unit of all INSTEON Links, and any programmed X10 addresses. 1.Before resetting a KeypadLinc that has been Linked to an INSTEON Controller, be sure to Unlink it from the Controller first. See Unlinking KeypadLinc from an INSTEON Controller. 2.If you are using KeypadLinc to control any INSTEON devices, Unlink those devices from KeypadLinc. See Unlinking a Controlled INSTEON Device from KeypadLinc. 3.Gently pull the Set button at the bottom of the keypad out as far as it will go (about 1/8"). This "air gap" removes all power to KeypadLinc. The KeypadLinc LEDs and the load will turn off 4.Wait 10 seconds, and then push the Set button all the way down until it beeps (3 seconds) and release A few seconds after you release the Set button, KeypadLinc will double-beep and its LED will turn on solid If KeypadLinc is a dimmer model, it will turn on its load Factory reset is now complete. KeypadLinc has been reset to all the factory default settings and is ready for fresh programming and use." After this, you can add the device to the ISY-99. Put the ISY into linking mode, then do so for the KPL. For the KPL, I did this by pressing and holding the ON button. I believe that this is consistent with the instructions, also. Once linked, expect the ISY to recognize the device and add all the buttons to your "my lighting" tree. Since you are using the laptop on your LAN, you should expect the same results as your desktop. I do this regularly. If you are outside your LAN (WAN), you can also enable internet access on the ISY and perform system programming anywhere else you have internet access with your laptop. Folders are a relatively recent addition. I have lost track of when this came in, but I would not be surprised if it was an update that was not compatible with the ISY-26. I like the folder option. If someone does not come along to confirm, you can check out the thread on latest software and look at the history of each version.

UPB models???!!! I see no such device on your web page?!

I believe that there is a device called the "vehicle interface" that recieves commands from the vehicle and converts them to X-10. You could use this to trigger commands from the ISY-99. Unfortunately, I have no direct experience with this to offer. The only place I recall seeing this vehicle interface is from the homelink web page. It seems to me that they don't emphasise this product, and you may have to call them to find out more about it. Hopefully, they still make it.

This sounds like a conflicting requirement to me. Do you want them on indefinitely or do you want them to turn off 10 minutes after sensing motion?

I will have to take your word on that, since I dont know the current conditions. But I agree with you...I don't believe placement of this condition should make any difference to the total condition status results. It sounds as if your understanding and mine are the same. I wonder, however, if the problem is not the evaluation results, but whether or not the program condition is evaluated. Have you always forced an evaluation, by manually choosing "run if"? Is it possible that the condition would evaluate as you and I both expect, but that there is, simply, nothing triggering an evaluation? Another thing that I notice is that your "then" or "else" statement change one or more of your input conditions. Is it possible that running the program causes a change in the conditions which change the status? As an experiment to test this hypothosis, you could temporarily remove the "then" and "else" statements and see if this changes anything.

I am not following this statement. It appears that there are also differences regarding the placement and inclusion of "$sAlarmSys_Z26_MasterBed_Door" (first program does not include). I think you have more things going on here than just the placement of "$sAlarmSys_Z31_LaudryRm_Door". Which was the newly added sensor? I am curious as to what combinations of device true/false that are yielding program results different than what you are expecting? I tend to agree, however, that the second an third programs should behave equally.

I was not sure that restoration of power after a loss would trigger a program evaluation and program execution. If so, what would happen to the OP sample program if power failure happened at, as an example, 0400, well after it runs the first time. Would it run again? I am not sure that I experience enough power failures to be able to say with any degree of certainty how my programs react, but I do not recall any cases where they ever got off schedule. Perhaps I have gotten lucky and not had power loss during any critical program times. Perhaps a definitive answer will come from those with direct knowledge.

So...you think the original program would be more likely run at 0100 after a 59 minute power interruption? I would not expect this to happen, but you may be correct. I thought that if you chose the system option to get programs caught up after power failure, it would run this program regardless of the duration of the power failure. I had forgotten (or failed to notice) the missed schedule grace period.

I don't believe one can simply "strike" lines in the ISY code. The first two lines in your "if" statement are part of a single time condition that can, however, be changed to a different time condition. Rather than using the "from/to" time condition, simply use the "time is" condition. I, too, believe this would be a better solution: If Time is 12:01:00AM And Status 'Master BR KP / Irr Hold.MBK' is not On And Module 'Climate' Irrigation Requirement >= 0.50 then .....

I do two things when I loose internet connectivity. First, from the admin panel, I believe one can find the address under help>>about. Failing this, I disable internet access, then re enable internet access. It will give me the address for internet access.

I looked at the wiki: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Linking_an_I/O_Linc and you are correct. It only has the option to set momentary "A", based upon the condition the IOLinc was in when it was "linked". Unfortunately, I believe dsegneri has tried linking while on AND off, without any visible change in behavior. This is contrary to what I would expect from the wiki. Perhaps I am not understanding the issue here... I understand that the IOLinc relay cannot be a controller in a scene, only the sensor. This suggests that the "button" must be the controller in this scene. This is suggesting that the relay is, somehow, driving the switch (which I think is not possible...only sensors can be controllers). Maybe there IS a sensor in this equation somehow (perhaps in reference to wiring the contacts backwards). If there IS a sensor, and it is the sensor that is the controller of the scene, then I am thinking that the "trigger reverse" option in the IOLinc configuration could be the solution. I also remember something in the wiki garage door kit example about problems during power failure: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Garage_Door_Kit I believe the proposed example was to wire the sensor differently than shown in the directions. But then, I think this wiki article was based on a version of the ISY software that is pretty old by today's standards, and may not apply. Regardless, perhaps there is something here that can help dsegneri.

If you are programming through the ISY, have you tried changing these settings. If I recall correctly, you can select the device (IOLinc) at the device tree, and along the bottom is an button where you can view and edit the options. This includes the option for response to "on" commands, latching, momentary, etc.... I don't think the status of the IOLinc device, at the time of adding to the ISY, matters at all.

It sounds, then, that you understand things well enough to make a decision about which way you want to go. Good luck.

OK. I will take your word for that. Should I dare suggest that is not the insteon definition of a scene being on and run the risk of being called silly again? If you choose to use the programming logic of the ISY, it could address the logic to turn the keypad on. To do so, however, the keypad button in our example would not be part of the defined scene. However, if you define an insteon scene as including the keypad button, then you are relying on the inherent insteon capability of the devices rather than the logic of a program. I don't know about whether this is silly. I will leave that to your expert judgement. I am just a simple user of an insteon system. Yes, indeed, a scene can be defined three different ways. The ISY-99 creates such scenes. Perhaps the ISY-99 use of the term "scene" is sometimes a combination of pure insteon "scenes". Regardless, in my mind, this makes establishment of relationships between devices a bit easier to accomplish. Where you have three "scenes", the ISY-99 construct has one. It works for me. Apparently, this is not your preference. I actually find the ISY-99 model of a scene works pretty well. Perhaps the trade-off is that the definition of scene "status" becomes a bit more difficult to define. Design, as in life, is about tradeoffs. Apparently, powerhome has made different design choices.

Suppose one has a scene with a controller keypad button and two responder dimmer switches. Suppose the "on" levels for each responder is set at 50%. Suppose, then that each individual dimmer was manually set to 50%. The keypad controller would not be on. Is the scene on? That is all that it means. Suppose one has a scene with three devices, all controllers and responders. Each scene is defined differently, depending on which controller is used to activate it. When is this scene on? This topic has been discussed before, and I don't believe the omission of scene status is due to a failure to consider it. Certainly, it can get complicated pretty quickly.

I suppose the answer to that would also depend on whether there are any controllers of the scene, such as a keypad button. In the end, the answer really doesn't matter. I don't believe the ISY has what you are looking for. Good luck with whatever option you choose.

My understanding with regards to scene status is best shown by rhetorical question. If one has a hypothetical scene with two dimmer devices, each with scene "on" levels defined as 50%, is a scene on or off if both devices are currently operating at 60%? While I am sure there are logical ways to respond to questions such as this, I agree with apostolakisl: the ISY-99 does not monitor scene status. I continue to believe that you will find the ISY-99 to be lacking in this "intelligence" that you seek.

The ISY-99 is based on if/then/else programs, with conditions consisting of device status, program status, time, temperature, etc... joined by "or" or "and" conditions. If you can describe your needs using boolean logic, the ISY-99 can do it. Also, insteon sytems with the ISY-99 can take advantage of insteon scenes, so combinations of scenes and programs are typical. Your example sounds like something where you would use a combination of scenes and programs. However, you state that such a construct is "unmanagable" and "ugly". Given this, I cannot think of anything to offer that you would find otherwise.

Good catch. That is exactly the change that I would suggest, as well. Simple is all I can understand.