oberkc

A series of commands to turn off any light that you want off once the sun rises and don't want left on all day. The bigger point is that (unless you have another program that handles this) the two garage lights and kitchen lights will be left on indefinitely from this program should sunrise occur within the ten-minute wait period. If that is acceptable to you, then no action need be taken. If you want to make sure they will not be left on all day, put three commands in the "else" path to turn the three lights off. While there may be other ways to handle this type of condition, I find this simple and effective.

It certainly suggests that these devices are working. What is the electrical environment near the PLM? What other devices do you have plugged into the same outlets and circuit? Is your PLM plugged into any power strips or surge suppressors?

I expect this program to work EXCEPT when you happen to open the door less than 10 minutes before sunrise. If sunrise were to occur during the program wait period, it would trigger the program evaluation, turn false, halt the wait, and execute the "else" path. In other words, the lights would remain on indefinitely. One way to solve this is to add a step to turn your lights off in the "else" path.

Whether or not a fixture or lamp can be dimmed is dependent entirely upon the insteon device which actually powers it. A Keypad can be purchased in either dimmer or relay version. The consequence of this is only related to the load which is directly powered by the keypad (connected to the red, load wire from the keypad) via the "primary" button on the keypad. In addition, ALL keypad buttons can be virtual controllers of other insteon devices. That is, ANY keypad button can virtually control another insteon device such as a lamplinc, outletlinc, switchlinc, dimmerlinc, another keypad, etc. On a keypad, buttons other than the "primary" button can act ONLY as virtual controllers, since they have no ability to supply power to a fixture. So, if you have a lamp that is plugged into a dimmable lamplinc, and use a keypad button to control the dimmable lamplinc, then, yes, that keypad button controls a dimmable load, regardless of whether the keypad, itself, has an on-board dimmer capability. In my house, I have many insteon switches that power NO load directly, having nothing connected to the load wire, instead acting only as virtual controllers of other insteon devices. Whether or not they can dim a fixture as a virtual controller is completely independent of the dimming capability of that switch.

The only programmatic concern that I have is with your temperature condition. Unfortunately, I don't have the weatherbug module, but is it possible that temperature changes forces frequent program evaluations, such that your program execution is halted during one of the wait statements? My suggestion is to break this into two programs. The first: If On Sun, Tue, Wed, Thu, Fri Time is 8:00:00AM And Module 'Climate' Temperature > 32 °F Then run second program (then path) else The second program: if Then Send Notification to 'My e-mail' content 'Sprinklers Started' Set 'Sprinkler System / 7-Back Flowers and Trees' On Wait 10 minutes Set 'Sprinkler System / 7-Back Flowers and Trees' Off Set 'Sprinkler System / 2-Front Middle' On Wait 5 minutes Set 'Sprinkler System / 2-Front Middle' Off Send Notification to 'My e-mail' content 'Sprinklers Stopped' else

Perhaps it is similar to a garage door, but I am with Vyrolan on this. To offer an opinion on how well the IOLinc could integrate with a device that few around here have used (likely, in my estimation) would be speculation (educated or otherwise). I, for one, would hate to offer an opinion, have you spend your money based on that opinion, then find out I was wrong. If your question is now more to gain a better understanding of how an IOLinc works, allowing YOU to decide whether to try to integrate it with another device...that is a slightly different question. I use an IOLinc. Basically, it has one input and one output. The input is for a relay or sensor. The sensor input is either on (closed, shorted) or off (open). I don't believe the IOLinc cares as to the brand or configuration of the sensor, so long as it is a simple open/closed circuit from an electrical standpoint. The IOLinc can take this sensor condition (open or closed) and convert it to an insteon status or command (on or off). Once connected, this sensor can be used as can any other insteon device: as a controller in a scene. The output basically emulates a contact button similar to a simple garage door button or doorbell button. It can be configured to mimmick the closing of a contact, opening a contact, or momentarily doing this (mimicking a press of the garage door/doorbell button). This output can then be connected to any device that operates from momentary contact button type device, such as a garage door opener or doorbell. If your Seco-Larm kit can be connected to a momentary contact button, then I would expect that the output of an IOLinc could be used in this capacity. The IOLinc has the ability to configure much of the way it reacts to sensor input, the type of output (momentary or "latching") it provides, and the relationship between input and output, to suit a variety of uses. One common use for these relationships might allow one, for example, to operate a garage door ONLY if it is already open (thus providing some level of security against a door opening when not intended. Hopefully, this will allow you to decide if an IOLinc can be integrated with your prospective device.

