apostolakisl

Certainly if you had your clock set to sync with ntp at or near midnight it would lead credence to this theory.

Do you have any other programs set to trigger at or just before the time this program triggers? Or any other programs that are running, possibly in some sort of loop? That might explain the delay, but I don't know how to explain a complete failure to run, except if ISY is off at the time. I have had those programs running for a long time (like 3 years) and it has never failed to run, not even once. And you have had 6 in the past 6 months. Of course a failure to run at a specified time would not be specific to any particular program, but I am unaware of any scheduled program not running at the scheduled time on my ISY, though I might not notice some of them failing. I do like your idea to have the program trigger just prior to midnight and execute just after midnight. That is a clever way to leave your "catch up at restart" on without screwing up the date programs. Although I have my ISY on a UPS so it shouldn't be necessary. But ISY just completely blanking on running a scheduled program. . . Hmmm. Another possibility is a bug or error in the firmware. Have you tried updating the firmware? Lastly I suppose there could be a fault in the hardware, but it seems like that would fail more consistently. EDIT: Also, you are quoting the log as your source of runtime. But the log is generated separately. It could be that only the log time is delayed, not the actual run time. Have you checked your "last run time" in your program summary page to see if it is the same as your log time?

It sounds to me like you want to create schedules for your thermostat that are specific to a time of year (season). The following set of programs http://wiki.universal-devices.com/index ... _Variables allows you to create programs for your thermostat that are season dependent. for example If $i.month >= 1 and $i.month <= 4 and time is 8am Then Set thermostat to 70 Else - - So from Jan to April of every year the thermostat would set to 70 at 8am. Obviously you create as many programs like this as you want and include whatever parameters you want. Like if you have weather bug you could have the thermostat also depend on the outside temp in deciding the inside temp.

Interesting item. Do I understand correctly that this product requires that you use their server to use it? If so, is there a subscription or is it "free" for anyone who buys the hardware? And also, are you sol if the company goes belly-up? I have a couple of "chumby" items that are now pretty close to useless since they went belly-up.

Maybe I misunderstood, but I thought the original request was to detect whether the vehicle was IN the garage, not whether it is coming or leaving. Still, if the sensor was off and suddenly turned on, I think one could reasonably infer that the car just arrived. Obviously, a combination of sensors and logic would be required to ensure that it was a car, and not a lawnmower (or a person), but this is an issue not necessarily unique to this particular solution. Perhaps you meant that you would put the gizmo where the car normally sits instead of a couple inches from the door, where they normally are. Basically just an IR beam. That would work, and I suppose you could write some program to ignore if it just briefly gets interrupted (like if someone walks through it) versus if it were continuously blocked for maybe a continuous minute. This actually might be the easiest way to do it if you are willing to accept the outside chance that something besides a car could block it long term.

Except that it can't tell the difference between coming and going, or even if it is just a person breaking the beam as they walk in or out. If there were a wireless Insteon device that you could query, that would do the trick. Just put it in your car and connect it to the battery. Have ISY query it once every couple minutes, if it responds, then the car is there, if not, car is gone. The water detector might do that, but I don't think it is query-able.

The one I listed uses magnetic field to detect the presence of the vehicle, not ultra sound. I only could figure that out because it lists all the sensing specs in units of gauss. I did find how it receives signals. They sell "gateways". Unfortunately it looks like this is a subscription service that costs at minimum $39/year for them to send you texts or emails when the thing is triggered. You might be able to hack it? Hard to say. The usb gateway is $49 and the detector is $79.

I found this http://www.monnit.com/Products/Wireless ... ce-Sensors I can't figure out what receives the 900mhz signal it sends however. The documentation is quite vague on that. I was also thinking of a pad that one of the vehicles wheels would drive onto. This would close a connection which would trigger an IO linc. You could build something like that with a simple open/close circuit.

http://wiki.universal-devices.com/index ... _Variables I wrote this about 2 years ago. I just wrote some programs that do hour and minute a couple weeks ago too. They are in a forum post. All of these programs are most reliable if you have a ups.

There is no "flash" command in insteon, so the only way I know to do this is through a program. I forget the exact program language, but it is something like: repeat three times turn light on wait x seconds turn light off Yes, and if you want it to work so that it stays in the same state. If status basement light is not off and driveway sensor goes off Then turn light off wait 1 sec turn light on If status basement light is off and driveway sensor goes off Then turn light on wait 1 sec turn light off Although I tend to think the second program is not necessary since I'm guessing the basement light off means you aren't in the basement.

As Lee mentioned, those programs I wrote above are using "control". I really should copy real programs to keep things technically correct. They demonstrate the only time you use that combo of "is on, and is not off". This is because "control" programs only trigger when you do the exact thing listed (like push the "on" button of the actual device for a program stating "control is switched on"). Dimming or pushing off will be ignored by the program. That is why you need the "control is not switched off" line, to trigger the program when "off" is pushed. "Status is not" is often times used to encompass all of the states of a device being on. Since "status is on" means 100% on, and you might want to include all amounts of on from 1 to 100%, then you say "status is not off" to include all of those. In these programs status is not off and status is on are both saying the same thing for a device that is either on or off. For a device that could be in between, then the "status is not off" line becomes irrelevant since the program will behave exactly the same without it. It will be true when something is on 100% and false at any other time. It will trigger the same as well (with any change in state).

Including the "not off" statement is to drive the "else" clause. If you don't have an else clause, it serves no purpose. For example: If x is switched on Then do a Else do b This program will never run an else clause. the only trigger is it turning on. If x is swithched on and x is not switched off Then do a Else do b Now switching "off" the device is also a trigger. So, switching "on" runs the "true" and switching "off" runs the "else". Pretty much any time you use "not" anything, you are using it to drive an else clause.

