apostolakisl

I think I see the issue. Your last program is disabled. It won't trigger from the status of those 2 programs changing condition. That last program must be called by another program.

Yep, I could do that indeed. My intent was to not have multiple scenes with different ramp rates. When I click a scene controllers, I want the 2 second ramp. The long ramp is only acting as a warning that the lights are going to be turned off soon, so better activate the motion sensor to turn them back on. For your second question, I think I answered it in the last post, which is that only the "Kitchen Occupancy" scene is "active" You would be better off having 2 scenes. They both can have the same lights in them but different ramp rates. The 19 second ramp rate scene would be activated by your program, the 2 second ramp rate would be activated by the switches. This is a much better way to do that then the repeat dims.

I was looking at the last program with the repeats. Why are you doing 20 dims separated by a second? Why don't you create a scene with those lights and have the dim rate happen over 19 seconds (which is the choice closest to 20 seconds)? Then you just have the "then" clause execute the scene. Of course this doesn't answer the question as to why the else isn't running when the "if" condition changes. I'll have to look closer, but I have to wonder if your else clause isn't doing something that makes the "if" clause true again. You can open the program summary page and watch the status of each program change as it happens.

Copy and paste all the program to the forum. Please add the name of each program since the copy/paste doesn't include the name and we will need those names here.

Keeping the program "true" does not stop it from re-evaluating the if and starting the timer over. For example, If control light x is switched on Then wait x minutes do something Else blank This program will restart the wait every time light x on button is pushed, even if it is already on. In short, anything in the "if" clause that experiences a triggerable event, will kill a wait/repeat and either start it over again, or run the other clause. At times, this is a good thing. Like if you have a motion detector and want every re-trigger of it to restart a timer.

The issue with non-interruptable waits/repeats has been beaten to a pulp. Indeed, it would be nice to have it both ways and probably UD will do something that allows you to choose. In the mean time, you accomplish the same thing by splitting the program in 2. If various conditions Then wait x time do something Else blank Can be changed to Program 1 If various conditions Then run program 2, then clause Else blank Program 2 If blank Then disable program 1 wait x time enable program 1 do something Else blank Now your "wait" clause will run to completion no matter what.

Right click on the program and click "run if". The program should turn true if it is during the day, or stay false if it is at night. Also, using the admin console, turn your fountain (or light) on/off to make sure that the communication is working between ISY and the target device.

Since you haven't said otherwise, I assume your programs are still running and all the stuff you expect to happen is happening?

You could put a micromodule controlling the load behind a KPL. Then one button would control a scene where the micromodule turns the light off and a different button would control a scene that turns the light on. This all seems way too complex in my mind, however. I use the cree lights and am quite happy with them. They do not flicker, but they do "pop" a little when they first light. They aren't capable of anything much less than 12% so as you ramp it up, you get nothing until you hit 12% then "pop" is on at 12%. Same thing on the way down, but it goes lower before it "pops" off.

CAI webcontrol has a function called "webset". You can have 8 of them where each one can be set with an ISY REST command. CAI can append the REST command with any of its values (like temp, analog input voltage, a variable, etc). You can look at CAI's user manual to see all of the values on page 27-30. Usually this would mean that you set an ISY variable, but you could also use a REST command to tell ISY to set an Insteon device directly rather than set a variable. Also, you can use a REST that doesn't get appended with a value, like a device fast on command. If you care to learn all of the the REST commands it is in the wiki. This thread has a lot of info viewtopic.php?f=81&t=10141&hilit=webset&start=15 And this link is to the CAI user manual. http://www.cainetworks.com/manuals/webc ... 02-17f.pdf

Xathros is probably right. Especially if you can use that scene to turn the lights on without issue but then struggle to turn them off. That is classic sign of a noisy load. Many CFL's are noisy, but there are also quite a few that don't cause any trouble.

----- Front House-Garage Test Results ----- [Failed] Garage Outdoor Lights (23 F2 6E 1) [Failed] MB C - Front House (24 16 3B 5) [succeeded] Hallway A - Front House (22 CB 5B 3) [Failed] Front House Lights (23 F2 B0 1) ----- Front House-Garage Test Results ----- This was the scene test, and you had 3 out 4 devices fail. You appear to be having comm issues.

The "or" line won't block the sunset line from running true. The level 3 is in the tools, diagnostics, event viewer menu, but before confusing yourself with that, just look at the program summary page and report that. The level 3 check will tell you about communications, but you won't understand it without a lot of research. You need to open the event viewer and set it to level 3 shortly before sunset plus 4 hours so that it is running when that program is supposed to execute. You can then copy and paste that to the forum for interpretation. Also you can run a "scene test" on that scene. This will give you an idea of how strong the comm is. If you are needing multiple hops that is a sign of weak comm.

Like Xathros said, if it is working sometimes, you probably have a comm issue. If you truly only have that single "if" condition, then there can't be a logic issue. Do you have a whole bunch of other things all triggering at sunset plus 4 hours? Is there some electrical device in your house that might be on at that time that is impairing communication? Check your program summary page. It should list the last time that program ran, the next time it is scheduled to run, and whether it ran true or false last time. You should see that it last run at roughly MN last night and was true. It should be scheduled to run tonight at about the same time. If indeed that is what it says, then you are for sure dealing with a comm issue.

