ergodic

Any ISY program that changes the state of what also triggers it, is mostly doomed to inexplicable logic failure of some sort. Use two programs, one to trigger and one to test/execute. Leave the second disabled so it is only called explicitly by the trigger and not by ISY re-evaluation. Something like this: //P1: If status 'Porch Sensor-Sensor' is ON Then Run Program 'P2' (If Part) //P2: (leave disabled) If status 'Porch Lights' is not OFF and status 'KPL U1-A "Party"' is OFF Then set scene 'porch lighting' Fade Up wait 2 minutes Set Scene 'Porch Lighting' On

SH has the Minotaur moisture sensors. You could use the X10 version with an X10 powerflash (cheaper) if you have X10 ingress to your ISY, or the Insteon version with an IOLinc (more $). I bought the Insteon to use as a floor water alarm where I have an automated catbox inside a closet that's connected up to the water supply, but I haven't received it yet so I can't vouch for it firsthand. But for a fountain it might be a little cheaper to get a float switch at your local plumbing supply, epoxy it to the inside of the fountain unobtrusively somewhere, and run that to the IOLinc sensor input. It all can get a little complicated because it's outdoors. My solution was simply an outletlinc in the outdoor box fed off an inside GFI, and a fountain pump with a builtin thermal cutout. One in the front and one on the back patio. The back one ran dry for three days one time with no harm. These pumps cost a little more, but are easy to find if you search a bit and that seems simpler to me.

Note there is a straightforward to do this sort of 'toggle'-type of thing just using two simple programs: The first program waits for the keypress event and calls the second program. The second program tests the state of the device and runs the Then or Else part accordingly. The 'trick' is that the second program is always disabled, so the only time it gets evaluated is when the first program explicitly calls it. For example: Program P1: If Button is Pressed Then Run Program P2 (If Part) Program P2: (leave permanently disabled) If Status Device is On Then Set Device Off Else Set Device On IOW, separate the event you are waiting for from the status you are testing into two programs. The testing program is always disabled so the ISY doesn't poke around in it whenever the status changes. In this type of construction of a disabled program the "If" actually becomes more of a conventional programming-type "If", and so the Else clause can be quite useful here.

