ergodic

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.

I can, and yes, it is.

Happened again tonight, no specific cause I know of. Console was running OK, but when I came back, no status showing for anything. After a couple of query attempts, a dialog pops up showing: "Error" with a red "X". Top part says "Change of State Failed: UUID not found" with an address below that: [uUID] . A divider line, then the same message below. (00:21:b9:00:3e:a3 is the MAC address of my ISY.) I don't remember seeing this happen before V3, it is happening to me now a couple of times a week at least. As LeeG indicates, restarting the console is enough, a reboot isn't necessary. I do not think the SHN EZX10 is responsible, just that fooling around programming it seems to get me to this state fairly quickly. And when that happens I've sometimes had to do a hard power-cycle on the ISY to clear everything up.

I really should screenshot the thing, huh? I give you my word next time I will. (Or you can fool around with an EZX10-RF and you'll probably get there soon enough. ) As I remember it, it's basically is an "OK" dialog that has two "UUID" errors (whatever those are) on the top and bottom with what looks like Insteon MAC addresses in each one. I just click it away figuring it's time to reboot the ISY.

Having said I'd not seen it before, today I saw it. I'd just rebooted the workstation. When I brought up the console, nothing was statused and device queries didn't work. I just got the "double-uuid" error dialog. Restarting the console did not help. A reboot seems to have cured it.

Exactly like you, I'm on my 3rd PLM in about 3 years. The first two failed in those strange ways -- unable to connect to devices at random, scenes failing, that sort of thing. The first failure was the real hair-puller since it wasn't at all obvious to me at first that it was the PLM causing all the problems. Eventually I tumbled on the idea to look at the link database in the PLM and that's when it became clear that things were not at all well in there. And that doesn't count the recent failure of a EZX10-RF which was obviously a modified 2412S (mine still had the "2412S" sticker on it). And which failed in the same sort-of-incoherent way, with corrupt link tables. This may be the reason SHN started producing their own PLM. I replaced my last 2412S with a 2413S a few weeks ago. So it's too early to say if it is more reliable. But I kind of suspect you are right that regulation was the problem with the 2412S. The 2413S seems to be missing the big, nasty transformer inside so it's a lot lighter, and hopefully more sophisticated power regulation will make it more dependable. Just guessing, and I'm still keeping a spare PLM around anyway. I will say the 2413S seems a little faster on communication. I use a whole-network query as a sort of overall health indication of the Insteon network and for whatever reason that's about 20% faster now with the 2413S in there. As noted, you will need a separate P/S for the ISY with the 2413S. I've been using the Radio Shack universal that is suggested in the wiki and it's been fine, although I'd suggest if you use that you cut off and/or wrap up all the exposed, unused connectors that dangle around.

There seems to be a minor problem in the UI with the slider controls (or maybe it's just me, always possible). Click on any SL dimmer. If I grab the little "current state" level slider control and move it around, the dim level changes as expected. However if I click to the left or right of the slider control to step it down or up, the level display and actual level doesn't change (and a query then puts it right back where it was). I've tried this on several different dimmers and they all behave the same. And the same behavior seems to happen to the on-level and ramp rate controls though I've only checked that on one dimmer. I first noticed this in 3.1.1 but I'd assumed the ramp rate fix was part of it. I did clear the Java cache, and check that the version shows 3.1.2. I'm probably forgetting something though...

Makes sense. But it was a bit of a puzzle why the issue is so much worse when controlling a scene than when controlling the device itself (where it actually works reasonably well). I was also assuming an intervening "query" following the "bright" on the device to have queued up a command and thus cause any pending bright commands to get flushed through before coming back, but it doesn't appear things work that way. The purpose as explained is simply to keep the slave controllers sync'ed to the actual status of the device, which doesn't happen if you control the device directly. In this case there are only two of these programs (25% and 50%), so I can just define a couple of more scenes.

The program is disabled. Events, including it's own, can not trigger it to run. It is effectively an if-then-else. It doesn't execute unless you explicitly call it from another program or the console.

My understanding is there is no way to set a scene to x%; I would need to define a scene for each dim level, yes? I kind of remember the capability was proposed on the forum some time ago but I don't remember if anything more was done. It is a simple multiway switch setup. Three dimmers, one of them connected to the load. The scene defines all three as controllers. Ramp rate is 0.5sec, on level for all is 100%. Not sure why you'd expect the program to loop. The else clause does nothing and remember that the program itself is disabled so the only way it executes is if something explicitly calls it. It just doesn't stop at the right place. Not clear why.

I have a light ("X") that is controlled from three places, so like most of my devices, there's a scene for it ("Multiway: X"). Since you can't set the dim level of a scene directly, I tried using a disabled program like this to keep the 3 controllers in sync: Program X25 (always set disabled) If Status "X" < 25" Then Set "Multiway: X" Bright Run Program "X25" (If Part) The problem is that this takes the light full on. And the ISY console shows it at a status of 77% when the program is done, not something around 25%. (A manual query on the device then updates it to the triue value of 100%.) If I add a 1 second wait after the bright, then the light inches up to 54% with the console showing it at 25%. Again, a manual query updates it to 54%. If I change the wait to a query on the device it still overshoots. If I change it to the actual device instead of the scene, it gets much closer. It overshoots to 32% with the console showing it at 28%. So my basic question is why the ISY gets out of sync on the light status with the scene it's controlling, and is there a way to do this?

Thanks - I've never had that happen other than when linking with the EZ but I'll definitely watch for it now. Kind of weird whatever it is is able to persist through a reboot - I was thinking it had something to do with the write-update batching. BTW Do you know if there's any way to remove an X10 code for the EZ from the ISY? (At least anything besides deleting the device and starting over.) The EZ has a procedure for delinking an X10 code (pressing OFF), but I don't see any obvious way to translate that into the ISY.

Well, I somehow did it again. I added a link to the EZX10RF, but the ISY got itself into a state where it would only say "Discovering Nodes..." and the "Link Management" menu item wouldn't work. A reboot of the ISY then gets it into a mood where it briefly shows "Discovering nodes, Retry" and then closes out. Power-cycling the ISY clears that, but it is then in a state where nothing queries and it shows "uuid failed" with an address when you try. Rebooting the ISY again finally gets everything back working. I'm not sure how I wander into that, and it's probably me getting something out-of-sequence somewhere. But it's happened twice now, so not just a glitch.

Thanks! I've bumped into that list in various places, and those commands do indeed work via Telnet to the unit. All I really need is standby/on and the quick selects anyway. The part I'm not puzzling out is how to post them in via the ISY network interface. It's not entirely clear it's even possible.

Thank you. It is indeed working now. There were several problems going on: The first was that my PLM link table apparently corrupted when the ISY dumped last night and it only had about 1/2 it's link records (270 of 438 or something). So I restored that. The old EZ still does the record mismatch on that first link which I've just re-verified. The new one does not have this problem. Add to that my entire system clicks along noticeably faster with the comm events and fewer retries tells me something is wrong for sure with that old one. In fact, taking the old EZ off-circuit has fixed a long-standing sporadic comm problem out in the garage (which is where it resided). So a happy surprise there. And of course I'd forgotten how the ISY UI groups and displays the EZ nodes so I would have been stupidly piddling with that for hours if you hadn't reminded me. All good. In fact much better than it was. Thanks again.

LeeG, seems I still very much need your help. Still having the same issue with a new EZ, so it must be Me, not It. Here is what I'm doing: Starting with a factory-reset EZ and nothing in the ISY: I select Link Management... New Insteon Device. Address for this new guy is 19.ac.45, name EZX10RF, type is the same (03.0D). Leave "remove existing links." Click OK. The EZ add itself takes about 45 seconds. ISY shows busy and initializing system and the comm log scrolls along and all looks like it's working and the EZX10RF shows up in My Lighting. So far so good? My palm pad is set to house codes C1-C9. In the ISY, I clear the comm log. I select Link Management... Add X10 device to EZX10RF with the "EZX10RF" node selected in the console. I hold the EZ button 4+ seconds and let it up. I press C1-ON on the palm pad. EZ light flashes brighter. Then I click OK in the console. And here is where it seems to go off the rails. The ISY never displays a busy dialog, never shows a busy message. Just does a few comm commands and shows "Ready" in the lower left. The ISY is now completely idle and no X10 node has been added. Here is the comm log for that if it sheds any light: Tue 04/26/2011 05:09:09 PM : [LNK-BGN ] 02 64 00 00 06 Tue 04/26/2011 05:09:10 PM : [LNK-STAT ] 02 53 S(00) gid=01 19.AC.45 0000 00 Tue 04/26/2011 05:09:10 PM : Linked: Linked 19.AC.45.01 type=03.0D.00 Tue 04/26/2011 05:09:10 PM : [All ] Writing 0 bytes to devices Tue 04/26/2011 05:09:10 PM : ---- Initializing the linked devices ---- Tue 04/26/2011 05:09:10 PM : ---- All Linked Devices are now initialized ---- Tue 04/26/2011 05:09:10 PM : [LNK-END ] 02 65 06 : : Unexpected, ignored (65) Tue 04/26/2011 05:09:10 PM : [All ] Writing 0 bytes to devices Tue 04/26/2011 05:09:10 PM : ---- Initializing the linked devices ---- Tue 04/26/2011 05:09:10 PM : ---- All Linked Devices are now initialized ---- Tue 04/26/2011 05:09:10 PM : [All ] Writing 0 bytes to devices If I now go back and add X10-C2, it works - it behaves exactly as you describe and as I would expect, clicking along with peeks and pokes and what-not with the busy dialog and a new 19.AC.45.2 node showing up. FWIW, if I now try to add C1, it still doesn't add - same problem. Any suggestions?

Thanks, but do not walk down this road any farther. Seriously. The various EZ and EZ device add/removes have now put my ISY in a state where it would not query. After power-cycling it, it reinitialized and will not accept any backup to restore, even after a FR. I be bummed. I'm going to call UDI today to see what can be done, but I'd suggest discontinuing any more EZX10 testing. I'm quite sure something in all that was the cause.

Yes, that's more or less what I see when it works, but not when it doesn't. That, and the link mismatch, and the link error all make me think this guy's just broke in some weird way. My guy's even has a little "2412S" sticker on the back. I have a strong feeling I can add it to my growing collection of partly-functional half-brain-dead serial PLMs. Thanks for your efforts. I'll post back when I have a replacement but I'm betting that's the end of this nonsense.

The same thing happens if I try to link C1 first. If I then do a restore-device on the EZ and compare I always get that first record mismatch. If the restore was working and the ISY is sane I don't see how that happens unless the EZ is mis-flashing or misbehaving somehow. So I think this is simply just a failed EZ. It looks like a retooled serial PLM so it probably imbeds all the grief that goes with being of that heritage. I'll get another one and see, but my guess is a new one takes care of this. I think the root problem is shown in the comm log (below) for that first link. The "unexpected" LNK-END line. That shows for B1 and C1 linked first. It doesn't show on a successful X10 link up. Anyone from UDI have any different thoughts? Mon 04/25/2011 05:17:04 PM : [LNK-BGN ] 02 64 00 00 06 Mon 04/25/2011 05:17:05 PM : [LNK-STAT ] 02 53 S(00) gid=01 0D.FE.CB 0000 00 Mon 04/25/2011 05:17:05 PM : Linked: Linked 0D.FE.CB.01 type=03.0D.00 Mon 04/25/2011 05:17:05 PM : [All ] Writing 0 bytes to devices Mon 04/25/2011 05:17:05 PM : ---- Initializing the linked devices ---- Mon 04/25/2011 05:17:05 PM : ---- All Linked Devices are now initialized ---- Mon 04/25/2011 05:17:05 PM : [LNK-END ] 02 65 06 : : Unexpected, ignored (65) Mon 04/25/2011 05:17:05 PM : [All ] Writing 0 bytes to devices Mon 04/25/2011 05:17:05 PM : ---- Initializing the linked devices ---- Mon 04/25/2011 05:17:05 PM : ---- All Linked Devices are now initialized ---- Mon 04/25/2011 05:17:05 PM : [All ] Writing 0 bytes to devices

Yes I do! I got the $29.99 10-pack "deal". You know, the last chance one they give every ummm.... 15 minutes. I've tried a brand new one also. They both do the same thing. I'm starting to think maybe something's wonky with the EZ itself? Or maybe it needs a firmware update? The link mismatch says something. I just don't know exactly what. I'm going to try resetting it again, taking it out of they ISY, and linking in a dummy code first (like J9) and then see what B1 does when it comes #2. Thanks. I'll post back.

Sorry - I am not at home right now and can't see the specific labels. There is an option on the ISY link menu to add a new EZX10RF. That is what I'm using. There is also a post of on this forum with a discussion of same. I'm following the procedure the ISY dialog describes the link process for the devices. The documentation on the EZX10RF is a bit vague at the end as to whether one long press or two (between the program waits), but the flashing seems clear enough and I've tried it both ways. If I link B2 instead of B1 it all works, so I dobut it is the individual steps.

I added the EZX10RF using the ISY "Link device". Type from the list was 03.0d. Put in the name I want and Insteon address and it seems to find it OK. I never see a "System Busy" dialog on that first link. The event log just shows "writing 0 bytes to device" and does nothing more regardless of waiting. AFAICT the EZ and B1 code link up just fine. Just the ISY doesn't see the linkage. Sending the codes using a 16-button Palm Pad, pressing B1/ON. When I get home I may try doing a dummy code for that first link, since everything after that seems to go fine. But I don't like the link mismatch, nor the overall penny-in-the-fusebox approach.