jtara92101

In this case, not benign, though. I was getting this message when trying to change either the ramp rate or on level of a couple of dimmers in a scene. Now, I just get the message "request failed". Checking the log, there is no traffic generated. Now I'm getting "cannot communicate with MB Shower". Various messages at different times seemingly related to the same thing - I try to change the on-level or ramp rate of the MB shower in a scene, and it doesn't work, with these various error messages, some of which don't make sense in this context. The slider stays where I put it, but if I move to another node and then back again, I can see that the change was not made. Now despite the fact that the ISY claims it "cannot communicate" with the MB Shower dimmer, it IS able to successfully restore the device. I just queried MB Shower, and then tried again to change the on level. Here's what I got in the log. Anything unusual or incorrect here? This time I got -200000 failed to write device link, 2 times. It's a different error message practically every time! The 7 INST-ACKs below are from the Query I did. The rest of it is from my attempt to change the on level. Tue 11/02/2010 09:52:19 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:52:33 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:52:37 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:52:46 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:52:55 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:53:09 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:53:23 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:53:42 PM : [ D 75 42 1] RR 26 Tue 11/02/2010 09:53:42 PM : [D 75 42 1 ] Using engine version i1 for 'MB Shower' Tue 11/02/2010 09:53:42 PM : [D 75 42 1 ] Link 0 : 0FF8 [A2000F9F52FF1F00] Writing [A2000F9F52FF1F00] Tue 11/02/2010 09:53:42 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:53:51 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:54:00 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:54:14 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:54:28 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:54:32 PM : [D 75 42 1 ] Link 0 : 0FF8 [A2000F9F52FF1F00] *Failed Writing [A2000F9F52FF1F00] Tue 11/02/2010 09:54:32 PM : [D 75 42 1 ] Using engine version i1 for 'MB Shower' Tue 11/02/2010 09:54:32 PM : [D 75 42 1 ] Link 0 : 0FF8 [A2000F9F52FF1F00] Writing [A2000F9F52FF1F00] Tue 11/02/2010 09:54:32 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:54:41 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:54:50 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:55:04 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:55:18 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:55:22 PM : [D 75 42 1 ] Link 0 : 0FF8 [A2000F9F52FF1F00] *Failed Writing [A2000F9F52FF1F00]

Thanks, Michael. I guess I just hadn't paid much attention to the local ramp rates, since I rarely use paddles, since I have a KPL in every room that sets a scene (or scenes) for the room. The only stand-alone dimmer I have right now is a brand new one (5.15), so there was no problem programming the ramp rate.

Thanks! So, the only way to do this from a program would be the work-around I mentioned earlier, or else have the program first turn off the mutually-exclusive scenes, then turn on the new one. Since that would cause the lights to blink, the first work-around is probably the best.

-11022 Couldn't open file /conf/fyp.cfg -11022 Couldn't open file /conf/adr.cfg Flash corruption? Restore ISY? I got this when trying to set-up a new scene. I got down to a particular control, and got this when trying to adjust the brightness and ramp rate. I can change other stuff. Also got "cannot communicate with device" but was able to restore the device without error! Just happens when trying to adjust anything in the new scene past what I'd already set-up. Maybe just delete the scene and start over with it?

I gather there is an "old way" and a "new way" to do mutually-exclusive buttons. Administrative Console strongly urges you do do it the "new way". That is, using scenes rather than the mutually-exclusive settings on the switch. In my kitchen, I have a 6-button KPL. A is cooking, B is eating, C is reading. D has another use and isn't mutually-exclusive. I have 4 scenes - default, cooking, eating reading. The main on/off button (not connected to a load) is controller for default, and A, B, and C are controllers for their corresponding scenes. I added the A, B, and C switches as responders to the main scene (linked to the on/off buttons). Then added the main button, B and C to the cooking scene, etc. Then, I changed the sliders for the mutually-exclusive buttons to 0 in the set of sliders for each switch. I also set the A, B, C buttons to non-toggle on. I don't want the confusion of being able to turn off a scene with the scene button in this case. The OFF button is always used to turn the kitchen lights off. You want to cook, you press cook. You don't press cook to turn the lights off! Anyway, this all works fine and as expected as long as you are using the KPL. However, this scheme isn't usable if you are setting a scene remotely (say, with an ISY program.) The problem is, there are no sliders for the button responders in the scene itself! The sliders are there when you select the controller for the scene, but not for the scene itself. They are there in the device list, but no slider! When I activate a scene, (say, Cooking) using Administrative Console, A, B and C ALL light up! What am I doing wrong? I can see a possible work-around by putting each button as a responder in a scene by itself, and turning scenes ON or OFF from the program to effect the LEDs. It appears that a button responder can never have a slider in a scene, but always does for a controller of the scene? Why isn't ISY capable of doing what a hardware controller can do?