I have my front and back landscape on separate 300W transformers connected to regular SL dimmers connected through GFIs -- which I typically run at about 50% at night. Other than a little buzzing from the transformers because of the line switching at mid-load it has worked fine for 2 years. (Obviously dimming isn't an option with LED landscape lights.) If it were me personally, I wouldn't be comfortable running that close to the margins. Two separate, smaller transformers with an outletlinc, or sl relay/dimmers would be my choice. OTOH you're not really risking anything except premature failure of the controllers. Regarding screw-in LEDs I'm using the Pharox with Insteon in a few places indoors and I can say it performs well. Like all LEDs the output is overrated some - I'd say about 40-50W equivalent. But it dims down to about 15%, no flicker, not much heat, no problems and good color. It does have a metal jacket around the lower base so the light spread is reduced below the bulb. Not cheap either of course. If I could just find a decent dimmable MR16 50W halogen LED replacement for my ceiling downlights I'd be in hog heaven.

I'd like the wait 0 (or something) to be able to allow the ISY to check whatever conditions have changed and call the appropriate body program. The same as any other wait - just without a minimum delay. As long as the condition program and the body program are separated (as they are) it could be that body program or some other. Whatever the various transitions call for. In more specific terms, if you have S1.Cond/Body and S2.Cond/Body. S2.Cond says: "If S1.Body is true and " and the S2.Body it runs has this new "wait 0", there's no way it's re-entering S2 again because S1 is now false.

No, if you're writing event-driven conditions then you don't know which program to run, or if you want to run one at all - only the conditions on the target states "know". IOW you just want to give the ISY the opportunity to evaluate any changed conditions and run the appropriate program. If not, it just comes back. Then if you get there you know nothing is pending and you can indeed do a run program to jump to somewhere else. Since a "wait 0" has no documented semantics currently and does nothing anyway, I can't see the harm in having it do this. But wait .1 seconds would be OK too. An unnecessary 1 second delay in program execution is too long though.

But if the X10 from the MS is just being translated to Insteon scene commands, isn't that pretty much the same thing signal-jabbering-on-the-line-wise? Or am I missing the point, as I frequently do.... My musing mainly was to whether there is something available that could receive RF directly from the X10s and translate to network commands (which could then be sent to the ISY via the network module). I'm pretty sure it would be do-able with something like Homeseer and an X10 pickup isolated behind a Filterlinc or some such, but aside from requiring a PC to work, the net delay would probably be unacceptable. Especially given that the ISY program response delay is already kind of at the edge of what one wants to live with.

Chris: Could a wait 0 could be interpreted in a future release as with any other wait, but with a 0 minimum delay? It seems - just standing from the outside of course - that it would be quite useful, since the current wait minimum is 1 second and it would be most helpful to have some way just to let the ISY check what's going on. Darrell: I obviously have a lot of rethinking to do as regards motion sensors. The EZX10RF works flawlessly for what I've used it for and the ISY hooks in the Insteon scene-linked X10s perfectly. I only have a couple of X10 devices left on it, but it seems that may change soon, just based on what you've told me. Again, thanks for that. Since the X10 MS is an RF device, I'm wondering if there's any solution to translate X10 RF directly to either Ethernet/wifi network commands or to IR? That would serve to keep all that X10 jibberjabber off the powerline entirely until it got to the ISY, assuming there is no open X10 pickup plugged in. And the EZX10 and (I think) the 572 both can filter things out selectively as I recall.

I think the Kit.Motion.Body.S1.Sub substate has to be called explicitly, otherwise the ISY never gets a chance to invoke it because S1 runs through without any wait. (It isn't disabled.) Is this incorrect? The call to .IsNight from the resting state was just initialization. You're entirely right that it is probably superfluous. Believe it or not, I didn't know that about the motion sensor design, but it perfectly explains the occasional odd behaviors I've noticed -- I'd just chalked them up to comm issues. They ought to make that jumper 5. Thanks! Now that I've also replaced all my evil V35 switches I'm getting back very close to Insteon Nirvana once again! I do have a buttload of the X10 MSs sitting in a box, bought on one of their endless, hyperactive-GIF, email "closeouts," and an EZX10RF I don't really use for anything now. And stylewise I (and my Ms.) prefer the little X10s as they're less obtrusive - the bulky 2420M seems a little obnoxious used indoors. I may switch back to the X10s and just endure the every-three-months battery changing ritual. Anyway, using your idea to fix it I just added another state (S4). But I also realized while I was doing it that the S3 state isn't really necessary. I also put in a little .IsMotion program/function to tighten it up. So here's what I end up with. I just made the changes, tested it, and seems to work fine, at least at nighttime. And now that it just occurred to me I can insert code in this #!%@!% bbs, it should be a whole lot easier to read! S0: Resting state Jumps to S1 when motion is detected and it is night Jumps to S2 when motion is detected and it is not night S1: Nighttime state Turns up the island light Jumps into S2 S2: Waiting-for-both-MS off state Jumps to (new) S4 when status of both MSs goes to 'off'. Just as a failsafe, after 4 hours, flows to S4 anyway, haven't really thought this through... S4: Waiting-for-either-MS-on state Jumps back to S2 when on is received from either MS Otherwise after 15 minutes turns off the lights and flows back to S0 Here are the revised programs ===== Kit Motion.Cond.S0: ===== If Then Run Program 'Kit Motion.Body.S0' (Then Path) ===== Kit Motion.Body.S0: (marked for run-at-startup) ===== If Then Run Program 'Kit Motion.Body.S1' (Else Path) Run Program 'Kit Motion.Body.S2' (Else Path) Run Program 'Kit Motion.Body.S4' (Else Path) ===== Kit Motion.Cond.S1: ===== If Program 'Kit Motion.Body.S0' is True And Program 'Kit Motion.IsNight' is True And Program 'Kit Motion.IsMotion' is True Then Run Program 'Kit Motion.Body.S1' (Then Path) ===== Kit Motion.Body.S1: ===== If Then Run Program 'Kit Motion.Body.S0' (Else Path) Run Program 'Kit Motion.Body.S2' (Else Path) Run Program 'Kit Motion.Body.S4' (Else Path) Run Program 'Kit Motion.Body.S1.Sub' (If) Run Program 'Kit Motion.Body.S2' (Then Path) ===== Kit Motion.Body.S1.Sub: ===== If Program 'Kit Motion.Body.S1' is True And Status 'Kitchen Island' < 50% Then Set 'Kitchen Island' 50% ===== Kit Motion.Cond.S2: ===== If ( Program 'Kit Motion.Body.S4' is True And Program 'Kit Motion.IsMotion' is True ) Or ( Program 'Kit Motion.Body.S0' is True And Program 'Kit Motion.IsMotion' is True And Program 'Kit Motion.IsNight' is False ) Then Run Program 'Kit Motion.Body.S2' (Then Path) ===== Kit Motion.Body.S2: ===== If Then Run Program 'Kit Motion.Body.S0' (Else Path) Run Program 'Kit Motion.Body.S1' (Else Path) Run Program 'Kit Motion.Body.S4' (Else Path) Wait 4 hours Run Program 'Kit Motion.Body.S4' (Then Path) ===== Kit Motion.Cond.S4: ===== If Program 'Kit Motion.Body.S2' is True And Program 'Kit Motion.IsMotion' is False Then Run Program 'Kit Motion.Body.S4' (Then Path) ===== Kit Motion.Body.S4: ===== If Then Run Program 'Kit Motion.Body.S0' (Else Path) Run Program 'Kit Motion.Body.S1' (Else Path) Run Program 'Kit Motion.Body.S2' (Else Path) Wait 15 minutes Set Scene 'Scene: Kit On' Off Run Program 'Kit Motion.Body.S0' (Then Path) ===== Kit Motion: IsMotion ===== If Status 'Kitchen: Motion (Oven)-Sensor' is On Or Status 'Kitchen: Motion (Sink)-Sensor' is On Then Else ===== Kit Motion: IsNight ===== If From Sunset - 30 minutes To Sunrise + 30 minutes (next day) Then Else ===== Kit Motion: Reset State (just for debugging, not needed) ===== If Program 'Kit Motion.Body.S4' is False And Program 'Kit Motion.Body.S2' is False And Program 'Kit Motion.Body.S1' is False And Program 'Kit Motion.Body.S0' is False Then Run Program 'Kit Motion.Body.S0' (Then Path) Overall I think the formula kind of boils down to this: 1) Draw your diagram. Begin by drawing a circle for the resting state and being thinking about what events trip you out of that. The rest will flow from that pretty quickly though it may take a few tries to get the logic right. 2) For every state in the diagram you will have two ISY programs: a body.state and a cond.state. Exactly one body.state program can be true at a time; that tells what state you are currently in. 3) The body.state program has no conditions, just a "then" clause. It first sets all other body.state programs false. Just boilerplate. It then does whatever you want that state to do, if anything. Sometimes a state is just to be able to distinguish where you are in the flow, and may do nothing. There is always a starting, resting state that usually does nothing and should be marked run-at-startup. If the state does a wait or you don't mind putting one in, then you can transit directly to the next state as the last statement ("Run Program Body.Target (Then Part)", instead of using a condition on the target state. The same is true if there is only one transition out of the state. Otherwise I believe you have to give the ISY a chance to check the other transit-out conditions and so you have to use conditions to handle every exit path. Again, if there's another / better way to handle this, I'd be most eager to know it. 4) The cond.state lists the condition(s) for all incoming transitions into that state. It "and"s the source state = true, with whatever condition takes you from that source state to this target one. This corresponds to a transition arrow on your diagram. If there is more than one incoming transition to a state, they are simply "or"ed together to create the one test. The "then" clause for a cond.state has a single statement executing that state's body program. If you're tempted to put something else in here along with that, I'd also recommend a comment to the effect: "welcome to the 7th level..." or "abandon all hope..." Anything along those lines will do nicely. 5) If you find yourself using the same tests repeatedly, consider making a separate little true/false program -- like the .IsNight and .IsMotion programs above.

