oberkc

To continue with the ping pong table example... Just to be clear, you need an ISY scene that includes the "scene" KPL button as controller and any of the "second" KPL buttons that are part of the scene as responder AND any of the ping pong table light switches as responder. This is in addition to the scenes you created where the second KPL buttons are controller and the switches are responders. If, in fact, this is what you have, from the listing of devices and scenes, click on the first KPL button that is under the scene (as controller) and make sure all of the responder ON levels are something other than zero.

A device behaves as a controller only when activated directly. Wehn that same device (for example, a keypad button from the second keypad) is activated as a result of being a respoder (from the scenes keypad) it does not act as a controller. The solution is to include the ping pong table lights as a reponder to your scene button.

Like any other computer, the ISY will do (and tell you) only that which you program it to. Yes, you could log in periodically to check the status of a particular motion sensor node but, as LeeG points out, this status may be lost during a power surge or similar. Yes, you need to program this. Something like: if status motion sensor battery node is on then send notification to... else

The way "status" conditions work is that they trigger on any CHANGE in status. In other words, this would trigger from off-to-on and from on-to-off. Once triggered, the evaluation would be true (run then) when on-to-off, and false (run else) when off-to-on. Since there is nothing in the ELSE clause, nothing will happen when change status to ON. I believe this will do what you asked for.

Warning...I don't have a synchrolinc, so I am making educated guesses here. I assume that the synchrolinc can act as a controller in a scene, so this suggests that you could use a "control" or "status" condition. If you want to send a text when the synchrolinc changes from ON to OFF, try: if status synchrolinc is off then send notification to 'xxxx" content 'yyyyy' else

I understand. I am still this way, and I would like to think I am beyond a novice. Only the ISY, for the purposes of controlling your system from a network device, such as a smartphone. No...not if you plan to configure these manually. Enabling this may work in some cases, but I understand you are better off doing this manually, through your router settings. Now I am more confused. Octet? What URL? Do you know your own IP address? The answer to that may depend on the frequency which your ISP changes your address. Any ideas? I do not have a static IP, but my address stays pretty constant, changing pretty infrequently (such as during long power outages). If your changes often, a static IP address would eliminate the need to enter the new address every time yours changes. The IP address is different than the reservation on the router. I think of this in terms of the LAN (local area network, or on the same network) or WAN (Wide Area Network, from outside your router/wifi network). The IP address is the address one uses to get to your local network, through the router. You can find your IP address within your router settings, or at whatismyip.com. Your reservation is the address within your local network, and probably looks something like 192.168.0.XX. For setup of your ISY for remote access, you should check out: viewtopic.php?f=26&t=635

I have a relatively new ISY and PLM (less than a year, I estimate) and my oldest insteon devices go back to about 2007. All work well together.

I see no reason why setting the ramp rate and ON levels could not be done independently, by a program. One thing to watch out for is to be sure to set the ON levels and ramp rates based upon which controller(s) you intend. Make sure you are setting the ramp rate for the motion sensor as controller, and not just the switch, or the scene level.

I am having trouble explaining the described behaviour based on apostolakisl program. I cannot see how turning off the light would trigger the fan. In your version of the second program, are you using "control" or "status"? If you don't mind, please post your programs.

there are lots of LED undercabinet light options that plug straight into normal outlets or can be hardwired. There is no need to go back to halogen, other than because of preference. Besides, halogen do not give off light at the 5000K range.

Have you read the wiki? Have you read the user manual? Have you read the manuals that come with each device?

In the listing of programs, right-click, run then path. It appears to me that you have a failure in the scene test. While not conclusive, this is a bit of evidence here. Does it consistently fail? More failures. Ugh. Did you disable the programs before trying this test? Did it affect the results? I think I am starting to see a pattern here. Your scene tests suggest communication problems. Your device failing to respond from manual triggers suggests communication problems. Perhaps this is the root cause of your issue? Have you read any of the (many) threads on communication problems and troubleshooting? It can be a frustrating process. Start with the easy stuff...is the PLM plugged into an outlet or circuit that has lots of other computer stuff, UPS, surge suppressors, computers, routers, modems, etc....? Do you have two access points or other means to couple your electrical legs (phases), confirmed on opposite legs by the method in the user manual?

