ergodic

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.

Was having trouble with the EZX10RF so I completely removed the EZX10RF from the ISY, factory reset it and re-added it with a "clear all links". (I've tried this a few times, always with the same results.) The problem is that I cannot seem to link X10 code B1 to the ISY. B2-B7 add fine, just not the B1. Even if I link B2 first, B1 won't link in the ISY. I assume other house codes would do the same but haven't tried any. I seem to link the code to the EZ OK. Then click OK in the ISY dialog and the ISY log shows "writing 0 bytes to devices" and nothing else. No subdevice shows up, no "wait..." dialog. Nada. When I read the link table for the EZ after that, it shows me this (the device address of the EZ is 0d.f1.cb): 0FF8: E2 01 11 CC CD 03 05 92 0FF0: 00 00 00 00 00 00 00 00 This shows a mismatch with the ISY link table which shows: 0FF8: E2 01 11 CC CD FF 1F 01 Any idea what gives? Should I try linking some non-used code first like J1 just to get past whatever this issue is? Or is this something deeper? Also, I'll mention there is a minor bug of some sort with the EZ and the ISY. At one point I accidentally tried to add an X1 device to the EZ after I'd deleted the EZ from the ISY again. The ISY doesn't like that. It gets into some sort of snarl where an "OK" dialog comes up "discovering nodes, retry" then closes out. The only way to clear it is to power-cycle the ISY. A reboot doesn't help.

I have a couple of the newer Denon receivers 3310CI and 3311CI, that provide networked access to control the unit via a browser page. So far though I haven't been able to crack the code on issuing direct web commands to the unit. Has anyone found a way to do this? The units also support commands issued via telnet and I've scrounged up a little documentation on that. But does the ISY have a way to issue telnet on port 23?

If I use the d/l .jnlp XML applet (adjusting the URL for 3.1.1), it works every time. I use the locator screen and then the ISY login comes right up If I use the "My Lighting" shortcut that places on the destkop, or the ISY URL in a browser directly, Java crashes every time.

Too much optimism - it's doing it again. I closed it tonight and reopened the ISY console and Java crashes out again -- in both 32 and 64-bit browsers. Clearing the Java cache, rebooting, etc. doesn't help. No other problems on this machine, and nothing in the system logs to suggest a direction. I did notice I get a Java dump log on my desktop. The beginning of the contents are pasted below. The trace goes on for a couple of pages, I can forward one if it's of interest. Any suggestions? ******************* # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d8960b5, pid=1256, tid=9160 # # JRE version: 6.0_24-b07 # Java VM: Java HotSpot Client VM (19.1-b02 mixed mode, sharing windows-x86 ) # Problematic frame: # V [jvm.dll+0xa60b5] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x02621000): VMThread [stack] [id=9160] siginfo: ExceptionCode=0xc0000005, reading address 0x28f90000 Registers: EAX=0x28f90000, EBX=0x392af9e8, ECX=0x02a6fc28, EDX=0x392af9fc ESP=0x02a6f93c, EBP=0x02a6f944, ESI=0x02a6fc28, EDI=0x392af9fc EIP=0x6d8960b5, EFLAGS=0x00010287 Register to memory mapping: EAX=0x28f90000 0x28f90000 is an unallocated location in the heap