oberkc

Possibly. I thought it was holding it on, but I may be confusing it with other devices.

Sometimes, existing switches are wired via method known as "switch loop", where there only hot supply and swithed return (no neutral). Wire colors can be unreliable indications of purpose. Three-way switches can, sometimes, not include a supply or neutral. But...if your LED is coming on and off with the switch, I would tend to discount wiring problems at this point (though loose connections can cause problems for insteon communication as well. The "surge suppressor" jumps out at me. Based on my experience and perceptions from reading this forum for a while, that is a suspicous candidate as a possible communication interrupter. It would be useful to determine if on the same circuit. Can you temporarily remove it from service to see if this solves your problem? I have not measured RF range of insteon devices, but there have been enough discussion around here that I would not rely on RF exclusively. Depending on installation (including orientation, box material, wall material, environmental) range can be quite limited, apparently. Good. Instructions for the togglelinc (and most other insteon devices) are written based on the assumption that there is no central controller. My favorite method for adding an insteon device is to first "add new device" from the ISY admin panel, then press and hold the togglelinc ON until beeps (usually around five seconds). At this point, the togglelinc should be listed.

I would put the possibilities into the following categories (not necessarily prioritized), based on your post: a) device failure switch wired incorrectly c) communication problems d) procedural For now, I would ignore the possibility of a device failure. Regarding wiring, how did you verify correct supply wire (hot) connected to black wire? Do you have it connected to a load (red wire)? Does the little LED on the togglelinc turn on when the switch is off? Regarding possible communication problems, what other devices are plugged into the same outlet and circuit as your PLM? Computers? Surge suppressors? UPS? Lots of power supplies? As far as procedures go, which did you follow? The ones that came with the togglelinc? The ISY-99 user manual/wiki?

I don't try to send rapid-fire commands. Yes, when there is less-than-ideal communication, things CAN slow down, waiting for acknowledgement, though 20 seconds is certainly longer than I have experienced (suggesting, perhaps, that you still have something that is causing some complications). Based on responses around here, I think folks have had mixed luck with trying to send out on-off-on-off commands in quick order. I don't know if you are sending commands to individual devices, or to scenes, but you might try the other way around. I can never remember which is which, but one does not wait for acknowledgement, and the other does. Perhaps that would help speed things up a bit.

http://www.universal-devices.com/docs/p ... 5%20v2.pdf Although, about the manual, I was speaking more liberally, to include seeking further guidance (including from this forum or the universal devices wiki) when it is not self evident how to achieve desired results. No harm, unless there are unintended consequences.