You could probably hook the led up to the sense input on the iolinc also. If the device "seizes" your phone line, then you could run the 5v from the iolinc output to the phone line input on your alarm and then hook the 5v sense up to the alarm panel phone line output. When the alarm panel seizes the phone, it should cut off the 5v to the phone output wire and trigger the iolinc to register an "off" on the sense wire.

If it does not have any voltage out or contact closure to indicate it is in alarm status then you would have to rig it a bit. Does it have any led's that light up while it is in alarm or trying to dial? If so, you can solder on a couple leads to it and connect to a CAI webcontrol board and have it trigger an email itself or send a network command to ISY to do the same. When the LED turns on, the CAI will see voltage and you can use that to send a REST command to ISY. For example, the following program on ISY would check input 1 for voltage. If it is true (1), then it runs a subroutine that sets a variable on ISY to 1 (the webset command). When the voltage shuts off, it sets the variable on ISY back to 0. The webset language is set up separately and is just the REST command that sets the ISY variable you choose along with your ISY IP address, username and password. So, in summary, this toggles a variable in ISY between 1 and 0 depending on if the CAI is getting voltage or not (if the led is on). The CAI board draws essentially no current so you won't over-current your alarm panel. START TESTEQ IP1 1 CALLSUB ISYSET TSTEQ IP1 0 CALLSUB ISYUNSET END ISYSET: TSTEQ VAR1 1 RET WEBSET URL1 1 SET VAR1 1 RET ISYUNSET: TSTEQ VAR1 0 RET WEBSET URL1 0 SET VAR1 0 RET

That could work, but not in the usual way it is designed to work. The micro-module is meant to be hard wired to a regular switch and it senses that switch status and then the micro-module itself switches the load on/off to the device. So, you would still have the switch from the wrong room doing the controlling wired like that. You could put a micro-module and a switchlinc at each location and then link the switches using the Insteon communication and not hard wire the load wire from the switch to the micro-module sense wire. In other words, just cap the sense wires. Don't forget, the inline linc or micro-module can be placed in the box at the light fixture where you may have plenty of room. EDIT: Also, be sure to note that the micro module dimmer is only rated at 100 watts. The inline linc is rated 400 watts. If you have more than 400 watts you'll need the micromodule relay which gives you a full 15 amps but you get no dimming.

Are these the only 2 switches for the 2 respective lights? In other words, is the load wire for the light in room A in the switch box in Room B? If the answer is yes, then pretty much you would be looking at using an inline linc plus a switchlinc. If not, then you must have 3 way switches and it is a matter of putting a switchlinc where the load is and then putting another switchlinc at the other box.

I dont' have any Insteon motion detectors, but I believe your problem is that you are using "status" rather than "control". The motion detector is probably timing out and sending an "off" command prior to the 3 minute wait, which is terminating your program "wait" and re-evaling to false and running the "else" clause . . .which is blank and does nothing.

Just curious, with mobile linc, you have to buy it for each device, not for multiple devices on each account? Do they charge for these plugins (like voice/elk/etc)?

In the case of android, tasker handles the geo-location duties. When tasker senses crossing some threshold, it will call on mobilinc to perform the insteon duties. My experience that the state of mobilinc matters not at all. Tasker runs in the background. Just reading this thread and noticed this. Mobilelinc is not necessary to geo-fence, only tasker. Tasker can send REST commands to ISY directly. The simplest thing to do might be to have Tasker set a variable on ISY which indicates you have entered the geo-fence and then let ISY do the rest. Similarly, you set Tasker to "un" set the variable when you exit the geofence. Tasker is an incredibly powerful tool, albeit not the simplest to figure out.

The only security system the ISY natively integrates with is Elk. Elk is compatible with a couple different wireless protocols including caddx.

1) none of the hot water tank will empty if the break in the line is at a higher elevation than the tank. Most tanks are in the lowest room in the house and most water lines, at their lowest, are at least a couple feet higher than the floor of the room they are in. 2) if the hot water tank is higher than the break, it will only leak until a vacuum develops. Water can't leave the tank if air can't get in. 3) if the "break" is just a drip type leak, it will stop when the psi drops sufficiently.

Thanks for the experimental data. Just for the sake of completeness, I do not have an expansion tank on the hot water tank . . . I don't have a hot water tank (I have tankless). If you had relief tank, you would have maybe 1/2 gallon of reserve pressure. Also, I suppose if you had a hot water tank in the attic, you would have more of an issue with gravity and stuff. How much I don't know, it wouldn't take too long for the vacuum to set up and stop flow from the tank. But most people put the hot water tank in the lowest part of the house (basement/garage).

Hmm.... Didn't think of that. The lip of the mat is flush against the back wall. I just poured a cup of water down the back wall and most drained into the mat and set off the sensor. I think I'm good in the kitchen. That might not work for the utility cabinet with washer since it's a textured wall rather cabinet back. I'll have to rethink the idea of getting one for in there. The leak at my house ran down the inside of the wall. It soaked the insulation and sheetrock and got the wood floor that butted up to the sheetrock wet which is what tripped the water sensor. This was behind the dishwasher. Had I had a pan under the dishwasher and this in the pan, it never would have tripped. I had to pull the dishwasher, rip out the sheetrock and insulation and repair the pipe. I put new insulation in but didn't bother with sheetrock. I didn't see any reason for it behind the dishwasher.