I won't disagree with that in the slightest, except I was hoping that what I wanted the programs to do was clear. I'll try and explain anything I can, but as with all things like this it is much easier to just try one than to dissect it verbally. The ISY uses what technically would be termed 'functional' (ie stateless, variable-less), 'event' programming and that indeed is not the way people think at all. So you need some methodology that bridges that gap. Ad-hoc programming in the ISY just doesn't work for me. So if you can separate out what you want to do and diagram it, and then have some rote mechanical method to develop the ISY programs from that, it is much, much easier to get something that works, that you are sure should work at least, and also can be expanded or changed later. The end programs may not be pretty to look at, but what ISY programs are? If I were to suggest one simple change to the ISY, it would be to relabel the display of the existing trigger "If...Then...Else" program p-code as "When...Then...Otherwise". Then add a real, synchronous "if" test for use inside program clauses. A subset of the existing "if" trigger tests would be fine. This one change would eliminate a ton of program hair as well as a lot of confusion regardless of how you go about programming your ISY. "If (my-light < 50%) Then Set My-Light 50%". This doesn't require any retooling of the basic ISY model that I can see and doesn't need variables or such. Of course variables, even simple, global, boolean variables, would be helpful. But they don't seem to be forthcoming any time soon. And without a conditional test statement I frankly doubt they could be employed to their full usefulness anyway.

