oberkc

So....you want something to happen when the catgenie "starts". This indicates an increase in power consumption, correct? This causes the synchrolinc to send an ON command, correct? Then you want something to happen at the "end of the cycle". Can we assume that the catgenie will reduce power consumption sufficiently to trigger the synchrolinc to send an OFF command? But the hiccup is that the catgenie also cycles between high- and low-power modes several times during a cycle, correct? But you have determined that these OFF periods of time are less than 3 minutes, and that any OFF period longer than 3 minutes constitutes an "end of the cycle", correct? And, we now understand that you want the programmed events to occur only once...one at the beginning of a cycle and one at the end of the cycle, but none between...no duplicate events, correct? Can we assume that the programmed events (ie "physical parts"), themselves, have no wait or repeat statements? If the above is correct, I would further modify my suggestions if control "synchrolinc" is switched on <<and status of "THIS PROGRAM" is false <<then run "DO WHATEVER YOU WANT" program (then path) <<else nothing If control "synchrolinc" is switched off <<and "synchrolinc" is not switched on <<then wait 3 minutes <<< make sure it is a real OFF run "DO WHATEVER ELSE YOU WANT" program (then path) <<run "ON PROGRAM" else path <<< notes: turns first program FALSE else I am a big fan of exploiting the inherent capabilities of the programming language and use variables only when I can find no other way around doing so. Perhaps I simply enjoy the intellectual challenge, but I find this less complicated.

Upon re-reading the original post, as well as the response by TJF1960, I wonder if I may not fully understand the problem here. If the idea is simply to force a 3-minute wait after an OFF command to ensure it is truly off (rather than one of those tempory low-power moments in the normal duty cycle of the CatGenie), I would update the last of my programs from: If control "synchrolinc" is switched off then run second program (then path) else nothing To: If control "synchrolinc" is switched off and control "synchrolinc" is not switched on then wait 3 minutes run second program (then path) else nothing

These little red exclamation points generally indicate an inability to communicate with, or write updates to, a given device. What happens if you right-click, and select "write updates" (or something like that)? Do you have access points installed on opposite legs of your electrical system? First, make sure that the device you wish to use to control the scene (a keypad button, in this case) is defined as "controller" (as opposed to, simply, "responder") of that scene. Once a controller, select that scene device from you admin console and make sure that the ON levels (level to which scene devices go to in response to this controller) are where you want them. These responder levels can, by design, be different than the levels at the scene level, and can also be zero (turn off in response to an ON command).

Unfortunately, I do not have a synchrolinc, so I can only offer suggestions based on assumptions. You say that "3 minutes later is fine". Do you prefer later, or immediately? First I would create the two programs that you want to run, one for when the unit turns on, the second for when the unit turns off. These programs would require no conditions, and look something like: if (nothing) then do whatever you want else (nothing) I would then create two programs, one to watch for ON commands from the synchrolinc, the other to watch for OFF. They would look something like: if control "synchrolinc" is switched on then run first program (then path) else nothing If control "synchrolinc" is switched off then run second program (then path) else nothing

Not that I am aware. However, I don't find it overly burdensome to simply put the ISY into linking mode, then, simply, do the same for each new device. One does not have to return to the ISY after each new device is added.

The symptoms you describe strike me as indicative of a potential powerline communication problem. Do you see other signs of poor communication, such as lights sometimes not responding or slow to respond? Do you have access points or other dual-band devices? Do you have your PLM plugged into outlets with lots of other electronic devices?

As far as I know, the keypads have only two LED states: ON and OFF. The levels can be adjusted to reflect each of the two states, but I don't believe that a normally-functioning keypad would slowly increase or decrease in brightness. The only explanation I can think of is a faulty keypad. Perhaps you could remove the keypad from the ISY and perform a factory reset on the keypad?

According the the user manual, the ISY-994 is connected to the PLM via "standard cat 5e patch cable". This does make me wonder, however, if it is connected to the correct port. If you haven't already, it is probably worth confirming that the PLM is plugged into the "port A"