Indeed, air-gapping the Switchlinc does make the ramp setting "stick". Thanks! As well, setting the ramp rate by setting the brightness level with the paddle and then double-tapping works as well. (But, of course, isn't accurate, and won't program over the full available range.) The dimmer is marked V3.3, and reports V2.7 in Administrative Console. (Guess these are a hardware and firmware version?) These aren't really ancient. Strange thing is, I swear this used to work. But maybe I just never noticed. I seldom use local controls (lots of Keypadlincs that control groups of dimmers). I guess the ramp rates would be made permanent the next time I have a power outage or flip the breaker, LOL. And when you are installing switches, the probability of flipping the breaker is increased. (I don't know about YOU, but...) I wonder, though, if Universal changed something about how it goes about setting the ramp rate? It's just so strange I never noticed this before! I mean, what's the first thing you want to do with a Switchlinc? Fiddle with the ramp rate, of course!

This is probably related to my ongoing issues related to having replaced my PLM with a dual-band model... I can't change the local ramp rate on any of my "old" Switchlincs. The ISY acts like it is changing it, and the log produces traffic when I change it. But the change doesn't take effect. The ramp rate doesn't change. Changes to local on-level do work correctly, though. As well, changes made to the ramp rate in scenes work correctly. Recently-installed devices work as they should. This includes both old (never installed) stock and newly-purchased devices. If I factory-reset a device, it resets the ramp rate back to .1 second. If I remove the device from the ISY, restore the ISY, and restore the device, the ramp rate gets programmed to whatever it was in the database. So, it IS able to change the ramp rate! But the only way I can change the ramp rate is by doing a "restore device". Example: I had all my devices set to 2 seconds, but I want them at 0.5. A few days ago, I was able to change all my devices to .5 seconds. But, apparently I forget to change one of them, or else the problem started when I tried to change that device... If I factory-reset that device, it goes to 0.1 second. If I remove it, restore the ISY, and restore device, it goes to 2 seconds. If I change it to, say, 30 seconds - it stays at 2 seconds! I don't know that I'm going to convince SmartHome to replace all of my old devices.

Now I do, but I didn't before I fixed it. You may have missed one post: I was able to fix the problem by adding the KPL and all of it's buttons to a scene as controller, adding something to control, verifying that all the buttons can control the load, then deleting the scene. After doing this, all of the buttons will then produce traffic. They didn't produce traffic until they were first added to a scene as controller. I think they may have somehow still been linked to the old PLM.

F.9f.52 V92/Connected 132

A bit off-topic, but I wish Smarthome would (a) catch-up, it's 2010 and ( be more explicit and technical about just what can and can't be dimmed with their dimmers. "Only rated for incandescent loads" is a non-starter. Incandescent lamps are very close to being BANNED, at least here in California! As for halogens, they ARE incandescent. However, they are often low-voltage, and there are multiple technologies used to deliver the lower voltage. There are dimmer compatibility issues for the various technologies. Now, there are some lamps that just can't be dimmed at all - for example most fluorescents. There is an older method of dimming them using a special ballast, but that requires dedicated controls. Newer ones can have circuitry built-in to allow them to be dimmed. Low-voltage dimmable lamps might use a transformer or an "electronic transformer". A transformer requires a "leading edge dimmer". That means that the "slice" taken out of the waveform to dim is taken out of the leading (rising) edge of the waveform, starting at the "zero-crossing" point. Some older dimmers took a RANDOM slice out of the waveform, and these aren't good with transformers. An "electronic transformer" might require a leading edge dimmer or a trailing edge dimmer. Some newer ones now work with leading-edge. Some are pickier and need trailing edge, and that's a pretty hard dimmer to find, though they are available. For example, all current W.A.C. track fixtures will work with a leading-edge dimmer. The Lightech electronic transformers I use for my under-counter Xenons (another type of incandescent lamp) require trailing-edge. The type of LAMP is irrelevant as far as the dimmer is concerned, if the lamp is low-voltage. The dimmer doesn't see the lamp load. It sees the "transformer" as the load. It's the type of transformer that matters, NOT the type of lamp! If they really are saying "incandescent load only", that means NO TRANSFORMERS, and that's impractical in 2010. The ideal dimmer would determine the type of load, and adapt to leading or trailing edge accordingly. As well, "sine wave dimmers" are becoming more practical, and this would be the real ideal! I *think* that the SmartHome dimmers are all leading-edge. But that's the kind of stuff they never actually tell us. We're too dumb to be able to use that information. At least that's the impression I get from Smarthome.