I like it! Very plausible explanation. Yes, that should be easily doable as LeeG proposed, assuming all the proper infrastructure is in place, such as phase couplers for X-10 and insteon, RF within range, etc...

I have quit trying to memorize how to get to Java settings, so I have resorted to typing "java" in the search field of the start window. From there, I find it pretty intuitive (in other words, I don't remember this, either) to find the java settings. From there, navigate your way to find where you clear the temporary files (again, all from a failing memory).

I have insteon and x-10 motion sensors. They work. Unfortunately, I am not smart enough to understand from your post what it is you are trying to do, or in what way your current setup is failing to do it. I am also a little unclear how an X-10 "PIR" (motion sensor?) responds to commands. Mine have no response to commands. Rather, they simply send commands based on motion and light conditions.

Beyond the now-occasional communication problem or operator error, never. I have experienced no indication that there is some inherent flaw or bug with the ISY that would prevent creation of scenes, for any device, at any time. Like LeeG, I thought your issue was with concern about toggling options. Is this a new problem? Were you having it before upgrading to 3.3.4? What are the symptoms (any error messages? Red exclamation points? Green symbols?) when you try to create scenes?

Unfortunately, I doubt anyone can offer guarantees. It is, however, a step worth trying.

I don't believe that a sensor can be a reponder, nor a relay as contoller. The sensor status is controlled entirely by the sensor, itself. The sensor can, however, be a controller of other insteon devices. The theory is that you want the sensor to "control" the KPL button status, and you want a KPL button press to "control" the relay. Thus sensor should be controller in its scene, and relay should be responder in its. Hopefully, I am not being dislexic.

This sounds correct. The direct way that I would check would be to observe the LED on the IOLinc. Does it come on when the door is open and off when closed? Every time? If so, then I believe this will work. Otherwise, there is a sensor wiring problem. I see you have configured your IOLinc to be in "momentary" (not latching) mode, but which momentary mode? This should be either momentary A, or B (B is my preference in this case). If the IOLinc is not configured in this way, the response to commands can be intermittent. If you have it in momentary A, make sure it responds only to "ON" commands, not off. I just wanted to make sure your sensor is defined in the scene as "controller". Is the KPL button H in non-toggle "ON" or "OFF"? Make sure it is "ON". I don't believe that your problem is related to anything JAVA or software version. To troubleshoot the problem, I would break this into two parts, starting with the KPL indication. Open and close the garage door using the wall button or car remote and observe the KPL button. Is the KPL button indicating proper status? Ever? Sometimes? If this is working always, great (move on to the control problem). If intermittently, is it possible that you are experiencing communication problems? If not working at all, this would cause me to suspect a scene or sensor wiring problem. If you begin to suspect communication problems, you can open an event viewer to see if the ISY/PLM are recieving status from the sensor. Once you have the KPL properly displaying status, what then happens when you press the button? Does it flash a couple of times, staying on? Flash then go off? Not flash at all? Does the door respond sometimes? Never? Only when open or only when closed? Ramdomly? If the IOLinc relay is not configured in the correct momentary mode, this would tend to cause your door only to respond when either open or closed, but not both. Communication problems, as with anything insteon, can cause intermittent operation. Also, some of the fancy new garage door openers can be picky, I understand, regarding IOLinc control. I recently tried to program a KPL button to momentary mode, but without apparent success. If your button is not flashing when pressed, it is NOT in momentary mode. Your specific symptoms should point to the next course of action.

In fact, your motion sensor, were it working, would turn your lights "OFF" (see last command of "then" statement), not to 60% as you appear to want. Are your lights staying 100% on, or turning off? I continue to suspect (as stated in my first response) that you are having issues with your motion program. I also suspect that, to provide meaningful support here, it will ultimately be useful for you to state what you want to happen, versus what IS happening. Also, please describe the content of any scenes used in your programs.

I understand that to make changes in the motion sensor settings from the ISY interface, the motion sensor must be set to link mode in order for the settings to be updated. Hopefully, others can confirm. If you did not do this, give it a shot. While this does not solve your problem, I have found that using the "on" only mode with the motion sensor to be better when using the ISY. I find there to be much more control over timer events when using an ISY program, rather than the built-in timer of the motion sensor. I also find that these types of events are much easier to modify when they are controlled outside the motion sensor. Consider the simple ISY program: if control motion sensor set on then wait 3 minutes set 'motion sensor lighting scene' off else If I had to wager, I would put money on the likelihood that more users of the ISY have taken this approach rather than relying on the motion sensor timer.

I am not certain exactly which of your three programs is not working ("both" programs work well, but which two?) Neither am I sure what you mean by "disable other programs". I will observe, however, that your motion sensor program could run into issues. Try changing "status" to "control". What devices are in your scene 'garage outside lights'?

A simple program such as follows will work: If Time is from sunset To sunrise (next day) And control iolinc sensor is switched on Then Turn lights on Else

No, unless this condition dictates a course of action, or unless you are overly sensitive to unnecessary insteon commands over the powerlines and airwaves. If you want simply to turn on or off some lights at a prescribed time, regardless of other concerns, then first checking status is unnecessary.

To me, that is the obvious setup. The wiki includes this specific example, and how to set it up. Your kit should be installed such that the sensor is "on" when the door is open. Configure your iolinc to be in momentary mode to respond to an "on" command. Configure your kpl button to be in non-toggle on mode. Create a second scene with kpl button as controller and relay as responder. Done. Configured in this way, there the KPL will be "on" when the door is open, and "off" when closed. Pressing the button will activate the door, regardless of status. AND...there is only one way that the button will display "off" (closed) ... Wen the door is closed and the iolonc sensor sends the proper command to the kpl button. This gives one a great confidence that kpl status is accurate when it shows closed.

This depends on where you mount your sensor. I like the sensor to be in contact when the door is FULLY closed, and open on anything other than fully closed. Some have mounted the sensor where the sensor is in contact only when the door is FULLY opened. Yes, I agree that it is best that the sensor is "on" when the door is opened. This is a personal preference, but I prefer the opposite. It is more important for me to be confident that the door is FULL closed, rather than FULL opened. Given this, I would rather have the sensor aligned with the door is closed.

I believe that in some parts of the world, these are known as 2-way.

I would not expect that this certificate would affect communication between the ISY and morninlinc..only ability to remotely log into your ISY. This would be best if others can confirm. One last shot that I can think of...what other electronic devices are plugged into the same outlet and circuit with your PLM? Lots of other computer stuff? UPS? Surge suppressor?

Try temporarily moving the morninglinc to the same outlet as the PLM. If it works, this tends to suggest that LeeG is correct.

I am unsure how wise it is to have a program in a perpetual loop, and to be initiating all this communication messages. But, if this is important, then it may be your only option. Perhaps the problems you are having are with your program. I offer the following suggestion regarding your blink program: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'Kitchen KeyLinc - D' on << Wait 5 seconds Run Program 'Blink' (Else Path) Else Set 'Kitchen KeyLinc - D' off << Wait 5 seconds Run Program 'Blink' (Then Path) In your initial program, you were simply changing the backlight level representing a state of "on". Hopefully, the distinction is sufficiently clear.

Regarding the garage door problem, may I humbly suggest that the best way to track garage door status (assuming IOLinc garage door kit with sensor) is NOT a program, but a scene with IOLinc sensor node as controller and keypad button as responder. Using the same button as a trigger for opening/closing the door introduces some additional considerations, but can be done. My first suggestion would be to visit the UDI wiki and search on garage. You should be able to find an example. You expressed, however, a desire to activate the door by pressing the button "twice". Are you referring to a "fast-on" (quick double-press)? What do you want to happen if you press the button only once? What do you want to happen if you press the button when the door is closed (and button H is not on)? Do you expect the button H to display a correct door status even after someone has pressed this button (once, twice, more)? Like the wiki example, I use a single keypad to control a door as well as display status. I don't require a double-press, however. Perhaps you can think further about how you want your system to respond to the various possible combinations of button H status/presses and consider some alternatives?