Darrell: Clearly I should probably stick with an example of what I actually use Here's the program set I have for my kitchen. There are two motion sensors. The idea is I think fairly typical: At night, I want to turn up the lights over the kitchen island to 50% if they're off or less than that when somebody walks in. And regardless of whether it is day or night, after 15 minutes of no activity I want all the kitchen lights to shut off using a scene I've defined. The full set of programs is below. There are four states in this little engine: S0: Resting state Jumps to S3 when motion is first detected S3: Motion initially detected Jumps to S1 if it is night, otherwise jumps to S2 S1: Nighttime Turns up the island light Jumps into S2 S2: Waiting-for-no-motion Jumps back into itself when any motion is redetected After 15 minutes flows back to S0 Here's the little diagram - I hope it's legible - this stuff worked better back in the days before variable width fonts .... S0 | | (motion) | V . . (night) S3 -------> S1 | . . . . . . . . | | (not . . . . .| | night) . . . .| V . . . . . . . .| S2 <---------+ . / .^ +---+ (motion redetcted) The S2 state is the interesting one. It has three incoming transitions, so three clauses in it's condition list. This brings up an issue: why not just exit to S2 at the end of S3 with one of those "tail transitions," instead of using conditions on the target states for both exits out of S3?" In other words, remove the "if...S3 and not night" check from S2's condition list and just put a 'run program S2' at the end of S3? It would certainly be simpler. My answer is that this can work, but you also have to put a "wait 1 second" before you make that leap. The ISY may be event-driven but like any single processor it can only be doing one thing at a time. Without a wait to suspend execution of S3 and allow the ISY to test the other conditions, specifically the one that takes it to S1, it appears it never gets a chance to check that before making the direct leap to S2. In the past, I've experimented with a 'wait 0 seconds'. One might expect this would be enough to just put S3 back at the end of the ISY's execution queue without any minimum delay and so give it a chance to check on what else might be going on. But it appears to just optimize it out instead or something else like that; this is all speculation since I don't know anything about the ISY's execution model. In some cases the wait isn't a problem - you're waiting in the state anyway. But here it would just slow down the program to no other good purpose. If anyone from UDI, or anyone else, has any ideas on how to do this better or more easily, I'd be very much interested. It comes up often. There are two oddball programs. The "IsNight" program is just true or false depending on whether it is "nighttime". I use this because the definition of "nighttime" is used in two conditions and I want to be sure if I change it later I don't have to remember to do it in more than one place. The other thing that needs comment is the "Body.S1.Sub" program. I need something to test if the island lights are currently below 50% and only raise them in that case. Otherwise if the lights were already brighter, they'd get dimmed down -- far more remarkably annoying than you might think if you've never actually had it happen to you. The ISY of course has no "if...then" testing inside program clauses, something that would be most, most welcome. So I break out this little routine that's called from S1 to check the lights and raise them only in that case. You could do this with an added state or two of course but it really isn't necessary. The programs I use for this are these. ===== Kit Motion.Cond.S0: ===== If Then Run Program 'Kit Motion.Body.S0' (Then Path) ===== Kit Motion.Body.S0: (marked for run-at-startup) ===== If Then Run Program 'Kit Motion.Body.S1' (Else Path) Run Program 'Kit Motion.Body.S2' (Else Path) Run Program 'Kit Motion.Body.S3' (Else Path) Run Program 'Kit Motion.IsNight' (If) ===== Kit Motion.Cond.S1: ===== If Program 'Kit Motion.Body.S3' is True And Program 'Kit Motion.IsNight' is True Then Run Program 'Kit Motion.Body.S1' (Then Path) ===== Kit Motion.Body.S1: ===== If Then Run Program 'Kit Motion.Body.S0' (Else Path) Run Program 'Kit Motion.Body.S2' (Else Path) Run Program 'Kit Motion.Body.S3' (Else Path) Run Program 'Kit Motion.Body.S1.Sub (If) ===== Kit Motion.Body.S1.Sub: ===== If Program 'Kit Motion.Body.S1' is True And Status 'Kitchen Island' < 50% Then Set 'Kitchen Island' 50% ===== Kit Motion.Cond.S2: ===== If ( Program 'Kit Motion.Body.S2' is True And ( Control 'Kitchen: Motion (Oven)-Sensor' is switched On Or Control 'Kitchen: Motion (Sink)-Sensor' is switched On ) ) Or ( Program 'Kit Motion.Body.S3' is True And Program 'Kit Motion.IsNight' is False ) Or ( Program 'Kit Motion.Body.S1' is True ) Then Run Program 'Kit Motion.Body.S2' (Then Path) ===== Kit Motion.Body.S2: ===== If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Run Program 'Kit Motion.Body.S0' (Else Path) Run Program 'Kit Motion.Body.S1' (Else Path) Run Program 'Kit Motion.Body.S3' (Else Path) Wait 15 minutes Set Scene 'Scene: Kit On' Off Run Program 'Kit Motion.Body.S0' (Then Path) ===== Kit Motion.Cond.S3: ===== If Program 'Kit Motion.Body.S0' is True And-( | Control 'Kitchen: Motion (Oven)-Sensor' is switched On | Or Control 'Kitchen: Motion (Sink)-Sensor' is switched On -) Then Run Program 'Kit Motion.Body.S3' (Then Path) ===== Kit Motion.Body.S3: ===== If Then Run Program 'Kit Motion.Body.S0' (Else Path) Run Program 'Kit Motion.Body.S1' (Else Path) Run Program 'Kit Motion.Body.S2' (Else Path) ===== Kit Motion: IsNight ===== If From Sunset - 30 minutes To Sunrise + 30 minutes (next day) Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') ===== Kit Motion: Reset State (just for debugging, not needed) ===== If Program 'Kit Motion.Body.S3' is False And Program 'Kit Motion.Body.S2' is False And Program 'Kit Motion.Body.S1' is False And Program 'Kit Motion.Body.S0' is False Then Run Program 'Kit Motion.Body.S0' (Then Path)

