oberkc

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.

You are not the only one that has occasional trouble with clocks. I, for one, have had troubles before. I simply tried another time source without trying to figure out why. Sometimes, you get lucky. I also have a VAGUE recollection that success can sometimes be based on the frequency that you sync time. I believe the ISY has a setting for frequency of updates. Assuming I remember correctly, what is your set to? More than once a day?

I had assumed you had already created the scene and that the only change necessary was for you to change your behavior. Apparently not. Did you instead create an ISY program to turn on the outlet in response to a command from the switch? If so, I definitely suggest a scene, rather than a program. Make sure your scene includes both outlet and switch, and make sure the switch is defined as "controller". Then, in moblinc, control the scene rather than outlet or switch directly. And...yes...delete the old program.

Yes, there is. You created a "scene" when you programmed your button to contol your fireplace. The scene included your button and your outletlinc. In order for both devices to reflect current status when controlled via mobilinc, you must turn on (or off) the scene, rather than turn on a single device within the scene.

In case you have not seen it, each update gets a new topic, with change description. Try here: http://forum.universal-devices.com/viewforum.php?f=25 You can review each update at your leisure and find what is in each, including recognition of any new devices. I have not memorized the change log, unfortunately, so I cannot answer without performing the same review.

Unspoken regarding this suggestion is that programs with "wait" statements will be interrupted should an initial condition (such as "status") change. So...when the light is turned off, then back on, this will halt the execution of the program, starting it again when the light is turned off the second time. In some cases, this can be undesireable. In this case, however, it is a nice capability.

I use the garage door kit and ISY based upon the excellent example in the UD wiki. It takes advantage of latching mode and works beautifully (at least for me it does). The example, however, is based on a scene relationship between controller (keypad) and responder (relay). There is no ISY program controlling the garage door. I remain a little unclear about your goals with your garage door kit, but I think it premature to globally accept a lack of door mode behavior. The door mode behavior does work in certain conditions. If, however, your C# program can handle only direct commands, then perhaps that is a limitation you will have to live with.

It seems that each version of software brings with it recognition of new devices. Perhaps your new insteon device data was added after ISY v3.2.6? Have you checked the change description for the newer software builds? I know that 3.2.6 is the most recent formal "release", but I would not hesitate to update to a newer software version if I thought it would solve a problem.

Since it is easy, my first instinct would be to clear the java cache.

I would not be looking at access points for any issues you are having with hop count. I would look, instead, for powerline communication problems.

I mounted mine on the door frame, low, near the floor. It is not necessary to mount it to concrete.

I agree that the included instructions don't apply when using an ISY-99. I also found the instructions regarding the colored wires to be confusing, at best. I am not sure that i agree that these terms don't apply. NO would apply your second example, in my mind (close when magnet is near). NC would refer to your first example (closed when magnet is away). I suspect, too, that much of your issues are related to the way the IOlinc operates outside the control of universal devices. The relay, for example, does not report status.

I am curious which "box" you have...is it the signalinc? Is it wired into two breakers from your panel?

Are you sure that it is necessary to include the "stop program" command? My recollection is that initiating a "run program" will interrupt an ongoing wait statement.

is your variable defined as an "integer" or "state"? I believe this program would work as you expect if the variable is a "state" type.

Perhaps, also, that program is being called by another program, such as: if ... then run sunset program

I understand that integer variables will not TRIGGER a program evaluation, but STATE programs will. For example, your program C1 has in it only a condition based on an integer variable. If my understanding is correct, this program will NOT execute, because there is nothing to trigger an evaluation. Perhaps this is why your series of programs is getting stuck? But, as I said, I have yet to need variables and can speak only based on things I have read around here. Hopefully, others can confirm this.

I stared at this set of programs for a while and am having trouble following the logic. What is the purpose of the two variables? Perhaps including some explanation as to the purpose of the various programs would help spur broader response. I don't use variables in any of my programming, but I understand there are two types: integer and state. What types are your two variables? If integer, this could explain why you are not getting the response you expect.

It could be a lot of things, but my first thought is to make sure you have the latest version of firmware for the isy. I recall the bulb being added relatively recently.

This is how I would do it. I understand that there is no such thing as "scene status", so one must look for triggers from the individual scene controllers. No better way is coming to mind.