oberkc

Turning on and off a folder does not sound outside the realm of what can be done now. What device do you wish to use (tablet, cell phone, something else) so you wish to be able to control this virtual device? If you were to describe your intentions, perhaps someone could come up with a solution. Perhaps I just don't understand the meaning of a "virtual device".

I must admit to being curious what it is that you cannot do with existing programming capability.

This sounds like a problem with the keypad, itself. Have you attempted to remove power for 20 seconds or so, then restore? Does the ISY show any device status for the failed buttons? What happens when when you restore the device from the ISY?

The program seems simple enough that I would look for other reasons this is not working. Choose one of these programs from the program listing, right click, run then. Does it send a message? If it does, then look for clues that the ISY is not seeing the status of the devices.

I don't believe a uery will ever yield a false value. Instead, it would result in a comm error and unknown state. On the other hand, it is possible for the ISY-assumed state of a given device to be false hen commands are sent and devices fail to respond. What my be happening with you is that a device status becomes out of sync with reality sometime during the day. The 3am query corrects this condition resulting in the ISY perceiving a status change. Programs triggered by status are, subsequently, triggered causing some of your lights to come on. I don't believe a query alone will cause lights to come on. I also understand you can disable the daily.query without the world coming to an end, it this may increase the possibility that ISY status for any given device mismatches true status. How important this is would be dependent on which devices these are and what programs you have that depend on said status.

The difference with using a pogrm versus scene I based on the desire to have the kpl button indication be off=closed. Using the now-standard sensor, installing the sensor to be in contact when the door is closed would result in a ON indication with the door closed. Using a scene in this case would result in the button being ON=CLOSED. Using the other sensor, installed as before, you have the option to choose (by wiring methods) whwhether ON or OFF= CLOSED.

I have not rechecked, but I recall that there is an option to get caught up with programs and schedules that one can select or deselect. I think it is under the configuration tab. Perhaps yours is selected and you are seeing the result of this?

The solution is likely predicated on what you WANT the lights to do after you incorporate them into the insteon world. Solutions include using a keypad at the existing switch location and use micro modules (or inlinelincs) at each fixture location. If you desire manual control of only one fixture, you could skip the keypad and install a single switch. Make sure you have a neutral at the switch box location that is on the same circuit as the hot that feeds the existing switch.

and... when you set the responder levels, make sure you set these for the scene level AND for the KPL controller button. You have to set these in two places for this to work.

While the button grouping is a viable option, it can start to break down if you control it from the ISY or an app on a mobile device. Groupings only work when the keypad is controlled by direct push of the buttons. It sounds to me like you may have missed a step from the other post. Yes, set each button as non-toggle on. Add the fanlinc appropriate speed to the button (for example, add the fanlinc medium speed to the button assigned to trigger medium speed). Finally, add the other three buttons as responders. When you do that, make sure each of those responders is set to an ON level of ZERO! I think you will like this approach better in the long term.

You are correct...It would not matter. I was responding to the original suggestions that one could create some scenes manually, and create other scenes via the ISY. A more accurate statement would be that the ISY should be aware of all links and scenes, however created originally. Having links outside the ISY is more difficult to manage, in my mind.

I find scenes to have a couple of benefits over programs. First, response is quicker. A device responding to a scene command from another device generally reacts faster than a device responding to a program which was triggered by another device. Second, I find the growth path easier to manage with scenes. As my number of devices grows (incrementally for me), I find that I don't have to worry much about how this affects my programs. All I have to worry about is putting the device into the correct scenes. I find it easier and managing scene construct than programming. This benefit, however, may be dependent on the kinds of things one does with programs. To elaborate on the second point, I have an ALL HOUSE INTERIOR scene. Any new device that I add to the inside of my house goes here. The various programs that control when my house goes to sleep will work properly without any changes. I have a HOLIDAY scene. Any new devices that are for holiday decorations go into this scene. I have a couple of programs that call on this holiday scene. Making one change to a single scene is easier, for me, than making changes to multiple programs. I simply find this the easier way to manage my growing insteon system.

In my mind, a simple program such as: if control 'switch-A' is on << then do something else nothing will NEVER be false, unless triggered externally, such as being called from another program, or if triggered by additional conditions within the program, such as: if control 'switch-A" is on << and time is between 0700 - 1000 << Then... Else... Such a program will trigger itself at 0700 and at 1000, and upon receipt of an ON command from switch A. Such a program will be TRUE only if receipt of an ON command occurs between 0700 and 1000. It will stay true until 1000, at which point this program will turn false and stay false until receipt of another ON command between 0700 and 1000. aweber1nj, it seems to me from your posts that you are understanding it just fine. Just to be sure, I offer the following examples: if control switch-A is turned on <<< if control switch-A is turned off <<< if status switch-A is ON <<< if status switch-A is OFF << if status switch-A is NOT switched OFF << The other thing about the ISY that seems to trip folks up who have experience with other programming languages are WAITs and REPEATs. If a program is triggered while in a waiting period, the execution will halt and start executing a new path, based on results of the evaluation. For example: If control switch A is turned on and control switch A is NOT turned off then wait a few minutes do something else do something else In the program above, if switch A is turned ON, it triggers an evaluation and the evaluation for the entire condition is TRUE. Then path will run. If, in less than a few minutes, the switch is again turned ON, the program will halt the existing wait period and start a new wait period. If, in less than a few minutes, the switch is turned OFF, it will halt the existing wait period and execute the ELSE path. Beyond triggers and wait/repeat, I think you will find the programming quite intuitive and consistent with your experience. Hopefully, this helps.