Well, I've just finished replacing all the V35 dimmers and everything's back to working 100%. A full house query completes in 15 seconds again. SH doesn't have the SL relays in stock but they don't seem to be causing a problem right now so I'll swap just them out in a week or two when they're available. Why a firmware issue would cause a problem to show up after a year is beyond my ability to comprehend, but whatever, these things are definitely EVIL!

This comes up so often I thought I would share the methodology I now use to develop all my ISY programs. This method is easy to understand, quick, and once you've outlined your logic on paper, it is straightforward to produce a set of ISY programs that implement it reliably. I'm afraid this may end up being lengthy so please bear with me; I have no way to draw paper diagrams here so everything will have to be via tedious description. I’ll start with a simple example: Press a keypad button ("KPL A") three times in succession to turn on a light. If more than 5 seconds elapses between presses, the sequence resets and you have to start over. I use something quite like this for my garage door open programming: it prevents the door inadvertently opening if you happen to hit the KPL button by accident. You can also have a little fun with this idea, for example turn the aux buttons of a KPL into a combination lock. I'll also note that to actually do this, you may know Insteon requires we create a scene ("Scene KPL-D") with the button in it - this is just in order to be able to toggle the keypad light on and off from the ISY. To start, draw big, labeled circles to represent all the different “states†of your process. These are generally the places where you are “doing†or “waiting†for something. For example, “the garage door is open and we’re waiting for the close button.†Each situation is different but generally the states will fall out pretty quickly once you’ve grasped the idea and you start to diagram the flow of your particular logic. States generally map to a particular point of logic: (Eg. “My garage door was opened by a motion sensor and we’re waiting for the off from the motion sensor.â€) And you’ll always have a starting “quiet†state that does nothing. In this example the states are pretty easy to see, there are four: a start/reset state, a state for the button having been pressed once, pressed twice, and pressed three times. We'll use labels S0, S1, S2 and S3. Then you draw arrows between the states. Label the arrows with the triggers that cause that particular state change. Anyone with an information science background will immediately recognize this as a basic "state machine". No matter, just diagram how your logic flows from one state to the next. Don’t worry about the ISY just yet. And don’t worry if your logic isn’t fully developed, you can always go back later and expand on it. For this little example, we draw an arrow out from the edge of the S0 circle to the edge of the S1 circle, indicating a press of KPL-A when you're in state S0 takes you to state S1 (first button press). Likewise S1 to S2, and S2 to S3. These are of course all basically the same transitions, but the only way a state diagram has to "remember" anything is by the state it is in. We don't need no stinkin' variables. Or more precisely, the states themselves are our variables. This is partly why this model works so well for the variable-less ISY. The important thing to understand about state diagrams is you have no idea how you got to the state you're in. If you need to "know" that for your logic, you simply break out more states. Inside or near each state's circle you note what that state does when it is activated. For example, S1 turns off the KPL light to indicate it is ready for another press, then waits 5 seconds, and then - assuming nothing else has interrupted it - returns to state S0. S1, S2 and S3 all will have arrows back to S0 representing this "timeout" transition (ie you waited too long to press and the state reverts back to S0). I like to draw these explicit transitions from inside the circle. I'll also point out that in a less trivial example than this - one involving say motion sensors - you often have arrows going from a state back to itself. For example if a motion sensor sends a repeated "on" signal while you are waiting in a state, you want to restart the timeout in that state by re-entering the state. Now, if you've suffered this so far, I'd really recommend you actually draw this out in some fashion on a piece of paper even though it may seem obvious or even trivial. You might want to implement this in your ISY to get a feel for the process. The basic idea is to separate out figuring out what you want from the actual ISY programming. Now that we have our diagram, we can easily get to an ISY program set by a rote procedure. Each state will be represented by two ISY programs: one program will test the conditions - these are all the incoming "arrows" to that state that represent the various trigger conditions into it. The second program will actually perform whatever that state is supposed to do. OK. Here were are at the eternal sticking point: Why two programs for one state? All we need is one set of conditions and one "Then" body to execute it. So... one program, right? Wrong. As has been explained on this forum in innumerable posts including this very thread, the ISY executes either the Then or Else body of a program whenever any of its trigger conditions are TESTED. This causes the program to be reset and would be really a Bad Thing: we only want the code for our state to be run when one of the trigger conditions (incoming state changes) is true, not each and every time they are simply checked by the ISY. If you don't understand the difference, keep re-reading it until it makes sense. It is critical to understanding the difference between the way you think and the way the ISY thinks. So we end up with eight programs for our four states. We'll call them here S0Cond, S0Body, S1Cond, S1Body and so forth. The structure of the four S*Cond programs is all basically the same, short, sweet and simple: just test the conditions for the incoming triggered transitions that activate into that state. If any of the conditions are true, the "Then" part calls the corresponding S*Body for that state. Once again, you must run a separate "body" program. Do not just put your state code in the condition test "Then" part. It might work after a fashion, but I can promise you it will never work the way you want. So here's our S1Cond (excuse the reformatting for brevity) If (Program 'S0Body' is True And Control 'KPL D' is switched On) Then Run Program 'S1Body' (Then Path) That's it. The condition list connects each transition coming in to this state with a pair of "and"-ed tests. One part of the "and" to name state you'd be coming from, and the other for the event causing the transition from that state to this one. This is honestly far simpler to actually do than to explain. In this example there is just one transition into S1 (from stating state S0). But if you have multiple transitions coming in to the state you merely "or" a set of these parenthesized tests together to trigger off any of the possible incoming transitions that can get you to this state. The ISY nicely takes care of checking these conditions automatically any time a transition might happen. Now, what is in the S*Body programs? The first thing it must do is set all of the other state's body programs false. This cancels whatever they might be doing, effecting the actual transition to this state. Remember, we can only be in one state at a time. That also declares those other state programs false" to the ISY. This is crucial because we are using the true/false status of the S*Body programs to “remember†what state we are in. After that you just do whatever you want to in the state - if anything, and then put in any explicit transition that happens if the state times out or exits before any other condition triggers in the ISY to cancel it. These 'tail' transitions are explicitly in your state code - by calling the body program for the target state, usually as the last thing that state does. So they are not called out in the trigger condition list for the target state's S*Cond tests. All other incoming (triggered) transitions are, but these are transitions are programmed, not an event. That's why I draw those arrows starting from inside the circle, as they are implemented differently, Here's our S1Body for example: If - No Conditions Then Run Program 'S0Body' (Else Path) Run Program 'S2Body' (Else Path) Run Program 'S3Body' (Else Path) Set Scene 'Scene: KPL-D' Off Wait 5 seconds Run Program 'S0Body' (Then Path) Again, generating this program is more or less a rote process. In fact I typically first just create one template "cond" and one template "body" and use the ISY to copy and edit since they're all so similar. You also want to use a careful (and terse) naming system to keep things clear and I recommend using a common prefix so you can watch them grouped together in the ISY Program Summary. The only things to think about for the Body programs are how long to wait before making an explicit timeout transition out, and what you to do around that waiting. For the most part you have the freedom to do whatever you please without worrying about strange interactions, since you know the program isn't going to get self-disrupted - it is 'protected' by it's S*Cond wrapper. In some cases you may have no timeout inside a state. For example, here's our S3Body: If - No Conditions Then Run Program 'S0Body' (Else Path) Run Program 'S1Body' (Else Path) Run Program 'S2Body' (Else Path) Set 'Our Test Light' On Set Scene 'Scene: KPL-D' Off Run Program 'S0Body' (Then Path) This state just notes it is in state S3, then resets the KPL button off, turns on the target light (“success!â€) and transitions back to the resting state S0. (S0Body of course does nothing except turn off the other three states and exit itself, staying true.) Finally, we need something to initialize the state of this logic to S0 when the ISY boots up. Remember, we require exactly one of the S*Body programs to be "True" at any time, indicating the state we are in. I do this by simply marking S0Body as 'run at startup'. Easy. If you're the worrier type, you can create a separate program that triggers on all four Body programs being false and if so runs “S0Body (Then)â€. I don't bother with this, but it takes care of someone, say, manually setting S0Body false from the ISY console or something odd like that happening to make things inconsistent. Here’s another example I just ran into on the forum: you want to turn your Denon amplifier off at 11:45 and turn it back on at 7AM, but only if it was on at 11:45 in the first place. We have here two states: the beginning/idle state we'll call Denon.S0 and a state S1 that represents the amp was on at 11:45 and waits for 7AM to turn it off and goes back to S0. Two states = four programs... Oops, not quite. We have no way - at least no easy way I know of - in the ISY to wait inside a program for a specific time of day. Now, there are all sorts of ad-hoc ways you could cook up to shim around this problem: some stupid little thunk program to trigger true at 7AM and test that in a repeat loop and so forth. But all that nonsense is precisely what we're trying to get away from. Fuggedaboudit. The solution, as always here, is simply to add another state. Now, S1 merely serves to record that AMP was on at 11:45 and exits doing nothing except staying true. A new, third state, S2, triggers from S1 at 7AM, turns off AMP and returns to S0. Three states. Six programs. OK. Again, excuse the reformatting. Denon.S0.Cond: If (nothing) Then Run Program 'Denon.S0.Body' (Then Path) Denon.S0.Body: //set to run-at-startup If (nothing) Then Run Program Denon.S1.Body (Else Path) Run Program Denon.S2.Body (Else Path) Denon S1.Cond: If Program Denon.S0.Body is True and Time is 11:45PM and Status 'AMP' is On Then Run Program 'Denon.S1.Body' Denon.S1.Body: If (nothing) Then Run Program Denon.S0.Body (Else Path) Run Program Denon.S2.Body (Else Path) Denon S2.Cond: If Program Denon.S1.Body is True and Time is 7AM Then Run Program 'Denon.S2.Body' Denon.S2.Body: If (nothing) Then Run Program Denon.S0.Body (Else Path) Run Program Denon.S1.Body (Else Path) Set 'AMP' Off Run Program Denon.S0.Body (Then Path) OK, let's take the gloves off. I hear you: "But I can do this little thing in 3 programs (or 2 or 1 or one-half a condition test with my eyes closed, or whatever). Why 6? You've got programs doing basically nothing - we can get rid of them." Yeah, yeah, yeah. If you want to chase the infamous "Busy Beaver" problem, far be it from me to dissuade you. Enjoy yourself. But if you've followed me this far I'd guess you already know from experience that with the ISY madness lies down that road. Maybe here you can indeed toss out "Denon.S0.Cond", but maybe later you'll really wish it were there when you make some enhancement. Like the one I make below. So my advice: stick with the structure. The main point here is that using this technique everything is simple and more or less as understandable – at least as anything can be with ISY programs. If my logic diagram does what I want, I can more or less be assured that the programs I generate from it this way will implement it correctly. And if I have to change the logic or add more states, I know exactly what to do and where to look to do it. I don't have a Denon amp to test this with but I am still reasonably confident that - absent any typos - the above set of 6 programs will do the job exactly as described without endless fiddling and forum posts. Here's an illustration. Suppose we want to enhance this a little. If someone turns on the amp between 11:45 and 7AM then we want to 'reset' the logic and so not turn the amp back on at 7AM. Easy. Just add a transition arrow from S1 to S0, triggering on 'if AMP is switched on'. So, you put that condition on Denon.S0.Cond and you're done. Let’s apply the technique to this specific post: Between 10PM and sunrise if we get either of two off signals, but with either of two ‘test’ lights still on, we turn off a few lights. I’m assuming the idea is that people are still up. If neither of those two lights are on then we turn off a lot of other lights. From resting state S0, we have a transition to a state S1 between 10PM and sunrise if either of the two test lights are also still on. We have a second state S2 activated from S0 between 10PM and sunrise if neither of the two test lights is on. There are a couple of other ways to structure this state diagram, but however you graph it you should be able to produce the 6 programs to implement it easily. Again, if you’re tempted to now “optimize†it down to 4 or 2 programs, my unequivocal advice: resist that temptation. Now this technique is hardly perfection. You can still have race conditions in your code, unexpected device interactions, Insteon signal collisions or missed signals. And the ISY has no variables or macro substitution so you can easily get copy/paste errors if you change something one place and don’t mirror it somewhere else it needs to be. All the usual stuff. But it is much, much easier to debug and solve these problems inside this kind of structure. It’s kind of cool to sit and watch the “True†indicator jump from program to program (state to state) in the Program Summary screen as it runs. I always know exactly what it should be up to and why. A poor man’s debugger. If I see two “true†body programs I know I probably added a state and forgot to clear it in one of the other states. I would certainly agree with the suggestion that ISY programs’ semantics could be fleshed out a tiny bit without violating the ISY’s essentially functional, stateless nature. Maybe a third “onlyif†clause. Or perhaps a program modifier to indicate that current then/else execution shouldn’t be interrupted until the conditions actually test true. Lots of possibilities, any of which would be welcome. This would collapse this method into needing half the number of programs and would also make things easier to understand regardless of what method you use to produce them. I will make one other note, I have an ISY99ir/pro. As I understand it, it has limit of around 1000 programs. I've never come anywhere close to that - my little room logic programs rarely get past 8 states and I only have 10 rooms including the patio. But, maybe you live in a mansion and you're an ambitious ISY programmer with a non-Pro ISY. Just be aware that there are limits of some sort, though I personally don't know what they all are as I've never bumped into any of them. HTH

