oberkc

Have you tried moving the plm to different outlets and circuits? To the same outlet a the lamplinc? Have you confirmed that you have communication across legs of your electrical system?

So, atthis point your immediate concerns are limited to restoring the orignial functionality? Since your system was working before without the ISY, this suggests programs were NOT involved...only scenes Decide, or try to remember, what each switch did. What light or lights did each turn on before you added the ISY? I suspect you will find that Every fixture is currently controlled by one, and only one, switch and that the switches that currently do not control anything were "virtual" three ways with those insteon switches that DO control something. Once identified, creat a scene for each set of switches that you want to control a given fixture or fixtures. To each scene add all the switches that currently control those fixtures and those that you want to control those fixtures. Add all as controllers. To get beyond generalities, I suspect you will need to identify all the switches, what each currently does, what you want each to do, and post back the results.

If you are performing scene tests, be aware that programs that are triggered by the devices in the test can cause false results. Be sure to disable any such programs.

Along the top is a tab "programs". Below that are three (i think) options...details, summary, and something else. (Dont quote me, this is all from memory.). Ibelieve the summary tab is the one showing the status of all the programs.

Sorry I missed some of the details of your original post. If running "then" portion of program works as expected, i wonder about entire program, or other programs that may be accidentally triggered. I am unaware of "timing" issues that would cause this. However, I could envision a couple of programming problems that might cause this. I certainly encourage you to post the actual program. Perhaps there is an issue that someone might catch. Short of that, open the program log which shows program run times and current state (true or false). Initiate the event or events that you believe would trigger this program. Does it? Does it trigger any other programs? Does this program end up true or false?

It appears to me that your understaning is completely accurate across the board. I expect that when you command the scene containing only the button to be off, the button should, in fact, turn off. The qyuestion becomes why it does not turn off. Were this me, I would select the single-button scene from the admin console and manually tell it to turn off. Once done, confirm whether it is actually off. If not, my best guess is a communication problem. If so, manually turn the button on, and select the prgram at the admin panel. Right click and run the "then" clause. Did the button turn off? If not, your "then" clause has an error. If it turned off after running "then", my best guess is a problem with the "if" clause.

Larrylix and mwester have offered good advice. My only concern with proceeding much further and offering more detailed advice is that I prefer to better understand WHAT you want to accomplish before advising on the HOW part. I dont believe you will have any problems putting things back in order...nothing is physically broken. I see nothing here to get overly-concerned about. If all you want to do is get back to where you were, this would be a ten minute task once you get past the learning curve about scenes, controllers, and responders.

It sounds to me that, prior to your introduction of the ISY, the existing switches had some scenes and links already established. Then, when you added the devices to the ISY and chose the "remove existing links" option, those existing scenes were wiped out. I dont think anything is broken, but you will have to recreate the scenes that existed before, or create different ones if you prefer things that way. Most likely, some of your switches are wired directly to a fixture and some are not. If you have a switch that used to control a light but now does not, that switch is probably not directly connected to anything. My guess is that those switches, before ISY, were linked to other insteon switches that WERE connected directly to a fixture. Lets start with one of your examples...the 8-button keypadand dimmer switches. If the dimmer switches befor ISY controlled the same light as does the keypad, then they were linked together (and got wiped when you added them to the ISY). To recreate what was there, you would most likley create a scene in the ISY admin panel, and add the keypad main button, and the dimmer switches, all as "controllers". There is a learning process one must go through with the ISY. Be sure to check out the wiki and user manuals. I am curious, however. If everything was working, why did you feel the need to add an ISY? Did you have something you wanted to accomplish or change?

Personally, I don't think it much matters directly whether the LED is on or off when the door is open or closed. I believe the issue most people have is when they link some insteon device (such as a keypad button) as an indicator that the door is open or closed. Most, myself included, want the indicator ON when the door is OPEN. This eventually leads such people to believe that a "Normally Closed" switch is the best option, since it would be ON when the door is open (based also on how the sensor is mounted). You could, of course, mount the switch such that the magnet and switch are engaged when the door is fully open, but this does not seem to suit most' ideas about what is the definition of a closed (fully?) or open (full, partial?) door. Unfortunately, this is not the type of switch that comes with the garage kit. If you are not using the relay in any particular scene, I don't think the type of magnetic switch matters much at all. Certainly, the ISY works just fine with either.

Assuming that I understand your intentions, I suppose you could try something like: if status bath entry is On and status fan is off and control sensor is on then run next program (then path) Next program (disabled): if nothing then set fan on wait 15 minutes set fan off If you want to define a time other than 15 minutes to wait for the next fan trigger, a few other steps may be needed.

Most likely it is the condition "And 'Outside / Outside Lights' Status is Off" That is retriggering the first program. Despite common usage, I dont believe it serves much purpose in most cases and I would remove it. Unless you want an excuse to play around with variables, none are required here and, in my estimation, simply add complesity.

