ergodic

Dude, you totally, totally rock. These things are awesome. 15 minutes with these and I never wanted to see another wire nut again. The 5-wire ones are a tad larger volume-wise than a mid-size wire nut, true. (The 2-wire seems smaller, and the 3-wire roughly the same.) But they are a nice rectangular shape and so far I find it easier to stuff them in a corner or side without running into the clearance problems caused by space-wasting, conical-shaped wire nuts. Not to mention the dozen other advantages they seem to have. NEC 300.14 does require 3" extending outside the box. I suppose who's going to care after final permit sign-off? Still, that's a one-way street and like oberkc I'd be very wary of taking wire lengths down much less than that, regardless of the connector. A deep-well or side-cavity remodel box seems to me a better way if the existing box is stuffed full.

I'm not really seeing any actual problem with my motion sensors so far as I can tell - though for a while I thought I was - neither V1 or V2. Just the miscast error report pointing a finger at them.

I replaced the KPL, and immediately noticed the ISY was having problems trying to reprogram it. This is now quickly devolving into one of those pull-out-your-hair, no-kidding-really, Insteon comm problems. This box has the KPL and another primary SL dimmer controlling two incandescent light loads. There are two more hot branches in the box going off to SL dimmers nearby. These other two dimmers are just for multiway control of the respective lights -- the load line on them is nutted off. (All dimmers are V.38, no V.35 stuff anywhere.) So.... I disconnect both remote lines leaving just the two primary devices in the box, and everything works fine. A reprogram on the KPL runs right through with no problems. Now If I connect either one of those two remote 'travelers', things degrade: one time it completed a restore-device on the KPL but with a lot of delays, and once it died with a failure to communicate. If I connect up BOTH remote device lines, the ISY can't complete a restore-device on the KPL (two tries with that). I'll have to repeat this experiment some more to be really sure of all this, but that's how it seems to stack up. On one of the remote dimmers I hooked up the line and disconnected it at that dimmer, but it still had comm problems. Huh? What's up with that? I am pretty sure there's nothing else on these two spurs besides those SL dimmers. So.... is this maybe some kind of marginal signal level on that branch? Seems strange if so, the run isn't that long and the two remote dimmers aren't more than 10' away. I've got APs all over the place and the house is only about 2000 sq. ft.

No Avast. AVG 2012 Business Internet Security.

FWIW, the subscription issue seems to be noticeably worse for me between 3.1.6 and 3.1.9. (I didn't load any of the intermediate ones). It probably happens 1 out of 3 times now when I open the console, sometimes two or three times in succession. Just for me, one thing that would be "better logging" would to eliminate the comm. error pop-ups and place them in a separate, non-interrupting, scrolling, log window where you could see the history and event time clearly and don't have only the last one for a device -- one that disappears as soon you dismiss it. Last-error-time, device error count/failed comm percentage for devices are simple but also could be very useful logging diagnostics. Even a line in the event log indicating when a comm. has failed would help. Figuring out what represents a retransmission/comm failure from the event log may be easy if you have the Insteon protocol reverse-engineered and memorized, but I don't and it's often difficult to even tease out what's what.

oberkc / LeeG: Thanks much for your suggestions. There is nothing else on this branch or anywhere else with any chronic problem that I know of. It is a dedicated lighting circuit so at least there can't be anything new 'plugged in'. And I suppose this KPL isn't really having a "problem" either -- other than the sporadic comm message and the ISY query problem when that happens. It continues to respond fine to all scene requests, the ISY MS program, and other linked devices. Seems an odd failure mode, but it wouldn't be the first time for that. So I think I'll try LeeGs suggestion first to replace the KPL with one of the spares I keep around. I don't have a "new" new one, I also don't relish the thought of going back into that j-box, but at least it should tell me something. If that doesn't work maybe I should try a PLM restore? The links tables appear to match so I haven't done that yet. FWIW this morning it had popped up again with the comm message so the reset/restore didn't 'take' for long.

I have a KPL which on occasion gives me a comm error pop-up in the ISY. ("Unable to communicate with...") This KPL is a V.2D. It is tied to an incandescent load. It mainly operates though a scene that is activated by an MS. The error indicates no problem you see. The KPL seems to work fine regardless. So I never know the error's been logged until I actually go into the ISY console. But tonight it popped up while I was in. So in an uncharacteristic burst of ambition I decided to try and track it down. When I operated the KPL locally or via the MS program in the ISY, it would respond and the ISY cleared the error flag. But when I then tried to query the KPL, the ISY would send three INST-ACKs getting no response and re-flag it "!". I tried this several times - consistent each time. So I next factory-reset and then restored the KPL from the ISY console. Click-click-click right on through the reprogram. No delays, no errors. Nothing else going on in the house of course. And now a query works fine. Only problem is that I've tried the reset/restore several times before and sooner or later it always starts generating the sporadic comm error pop-up again. I can't really add this up to much of anything. There's an SL dimmer in the same box which works fine and gives no error. It's a deep-well box with a fair amount of wiring running in and through it, but I've checked and re-crimped that box in the past and it's fine. I replaced all my V.35 buggy SLs over a year ago so I don't have that problem. So what does this suggest? 1) The KPL is bad? 2) Some ISY/PLM issue? 3) Another device interfering? 4) Something else? Some other test to try?