Michel: As usual, thanks so much. I did speak to SH and they are quite agreeable about replacing them. I'm not looking forward to pulling 4 dozen dimmers but it sure beats pulling my hair. Does this affect V.35 relays also? I forgot to ask them. SH support did indicate some dispute about where the problem lies. They told me the ISY is the only PLM client that has this issue with V.35. So this is strictly idle curiousity on my part and I'm sure SH isn't sharing details of their firmware, but have you any sense about where the issue originates from? It just seems weird to me that functioning switches would 'degrade' after 18 months because of firmware. It sort of suggests a faulty hardware component, no? But then I'd assume everything would have a problem.

Clue me in here: I've starting seeing totally mysterious problems with a number of dimmers that have been working flawlessly up until recently. The problem first surfaced in a garage motion sensor, but has since "spread" to other places. I've done the usual unplugging, diagnostics, etc. When the ISY shows a device has trouble communicating, I can't even do a restore-device on it; it tries and fails somewhere in the middle of the process. So I'll try the restore two or three times. Then go down to the device, do an air-gap reset and then the restore will complete instantly and perfectly: "click...click...click", no retries and no errors. But then, after some time, the **** device starts having the same troubles again. So now I'm wondering, can this be () the Dreaded V.35 Problem? All of my SL dimmers are V.35 and have been in place about 18 months with no issues, at least until now. I don't see any comm issues on the KPLs. The place where this first showed up - the garage motion - is not an SL (a KPL), but it is on a branch with a ton of other lighting V.35 SLs. If this isn't the V.35 issue, any ideas what it might be? When I originally asked SH about the V.35 problem they told me not to worry as long as the dimmers weren't showing any issues, but I'm also wondiering if that was a touch optimistic?