OK, I found a work-around to get the small buttons on the KPL linked to the PLM. (Right-click on the device list isn't working, so I can't "remove" a device from the ISY). 1. Create a new scene 2. Put some light in the scene as a responder (not sure if this is necessary) 3. Put the button which isn't sending messages to the ISY in the new scene as a controller 4. Push the button to verify that the light comes on. 5. Remove the light and the button from the scene, and remove the scene. This procedure has restored communication with the ISY with all of the previously-unresponsive buttons. I am getting a lot of "Process message failed" messages in the log.

Well, now I've got another KPL that doesn't work. The ISY doesn't follow the status of the D button on my kitchen KPL when it is pressed. This is also true for the C and D buttons on my balcony KPL, and the A, B, C, and D buttons on my master bedroom KPL. Office KPL works as you'd expect. I can see status updates on all 4 buttons. Smarthome previously RMA'd my PLM. They replaced it with the dual-band model, since they no longer had the original one in stock. Not sure if I unlinked things properly when I replaced it. Is it possible that there's no way to remove links to the old PLM? I factory-reset all of the troublesome KPLs and they still act the same way.

I know this sounds strange, but that doesn't work. There is no "remove" when you right click on it. In fact, there's nothing. Now, I DID get a "remove" option the first time I tried this. But I decided not to do it yet, as I wanted to write down my settings, remove the switch from scenes, etc. Now I don't get a right-click menu on ANY devices. I even closed and re-opened the admin console... As well, in the "My Lighting" display, there is nothing shown for "Current State" for the four small buttons on the "bad" KPL. (I do get a current state for the main button.) If I do a Query, though, then the Current State DOES show after that. I do have a bit more information, though. I do NOT see anything in the log when I press those keys. But I'm not sure that I should be, as I tested this on a "good" KPL, and you don't see anything in the log unless the switch is actually linked to something. So, for example, I have a KPL where A controls a pump and B controls a fountain on my balcony. C and D haven't been programmed to do anything. I see it in the log when I press A or B, but not C or D. I'm wondering is the ISY is being "too smart for it's own good". I just checked the current state column for the "good" KPL. It toggles for A and B, but not C and D. Yes, that is it! I added a little program with an "If Control Balcony C On". No traffic is seen, the current state doesn't change, the program doesn't run. Apparently, simply having a program reference a switch isn't enough to get it linked to the ISY?

How do I do that? There's no obvious way to "remove" a device from the ISY. I've wanted to do that in the past, but couldn't find how you do it. There is a "disable" option, but I dont think that's what you mean.

OK, seems to be a bad KPL. This works on my other KPLs, regardless of version. It works on V1.8 and V5.3 So, I'll see if Smarthome will replace it. I've already factory-reset the KPL, so not sure what else I could do.

I'm trying to trigger a program using Controll Off in the If. This works fine for the "main" button on the KPL. But testing Control Off for any of the sub-buttons (A-D) just plain doesn't work. Right now, I don't have the program doing anything - I am simply looking at the "last run" time to see if the program has run. It hasn't. I tried factory-resetting and restoring the device. Didn't help. The KPL is v1.8. I don't think I've ever been able to get this to work, but I just isolated it to the sub-buttons. I had been under the impression that "control" didn't work, but then I accidentally discovered that it does work for Switchlincs, and now I see it also works for the main on/off button. What's the secret? I have the button in "non-toggle OFF" mode, and not grouped. But those settings don't seem to matter. The button is a responder in a scene containing only itself. I use that scene to control the LED so that it is lit if lights in other parts of the house are on. But, again, this has no effect on the problem. I tried a different button that isn't a responder to anything with the same results.

