apostolakisl

I think I am going to use this idea. When we have a house sitter, I will have her Elk code activate a notify setup. If any light switches are turned on in the parts of the house she is not supposed to be in, it will send me an email.

As mentioned, there is no need to ever abort anything. The program that would enable/disable the folder would run in a split second, you couldn't abort it if you wanted to, it would have already finished running. I would be quite surprised if you used some pet sitter who would start pushing unlabeled kpl buttons that might be at some random location in the house knowing that it might turn on/off tracking of them. Furthermore, if you put it in a room that is tracked, they wouldn't be able to get to it without triggering the tracking anyway. Like a KPL in the master bedroom. Lastly, if you have Elk, you can use the last user function to activate the tracking. I assume you have given your house sitter there own code, and Elk can simply enable that folder of programs whenever the last user was the house sitter, and disable when the last user was you. The last user function is only in Elk rules (not ISY), but you can have it turn a phantom output on/off which ISY would then use as a flag to enable/disable the folder. This of course is the slickest, since it requires no additional action on your part. .. it will function automatically.

Most people would use a kpl for things like this and assign one of the buttons. That gives you a way to simple push a button in your house to activate/deactivate. Or a program as suggested to toggle the variable. The "then" could set it to "1" and the "else" could set it to "0".

Along the same lines as the 2 second delay would be to right click the program in the program tree and click "run then". This will eliminate the possibilities that Insteon transmissions are interfering with x10. Furthermore, you might move the plm to an outlet near the x10 device or vice versa to further determine if it is noise or signal attenuation.

I'm in this camp. I would describe it as "sheltered". I have switchlincs for 4 years now in a third garage which is unheated/uncooled and no problems. Of course I have also had a number of switchlincs go bad that lived their whole lives at 72 plus/minus 2. I have never let any of them get wet.

OK, I read it again, and indeed it sounds like it may toggle the light with a toggle in sense. I had read that manual prior to oberkc's post but I guess I read to quick. I think I was biased because the older discontinued switches with sense built-in didn't do that if I recall.

That's not how I understand the sense to work on this module, but I'm probably wrong. I don't have one yet. Does a change in the sense wire TOGGLE the output (the way I hope it works) - or does the output follow the state of the sense wire (and controlling via insteon essentially let's the two get out of sync with each other - necessitating the double switch)? If the latter, I guess I won't be buying any. Michael. That is also how I would HOPE it would work (toggle the sense causes a toggle of the load, paying no attention to the actual state). Or at least have that as an option. But, it does not appear that such an option exists. It really does not seem like it would be a challenge to write that logic into the firmware. In my mind, this would be a very well liked feature.

That is not much different than the historically-typical three-way. Up or down has no meaning with those, either. Yes, I prefer up=on, but we have lived with other options for a long time. Theoretically, if there was enough space in the box, one could simply keep ALL the existing switches and install a micro module somewhere to power the fixture. Instant insteon. No, not up or down, up and down. With sense if you turn the light on with a switch, then turn the light off with Insteon command, then want to turn it back on with a switch, you need to turn power off to the sense wire, then back on again. Depending on which way that particular switch is at that time it might be up down, or down up, but either way you are switching back and forth, which ain't right.

You don't want to do the sense micro-module. It is totally screwy having to turn a switch up/down or vice-versa to turn a light on. That is just goofy. If they programmed the sense to change state on a change of the sense state that would work. In other words, whatever state the micro-module is in (on or off), it will go to the other state if the sense changes from whatever state it is in, to the other.

It would have to be an ACK that the PLM is looking for. I don't think a failed ACK from a device when the PLM wasn't the controller will trigger ISY to update the responder/non-responder status.

Post your program. You probably made the classic mistake of not putting a "turn off the lights" command in the else clause. For example If From 6:30:00AM To 11:00:00PM (same day) Then Set Scene 'Christmas Scene' On Else Set Scene 'Christmas Scene' Off ISY logic is that "from" time triggers the program and runs "then" and "To" time triggers and runs the "else"

