oberkc

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?

Yes, that appears to be a problem for some None that I can think of. This sounds like a case where nested statements would be useful, but I don't believe ISY has such capability. Are you trying to remember exact state (10%, 50%, full on)? I believe the answer is the same. The only possibility that I can think of would be if you were able to come up with some variable value for each that, when added all together, would result in an unambiquous result. Taking a simple example of two devices, with $device1=1 (for on) and $device2 = 2 (for on), adding them together would result in a value of anything from zero to three. Zero = none on. One = device1 on and device2 off. Two = device2 on and device1 off. Three = both devices on. Obviously this is a bit more complicated with 12 devices. I believe you can query "my lighting" Regarding the all on command, I approach this via a combination of scenes and programs. I have found it valuable to maintain a couple of generic scenes: All (interior) and All (exterior). In my case, all devices are defined as responders. I use those scenes in several different programs. One is a program to shut off all lights at a prescribed time. One is to turn on all exterior lights as a result of a keypad button press. A third is, as you desire, to turn off all light (interior and exterior) in response to a button press. This has worked for me. Alternatively, I believe (have not tried) that you can create a program to turn off "my lighting" in response to an insteon command, such as a keypad button press.

Less than 50 programs for me.

Hey Issacsim, In my opinion, the more critical decision you have to make is which protocol (z-wave or insteon) you wish to pursue. I think that is a much larger factor than a comparison of the hardware specifications in the competing controllers (though, as a fan of the ISY, I cannot help that a comparison of controllers would tend to suggest taking the insteon route). In my experience, the "hardware" is fully up to the task that most people will ask of it. It is a little like how Rolls Royce specifies power in their cars: "adequate". You will be happy with it. Do you prefer the hardware of Z-wave or insteon? Are you comfortable with a sole-source for you swiches and modules (insteon) or is multiple vendors important to you (z-wave)? Do you believe that one protocol has a better future than the other? Do you percieve performance of insteon or Z-wave to be superior? These, in my mind, are the questions you should be asking and answering. Then, if you decide to go with insteon, the controller decision is made (ISY!). Likewise, if you prefer Z-wave, then perhaps another controller would be a better solution for you.

I find this statement to be quite interesting. Based upon my reading of the micasaverde documentation, I would have called it a Z-wave controller with limited (very) support for insteon. Based upon my understanding of the ISY series of controllers, I would call it an insteon controller with limited Z-wave device support. I am having trouble understanding how both could meet your needs, unless you are still flexible with regards to which protocol (insteon or z-wave) you will take.

I just upgraded. IMO, the -994 offers no noticeable speed advantages. I doubt that the programming taxes any current processor. I also assume that the speed limitation has nothing to do with processor, but insteon communication. But I don't have anything too complicated as far as programming goes.

I just performed this upgrade. For the most part in my case, it was as simple as you describe it (assuming one keeps the same PLM). All devices and programs transferred without any apparent problem. The exceptions for me: a) I had to reset my location, for time and sunset purposes. I had to request transfer of my X-10 module. Painless and quick. Response from UD was near instantaneous. c) Internet access required a visit to my router settings. I had to reconfigure my port-forwarding rules to match the new address for the upgraded controller. d) updating the port number in the ISY settings to match the router. Once done, mobilinc on all my tablets and phones synced up without a problem and all was well with the world.