i guess I'm missing something here. After reading this, I disabled a program that's called from another program. It no longer worked. So, I set it back to enabled. Not sure if it always evaluates as "false", or returns the last condition from when it WAS enabled.

OK, this version is insensitive to how I turn the MBR lights off. It still needs the delay, though. I know I can get rid of the delay by switching off the master bath lights individually, but then there is a delay as each light is turned off. Program "MBR Occupied" If Status 'MBR / MBR Overhead' > Off Or Status 'MBR / MBR Track' > Off Or Status 'MBR / MBR Floor Lamp' > Off Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') TRUE if MBR is "occupied" - i.e. at least one MBR light is on. Use a higher level than OFF if a "night light" function is desired. Program Master Bath off with MBR If Program 'MBR Occupied' is False Then Wait 2 seconds Set Scene 'Master Bath / Master Bath Default' Off Else - No Actions - (To add one, press 'Action')

I have a little program that turns off my master bathroom lights when I turn off my master bedroom lights: If Control 'Master Bedroom / Master Bedroom Keypad' is switched Off Or Control 'Remote / Remote A MBR' is switched Off Then Wait 1 second Set Scene 'Master Bath / Master Bath Default' Off Else - No Actions - (To add one, press 'Action') This didn't work at all until I added the Wait statement. Actually, it works unreliably with the 1-second wait - I haven't determined yet just how much delay is needed, but it seems to work reliably with a 5-second wait, and it seems OK right now with a 2-second delay. It is completely reliable if I set the individual dimmers in the bathroom, rather than setting the scene. But, then, the lights go out in sequence, rather than all at the same time, which is annoying. (Aside: is there a way to avoid the "sequencing" if I turn them off individually? Maybe make a program for each one, and run the programs? When a program runs another program, it doesn't wait for completion, before continuing, right?) Also, I guess I should really be testing for the status of all of the dimmers in the MBR, rather than control actions, right? As it is, it won't turn the bathroom lights off on a fast-off or a fade-down to 0. (By habit, I normally fade-down the RemoteLinc.) Why do I need the wait? Is there a better way to do this? I discovered the "fix" of using the wait quite by accident. I'd thoroughly convinced myself that "set scene" simply didn't work at all, until I tried sticking in a Wait. This post seems somehow relevant: http://forum.universal-devices.com/view ... cene+delay[/code]

Turns out I didn't. Sorry, I hadn't checked the manual. Though I've found the manual fairly worthless, there's actually a clear description of this there. It certainly isn't obvious. Select any button on a SwitchLinc, then press the Mutually Exclusive button. A list of buttons (the main button and the smaller buttons) will pop-up along with Mutually Exclusive Buttons 1 and Mutually Exclusive Buttons 2. The latter are apparently some special kind of "scene" but won't appear in the main list of scenes. These scenes only apply to this specific SwitchLinc. You have to drag the names of the buttons you want mutually exclusive into the 1 or 2 scene. (I assume for an 8-button SwitchLinc there would be 1, 2, and 3?)

I set the buttons on a KeypadLinc to mutually-exclusive. How do I undo this?! "Reset" does not change it. It seems to have automatically included the main switch on the KeypadLinc, as well as created two scenes called "Mutually Exclusive Buttons 1" and "Mutually Exclusive Buttons 2". However, these scenes don't appear in the tree - just when you click on the "mutually exclusive buttons" button.

As is the case with most firmware-based products. 99% of the time, updates go smoothly. How you handle the other 1% can make the difference between an excellent product and a so-so one. I suppose a home hobbyist is considered a non-critical customer, and an installer would have spares on-hand. I'm used to dealing with equipment used in more critical applications. I've noticed that. I came here before I purchased the product, and was impressed with the apparent responsiveness of the company. That just added to my frustration when I received the produced and it was not what I expected. As far as Insteon goes, I've gotten excellent support from them. Maybe my experience with them is as atypical as it has been with Universal Devices. My last post where I made what I thought were some excellent suggestions was deleted with no notice to me. Perhaps this was the wrong board for it, but the appropriate response would have been to move the post or delete it with a request that I re-post on an appropriate board topic. (FWIW, although I didn't address it directly in that post, I think the biggest limitation is the lack of variables and arithmetic computation. You really have to stand on your head to do things that ought to be simple. OK, I can see ways of having "kinda" variables, but how do you add 2 + 2? You don't.) In the same post, I also acknowledged that some of my initial assumptions were wrong. But, with the post deleted, I am left looking like a jerk. I really think it's pretty low to accuse a customer of spreading mis-information, and then clip-out their response correcting previous statements. Surprise me, and let this post stand. I'll shut up on the subject.

Have you tried clearing your Java cache after the update? Yes, I did. That is, assuming that "clearing your Java cache" means "go to the Java Control Panel and delete the temporary files". (Yet another documentation issue...) As well as power-cycled the device and rebooted from the telnet console. None of this worked. It eventually did work in Firefox. No clear reason why. I noticed that I wasn't being prompted for a password in Firefox, but I was in IE, so I thought a cookie might be keeping me logged in, and it might be a good idea to delete the cookie. But no cookie found in Firefox for the device. Don't see a stored password, either, so dunno what the isy is doing to keep me authenticated between sessions. The really weird thing is it reporting the wrong version of the firmware (wrong model) with Firefox, and correct with IE. Please, guys. Double the flash if you have to, and add "go back to previous version". This is firmware 101. Should be one of the first bits of firmware developed for any downloadable firmware device. (i.e. even before user functionality) I am appalled that a mature product doesn't have it. Sorry for the rant. At work right now, I'm unraveling somebody else's configuration management mess - a lovely legacy dropped at my feet. And then I get this unpleasant reminder of the consequences of CM gone bad (or lacking at all). So, I'm a bit sensitive about these sorts of issues right now. I do agree, it's the best device on the market for the purpose. That doesn't make it good. Just the least bad of a bad set of choices. It's not very satisfying either from the standpoint of a non-technical consumer nor a techie. It's possible to design products that work for both, but this one works well for neither.

Not a good initial experience with my new isy-99i. I downloaded and installed the 2.6.7 beta update. It bricked my device. Apparently, either the link or the zip file are wrong - apparently, I managed to install an isy-26 update on my isy-99i. Now, when I start-up the administrative console, I get an error popup saying: "Invalid Request" (wow, incredibly informative...) Help, About says: My lighting: uuid:00:21:b9:00:3b:bc null v.null Product: ISY26 (1010) My URL: http://10.0.1.5 Internet Access: Disabled Accessed the telnet console (despite the fact that the documentation says Telnet is disabled by default...) and got this from VE (and what's up with commands having to be UPPER CASE?!): http://10.0.1.5>VE Product: (1020) ISY 99i 256 App: Insteon_UD99 Platform: ISY-C-99 Version: 2.6.7 Build Date: 2008-09-09-00:43:10 Other Services: - Programs Enabled LS gets me this: http://10.0.1.5>LS /TESTFILE.TXT 75 [LOG] [.] [..] /LOG/LOG.UD 60928 [WEB] [.] [..] /WEB/DRIVER.XML 6328 /WEB/LATLONG.XML 11061 /WEB/MAILTO.XML 31820 /WEB/TTYSET.DAT 80 /WEB/UPNPALG.XML 261 /WEB/UPNPSVC.XML 19709 /WEB/CE.JAR 105284 /WEB/CHART.JAR 912631 /WEB/CLOSE.HTM 233 /WEB/FAVICON.ICO 1406 /WEB/FP.JAR 729470 /WEB/INSTEON.JAR 679409 /WEB/UD.DCF 1218 /WEB/UDLOGO.JPG 34639 /WEB/UDIWS10.WS 77601 [.] [..] /CODE/INSTEON.IMG 365580 /CODE/ROMMON.UD 16280 [CONF] [.] [..] [D2D] [.] [..] /D2D/0001.PGM -1 /D2D/0002.PGM -1 /CONF/0.UCF 640 /CONF/DEVCNF.XML 6582 /CONF/0.NCF 136 /CONF/0.UND 600 /CONF/PLMID.BIN 128 /CONF/CJ.UCF 468 /CONF/MIGRATED.D2D 18 /CONF/E0B04.REC 172 /CONF/D8607.REC 116 /CONF/D8AF9.REC 116 /CONF/D71C3.REC 116 /CONF/D87C8.REC 116 /CONF/1.UND 600 /CONF/2.UND 600 /CONF/3.UND 600 /CONF/4.UND 600 /CONF/5.UND 600 /CONF/6.UND 600 /CONF/7.UND 600 /CONF/8.UND 600 /CONF/9.UND 600 /CONF/10.UND 600 /CONF/E08DF.REC 164 /CONF/DC94C.REC 164 /CONF/11.UND 600 /CONF/12.UND 600 /CONF/13.UND 600 /CONF/14.UND 600 /CONF/15.UND 600 /CONF/16.UND 600 /CONF/17.UND 600 /CONF/18.UND 600 /CONF/19.UND 600 /CONF/20.UND 600 /CONF/D7BFA.REC 116 /CONF/21.UND 600 /CONF/DA3E9.REC 116 /CONF/22.UND 600 /CONF/D7542.REC 116 /CONF/23.UND 600 /CONF/D80A6.REC 116 /CONF/24.UND 600 /CONF/E7C42.REC 116 /CONF/D8965.REC 116 /CONF/25.UND 600 /CONF/26.UND 600 /CONF/A22F0.REC 84 /CONF/27.UND 600 /CONF/UDFLPL.XML 14698 /CONF/28.UND 600 Oh, yea, the logger shows this on the Telnet console (at any debug level) when the "Invalid Request" message comes up. http://10.0.1.5> H_ERROR:-10011 : LOGGER:-10011 : n=[null] c=[null] a=[null] I re-downloaded and saved with a different name, just to make sure that I'd downloaded the correct link. The files are the same size, though I didn't do a comparison. However, I did subsequently also download the purported isy-26 download, which IS a different size (1 byte shorter) than the isy-99i download, so clearly I downloaded from the correct link. As a software engineer, I am appalled by the lack of good configuration management practices. BTW, I have specific experience with these kind of issues, as I've written the boot-loader and update support for firmware devices. - Incorrect image (either incorrect link or incorrect content at the link) - The fact that the device was even able to install an image for the wrong device. How hard is it to embed a model # in the image, and refuse to install if it doesn't match? - Apparently no QA to insure that the right images are at the right links. - No obvious way to recover - I'm unable to perform another update ("Upgrade Failed: Invalid or inconpatible upgrade file") Checked the Advanced Configuration Guide, and there's nothing in the Administrative Shell to download or restore an image. I will have to return the device. I will be returning it for a refund, not a replacement. (There's a little hole in the front that looks like it might be for a reset button - but no mention in the documentation. It seems unlikely, though, that this would restore a previous image, since there's no mention anywhere of retention of a previous image) - Horrible user documentation on the update process: it implies a user ID/password are required (but, actually, only for betas, and they are posted here in the forum). I was wondering when/how I would receive a password (was assuming I would get an email, but still waiting for it (I only got a UDI Receipt Confirmation confirming that I'd registered) but then it never said that I'd receive on - No backup image stored! It is common practice to provide flash storage for at least two system images, so that the previous image can be restored in case of an update failure. There are MANY reasons for doing this, including: customer error, interrupted download, configuration-management screw-ups by the vendor... Frankly, I'm severely disappointed with the device anyway. I would have returned it in any case. It is incredibly slow and impractical to program (perhaps though this is just an Insteon limitation), inflexible (ridiculous, extremely limited dumbed-down drop-down programming), counter-intuitive user interface, etc. etc. etc. No way is this junk worth $300. The RIGHT way to do it: - embedded Linux device - general-purpose programming language (say, Ruby) with a friendly front-end (yea, maybe even "drop-down programming" for non-programmers, yet still allowing the flexibility of a real programming language when necessary - at least the bare minimum of decent configuration management, make SOME effort to prevent update errors and provide for recovery, etc. - It is always a bad idea to cheap-out on flash memory and RAM. Whatever you think you will need, double it, and double it again. It never ceases to amaze me the devices that become obsolete simply because the firmware has grown, and the device has run out of memory... ----- Now, after all that - it works. Wish I know why. I decided to try it with IE (was using Firefox) and now it just works, and even reports the right version: My Lighting: uuid:00:21:b9:00:3b:bc Insteon_UD99 v.2.6.7 Product: ISY 99i (1020) Still doesn't work in Firefox - still getting Invalid Request and wrong version information.