ergodic

I've found in the past that the Kill-A-Watt (at least the basic one I have) not too useful. While it seems to handle the power angle compensation OK (at least it says it does), it's totally confused by switching dimmers. Mine basically shuts down or reads 0 as soon as the dimming level goes below about 95%. Does the UPM meter handle this better? Is there anything I could easily rig to clamp-and-tap in the panel without actually pulling wires out of breakers that would give a true power reading?

My usage into what SCE called "Tier 5" marginal pricing: about 34 cents per KWh. It's a motivator to try and trim power consumption. So, for two weeks I've been trying to figure out a branch circuit I have that's drawing about .8A when nothing on it is on - at least as far as I and the electrician who wired it can find. The circuit is kitchen/dining overhead and garage area lighting. There are about 12 Insteon controllers on the circuit, a mix of KPLs, dimmers and relays. Totally frustrated at not being able to find where the power is going, I put an old KPL on the bench. I connected power and neutral and clamped the current at 2 - 3ma - about what I'd expect. So then I pulled the cover off a garage box with two live controllers in it. When I disconnected the two switchlincs (which were off), current on the branch dropped from 800ma to 680ma. One device in this box is a SL relay that is just used as a 2-way and the load isn't even connected. The other is an outside door light dimmer. Both were in the off state. Each of the two switchlincs appears to be dead-drawing about 60ma (about 7W!). That seems awfully high, but multiplied across all the controllers on that circuit it would explain the off-state loading. So has anyone ever measured the overhead loading for any of the Insteon controllers? The SH data sheets I have say nothing specific about it. 60ma at 120V is about 7W which seems way too much. Is it possible that some way a miswiring or defective controller somewhere in the branch could cause this to happen?

Thanks. I just got the download and upgrade instructions for 2.7.10. I haven't made any device KPL changes at all (too busy with the problems ) So is it possible to just update to 2.7.10 from 2.7.9 and leave it that way? Or not advised even those the upgrade notes suggest that's possible.

I have 2.7.9 running, and as you well know I've replaced my PLM while that version is installed. Thanks for your help with that. So... my 2.7.6 backup obviously will be from the old PLM. Would the procedure be to restore that backup to the ISY, upgrade to 2.7.10, again re-do the restore PLM operation, and manually restore devices again if that seems to be necessary. Or do I do the restore PLM first with 2.7.6 and then upgrade? Or something else? Especially with all the motion sensors and remotelincs around here, the PLM restore is a real job. And a little nerve-wracking. (Why SH couldn't just make the PLM ID soft-programmable is a bit of a mystery. It would make things soooooo much easier when they fail. Which they seem to like to do.) I could just wait for another release. But reading between the lines I'm assuming 2.7.9 is using a dead format that won't be upgradeable with any future release? And if so do you think it likely that the 2.7.10 alpha format also will be deprecated before the final release? Not complaining you understand -- I perfectly well saw the alpha notice on 2.7.9 and .10. Just asking the best way to go about this.

Well, I can pass along more information: I tried restoring a few devices individually and started seeing "Failed writing" in the event log (writing on that device ID, not a pending batch write). So with nothing else to try, I rebooted the ISY. Note I did NOT repower the new PLM. After the ISY restart I was able to restore devices with no errors, and after doing so that device would then communicate status. I can see no difference in the device link tables - they compared OK before the restart and after. I've now manually gone through them all, restoring one by one. I saw no errors (save the occasional "unexpected..." line). Having restored all the devices including RLs and MSs, I now can do a full query on the entire house with no delays or errors - the whole thing takes about 35 seconds. Just the way it used to be. How long it will stay that way I won't know for a few days. I'm saying my prayers. So at various times over the last couple of weeks I've speculated this was: A comm problem, The dreaded V.35 problem, A bad PLM, Corrupt link tables, Some damage from the power failures we had. But I'm now starting to believe that some - or most - of my issues were with the 2.7.9 update which I perfomed about the same time. The old PLM may well have had an issue that precipitated things but I'm not exactly anxious at this point to put it back in and try to find out. There is definitely something not entirely right about the Restore PLM feature in 2.7.9. Of that I'm almost 100% positive. All I can suggest here is to try replacing the PLM in your test network or home or where ever you field test this sort of thing with one the ISY hasn't seen before and watch what happens. The batch mode feature seems to need a little tweaking. On my menu it shows "turn batch mode on" with a greyed-out icon. But from what I see it IS in batch mode that way. Also, batch mode tries to write RemoteLincs and Motion Sensors in the background which is sort of hopeless since these have to be put in link mode manually. I'd suggest possibly just leaving these out of the background batch write attempts. The whole RL/MS thing is a bit of a problem in a restore PLM operation. It tells you to put all of them into link mode, which in my case at least is more or less impossible since there's quite a few and they time out of link mode long before the restore PLM is finished. Possibly just prompt for each one by name with "OK"/"Skip". If there's a 2.7.10 ready, I'm game. I'm not going back at this point so forward is the only direction