Just to confirm I understand a few details... - you have a "hallway KPL G Basement Dim" device. Is this a different KPL G that is controller of the scene "basement dim"? If different, is it part of any of the same scenes as the other KPL G button? - what is the difference between the "basement off" scene and the "basement LED off" scene? The KPL G is controller in the 'Basement Dim' scene Its a responder to the All Off scene (just a whole house off scene) and the Basement Dim scene You state that the KPL G is controller to the basement dim scene and also responder to the basement dim scene. Correct? Since, with the ISY, any controller is automatically a responder, are you suggesting that these are, somehow, different scenes? Or...are you just reaffirming the principle that controllers are responders. Based on what I see, the KPL is part of the following three scenes: All Off, Basement LED Off, and Basement Dim. There are no other scenes in which the KPL G button is a part, correct? These two programs are the only two that affect on, or are affected by, the KPL-G button, or on/by a scene that includes the KPL-G button. Is this correct? There are two reasons (beyond device failure) that I can think would cause the KPL to not come on when you expect: communication error or program/scene error. I would like to eliminate the communication error. Have you performed any scene tests of the "basement LED off" scene? Have you performed any scene tests of the basement dim scene? What are the results? Have you manually executed the THEN path of either of these two programs? What are the results? Do they always turn the KPL G button on/off as expected? Be advised that you may need to temporarily disable these two programs to achieve successful results. Once we can reasonably eliminate comm errors as a factor, we can look at the interreaction of your programs/scenes/devices.

nothing wrong that I can see

I responded at smarthome forum.

I am still suspecting issues I have already asked about, but have missed your response. This includes ON levels, in what scenes is the KPL button, little symbols, results of scene tests...? It really helps if you respond to those kinds of questions. Without details, one can only speculate. My best guess is that your KPL (both controller and responder) is part of multiple scenes, that the scene 'LED OFF Scenes / BASEMENT LED OFF" includes some, or all, of the devices that are a condition in your program (causing the program to retrigger), that you have other programs that turn the KPL button off, or some combination of these issues. Or, it could be a simple communication problem. Perhaps I can summarize: a) in what scenes is the KPL. Name all of them. Which controller, which responder? what devices are in scene "LED OFF Scenes / BASEMENT LED OFF"? c) what other programs affect the KPL button? What program or scene turns it off (have I missed this?)? This CAN be solved.

If you are using a KPL button to initiate a program to turn one scene on and another scene off, then, no. If you are using combinations of scenes and programs, I can see where this might get messy quick if one is not careful. Of course, no insteon device can be CONTROLLER of more than one ISY scene. Perhaps it would be worthwhile to select the KPL button, and check (on the right) which scenes this button is controller of, and which it is responder to. Report back the results.

This tends to confirm, in my mind, that the problem is NOT with your program. Possibly. It could also be a communication issue. Are you sure the keypad button is part of the scene? When you select the scene, what is the ON level of the button? 100%? Zero? Are there any red or green symbols next to the device in the ISY list of devices? What happens when you perform a scene test on the troublesome scene? If the above steps showed no indication of problems, I would go a little deeper. Because it is pretty easy to do, I would then restore the keypad device and hope this solves the problem. Please report back your findings.

I have also been watching that thread. It seems you are getting good advice there, by folks generally more knowledgeable than I. I may jump in soon, however.

So...I think we can eliminate the program as a cause, for now. Possibly, but not my first guess. It does seem, however, that some PLMs work better than others (for some reason). I would try a couple of things first. I would perform a device restore from the ISY on the switchlinc to see if this helps. There are no funny green or red symbols on your list of devices, are there? Does a device query give any results? What happens if you perform a scene test on the scene that includes the stubborn swithlinc? Failing all else, I would remove device from ISY, perform a factory reset, then re-add.

What happens when you turn the scene on manually from the ISY? Does it come on? I see no program problem here. Why the wait?

Have you tried the scene manually from the ISY? I dont believe that this is a program problem. Most likely communication issues with that switch.

Does your sidewalk and driveway have expansion joints?

To LeeG's typically thorough explanation, I would add one common programming error with "status" that are, generally, not an issue with "control". Often, one sees program constructs with a variation of a theme (admittedly extreme) such as: if status switchX is off then turn switchX on wait a few seconds turn switchX off else turn switchX off Such programs are those that change the status of a device which then trigger a reevaluation of the condition, can halt wait statements, trigger follow-on actions, and so on and so forth. Such programs can create loops, including infinite loops. When you create programs, watch out for programs with status conditions for a device, and actions for the same device.

By integrate, do you mean to -insteon ability to sense when the gate is open -open and close the gate with insteon -both If the first, then techman's solution may work for you. If the second or third, then I agree with xathros. However, is there a possibility for you to extract 120VAC from the solar battery system? (I doubt it, but this may offer an option to consider).