oberkc

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

Perhaps I am missing something here, but let me clarify how it works at my house. If I am on wifi or ethernet on my LAN, I use only one address: http://192.168.0.33:88/ or https://192.168.0.33:555/. Both get me to my dashboard. The secure port gives me a certificate error, but I have never attempted to resolve that issue. Both of these ports match what is in the ISY and router. External access is through an entirely different IP address. When I connect externally, I use the external ip address https://70.aaa.bbb.ccc:port , using the SAME port numbers as when internally. Now that is appears you have both secure and non-scure ports working internally, do you continue to use the https://50.xxx.yyy.zzz:59876 address externally? Have you checked this address more recently through whatismyip? Is it possible that your ISP has changed it?

you might try https:// rather than http://. Is port 443 a secure port? In case you missed it, there is actually a sticky topic under how to. In that sticky topic is a reference to: http://portforward.com/ Where this likely describes the setup in your particular router. Both are worth checking out.

Yes...each motion sensor has three: motion, light, and battery. For this project you only need worry about motion. For future reference, you could use the light sensor to identify when it gets "dark" and you can use the low battery as a trigger to send you a message telling you that it is time to put in a new one. Yes, I suspect this might take more than one program. I am not convinced that a variable is needed, but sometimes that is a programming preference for some. I suspect that the use of variables makes the logic easier to follow in many cases, but I have found few cases where they are truly NEEDED. The first part is to get your sensors located where you want and confirm that they react as you expect, and that they communicate reliably. Beyond that, a program would probably look something like if control "motion sensor 1" is on <<<"motion sensor 1" would be the name you give it then wait 15 seconds run "this program" else path <<< "this program" would be the name you give it else A second program looking for motion on the next motion sensor if control "motion sensor 2" is on and status "this program" is true <<< "this program" refers to the first program, not the second then do whatever you want else nothing There is a suggested approach that can, potentially, create some ideas in your mind. The syntax is not exact, but the ISY will create the right wording. No variables...no mess...fun!

in those pretty, little icons along the top left, the two right-most symbols are where one enables and disables the mode to write changes to devices. One is for battery powered devices, the other is for the rest.

Unfortunately, we are reaching the limits of my knowledge and experience. In your port forwarding rules, I note that 59876 is listed under "range". And you have 443 under "local port". None of these terms show up in my DLink port-forwarding rules page. I am also curious what it is that your ISY settings for secure and non-secure ports are? Is one of them 59876? I believe these need to match. Have you tried 443 as a port number: https://50.xxx.yyy.zzz:443/

It is a simple program. The problem that typically comes up is when a path (THEN or ELSE) retriggers the program, but unless the scene "basement LED off" or "hutch LED on" includes devices that are part of the programs condition, then this should not be a factor. Have you tried any experiments to further isolate the problem? Have you tried manually executing the THEN or ELSE paths to confirm that they work? Have you watched the program state from the ISY to see whether it is executing? Have you confirmed the ISY-presumed state of your devices match reality? If the program appears accurate (and it does to me), then I start looking for other potential issues.

My experience is that, in addition to the steps described by kman, one must set up port-forwarding rules in the router to match the ports defined in the ISY. In doing so, be aware of the other devices on your network and ensue that there are no other devices trying to use the SAME ports. It is likely best to use ports other than 80 and 443. Once established, the address for your ISY when outside your LAN would be: Https://myipaddress:mysecureportnumber/

These are all good questions. Yes, your understanding is accurate I believe. Unfortunately, reality collides with theory based on my experience and what I read around here. Xathros ably explained many of the benefits of access points. I would add a couple more: flexibility of placement for phase coupling, and flexibility of placement for RF coverage for use with other RF-only devices such as motion sensors and remotes. Theoretically, once you have two access points, you can add as many more (even having an odd number) as you need for the coverage concern. My experience confirms theory in this case.