The only way ISY will be able to control speed is by getting a fanlinc. The only possible caveat to that is that you could train an irlinc or global cache unit to shine the ir commands to the fan from a nearby location. This assumes that the remote that came with the fan is ir based.

That program doesn't do exactly what you asked, but it might be what you meant. "(changed from Off to On) I want to wait 10 minutes and check that sensor again. If it is still on I want to send an sms notification." Taken literally, this could mean you want it to ignore any off/on cycles that happen during those 10 minutes. This won't be the case. That program will only send you an SMS if the i/o linc were continuously on for 10 minutes.

This is because outlook doesn't get emails pushed to it. Outlook runs a send/receive at whatever interval you set it to in the options. So outlook doesn't know there is an email waiting for it to receive until it runs its next check.

Afraid I am at a loss here. I have never seen a switchlinc behave as you say with the led's flashing and the load flashing. When you push the on button on a switchlinc, the led's should travel up to the "on level applied locally" setting. The load directly connected to that switch will always do the same. It won't matter what scene it is a member of or if it is in any scenes at all. In this respect, an Insteon switch behaves just the same as a non-insteon dimmer. The only possible way to alter that behavior is with a program in ISY, but still, what you describe still makes no sense. Of course none of the switches local or scene behavior requires ISY. So if you wanted to rule out any ISY affect on the switch/scene, you could just unplug it. ISY is only a tool to setup the switches or to run programmed events.

I guess ISY firmware needs an update to support the higher temps. Not sure why it doesn't already, perhaps there is a reason that isn't so simple. I am sure Michel will chime in with an answer to that. A solution would be to use a CAI webcontrol board with a waterproof 1-wire temp sensor. The CAI can be programmed to post directly to ISY variables on any schedule or condition you like. Or, you could skip the ISY and program the cai board to cycle the recirc pump on its own.

Your saying some weird stuff. Why are you pushing buttons with the tip of a screwdriver? Which buttons are you pushing with the tip of a screwdriver? What happens when you push them with your finger like normal? Aside from physically breaking a switch using an instrument instead of your finger, it shouldn't matter what you use to push a button.

120v smokes have a third wire for comm. The hot and neutral don't carry any comm. But it still is not code to use the hot/neutral for anything besides the smokes and (unlike some codes) this code is actually a really good idea.

The main 2 kpl buttons on a 6 button device are the same as pushing the on or off side of a switchlinc paddle. They are not listed as two separate buttons. Looking at your screen shot, it appears that it is already done correctly. Your "All On" scene has all three devices as responders and the two KPL's load switches as controllers. It should work. But I wouldn't name it "all on" since it doesn't only turn them all on, it also will turn them all off if you push the off side of the kpl. So, in short, it appears you had everything correct from the start. Perhaps you had some comm failures because something in the house turned on that was making noise. Edit, and by the way, the blinking kpl buttons happens when there is a comm failure.

What do you mean "I switched the paddles on the switchlincs"

I have a lot of experience with Harmony remotes and ISY, however, not the "smart control" model. Though I suspect it works the same as the other harmony remotes of which I have 2 890's and a 900. I presume the harmony base station emits IR commands on command from your phone or the included remote. The base station IR output needs to point in the general direction of the ISY input. Harmony has the 40 ISY base commands built in and it sounds like you already added those. You also need to install the 40 base commands to ISY. If you use all those up, you can add more using the learning mode for both ISY and Harmony. Then you need to write programs in ISY that respond to triggering the 40 base commands. If IR 'IR_013' is Pressed And Status 'Theater / Theater Sconces L' is not Off Then Set Scene 'Theater On' Off Else - No Actions - (To add one, press 'Action')

First off, use the search function in the programs editing section and search the name of the switch (edit: also any scenes that is a member of) to make sure it only exists in the programs you specified. Obviously if it exists in an unintended location, delete it. If all looks good, then you will have to wait until the problem occurs again. If/when it does, go back and look at your log. Also use the programs summary page to see what programs ran, when they ran, and whether they ran true or false.

You didn't mention a fanlinc, but I assume you have one. This post tells you how to set up a kpl with a fanlinc. You will see that some of the setting have kpl buttons as controllers. A KPL button that is not a controller of any scene will do nothing but light up when you push it. For a button to control anything besides its own load natively (as a pure insteon device), it must be a controller of a scene. viewtopic.php?f=26&t=10312&hilit=fanlinc+setup The concept is as follows. You have 4 scenes, one each for high, med, low, off. You dedicate 4 kpl buttons to those 4 states. Each kpl button is in each scene, one of them is a controller, the other 3 are responders. For example, the "high speed" scene might use button A. So button A is a controller of the scene and sets the fanlinc to 100%. The other 3 buttons are responders and set to 0%. the "medium speed" scene might use button B. Button B is a controller and sets the fan to whatever it needs to be for medium (like 60% I think), and the other 3 buttons are set as responders of 0%. etc. So in the above example, button A is the only controller of a scene with the fan and the other 3 buttons as repsonders. When you push A, the fan responds by going to 100%, and whichever of the other 3 buttons will shut off. Technically, you don't need the other 3 buttons to shut off, but it is a nice feature. This way it will only have the one button lit that corresponds to the current speed.

It may be the installing a new OS fixes your problem, but in that case it would indicate a corrupted xp on that computer, not that xp itself is problematic. I have 8 computers running xp and all of them run the admin console just fine.