oberkc

This option (enable internet access) is to enable one to log in to the ISY from a remote location, outside your home network. The types of problems you are experiencing are usually followed by questions about routers and firewall settings. I have tried my best to stay ignorant of such things, so I will not try to fool anyone into thinking I know anything about them.

Easier is in the eye of the beholder, I guess. I am just not percieving any of these changes as so. To me, these are just different ways of achieving the same goal...no easier or harder to understand. Sorry...I am having trouble getting excited about this type of change. People have told me that different opinions are what makes the world interesting. In my mind, too, if you are sufficiently advanced to desire (or even understand the purpose of) separate triggers, you are sufficiently advanced to understanding existing trigger mechanisms. This change is not going to benefit those who have no clue about programming (in my mind, at least). But I enjoy discussions on these topics. I guess we will see if, and how, Universal Devices responds.

I don't disagree with this either, but your proposal for a wholesale change in criteria wording is not (as near as I can tell) part of the proposal to which I was responding.

I must count myself among the skeptical regarding this point. While it appears that this may add some flexibility for the advanced user, and may make the ISY more consistent with other advanced programming languages one may be used to, it does not reduce the level of understanding required. On the contrary, I see this as potentially adding one more thing that can go wrong. Example new thread: One still must understand the concept of triggers and conditions. One must still understand the existing defualt triggers. No....I don't see this forum going out of business any time soon. It is just that the questions will change.

Indeed, it is. I just wanted to make sure you were not laboring under a false pretense.

Given that one can already separately specify triggers and conditions (disable the condition program, write a separate program for triggers), the question seems to me to boil down less about program limitations and more about intuitiveness and user friendliness.

Nice! Now the fun and addiction begins.

I believe you are correct, in that the mutually-exclusive option for those buttons function only when the buttons are activated locally. If you are going to have an ISY program activate the scene, then it would be a simple matter to add a program step to turn off the correct buttons. If you are activating a scene from the ISY admin panel, you could manually turn off the buttons off. In my experience, there is very little reason to control my lighting from the admin panel, except for troubleshooting purposes. Since you have established mutually-exclusive relationships between the three KPL buttons, only one will be on at any given point in time. There should be no reason to write a program to cause this to happen. Based on what I understand from your post, you should be able to handle your needs with one scene, three buttons as controllers, each button having it's own settings, with the three buttons in a mutually exclusive relationship. Am I missing your question?

My understanding is that current versions of most devices support "off" as a viable response to a scene "on" command. Are you suggesting that, when you select button A within the scene definition, "off" is not an option you can choose for the load-controlling device? Yes, a program can do this also, but I did not think it necessary.

This is to offer as much flexibility as possible. The scene level generally refers to the settings when called from the ISY and programs. The device level is the settings when called from that device. This allows multiple scene settings to be set based on the device from which it is controlled. In case you wanted the same scene response from a particular device as you would get when calling from the ISY. Am not sure what is your question here. If you turn a scene on from a program, all responding devices (controllers are also rsponders) that are part of that scene, including KPL buttons, will go to the "on" settings, as defined under the master scene definitions.

That seems very strange to me that these would show different status. I would have assumed that the information displayed would be from the same source. Good. I think, however, I would still remove the offending devices from the ISY, perform a factory reset on the devices, then add them back to the ISY using the automatic method. The version 00 still has me concerned. The automatic detection should give you an accurate version number. Do you not have any access points? Is your PLM a dual-band version? Are any of your other devices dual band? I am wondering if the lack of version number is indicative of failed communication. Yes, this sounds like a viable option, but I think you will find adding the devices back into programs and scenes still easier. Besides the discrepancy in status, is your system (programs, scenes) working as expected?

I am not sure that I understand the difference between "regular page" and "admin console". This definitely concerns me. In devices that are easy to access, I have never seen the value in manual linking. I would do this by "start linking" and autodetect. It will not delete scenes and programs, but it will delete this device within the scenes and programs. You will have to re-add it. The other factor that could come into play is the version of ISY software you are running. I would upgrade to the latest available version if you have not already done so. Sometimes, support for the latest generation of devices is included in these upgrades.

As others have addressed, I assume there is a possibility that the switch is the one directly controlling the load. If so, then it sounds as if you need to take the advice of Sub-Routine. To which I would add.... One other factor that I recall when trying similar things is that older versions required resetting of power before local control settings such as this take hold. I do not remember the cut-off version. Hopefully, yours are newer.

Of course, this is already achievable by disabling programs. The remaining question is whether you believe this would be more "intuitive". I cannot help but wonder if there would be fewer or greater numbers of questions and confusion. My suspicion is that neither (existing or proposed) option is inherently more intuitive than the other.

I am not overly hopeful that this will solve your problem, but it is worth checking. What is often not clear to me is whether hooking an insteon switch into a noisy load would contribute to communication problems, even when the switches are off. Or...does replacing a dumb switch with an insteon switch create new communication problems if that switch controls a noisy load. BTW, what are the loads on the four new switches? How did you add the devices to your ISY (manually or "start linking")? Did you experience any problems (or even apparent delays) with adding these devices to the ISY? I wonder about the possibility that there is a corrupt link database in the device or ISY and what affect that may have on the performance of your existing scene.