Well, this somewhat limits the value of the responding/not responding programming clause. What it comes down to is either a direct action taken on the device, or an action taken by the PLM/ISY on the device are the only events that would pass real response info back to ISY.

So I can assume the converse is also the case. In other words, if a switch that ISY had previously recognized as responding (no red exclamation point next to it) fails to respond to a scene command generated by another switch, ISY will assume it did respond.

Yes, I didn't read what you read careful enough. If you are OK with eliminating the other switches you will probably be OK as stated. You will need to splice wires and then cap the boxes. And if you have 3 switches on the light, you actually have a 4-way switch. And I could be wrong on this point, but I don't think anyone ever wires a 4-way switch by switching the neutral rather than the hot.

I also came to notice that using the light switch as a responder in a scene does not update the responding status in ISY. I had it listed as a non-responding switch in ISY by pulling the disconnect, then using ISY to try to turn it on. Then I reset the disconnect and used another switch that it was in a scene with. The switch in question changed status (and thus presumably should have updated ISY), but ISY continued to list it as a non-responding switch until I used ISY to control it or until I directly pushed it. This was repeatable. Shouldn't ISY have recognized that it was alive when it changed status responding to that scene?

Sorry, not possible. All 3 need to be Insteon.

This sounds exactly like every other STATUS condition, correct? Not exactly. The status of the light as far as on/off/x% does not trigger this program. Only if the status "responding/not responding" changes does it trigger.

Indeed. If Status 'Kitchen / Kitchen Micro-Island' is Responding Then $Int_56 = 10 Else $Int_56 = 5 This program ran false upon my first action taken on the switch after the hard disconnect was pulled and true upon the first action taken on the switch when the disconnect was restored. And changing the languange to "is not" simply swapped when the "then" or "else" happened. And forcing a "run if" after the switch was already in a hard disconnect also caused the "then" or "else" to execute properly.

I was able to get my connection back up. Indeed it appears that "status responding" is not a self triggering clause. I turned the device on/off and querried it and the program never ran. A "run if" got a "true" result. So it is like a regular "status" statement in that it checks the current status in the ISY database upon encountering the clause. It is not however like a regular "status" statement in that it does not self trigger on every change in status. I will pull the gap on one of my switches when I get home and see what happens. I would expect a "run if" to result in a false result provided I first try to communicate with the switch so that ISY has it as not responding in its database. EDIT: after reading the above post which happened during my writing of this post, it appears that he is saying that a change in the status of responding vs non-responding is a trigger. Other changes in the status of the device are not proving to be triggers.

That is, at least, the best working theory so far. If this is the explanation for why it is not returning TRUE when manually triggered, then that aspect of this statement is unlike other STATUS statements, and more like a CONTROL statement in this regards. I would be disappointed if this proves to be the case. I just checked it. It is like "status". I am at the office so I can't pull the disconnect on one of my switches to check what happens when it is not responding. However, unlike other "Status" events, the program does not run when the status of the light changes. As far as I can tell, "status is /is not responding" is not a self-triggering clause. EDIT: I need to play with this when I get home. My remote connection keeps dropping.