Well, the MS didn't resolve it. After a couple of days, it's back. I posted a separate question regarding V.35

Your #2: The device wasn't reliably responding. FWIW I found the problem - in the garage where the MS is located I have two FilterLincs stacked together for the lighting circuit. Remarkably, I found one alone wasn't enough to clean out all the fluorescent noise from the electronic ballasts. When I worked on the garage door opener recently I had to unplug them. When I reconnected them up, I'd plugged the second into the "Always On" of the first, instead of its filter output. Noise in the line = quick death to stable Insteon. Case closed. Thanks for your help.

OK, thanks. That's actually very helpful to know since I see those from time to time and always wonder if it's a problem. There are "duplicate message"s in there. I tried the battery (twice). This is in the garage where the cabling cabinet is located so the AP at the PLM is only about 8' across the room. It flashes for the MS and obviously the ISY is aware of it since there are event messages. The load it's controlling works fine otherwise and the ISY can query and change it. Kind of a mystery. I'm going to try another MS and maybe just finesse the problem away. It's the only problem I'm having that I know of.

I'm having trouble with a motion sensor. It isn't scene-linked, just runs programs for the on/off states. It stopped working reliably a few days ago. I've done a restore-device on the KPL device the program controls, the MS itself, and a PLM restore but it hasn't helped. Running 2.7.15. When the MS triggers, the event log sees it, but it logs events like these: Sun 05/23/2010 11:58:57 PM : [iNST-SRX ] 02 50 11.9B.5A 00.00.01 C7 11 01 LTONRR (01): Process Message: failed I can post the whole sequence if it is helpful. 11.9B.5A is the address of the MS. I'm hoping maybe this points to something, but I don't know what the "Process message: failed" signifies.