They should, but it seems the anecdotal evidence suggests otherwise. Perhaps range is better with access points. Perhaps the flexibility afforded a plug in module not tied to a physical fixture is beneficial. Perhaps installation of switches into boxes messes with range or performance. Who knows.... As for me, I consider the money I spent on my four access points to be well spent.

When I see a bunch of things apparently "failing" simultaneously, I try to think of common factors. Besides RF, this could also be explained by something that is causing a communication failure with the ISY, itself. a) do you see any other evidence that the ISY is failing to see insteon communication activity? do you seen any signs that the motion sensors are communicating with devices other than the ISY? c) did you recently add a new device to the outlet/circuit powering your PLM? There are a few, simple, experiments that could point to the root cause. Try moving the PLM to the same outlet as one of your insteon access points (use an extension cord, if necessary). Create a temporary scene, with a motion sensor as controller and some light as responder. Does motion trigger this scene?

I am actually surprised this program returns your temperature to the original temperature at the end of the period. if from time A to time B then do something else do something else Programs like this work such that at TIME A run the THEN clause, at TIME B run the ELSE clause. If you want it to change the temperature and the variable, you have to specify both, in each clause. Since your program had no ELSE clause, I don't believe it was this program which caused the return to the original temperature.

Not that I am aware. I assume you would know about (unless your memory is like mine) any program, or manual disable. I agree, there is nothing in the program that makes me suspect it would not fire on its own. I don't know about any particular advantage in breaking apart your email and cell issue, especially since you tested it out and it worked.

Since you did not post the program, I could only ask the general question. If you have satisfied yourself that it cannot be a program error, that is good enough for me. Your original post did not address the possibility (except for the THEN path working correctly), however, so I simply raised the question for you to consider. If there remains any doubt, feel free to post it for a second opinion. Of course, it could be the program being disabled, either manually or by another program. It could be part of a folder that is disabled. Yes, it could also be a logical condition error. Unfortunately, I don't have access to your program to do anything more than speculate.

Perhaps a program error?

The program is simple enough, but I cannot help but wonder if your TO time is causing trouble. I am unsure if "Sunset + 9 hours and 43 minutes " would be SAME DAY or NEXT DAY. As an experiment, you could temporarily change this to "Sunrise (next day)" and see if this solves the problem. Double-check, also, that the time being registered by the ISY is consistent with your time zone and location. Double-check that the program is "enabled" and confirm that you have no programs that would disable it or that the program is not in a folder which is disabled.

While "going into" your switches may offer clues, the obvious failure point sounds like the fixture wiring, itself. (This is where you originally "opened" or disturbed the circuit, correct?). Even if you observed no wires having broken free from wire nuts or terminals, this is still the place I would start. I have experienced open connections between two wires visibly connected by wire nut, but not making good connection for some reason. It seems easy enough to open the fixture again and simply tug on each of the wire connections to see if anything comes loose or free. Obviously, such action should be performed carefully, and with the power shut off from that circuit and any other in the box (if more than one circuit). Failing this, were you to post some pictures or detailed description of the wiring in your ceiling box, it may be possible to recommend some further troubleshooting suggestions. Pay special attention to: a) color of each conductor insulation (black? White? Red? Green? Other?) groups of conductors in a cable (one cable with black, red, and white conductor?) c) any markings on conductors (expecially white ones) that appear to be an attempt to identify it as a different color. This can include paint, ink, electrical tape. d) what conductors are connector to what other conductors, or to the fixture, itself.

I am with LeeG. I would be amazed if all six on a single circuit failed. I suspect this is a wiring issue. I would be checking for the proper voltages and neutrals at the various boxes.

One way to confirm this would be to temporarily disable the program, then see if your devices still respond to the motion sensor. If so, you still have scenes somewhere. You may consider performing a device restore from the ISY. Like LeeG suggests, in order to reprogram/restore/configure/set up scenes in a motion sensor, one must put the motion sensor in the linking mode, then write the changes to it. Do you see any little green arrows next to the motion sensor in the device listing? Failing those things, the best approach would be to remove the devices from the ISY, perform a factory reset on the devices, add back, then recreate any needed programs. Unless you see signs of communication errors, this may not be an issue. Long term, however, I believe it best that the ISY on a really-good circuit. Given this, I would filter your servers, and any other electronic gizmo on that circuit. The PLM is too important.