No...I find this consistent with other STATUS conditions. These all respond to any CHANGE in status. A CONTROL condition, by comparision, only responds to reciept of the expected (whether ON or OFF) command, regardless of whether this constitutes a change (receipt of two ON commands in a row would, for example, twice trigger the program, whereas only once for a STATUS). Neither will a CONTROL ON condition will trigger from receipt of an OFF command, or vice versa. Another difference is that CONTROL conditions respond only when the specified device is acted upon locally. STATUS will trigger whether initiated locally, or as a result of being a responder to another insteon device. Oberkc: I agree with everything above, with the addition that a STATUS condition can be queried to show the current state of the device. (For example a program with "If Status "Bedroom Light" = ON" can be run at anytime and will evaluate either True or False based on the CURRENT condition of the bedroom light). This is the part that the "Status = Not Responding" doesn't seem to follow (unless I'm missing something...). If I have a device showing a red ! (i.e. not responding), and I run the following program: If Status 'Device' is not Responding Then Send Notification to 'Brian E-Mail' content 'Not Responding' Else - No Actions - (To add one, press 'Action') It should return "True" and execute the "Then" for as long as the red ! is present. It does not do this, and according to TJF1960 this is by design. It should also (as you say) execute the "Then" anytime the device goes from Responding --> Not Responding. This works properly. "is not" means the same things as "is" except it runs the "else" clause. You would want to write your program as follows. If Status 'Device' is Responding Then - - Else Send Notification to 'Brian E-Mail' content 'Not Responding' If you force run the program, then it will be false if it is not responding

In this situation, And vs Or makes no difference. The result will be the same. An "on" command will drive the "then", an "off" command will drive the "else" If Control 'device' is switched On And Control 'device' is not switched Off Then If Control 'device' is switched On Or Control 'device' is not switched Off Then The logic is as follows. This stand alone program has only 2 possible triggers, 1) pushing the "on" paddle 2) pushing the "off" paddle If the "on" paddles is pushed, both clauses will be true. So it doesn't matter if they are connected by "and" or "or" If the "off" paddle is pushed, both clauses will be false. So, again, it doesn't matter if they are connected by "and" or "or" The purpose of the "is not" clause is to have a trigger for the "else" statement. Without the "control is not switched off" line, there would be nothing to trigger the program to run "else". So if you want one thing to happen when the "on" paddle is pushed, and a different thing to happen when the "off" paddle is pushed, you write it this way. The other choice of course is to have two separate programs.

CAI webcontrol is well suited to this. It uses 1-wire and can handle 8 temp sensors on one unit. The CAI has a built-in function for posting to ISY variables. It also has one humidity input, 8 ttl outputs, 8 digital inputs, and 3 analog inputs. ISY can also post directly to CAI variables or directly turn its outputs on/off.

How old are your switches? Some older switches require a power cycle when re-programmed. Try pulling the disconnect tab for 10 seconds and then popping it back in (don't hold it in or you will factory reset the switch. .. which may be the next step in fixing your issue anyway).

I'm not exactly sure what you mean by fast on. I think you mean that it is ramping up at the .1 second rate rather than actually being a "double tap" fast on. To set up a simple virtual 3 way where all the switches do the same thing. 1) Create a scene by clicking "link management" then "new scene" 2) Add the switches. Right click the switch in the main tree on the left and click "add to scene" then use the list of scene names and click on it. Check the box to make it a controller. You can also drag and drop it. Repeat for all switches in scene. 3) Click on the scene in the left column tree. 4) In the right pane in the middle, click "apply changes to all devices" 5) Slide the ramp rate and on level to where you want them. 6) Click on the individual devices under the scene name in the tree on the left. 7) For each device click in the right pane in the middle "copy scene attributes from. . " The 2 key steps are step 4 and step 7. Step 4 makes all the switches respond to the scene command the same. No matter what activates the scene, all the devices will do the same thing (except the switch you actually pushed, it may or may not respond the same, see next step). Obviously, don't click this if you want some switches to do different things. Step 7 makes each switch respond the same as the scene when you physically push on THAT SWITCH. When you physically push a switch, it responds to "applied locally" attributes, not per any scene it may be a part of. Again, don't click that button if you want the button to behave differently when you physically push it vs when it responds to a scene. Trying to break it down, if a switch is a controller, when you push that switch, it does 2 things, it sends out a scene command and it does its own local thing. The scene command is heard by all switches and if the switch recognizes the scene name, it responds. If not, it ignores it. Pushing a switch will always make that switch do what it is programmed to do when pushed locally, any behavior it has related to any scenes is irrelevant. While this may seem complex, it is what makes the Insteon network so uniquely programmable. You can have things behave very differently depending on your desires.