To larryllix' accurate observations, I add: - get rid of first condition (Status 'Back porch motion-Sensor' is Off) from second program. If the motion sensor fires, you want this program to run, regardless. Neither do you want this program to trigger itself at each change of status. -get rid of third condition from second program. The first program is already constrained by this time period, and will only call it between those times. Neither do you want this program to trigger itself at sunset and sunrise. Also, in this case, there is no value to using a variable here. Instead, you can simply call the second program from the first, at the correct moment.

Very likely, yes. May be triggering fine, though, but always evaluating false.

The only thing I see funny is the "same day" condiition for sunrise. Perhap you should try sunrise on the "next day"?

As I go back and re-look at all this hue stuff I am reminded, too, that it would be valuable to assign one's hue hub with a static address. (I assume most would do this through the router.) The static address would help ensure things keep working after power failures or other reboots.

Well. OK, then... here is my network resource to turn ON a hue light.

Is the only way to add pictures being via URL? Can one not simply past a jpg-type file directly? I would past a couple of shots of my resources, but am not feeling overly ambitious enough to load them to some file sharing site.

Yes. Double check everything. Missing commas, extra spaces. Computers are not tolerant of anything outside of the expected.

"You must have put them there." It has been long enough ago that I would have to refresh my memory of the details, but I assume it is the login credentials for the hue hub, or something like that. Once it worked, I stopped caring.

When I compare my hue resources to Larryllix' screenshots, I see a long string of characters (that hold no meaning for me) in place of "ISY994use".

I do not recall problems sending direct x10 codes (don't do that much anymore). I am wondering if the "repeat 2 times" from the earlier programs cause some sort of signal clashing. But, like I said, it has been a while. Did you try the "belowcabs" approach in the original programs at one point (or just a single x10 command)? I am a little curious about why the original programming did not work. Glad you got it working.

So, you want a physical press of button A of a keypad to trigger an x-10 device, correct? if control buttonA is switched on and control buttonA is not switched off then send sppropriate x10 code (on) else send appropriate x10 code (off) Create a similar program for the B button. No need for variables. No need for multiple programs. I don't see anything jumping out at me regarding your current programs. If I were there, and interested in troubleshooting, I would be watching each of the variables to see if they are responding as you expect, and watching the program logs to find out which were not executing when you expect and whether other ones WERE triggering that you did NOT expect. I would watch the event viewer to watch for unexpected x-10 commands. I have no clue how or if the houselinc is affecting all this. I can tell you that I consider it highly likely that there is something else yet undiscovered coming into play here. I do not consider it likely that there is a programming bug. Do the keypad buttons have any x-10 addresses assigned, possibly? Are there other programs being triggered? This should not be too hard to troubleshoot if you want to take the time.

An example? Of what? A little more detail can help, perhaps. First, you must have the network module. It is an add-on to the ISY software. It cost $50, I believe. Do you have it? If not, you must purchase it (from "help" >>> "purchase modules".) Once you have the module, under "configuration" tab, you will now see a "networking" tab. You will have to "add" a network resource for every action you anticipate. You would need a resource to turn on a hue light to a certain color and intensity. You would need a different resource for a different color or intensity. You would need an additional resource to turn it off. You would need those resources added for each hue device. Do you know how to find the IP address of your hue hub? Do you know how to establish a static address for the hue hub from your router settings? These things will be important. To add a resource, from the network resources tab, select "add". Give it a name that will help you remember what it is and does. Double-click the URL associated with the newly-named resource. Fill in the fields in the pop-up, consistent with the instructions from the post linked earlier. Once you have established the network resources, create an ISY program which calls the resource. It can be as simple as: if time is sunrise then resource "myhueresource" You may need to create mulitple programs, depending on your needs and resources created. From mobilinc, find that program and run "then" path to manually turn on (or off) your hue lights.

I must admit that I would like a better description of what you WANT to happen. I find it difficult to look at a set of programs and try to figure out why it is not working as expected without knowing what is expected. It might also help to better understand what devices are....are "above sink" and "under cabinets" insteon devices? These are different than A1 and A2 x10 commands? Having said these things, the only thing that strikes me as unusual is the same as larryllix. Why did you disable the last four programs? I also cannot escape the suspicion that these programs are more complicated than need be. For example, program ID 0012 has two conditions, a variable and a device status. In essence, these conditions are redundant, since the variable is ultimately based on the status of the device. When the "above sink" is ON, the variable will be 1 and, when OFF, the variable will be zero. Basically, both conditions are the same.

Yes. Set up programs to call the hue configuration. From mobilinc, call the program. Unfortunately, you will have to pre-define the hue settings that you can call.