With a number of odd problems I finally decided to just replace my PLM. I picked up a new one from the SH store plugged it in and ran the "Restore Modem (PLM)" from the ISY console (2.7.9). Everything seemed to go fine, and I watched the event log as it ticked along for about 20 minutes. I did a few manual device restores on motion sensors, remotelincs, etc. afterwards. Everything looks fine and I can control the devices from the ISY. The little weird problems seem to also be more or less gone. So far, so good. The problem - a big one - I'm having is that the ISY doesn't now see any device changes. I've even tried re-restoring individual devices and comparing the links, but it doesn't make any difference. If I turn a light on the ISY thinks it's still off (at least until I query it.) The KPL buttons don't flash as they would for a missing PLM or scene device (they definitely did when I had the old PLM out), so I assume they're talking to the PLM. So what's going on? What do I do now? I be stumped and frankly a little nervous about trying anything else. I still have the old PLM though I don't see any useful road backwards.

Amazing, as always. You guys have been busy. BTW, I understand the new, little "Writing" green arrow, but what's the one that looks like "1011" or "ION"?

A question about what I see in the event log when I do a restore device on a motion sensor. The restore seems to proceed and complete OK, but the last line (see below) is always a "*Failed writing" on a device that isn't involved in any of the MS scenes (there's only one). The MS is ID "11.9d.28" - a sensor in a downstairs shower which keeps the lights on. What the ISY seems to be trying to write in that last line is ID "0e.72.25" - an upstairs lighting switch, at least if I understand it correctly. I've verified that the ISY doesn't show any scene connection between these two devices. The event log behavior is consistent if I repeat the restore. This is not the only device that does this on a restore, there are others. All seem to complete OK, it is just the event log that is puzzling to me. I'm trying to clear up some troublesome problems that I was thinking were a wonky PLM or comm issues, and it still might be. But I currently think this is some sort of link or database corruption. So I'm asking so I can understand if this is something normal or indicative of some problem. I've listed the last several lines of the event log for this restore in case they help, but it is just that last line that I'm really wondering about. *** Thu 01/28/2010 10:52:40 AM : [standard-Direct Ack][0E.72.25-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 Thu 01/28/2010 10:52:40 AM : [iNST-ACK ] 02 62 0E.72.25 0F 28 0F 06 SET-MSB(0F) Thu 01/28/2010 10:52:49 AM : [iNST-ACK ] 02 62 0E.72.25 0F 28 0F 06 SET-MSB(0F) Thu 01/28/2010 10:52:59 AM : [iNST-ACK ] 02 62 0E.72.25 0F 28 0F 06 SET-MSB(0F) Thu 01/28/2010 10:53:00 AM : [iNST-SRX ] 02 50 0E.72.25 0E.DC.6D 23 28 0F SET-MSB(0F) Thu 01/28/2010 10:53:00 AM : [standard-Direct Ack][0E.72.25-->ISY/PLM Group=0] Max Hops=3, Hops Left=0 Thu 01/28/2010 10:53:00 AM : [iNST-ACK ] 02 62 0E.72.25 0F 2B F2 06 PEEK (F2) Thu 01/28/2010 10:53:04 AM : [E 72 25 1 ] Link 1 : 0FF0 [A2010F380EFF1B01] *Failed Writing [A2010F380EFF1B01]

I didn't replace the PLM, I just selected "Restore PLM" for the one I have. As best I can determine it from the event log, the ISY didn't reprogram - or attempt to reprogram - the devices. Possibly it "knows" the PLM ID hasn't changed, or possibly there was an error of some sort during the process that didn't display but caused it to abort. I don't know why reprogramming the device links should even be necessary if the PLM isn't changed but it seems to be in this case.

Yeah, I thought I'd seen a full restore in there at some point, but where is it? I assume if the PLM address changes it would force a full restore since the device links have to change??

Yet another tidbit: I discovered after the PLM reprogram that the ISY was not seeing device status changes. The devices were working and controllable from the ISY, but changes at the switches weren't being seen by the ISY. So I did a "restore device" on one, and it then started working. I've gone through about a third of the devices in the ISY now one by one, and as I restore them they reconnect. (There's still a small right-click issue in the 2.7.9 GUI btw). On a few of these, I see the "[uNKNOWN]..." message as it restores the device, and these are the ones that seem to take a while. For example, "[uNKNOWN] 02 5D". In that case there is a device "0F 02 5D" in the scene so I assume the address is truncated or corrupted somehow, but where would this be coming from? If I figure out which devices those are and remove it and all it's scenes and reprogram it from scratch is that likely to remove the [uNKNOWN] stuff? And will that even help?

Well, I started having sporadic comm problems even without the power failures in the last week. Resetting the ISY and PLM usually clears it up for a while and then the nonsense starts again. The ISY will control a device fine from the console and then start having trouble with a query. I'll query it a few times and it will start responding again. And so forth. With nothing else to try, I decided tonight to reprogram the PLM (not replacing it). The first two attempts failed after a short time (the second attempt I think gave -20000 as the error). So I power-cycled the PLM and ISY. The next attempt failed about halfway through: the event log shows it was trying to program group 40 for a device and the next line is "Failed: Cannot write PLM control link for group 40". So, ever the optimist, I tried yet again. This time the ISY's PLM reprogram ticked along, setting group 0 and 40 for each device until it was done. As I wasn't swapping out the PLM I didn't put the MS and RemoteLincs into linking mode (that's a huge undertaking here) - I assume that was OK? I also noticed a few odd "UNKNOWN" lines in the event log while it was reprogramming the PLM: "[uNKNOWN] 02 0A" and "[uNKNOWN] 02 08" What's the deal with those? Anyway, things are now working again for the moment. What does all this add up to? Is this symptomatic of a failing PLM, or something else?

I do have it. It does seem excellent for controlling devices, but AFAIK you still need the admin console for linking, viewing events, etc. Or is there more? I wanted to be able to use the phone as a tool when I'm working on the system - a Swiss Army knife rather than a steak knife so to speak. I did try an RDP client from the phone to my workstation but it is fiendishly difficult to control the mouse. I'm going to try a couple of others but in the end I don't know how useful that will be.

Thanks. I do have a 13" laptop I use, as well as a small Asus netbook. The phone has wifi as well. I'd just like not to have to haul out the laptop from my car and boot it every time I need to check something. It's also a nuisance to cart around and keep from getting banged up when I'm crawling around. (Where do you put your laptop when you're balancing on a stepladder in the garage?) That's why the phone would be so handy - it's always sitting in my pocket and always on and ready. But, alas, it isn't to be. There are RDP and VNC clients available for the phone, I'm going to try one of those and remote in from my phone to my desktop workstation or one of my servers which are always on. Not ideal but it may work well enough.

Thanks. So much for "Java Everywhere". Apparently this all is Google's end-run around Sun's licensing for mobile (JavaME) platforms.

The basic web app helps a little to control things & I also have the iPhone app. But I really need to be able to access the admin console to be able to walk around, and configure / fix things, which is really what I want to use it for. I guess what I don't understand is why a new Java-based phone with a Java-based operating platform and a JavaScript-enabled browser can't pull up a Javascript-based web application. Grrrrrr. I've also tried a couple of the other open-source browsers on the phone and they don't work on the ISY page either.

I just got a new Motorola Droid (Android-based) phone. It would be very handy to use to access the ISY admin console while I'm walking around trying to configure and fix things. Very, very handy. Sadly, when I try to bring up the admin page it says "Java 2+ required". I can access the basic non-admin webpage, but not the Java admin console. Can anyone shed any light on this?"

Two thoughts FWIW: 1) Have you tried just doing a device restore from the ISY on the KPL and IOLincs (and anything else in the scene)? This frequently fixes up this sort of problem. 2) Garages typically imply fluorescent lighting, or CFLs in the garage door opener sometimes. This can cause all sorts of marginal noise issues for Insteon - things can work then not work then suddenly start working again - and it can drive you totally off your rails. If you do have fluorescent lighting just make sure it's off when you're testing - as long as there's no active load there can't be any noise issue.

VPNs can be configured to redirect the gateway through the VPN to use the office's Internet gateway. (This is to avoid the situation where the home machine gets a virus or trojan through its local gateway and then infects the network through the VPN). The office gateway has no access to your home LAN. If that is the case you should be able to access your ISY via the public Internet even with the VPN connected - provided you have made it available through your router and the office firewall policy allows that access. Alternatively you can ask your IT group if they can configure a 'split tunnel' for your VPN, allowing you to keep access to your local network while the VPN is connected.

If you have X10 devices or interfaces, I'd unplug those first.

OK. Had another power failure tonight. Things came up wonky - ISY couldn't talk to any of the devices. Just timed out after its retries and marked the device with "!". I removed the other devices (EZX10 and AP) from the power strip which had no effect. I plugged those back in, then re-powered the ISY but not the PLM and that cured it. The one test - an important one I think - I haven't tried is to re-power just the PLM and not the ISY, Something I currently can't do because the ISY is powered off it. I'll get some sort of DC adapter rigged in there for the ISY and then try a simulated power failure at the breaker box.

Well Michael, as is often the case with Insteon the plot thickens.... Tonight I noted that the ISY was having trouble communicating with some devices (roughly about a third, though that's just a guess.) Queries would either work after several tries, or just fail completely. Some devices had no problem at all. So... following your suggestion, I unplug the power strip to which the PLM (and thus the ISY) are powered, and then plug it back in. Presto! everything starts talking again and no problems. I can query everything and it all responds more or less instantly. Any ideas? Perhaps a voltage spike during one of the power failures did some harm? But then how could it just start working properly again? (Are these things protected internally?) Just FYI, the main power strip is one of those 6' wiremold affairs mounted on the garage wall: it has an access point, an EZX10RF, a FilterLinc (running into the cabling cabinet UPS), and a pigtail to a power strip also running inside the cabling cabinet that has only the PLM on it. The ISY is powered off the PLM cable. I've had no problems with this config up until this stuff started happening....

The PLM most definitely is not dead. After a power fail I can manually reboot the ISY (not the PLM) and everything then works fine. It does not show disconnected at any time. The only problem is with communications following a power failure - which seems to necessitate a manual restart of the ISY. I wouldn't dispute that the problem might be with the PLM if you think that's likely - I'll take the issue up with SH in that case. The PLM isn't that old. OTOH, I've never tried re-plugging the PLM after a power fail instead of the ISY. But I wouldn't know what to do with the information no matter which way that test turns out. I screwed up my courage and installed 2.7.9, but I haven't had a chance to test power-fail recovery yet.

Yeah, I've read that thread. It's hard to see how a backup p/s is a fix for this -- for one thing even a large UPS will run out of juice sooner or later. And this happens every time, whether the ISY's been off for 6 minutes or 6 hours. The PLM is V72 - not that old - got it about 6 months ago when the last one died. I'm going to try V2.7.9, I've been holding off to see if it achieves release status, but this problem is starting to cause social unrest around here.

I have an ISY 99i/Pro running 2.7.6. The ISY is powered from the PLM. The rest of the network is on a UPS (connected through a filterlinc). Anyway, some drunken halfwit ran his truck into a power pole out here in the canyons a few days ago. As a result we have had several power outages lasting minutes to hours as the power company tries to fix everything. Each time the power comes back on, after the ISY comes back up, it can't communicate with any of the Insteon devices. It is talking to the network fine, and it appears to be running fine, but a query on anything just generates the "lost communication with..." dialog after it gives up trying. I click the ISY reboot button, the ISY restarts, and all is then well. Is there a way to figure out what might be going on? Would connecting the ISY to a UPS-provided power supply fix this? I'm sort of stumped - I can't imagine that the ISY comes back online faster than the PLM initializes, so what could even be the reason for this?