Well, one thing I've learned is that these "cannot communicate with..." dialogs really need a timestamp on them or be recorded in the log. Unless I happen to be watching at the exact moment it happens, I have no idea what in the 100s of lines of logging I'm looking for. I did catch one fairly soon after it happened today - a motion sensor in a closet where I'm doing some work. The MS was never in link mode during that time. I did a search on the entire log history I had and there was only one "NACK" message. I've posted that section of the log below. The closet MS is 13.F3.E9 . It is linked in one scene with an SL dimmer. There is an AP in the same closet. (13.AD.64 is a front path MS, 11.9B.5A is a garage MS - Unfortunately some messages from both of those seem to be mixed in.) Sat 09/03/2011 09:33:37 AM : [standard-Cleanup][14.97.AA-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Sat 09/03/2011 09:33:39 AM : [iNST-SRX ] 02 50 13.F3.E9 00.00.01 C7 11 01 LTONRR (01) Sat 09/03/2011 09:33:39 AM : [standard-Group][13.F3.E9-->Group=1] Max Hops=3, Hops Left=1 Sat 09/03/2011 09:33:39 AM : [ 13 F3 E9 1] DON 1 Sat 09/03/2011 09:33:39 AM : [ 14 A1 37 1] ST 255 Sat 09/03/2011 09:33:39 AM : [ 13 F3 E9 1] ST 255 Sat 09/03/2011 09:33:39 AM : [iNST-SRX ] 02 50 13.F3.E9 00.00.01 C7 11 01 LTONRR (01) Sat 09/03/2011 09:33:39 AM : [standard-Group][13.F3.E9-->Group=1] Max Hops=3, Hops Left=1 Sat 09/03/2011 09:33:39 AM : Duplicate: ignored Sat 09/03/2011 09:33:39 AM : [iNST-SRX ] 02 50 13.F3.E9 00.00.01 C7 11 01 LTONRR (01): Process Message: failed Sat 09/03/2011 09:33:39 AM : [standard-Group][13.F3.E9-->Group=1] Max Hops=3, Hops Left=1 Sat 09/03/2011 09:33:39 AM : [iNST-SRX ] 02 50 13.F3.E9 18.D0.38 41 11 01 LTONRR (01) Sat 09/03/2011 09:33:39 AM : [standard-Cleanup][13.F3.E9-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Sat 09/03/2011 09:33:39 AM : [iNST-SRX ] 02 50 13.F3.E9 18.D0.38 A3 BB 81 (81) [color=#FF0000]Sat 09/03/2011 09:33:39 AM : [standard-Direct Nack][13.F3.E9-->ISY/PLM Group=0] Max Hops=3, Hops Left=0[/color] Sat 09/03/2011 09:33:41 AM : [iNST-SRX ] 02 50 13.ED.64 00.00.01 CB 13 01 LTOFFRR(01) Sat 09/03/2011 09:33:41 AM : [standard-Group][13.ED.64-->Group=1] Max Hops=3, Hops Left=2 Sat 09/03/2011 09:33:41 AM : [ 13 ED 64 1] DOF 1 Sat 09/03/2011 09:33:41 AM : [ 13 ED 64 1] ST 0 Sat 09/03/2011 09:33:41 AM : [iNST-SRX ] 02 50 13.ED.64 00.00.01 C7 13 01 LTOFFRR(01) Sat 09/03/2011 09:33:41 AM : [standard-Group][13.ED.64-->Group=1] Max Hops=3, Hops Left=1 Sat 09/03/2011 09:33:41 AM : Duplicate: ignored Sat 09/03/2011 09:33:41 AM : [iNST-SRX ] 02 50 13.ED.64 00.00.01 C7 13 01 LTOFFRR(01): Process Message: failed Sat 09/03/2011 09:33:41 AM : [standard-Group][13.ED.64-->Group=1] Max Hops=3, Hops Left=1 Sat 09/03/2011 09:33:41 AM : [iNST-SRX ] 02 50 13.ED.64 18.D0.38 41 13 01 LTOFFRR(01) Sat 09/03/2011 09:33:41 AM : [standard-Cleanup][13.ED.64-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Sat 09/03/2011 09:33:54 AM : [iNST-SRX ] 02 50 11.9B.5A 00.00.01 CB 11 01 LTONRR (01) Sat 09/03/2011 09:33:54 AM : [standard-Group][11.9B.5A-->Group=1] Max Hops=3, Hops Left=2 Sat 09/03/2011 09:33:54 AM : [ 11 9B 5A 1] DON 1 Sat 09/03/2011 09:33:54 AM : [ F D2 24 1] ST 255 Sat 09/03/2011 09:33:54 AM : [ 14 EF BD 1] ST 255 Sat 09/03/2011 09:33:54 AM : [iNST-SRX ] 02 50 11.9B.5A 00.00.01 CB 11 01 LTONRR (01) Sat 09/03/2011 09:33:54 AM : [standard-Group][11.9B.5A-->Group=1] Max Hops=3, Hops Left=2 Sat 09/03/2011 09:33:54 AM : Duplicate: ignored Sat 09/03/2011 09:33:54 AM : [iNST-SRX ] 02 50 11.9B.5A 00.00.01 CB 11 01 LTONRR (01): Process Message: failed

LeeG/Michel: Thanks. I've turned on the event viewer for device comm events. Sooner or later I'll be there to catch one. I've always assumed that an MS won't even be listening unless it is in link mode. And I gather from the remarks that's true. Which is what made them seem a little puzzling.

I get these things popping up at random several times a day -- 9 out of 10 of them for various motion sensors. The one that prompted me to ask the question is about 4' from the access point that is connected to the ISY. It hasn't been in link mode for months and there are no updates pending on it or anything else. So why would it be doing that?

What exactly is the ISY pop-up saying when it reads "can't communicate with " ? Does it mean it got a corrupt message from the MS, or is it something else?

Lord, is this something needed IMO. Universal Remote just announced a water-resistant version of the MX-900 RF universal remote. I've been watching but it isn't available on their site yet. If you were to pair that with a URI base station -- assuming you have an IR-capable ISY -- then you should be good to go. If not, then there are things like the IR-Linc to do the IR-to-Insteon translation. Be sure to keep the base station several feet away from any RF-generating devices like WiFi access points - they will constantly jabber nonsense into the IR line which the ISY will see. If you want to affix the remote permanently outside, you'll of course have to rig something on your own: a nice decorative chain comes to mind This will probably not end up being an inexpensive solution. So another way, one I've used, is to get the 10-pack of X10 10-code keypads when they have one of their "sales" (ie anytime), and tape one up in a quart-size freezer bag. Or if you have a shrinkwrapper available to you, use that - just don't make it too tight that it squeezes down on the buttons. The keypads usually last at least a year or so that way. And since they cost you about $3@, you don't much care when they die of internal condensation or sunstroke or battery leakage or whatever it is that kills them, or if they just 'walk away.' (Though his parents deny it, I'm convinced my grandson has a collection somewhere.) BTW don't try this, as I did, with a RemoteLinc, they are more sensitive, and cost a whole lot more. I have a EZX10RF which makes the X10 communication a little faster and more reliable. I'd recommend that. But the basic X10 signaling with the ISY usually works well enough if you have a phase bridge and don't have other big comm issues. You do have to program the X10 codes into the EZX10, but once its setup, there's no linking with the X10 keypads themselves, so you can change them out easily. And you get 20 buttons to play with in programs. There is of course less security with X10, but I'm not sure either technology has a great deal to brag about there.

It is also possible to implement a variable wait using a pair of programs - one to start the process and one to 'step down' to zero. And a simple (non-state) variable to implement the wait interval. For instance, this turns on a light after $V seconds (30 seconds in this case): //___________________ //Program TestVarWait If Then $V = 30 Run Program 'Wait.V' (If) //______________ //Program Wait.V If $V > 0 Then Wait 2 seconds $V -= 2 Run Program 'Wait.V' (If) Else Set Scene 'Scene: U/S Office Desk' On The main advantage of this design is you can treat "Wait.V" as a subroutine of sorts, callable with different wait times from different programs. Note that this does lose the initial value set into $V. The main issue with this is that the "Run Program Wait.V" (at the end of TestVarWait) executes asynchronously and so execution continues immediately. That is not an issue here, but if you are waiting for the event to occur before you proceed on, you need to add logic to initialize and in effect wait for "Wait.V" to become false. This seems to require creation of yet a third program. I've tried a bit to concoct something simpler using state variables to handle this, but without any real success - maybe someone else has an idea. Even with a 1 second increment, the variability I've seen seems quite small, though I wouldn't use that for something involving hours. And since even trigger / state variables aren't used for this and the actual executions are trivial, I'd be astonished if this adds any real loading to the ISY.

I did solve this, but I regret not in a way that is likely help you: I re-turned up my Homeseer 2 with just the ISY network plug-in (which actually works quite well). There is a Denon plug-in available for Homeseer 2, though it appears limited to a single receiver. With that arrangement I'm able to get the unit to go to standby/off and on, which is all I need, though it has some other capabilities. I could not find any workable mechanism to send Telnet port 23 data via the ISY network module. And I while I strongly suspect there may be a way to control my Denon directly via http, there isn't any information available, at least any I could find. And Denon support basically said "no." When I get some time I'm going to wireshark the Denon plug-in to see what protocol it's using. That may give me some inspiration.

Michel: Thanks. No, nothing that can't be worked around with run-at startup. I had just presumed that assigning a defined value to an undefined value would be considered a "change". Actually, the way I seem to use them, my preference would be for poking any assignment to a state variable to effect a trigger event on that variable, whether or not the value actually is made different by that assignment. But I realize it also depends on where you plan taking things down the line with state variables.

Java cache and certificate were cleared out before restarting the admin console after upgrading to 3.1.3. I think I noticed this first in an earlier V3 release, but not sure which one.

Installed with no issue. A couple of things I've noticed: #1: When I start the console after a reboot and it is doing it's query-all thing, the ISY often gets 'stuck' with the "system busy" indicator and progress bar at around 25% with no device communication going on at all. (Always stuck on the same device ID - button 4 of a 6-button KPL -- although everything in the console shows with a queried status at that point, including that device. Eventually the progress bar hits 100%, it disappears, and the ISY shows "Ready". However if I just close and re-open the console while it is in this waiting / stuck limbo status, then the progress bar is gone and the "Ready" shows as soon as it comes up. Especially with the new PLM a query-all on my-lighting now consistently is reliably going very fast, and I don't believe it is any sort of comm issue at work. #2: The ISY does not seem to recognize the initialized value of a state variable as a "change" when the ISY boots. And so programs that test for the inital value and do not also have a run-at-startup flag do not get triggered. I'd consider this a bug.

Didn't realize that, thanks!

Yes. That sort of thing. About all you can do with regular (non-state) variables at the moment are very simple counting operations. I'm not trivializing that - it's useful, but anything much past that seems to need variable/variable assignment and compares.

rhughes: 1) I think you could do a 0 init and run-at-startup, instead of the -1 init. I just started this attempt with that and left it that way. 2) I've fixed the test2.c0 which somehow got lines from one of the other programs - probably when I doing that copy-to-clipboard I just selected the wrong one. (Note to ISY: it would be really nice to have a copy-to-clipboard at the folder level.) 3) I tried several ways to boil the two occurrences of 1234 down to one. And also to try to make it a regular variable . I never found anything acceptable. The cures were all worse than the disease. If you come up with something I'd be interested to see it. Part of the problem is there is no way to do variable-to-variable assigment, so that limits things you could otherwise do.

Thanks for catching that. The .C1 and .C2 programs somehow disappeared in my copy/pastes to the forum. I've edited the post to insert them and fix the ">". Hopefully that's it.

The <0> is apparently what happened to ">" when the forum system got hold of it. I'll try to edit the post. The $test.state question is probably a good one. I'll have to look when I'm at the ISY console.

(Note: I edited this on 10/14/12 to restore some code that was missing in this post. I also had to make changes in order to work with the current ISY firmware. So these are a little different than originally posted. I have briefly tested them again and they seem to work correctly, but comments and revisions are always welcome. My apologies for the confusion -- ergodic) OK. With the new state variables in the ISY we still keep the overall “state machine†logic, but we can improve a whole lot on the old method. Here are the essentials: (1) First, the set of programs gets an ISY state variable assigned to track and control the current state. It is important to define this as a state variable because we’ll be triggering on it. (2) Next, we still have condition and body programs as before. But each body program will now have exactly one condition: a trigger that the state variable’s value equals that state’s number. “You idiot! You just got finished above telling me how important it is not to have any conditions on the body programs.†But that’s the old way. Now we are triggering the body programs when the state variable changes value, and that is exactly the behavior we get from the condition. So when the variable value changes, the correct state is triggered and run, and the other states’ body programs go false and stop. Neat, huh? (3) Lastly, transitions between states now are accomplished simply by assigning a new state number to the state variable. We then let the ISY triggering evaluation take over and do our heavy lifting. No more endless Run Program rubbish! Here’s an example of the “KPL combination lock†programmed this way. It's a good example because it is simple but still illuminates the state method, as well as some other nice techniques using variables. If you haven’t run into this example before, it requires the four auxiliary buttons on a 6-button KeypadLinc to be pressed in some predefined sequence. Here we will use A.. B.. C.. D as the sequence and 20 seconds for the timeout. There is also a 20 second timeout if no button gets pressed to continue to sequence. If the correct sequence is entered then a light is flashed and the programs then reset. The wrong sequence or a timeout will just reset with no light flash. Before we start, there are a few prerequisites: (1) You need a recent ISY firmware version 3 that has variables. (2) You have to have a KPL with the four buttons available. (3) You have to associate each of the four KPL A-D buttons with a scene — this is an ISY/Insteon requirement to be able to control them independently. (4) We need to define a state variable to control and track the current state: I’ll be using the highly creative name: “$Test.State†here. Again, is crucial to use a state variable; we need changes in the value to trigger ISY events. (5) We're also using a second ISY state variable: $Test.Code. This is for tracking the code sequence as buttons are pressed. Since ISY variables are only integers, button A corresponds to 1, B to 2, C to 3 and D to 4. So if A... B... C have been pressed so far, $Test.Code will be set to 123. To do I’m employing an old programmer’s trick. We multiply $Test.Code by 10 and then add in the next button's value (1..4) so that each digit of $Test.Code is always tracking the sequence entered. So if we end up with 1234 that means success. Any other 4-digit value means failure. Again, it is important to define $Test.Code as a state variable because we’re triggering on its changes. We also need to create a non-state (integer) variable: $Test.Temp. This is just used to build the value we want to assign to $Test.Code before actually performing the assignment in Test.CA, etc. More on that below. There are just three states in our state machine and they’re very easy to diagram: State 0: The idle state waiting for the first button press, which when received jumps to state 1. State 1: waiting for more button presses and will timeout after 20 seconds back to state 0 if the correct code hasn't been entered by then. State 2: the success state from state 1 and flashes the light before returning to state 0. In addition there are four other little programs, all similar, one for each button press A, B, C and D. They clear the button LED and update $Test.Code for the button's value. These are not state programs, just little routines to update $Test.Code. First, the three body programs for states 0, 1, 2. Again, each body program always has one condition ("If state is value) that triggers when that state value is set. This format is required: //TEST.B0 (initial state, waiting for the first button press) If $Test.State is 0 Then $Test.Code = 0 Set Scene 'Scene: USO A' Off Set Scene 'Scene: USO B' Off Set Scene 'Scene: USO C' Off Set Scene 'Scene: USO D' Off //TEST.B1 (waiting for more presses, or times out back to state 0 after 20 seconds) If $Test.State is 1 Then Wait 20 seconds $Test.Code = 0 $Test.State = 0 //TEST.B2 (success - see TEST.C0, flash the light and return to state 0) If $Test.State is 2 Then Set 'US Office: Cans 6' On Wait 3 seconds Set 'US Office: Cans 6' Off $Test.Code = 0 $Test.State = 0 Here are the corresponding condition programs that make the explicit transitions into each state. In addition to these, each state's body program can make a transition when exiting to another state. //TEST.C0 (go back to initial state if wrong code entered while in state 1) If $Test.State is 1 And $Test.Code > 1000 And $Test.Code is not 1234 Then $Test.Code = 0 $Test.State = 0 //TEST.C1.1 (Jump to state 1 on first button press) If $Test.State is 0 And $Test.Code > 0 Then $Test.State = 1 //TEST.C1.2 (Restart timer in state 1 on subsequent button presses) If $Test.State is 1 And $Test.Code < 1000 Then Run Program 'Test.B1' (Then Path) //TEST.C2 (Go to state 2 when buttons pressed in the right sequence) If $Test.State is 1 And $Test.Code is 1234 Then $Test.State = 2 Finally, the routines that update $Test.Code on each different button press and then clear the button LED. //TEST.CA If Control 'US Office: Cans 6 / US Office: Cans A' is switched On Then Set Scene 'Scene: USO A' Off $Test.Temp = $Test.Code $Test.Temp *= 10 $Test.Temp += 1 $Test.Code = $Test.Temp //TEST.CB If Control 'US Office: Cans 6 / US Office: Cans B' is switched On Then Set Scene 'Scene: USO B' Off $Test.Temp = $Test.Code $Test.Temp *= 10 $Test.Temp += 2 $Test.Code = $Test.Temp //TEST.CC If Control 'US Office: Cans 6 / US Office: Cans C' is switched On Then Set Scene 'Scene: USO C' Off $Test.Temp = $Test.Code $Test.Temp *= 10 $Test.Temp += 3 $Test.Code = $Test.Temp //TEST.CD If Control 'US Office: Cans 6 / US Office: Cans D' is switched On Then Set Scene 'Scene: USO D' Off $Test.Temp = $Test.Code $Test.Temp *= 10 $Test.Temp += 4 $Test.Code = $Test.Temp With this approach, it also is now simple to change the ‘secret code,’ as it is just a number in two places in the program set, instead of being wired into the logic. Simply change the two occurrences of 1234 to 1144 and now the press sequence is changed to AADD. Test.C1 is split into two parts. This is because state variables trigger only when the assignment changes the value. We have to do a Run Program in the second one because the state value is already 1 and it isn't being changed. There are other ways to do this, but this seems the most straightforward. The other note regards Test.CA/CB/CC/CD. Why is $Test.Temp needed to build and then assign the final value to $Test.Code? This takes some serious explanation. So why not just assign these values directly to $Test.Code as with: //TEST.CD (The WRONG way) If Control 'US Office: Cans 6 / US Office: Cans D' is switched On Then Set Scene 'Scene: USO D' Off $Test.Code *= 10 $Test.Code += 4 In fact, I originally wrote these four programs exactly in this format, and spent quite a bit of time trying to figure out why they didn't work. The problem is subtle. It is a result of the way the ISY handles state variable assignments. Each assignment creates a trigger event. The condition clauses of each 'triggerable' program are evaluated first. Then execution of any that match get queued up, in order for processing. In this case when the Test.CD program completes, freeing the ISY to process it's pending event/trigger queue. But this leads to an unexpected behavior. Consider the case of Test.CD getting a press of "D" as the final, successful button. Test.C0 gets queued up to execute it's Then part for the (wrong) 1230 value (resulting from the *= 10 assignment.) This execution happens even though by the time Test.C0 executes, the value of $Test.Code has already been set to the correct value of 1234. The condition on Test.C0 says not to execute if the value is 1234, but that test was done when the *= 10 took place. And the second, correct, trigger on 1234 never gets the chance to fire off because Test.C0 "thinks" the wrong 4-button sequence was entered (1230) and so resets everything back to state 0 failure. Bummer. It's worth noting you can accomplish the same thing without the temp variable, but including a small, one-second wait at the start of Test.C0. That permits the ISY to restart execution of Test.C0 with the pending queued-up correct value of 1234. But the delay is needless otherwise and the temp variable approach seems more appropriate. There is some more discussion of this later on in this thread. The bottom-line rule is: don't change the value of a state variable unless and until you want it to trigger on that value.

Now that variables are available, I thought I’d update my 'state diagram' approach to ISY programming to use them. ISY variables – particularly the “state variables†- are a natural fit for this. I’ve broken this into two posts. If you want to skip over the background here, the next post gets to an example of a new method using state variables. To very briefly recap the state machine method: you first diagram your logic on paper with numbered circles (“statesâ€). The states represent all the various sub-actions your programming needs. Then draw arrows labeled with the trigger events that transition between the states. Each state then breaks down into two ISY programs: (1) A “body†program with no conditions that execute the actions of that state, and (2) A “conditions†ISY program that only triggers on any of the incoming transitions to the state and then does a Run-Program on its corresponding body program. If you want to read more about this older, non-variable method to implement this, dnl started with my various haphazard, rambling posts and remarkably elaborated it all into something coherent, here: http://forum.universal-devices.com/topic/5410-triggers-and-conditions-and-ifs-oh-my/ This prior method used the true/false status of the body programs. Exactly one of the body programs was true at any time – representing the current state of the logic. But there were drawbacks: achieving this required a lot of tedious, easy-to-screw-up, copy/paste boilerplate. It resulted in obnoxiously dense programs since each body program first had to ‘false-out’ all the others. And, state transitions translated to “Run Program†statements — these can sometimes be tricky because of their asynchronous nature in the ISY. Anyone who seriously programs their ISY sooner or later come to realize why they have to break any nontrivial logic into two separate ISY programs. But it is worth restating in this case: The body program for a state MUST have no conditions so it is isolated from spurious ISY trigger events that could incorrectly cause it to be stopped. So the condition(s) for a state need to be tested/triggered by a separate program. We don’t care how often that program evaluates false because nothing gets disrupted when that happens. In effect, the condition programs insulate their body programs from events, only allowing the ‘correct’ ones through. If you try putting conditions on a body program, or statements in a condition program, you’ll quickly discover you need to be the love child of Countess Ada and Bertrand Russell to figure out what is going on. It would be nice if the ISY allowed us to simply delete the “Else†clause of a program as an indication we don’t want a program interruptible by false-state triggers – the Else section is rarely useful anyway. But we work with what we have. The next post shows a way to update this approach nicely using state variables.

This is the shortcut I've been using: "C:\Program Files (x86)\Internet Explorer\iexplore.exe" http://isy99:29418/admin "ISY99" is defined in DNS to the static IP address of the ISY. I had been having problems with 64-bit Java installed, which required me to use the Java download and finder. However I uninstalled 64-bit Java -- leaving just 32-bit, and it's been working fine with a regular URL since.