Which is why, at this point, simple is good. The program is fine. If you are having behavior that is hard to explain, look to issues other than the program. 1) As suggested by LeeG, it appears you may still have scenes in play, where a motion sensor is controller and some devices are responder, and the motion sensor is set with a 1-minute timeout. If you created these scenes manually (running around the house tapping buttons) , make sure you delete these scenes. Perhaps this could be done by "restoring" the device through the ISY. Alternatively, the instructions for each device describe how to do this. If the only devices you have in the ISY are the motion sensor, plug, and a few bulbs, perhaps it would be better to factory reset each, removing from the ISY and reading. 2) If you are seeing INCONSISTENT behavior, I would look for communication issues. Does it work sometimes or do the lights ALWAYS go off after 1 minute? Do all the lights go off sometime, or only 2 of 3 go off every time. When things work sometimes, but not always, I tend to think communication. With the ISY, WAIT statements can be interrupted. A program in a WAIT condition can retrigger and start over. I would not do this. I might try restoring the individual devices, or removing them all from the ISY and factory resetting them, but I don't believe restoring the PLM will solve whatever problems you are having. This might help if you are experiencing communication problems. It seems to me that the most common problems people continue to fail to understand is that one needs to couple the "phases" ("Legs" is more technically correct, I understand) of your electrical system, and that plugging the PLM into the same outlet as computers/UPS/surge supressors/printers/modems/routers can create difficulties. Next to the fuse box is good. A dedicated circuit would be good, if an overkill. Access points are good. Filters are your friend.

Yes. Until it all works then mine understands.

Putting a program in a folder may "disable" a program, but I do not expect this to halt a program, once running. When you say "some of the lights", are you stating that some lights within the scene "office lights" are responding as intended, but not all? Otherwise, please elaborate on "some". With your existing program, I see two possibilities that would prevent your lights from turning off. First, if the motion sensor continues to detect motion, it will reset the 15-minute timer. (This is how most would prefer, I suspect.) Second, the scene command fails to reach the intended recipients. There is a third possibility I can think of, but it would involve an ill-timed power failure. Otherwise, this program WILL continue to count down and execute the off command. If the program sends the command to turn the scene on (or off) and you notice only SOME of the lights responding, this tends to suggest (to me) that you have a communication problem.

Without seeing your program, it will probably be hard to state definitively. It could depend on whether you use status or control. It could be that something is interrupting the wait statement. It could be that you have scenes in play. It could be something else.

To continue the thought process started by LeeG, you may also consider a combination of things... Perhaps you would choose to use a scene to directly turn them on from a motion senso (perhaps a little quicker responding) and a program to turn them off. Make sure you explore the "options" for the motion sensor. You can configure the motion sensor to only send an ON command, using the ISY to shut them off after a period of time. But...you don't want both a program and a scene to turn them off. But, my preference is like Michel's: keep it simple. I would even go simpler than his example If Control 'Main Bath Motion.1-Sensor' is switched On Then Set Scene 'sMain Bath Lights' On Wait 4 minutes Set Scene 'sMain Bath Lights' Off Else - No Actions - (To add one, press 'Action') Like LeeG suggests, make sure your motion sensor is not part of any scene, and make sure it sends only ON commands. Unless you have some specific concerns (such as power failure during 4-minute countdown or need some type of manual override), I would expect this to work fine.

Yes, you would do this via a scene. Make the sensor a controller and rest responders. Depending on other factors (such as whether you want ISY to turn them off or take other action) you may need to configure the motion sensor to send only ON commands.

I see continued development. Micromodules have been recently released. 220V50Hz devices are now available. Over the recent years, we have seen the migration to dual-band devices. I see no signs of a near-term demise of insteon. Still, it is hard to predict the future.