The first ones that comes to mind are cell phones and computers. (Yes, I know. I assume that most don't read the manauls.) But, if we can imagine a world where nobody has seen or used one of these devices and, suddenly, we are trying to fully exploit one, how full would a forum like this be? Even in the real world, have you been over to the iPad or android forums lately? It is amazing the number of questions that are asked...over and over. I would imagine, too, that most of us here play tech support roles in our extended family for these devices for when there is something that a family member wants to do but doesn't know how (should have read the manaul). I opine that for those who want a "no manual" experience...get the hub (and live with the limitations). If instead, you want an insteon controller with near-complete flexibility, then a little manual reading is not too much to ask.

I am in no position to dispute the workings of most people's mind. I can only say that mine seems to find the feature useful. I can say, also, that my programming needs appear less ambitious than many around here. Perhaps that affects my perception. Only recently, have I found a program that I could not do without variables. In most cases for me, inclusion of variables added lines of code. I get a kick out of minimizing lines and numbers of programs, so perhaps I am a little strange in more ways than just my affinity for program status. My sense is that, rather than baffling, that in programming the ISY one must learn and pay attention to the details. Also, a sense of boolean logic is useful. Most of the endless questions on the subject are initiated by relatively new folks, I also percieve. Perhaps not intuitive? Maybe. However, my experience is that power and flexibility often comes with the cost of a need to read the manual (or, in this case, seek help and advice from others).

As a point of clarification, programs can run when the folder is false. Instead, they will not trigger from the IF condition. If called externally (such as from another progam), they WILL run. Yes I would cause a program to run whatever is in the ELSE path. If nothing, then I guess that would be the same as stopping. Also, I think it will halt/interrupt a currently-executing program only if there is a wait statement. Otherwise, I believe a program will continue to completion (which would only be a few seconds or less, anyhow). I have not double checked, but is there not a HALT program option to add to a program? (Memory is vague.)

I still like PROGRAM STATUS as a program condition. In most cases, for me, program status is a natural check. Use of variables can contribute to the need for extra coding in some cases.

My working theory is that "sealed" covers keep moisture and humidity IN. When I install outside, I make no attempt to seal anything. Rather, I do my best to keep direct exposure to rain minimized and, should moisture make its way past this first line of defense, a drain path out.

That is the same conclusion I reached from reading the manaul. Unfortunately, I cannot confirm by personal experience.

From the user manual: "Because Micro module comes programmed for latching switches, 3-way toggle mode is enabled by default. Normally, a latching switch reads the switch’s up position as on and down position as off. For example, if you turn Micro module on from the latching switch and off from another controller, the switch is still in the up (on) position; turning Micro module back on from the switch would require you to tap the switch down, then up again. The 3-way toggle mode overrides this sense feature, so in that same scenario—turning Micro module on at the switch and off from another controller, so switch is in up (on) position—you could then turn Micro module on at the switch by tapping it down."

I would be very surprised if any of this would be useful with motion sensors. Motion sensors cannot be responders. Motion sensors do not acknowledge anything. Based on what I have read here, it does not appear the ISY/PLM has any way of detecting a motion sensor being non-responsive.

Ugh. This I did not understand. I assumed a simple change of state in the sense wire would toggle the output. This would be no good...I agree.

That is not much different than the historically-typical three-way. Up or down has no meaning with those, either. Yes, I prefer up=on, but we have lived with other options for a long time. Theoretically, if there was enough space in the box, one could simply keep ALL the existing switches and install a micro module somewhere to power the fixture. Instant insteon.

Interesting idea! I don't see this device on smarthome web page. Has it been discontinued? This also may depend on how the circuit is wired. In some three-way configurations, I don't think there would be enough conductors.

It is, but not with B button as scene controller. The only way that I know to do this is by a program: if status b button is on then set lights to low level (best with a scene, possibly) else set lights to 100% (perhaps another scene with same devices, higher ON level)

assuming the program is correct (and it sounds like it is), my first suspicion would normally be that the load (when on) is interfering with insteon communication. But...houselinc worked correctly? Was the houselinc device plugged into the same outlet as the ISY PLM? Back to your program...is it too much to ask that you post it? Does your program have a statement in the ELSE path to turn off the lights?

Further thoughts on scenes versus discrete devices in programs.... Generally, I have few devices that are not part of a scene somehow. I have found it useful to have a few global scenes, such as all-interior, all-exterior, all-guest. I also have some large scenes such as evening, landscape, exteriorflood. In the end, I have very few devices that are not part of some scene, somewhere. Such use of scenes makes one a little less dependent on a controller, and can help make troubleshooting a bit easier. Also, when I add a new device, including it into one of the applicable scenes is all that is necessary (no program changes needed). Given these scenes, it seemed more natural to use them for timed events. In many cases, I have more than one program that turns on a given scene. Having it this way means that I don't have to duplicate a list of devices in more than one program, nor update multiple programs when adding/removing devices.

Absent other evidence, I take this as a sign of communication issues. I prefer a scene, but not necessarily for reasons related to reliability (though this may be a unintended consequence). I find scenes to be easier to manage as my system grows and my interests evolve. I don't believe there is an inherent benefit one way or another. I use both. I have an "all lights off" program which is set for a specific time. I have other programs which use the from/to construct. Once at the beginning, and once at the end. Nothing between. Of course. One way would be to create a program folder, enabled by the specific controller. In that folder, put your from/to program.

OK. Fair enough. In my mind this is the same, since we were not looking for status on/off, but status responding/not. But...point taken.

You cannot simply replace a one switch in a multi-switch circuit with insteon, leaving the others in place. You MAY be able to rewire the circuit to have a single insteon switch and no others, but this would depend on how the circuit is wired. If power is introduced at the fixture, then you would either need to add additional conductors between the fixture and switch box, or an additional insteon device (such as mircro module) at the fixture. Either way, you will need to re-purpose some conductors.

This sounds exactly like every other STATUS condition, correct?

That is, at least, the best working theory so far. If this is the explanation for why it is not returning TRUE when manually triggered, then that aspect of this statement is unlike other STATUS statements, and more like a CONTROL statement in this regards. I would be disappointed if this proves to be the case.

Yes. In my mind, this is an external "trigger" much like your earlier example where you invoked the "run if" command on that program. I agree, the program should react based on current condition if you invoke some type of external trigger or query. Like I mentioned before, I have no explanation why this does not work for you. I suspect TJF was speaking of triggers rather than evaluation, and suspect he would agree that a STATUS condition would indeed return TRUE if invoked (triggered) externally, whether manually or by another program. Still, I think this is more consistent with other STATUS conditions, rather than making it more analogous to a CONTROL condition. I think we all have the same understanding, but don't know why your program would not evaluate as TRUE when triggered externally.