You are not the first to express the opinion that there is something not quite right. However, I have always found that it works completely predictably once you understand it: that is, what triggers a program to be evaluated. Once evaluated, the "pure logic of the expression" does, indeed, govern the execution. Understand program "triggers", and I think you will find the ISY to be quite logical.

Yes. Under this condition (still assuming the simple case that this is the only program condition) the else path is not run.

The first program is my one-hour timer. It should be TRUE for on hour, then turn false. Program status(true or false) is based upon the last action taken (then path or else path). The statement to call the else path is there simply to change program status to false at the end of the one-hour period.

is not changing the LED backlights on a keypad considered a configuration change?

I would use scene tests to get a sense of how good is your communication. It will generally give you a sense of pass/fail. Pick a big scene. Run it several times. Make sure you disable any programs that can be triggered by devices in the scene. Do you find you system quick when you press buttons. Do the scenes react consistently, fast, and accurately?

All scenes should be created via ISY. Don't create any separately. Use scenes when possible. Programs when necessary. Then use more scenes. Use global scenes (all lights....all interior lights....all exterior lights...etc...) Scenes are good. Using scenes makes it easier to add new devices. Use folders for devices. I organize them by room. Sometimes by season. Organize programs using folder. I have seasonal programs folder. I have folders for programs unique to remote control (smartphone, tablet). Reuse parts of programs where possible. You do not need more than one program to turn all your lights off....rather, call program paths (then or else) from other programs rather than duplicating code. Device naming convention can be useful.

For the 60 minute cycle, I think I would go with a program something like: If (Nothing) Then Wait 60 minutes Run this program (else path) Else (Nothing) This program becomes my timer. It is true for 60 minutes after being called, then false. Then I would have a motion program something like If Status motion sensor is on Then Turn on pump Else Turn off pump Run timer program (then path) Another program If Time is between 6am and midnight And status timer program is false Then Turn pump on Wait 2 minutes Turn pump off Run timer program (then path) Else nothing This program, above, has some risks of being interrupted during the wait period, but I think things should be good when all three programs are in place. Still, if you head down this path, this is something I would watch for. For my extra credit, you could put these programs in a folder who's condition is based upon you away switch, and create yet another program (not in the folder) If control away switch is turned off Then Run another program (then path) Else I have not spent a lot of brain cells on this, hoping instead to through out some concepts that you may consider and apply. If so, pay special attention to the what-ifs, double checking that the pump is not inadvertently left on because a wait statement was interrupted.

The more intersting part of this problem is not the programming, but whether the concept proves useful in providing meaningful results. I look forward to hearing how it works for you.

If I understand correctly, I have no explanation for this behavior. You have a scene that includes the "home" button as controller, three KPL buttons as responders, and three switchlincs also as responders. You have confirmed that the ON levels are not zero for when the home button is controller. Yet, the reponders don't all come on. I understand that your comms looks good, and I agree. However, it is worth checking something. When you press the home button (to ON) and some of your reponders fail to respond, have you checked the status in the ISY for those non-responsive devices? Does it show OFF or ON for those devices? Does it match the true status of the devices?

what relationship does the "few lights" and the "3 different lights" have with one another? Are they all the same lights, some of the same lights, or none of the same lights? What buttons on the KPL controls these lights? What devices actually provide power to the lights? I am not sure what this means. Sorry. So...you want one of your KPL buttons to be a "home" button and when pressed, 3 different lights turn on and any other KPL buttons which individually control those same lights also come on. Do I have that correct? To do this, create a scene that includes the home button (as controller) the other KPL buttons, and any devices that actually provide power to the lights. Set the ON levels and ramp rates as you desire for the scene, and any controller in the scene. Is this what you did?

Right-click on the program name, choose run if, run else, whatever. I was not so much concerned about watching the one or two seconds it was running, but more checking program status (true meaning last ran THEN path, false meaning last ran ELSE path) and last run times to determine that it last ran when you expected and how you expected. Toggle a few of your devices and see if the program reacts. Also, look at any other programs you have to see if somehow they are unexpectedly reacting. Look for a program that runs several times in a row, going from true to false, causing your lights to turn on and off. Look for clues. Do you see anything that surprises you? I continue to think that it is something other than these programs that are causing this.

Yes! This is a key tidbit of information. Insteon and the ISY-994i are powerful enough and complex enough that it is definitely worth reading and re-reading the user manual: http://www.universal-devices.com/docs/p ... 5%20v2.pdf Check out para 3.2.3