ergodic

I suppose that's my question: what commands could you possibly send to an AP? I did disassemble it this evening, and noticed it is clearly designed to accept a daughterboard. So possibly it can be morphed into something more advanced? And then that something else might need a hardware address.

This finally turns out to have been a failing access point. I have two AC receptacles dropped down from both sides of the electrical panel in my garage. An access point is plugged into each. It turns out to have been most unfortunate to hide these behind the washing machine. I'd given up on ever figuring this problem out. But I happened to look back there the other day and noticed one of the access point's lights was flickering madly, dimly and continuously and the other phase wasn't doing anything. Replaced that AP and now everything is back talking at 100% again. It has also mostly ended the mysterious "unable to communicate" motion sensor pop-ups in the ISY. So add 'failing access point' to 'RFI', 'V.35,' 'bad PLM,' and the other "X" communication factors to check when the problem is impossible to explain by signal quality issues alone. BTW does anyone know why access points have Insteon hardware address labels?

Modest bug (I think). If you remove a device from the ISY and then re-add the same device back in, programs that reference the device in conditions will again show it (under the newly re-added name). I'm guessing this is because the ISY is indexing the device by it's hardware address, so when it reappears, programs are once again able to access it. However, the device doesn't actually trigger the programs any longer. IOW the programs show the device in the conditions and to all appearances are proper, but they don't actually work. If you then go in and manually change the device in the programs to anything else, and then change it back to that device, the ISY seems to 'hook' it back and the program then triggers as it should. I haven't done much testing on this, but that seems to be what happens.

You're correct: all that's been done (several times) and I'm on 3.1.9 I think I have a log extract where the MS Nack happens. Does this contain anything useful? 11.A4.43 is the MS, it currently is a V1 device. Tue 10/11/2011 10:36:09 AM : [standard-Cleanup][11.A4.43-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Tue 10/11/2011 10:36:19 AM : [iNST-SRX ] 02 50 11.A4.43 00.00.01 CB 11 01 LTONRR (01) Tue 10/11/2011 10:36:19 AM : [standard-Group][11.A4.43-->Group=1] Max Hops=3, Hops Left=2 Tue 10/11/2011 10:36:19 AM : [ 11 A4 43 1] DON 1 Tue 10/11/2011 10:36:19 AM : [ 11 A4 43 1] ST 255 Tue 10/11/2011 10:36:20 AM : [iNST-SRX ] 02 50 11.A4.43 00.00.01 CB 11 01 LTONRR (01) Tue 10/11/2011 10:36:20 AM : [standard-Group][11.A4.43-->Group=1] Max Hops=3, Hops Left=2 Tue 10/11/2011 10:36:20 AM : Duplicate: ignored Tue 10/11/2011 10:36:20 AM : [iNST-SRX ] 02 50 11.A4.43 00.00.01 CB 11 01 LTONRR (01): Process Message: failed Tue 10/11/2011 10:36:20 AM : [standard-Group][11.A4.43-->Group=1] Max Hops=3, Hops Left=2 Tue 10/11/2011 10:36:20 AM : [iNST-SRX ] 02 50 11.A4.43 18.D0.38 41 11 01 LTONRR (01) Tue 10/11/2011 10:36:20 AM : [standard-Cleanup][11.A4.43-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Tue 10/11/2011 10:36:20 AM : [iNST-SRX ] 02 50 11.A4.43 18.D0.38 A3 BB 81 (81) Tue 10/11/2011 10:36:20 AM : [standard-Direct Nack][11.A4.43-->ISY/PLM Group=0] Max Hops=3, Hops Left=0 Tue 10/11/2011 10:37:02 AM : [iNST-SRX ] 02 50 13.ED.64 00.00.01 CB 11 01 LTONRR (01) Tue 10/11/2011 10:37:02 AM : [standard-Group][13.ED.64-->Group=1] Max Hops=3, Hops Left=2

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

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

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

No Avast. AVG 2012 Business Internet Security.

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

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

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

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

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

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

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

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

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

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

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

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

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

Didn't realize that, thanks!

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

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

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