I have always accepted that there is a trade-off between simplicity/intuitive and flexibility/power. Maybe such a trade is not necessary, but I have always taken it as a a granted. Given this trade, I will take flexibility/power every time. My suspicion is that if you are able to find a way to get both, you will be rich.

My first suggestion is to return your house to the pre-new-device status (in your case, pull the power tab from your new switches) and see if this restores proper operation of the welcome home scene. To confirm (or eliminate) a couple of other possibilities, did you add any new lights to your house, or change the type of lamps (CFL, LED) in any of these fixtures? For example, do your new devices control a low voltage fixture or CFL? Did you change the bulbs in any of the fixtures that are part of your welcome home scene? Have you recently added any electronic devices to your house? This could be coincidental to the addition of your new insteon devices.

If you are asking whether lights can be turned on with one program and off with a second, I believe the answer is a confident "YES".

apostalakisl, dnl, don't get too hung up an this particular program example to conclude there is no value in this particular control condition. I created this program just to verify a theory. There is no practical application intended. But both of your conclusions are the same as mine, however: this particular sets of conditions has a pretty limited appeal. Consider, however, something such as: time is from sunrise to sunset (next day) or control 'xxx' is not switched On This simple change in conditions give a much broader set of possibilities. I think the possibilities are limited only by our imagination.

I may not get it, either, but here is how I see it regarding the sample program. Firstly, I believe that this program will be evaluated ONLY as a result of two triggers. One trigger is time=7:44pm. The other trigger is any receipt of an "on" signal from the switch "exterior sconse". Secondly, one must look at the results of the evaluation, once they are triggered. An "on" command from the switch would yield a "false" condition, but given the nature of "controls", that condition would be only momentary (at the time of command receipt). If the control condition were evaluated at a time other than upon receipt of the "on" command, the condition would be evaluated as "true". The time condition would yield a true result only if evaluated at exactly 7:44. So....at 7:44pm an evaluation was triggered. Time condition was true. Control condition was also true (because there was NO simultaneous receipt of an on command from the switch). Both conditions were true: program was true. The triggers forcing evaluation would be unchanged. However, the results of the evaluation would require only one of the two conditions to be true for the program to be true, rather than both. I originally believed the same thing about an IPad, but once available, I came up with some uses. I continue to be amazed at the creativity of the folks around here. While I don't currently use it and cannot immediately think of a use, I am not ready to conclude that there is absolutely no use for it.

I do know my way works. Yes, of that I am sure. For what it is worth, in support of another thread I ran a quick experiment with the following program: At 7:44, the status of this program changed from false to true. It remained so until I switched the sconse on, at which point it went false. This tends to support the theory that time-based conditions themselves only trigger an evaluation at the specified time. This is consistent with my understanding and tends to support the GregE's apparent suspicion that this particular example can be accomplished as a single program. It sounds as if GregE has the same personality as me....deriving some irrational pleasure in minimizing lines of code. I think, however, it may be good general practice to break them into two programs, just in case of something we were not smart enough to foresee. That is, unless we specifically want to take advantage of the ISY ability to halt programs midstream (such as certain motion sensor programs).

Hi dnl, I just created a sample program: If Control 'Basement/Garage / SW GRS Garage Exterior Sconse' is not switched On And Time is 7:44:00PM Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') When the ISY clock went to 7:44, the program status changed from false to true. I expect it to remain true indefinitely, unless the switch is turned on manually, at which point it will stay false until 7:44:00pm the next day. BTW: this is consistent with my single test point....I turned the switch on and the program reverted to false. If I remember to check tomorrow, I will see if the program turns true at 7:44p.

But, I thought that the time condition, in this case, would only evaluate once per day (at sunset). I see no other trigger condition forcing an evaluation that could result in a false condition, halting the program. (You are not suggesting that the "wait" statement, itself, triggers an evaluation, are you?) I expect this program to be "true" indefinitely...and that a single program would work here.

The response from Chris made me think differently. The expression WOULD evaluate as "true" IF it were evaluated. However, in this case, the only trigger that would force an evaluation (apart from additional conditions in the "if" statement) would be receipt of an "on" command, at which point it would evaluate as false. I think this is the case of differentiating between what causes an evaluation versus the results of an evaluation. Statements such as this are probably most useful in conjunction with other conditions, or if you want an "on" command to trigger an "else" statement. For example, I would expect the following statement to trigger an evaluation at 0900 and the evaluation to yield a "true" result: if time is 0900 am and control "XXX" is not switched on Consider the opposite.... if control "XXX" is switched on By the same thought process, this one never evaluates as "false".

So, is this statement always evaluated as "true" except at the instance when "On" is received. Is the implication also that the trigger for evaluation of this statement is still just an "On" command from the device (off, dim, bright, xx% will NOT necesarily trigger an evaluation)?