I mostly want to clamp on the two mains legs. I should think net power factor there is unlikely to be below 30% at least unless the entire house is off. Of course it's easy to think things like that when you're ignorant. But even if it is, I'll be kind of interested to know that. Yeah, I know - It's spec'ed at the usual 2A/1ma resolution at the low range, but who knows how it will do with trickle currents. Can't really afford a $2000 Fluke. So as usual I couldn't resist. OTOH I can't imagine it will be any worse than the little $50 clamp probe I use now

I actually found a clamp power meter I can justify: $149! Displays power factors down to 30% - or at least so it claims. God knows if it's any good at that price but I'll post back when I've got it in hand and tried it.

Not insulting - it's exactly the sort of stupid thing I seem to do all the time. But, no. Still it seemed an interesting question. So I tried it on the load side, after the lamplinc. Connected there it shuts off almost instantly - as soon as the level goes below 100%. So I toddled over to my local Home Depot this afternoon and picked up a new 4460. And it works perfectly. Go figure. For years I've just assumed it was the nature of the design.

Just FYI, I have an entire house full of V.35s . This issue showed up about a week after I had finished all the rewiring in the remodel and caused me a lot of worry. I even live close to SH, but in the end I just didn't have the stomach to go back and pull everything and replace it all, especially as the install appeared to be working fine. So I just gupled and crossed my fingers. That was 6 months ago. I still have my fingers crossed and all my SH invoices scanned in but so far no problems. SH indicated to me that they would be OK with replacing them down the line if they started to fail. They've been very good thus far about replacing flaky or infant mortalities with new devices. I do have a constant comm issue with one V.35 dimmer. It's for a shower light and I could care less. I've never investigated to verify it's the controller, though I suspect it is since everything else on the same branch in that room works fine. I would exchange any seemingly flaky controller with SH regardless of firmware version. Having a spare or two around for the various controller types - though I acknowledge a little costly - I find is also extremely handy in this regard.

You really just want to get your ISY getting its public name service from your ISP directly instead of the router. If you're able to set the router or the DHCP reservation in it to give out a hard-coded DNS, put in the 64.233.217.5 address and reboot the ISY to renew the lease. If not, connect to the ISY via telnet and hard-code all the IP settings there, including DNS. The dynamic DNS setup is not relevant to this issue. If the IP, gateway and DNS server addresses are correct in the ISY, it will work.

Well, I just tested mine again. The old and crappy (=$20) Kill-a-watt shuts off its display at somewhere just about 90% dim level when connected through to my highly-sensitive, tightly-engineered, resistive test load: an old kennel pad heater from a dog of long ago. When I looked, the UPM 130 meter spec indicates it measures power factor. Is it able to display it, or does it just incorporate it in the true power computation?