johnnyt

I'm going to add my voice to a h/w platform that offers better performance. I need something that can handle peak demands, not average or low demands. In my experience, once you hit more than about 300-400 programs and you have more than a few external systems subscribed to ISY, stuff starts to happen that is, IMO, performance related. While you could argue better programming on the part of the user might solve some of the problems, more power would solve most of them more cheaply in most cases. ( from having worked 20 years in IT) Sent from my iPad using Tapatalk

Thanks for your insights, ELA and IndyMike, I may spend a little time focusing on potential signal suckers I've overlooked. I already have about a dozen filters on various loads, including computers, UPS'es, amplifiers (sonos, powered sub, AV equipment), motors (fridge, HRV freezer, dehumidifier, microwave oven) but I've left a few wall warts alone (2 cordless phone charging cradles and an ipad charger come to mind right now). As I don't have any spare filters handy, what existing filters might be worth sacrificing to isolate the phone/ipad chargers? I know I'm stealing from Peter to pay Paul but is there a chance I don't really need filters on one or more of my fridge, freezer, HRV, microwave, and dehumidifier? I think I was doing it to filter out noise more than signal sucking, particularly since they are on their own circuits (except for dehumidifer). I don't have a way to test for noise so was only guessing they might be a source of problems in the first place. I also recently heard that induction motors, often used in fridges and HVAC equipment (like HRV?), are not a major source of noise... ELA, I can't find the great post you had on signal suckers. (Of course, you've had a few great posts on comms issues but I'm thinking of the one where you provided a list of signal suckers and their relative signal sucking ability.) Would you be able to point me to it? Finally, it's my understanding filters are signal suckers too and, therefore should only be used on something that is a known (worse) signal sucker or noise maker. Is that valid?

Thanks, LeeG. I may just use i2 when I need to read/restore devices that support it. Earlier today I removed all but 2 Access Points and there are still duplicate messages. In fact I noticed what looks like two duplicates in one case. See attached screenshot. I may try to unplug or pull the air gap out of all my dual band devices and pull out all a phase coupling AP to see if it goes away then add in one DB device at a time...

One downside of using the "Device Reported" setting for i2 support and the fact that it can't be set at the device level is that it doesn't work with my Icon devices when reading device links table. ISY ends up using i2 and sending extended messages, which doesn't work. I guess it's not a big deal to change it back and forth when I'm reading device links table given it's not something I do often. However is it safe to say this inability to truly know the i2 compatibility of the device affects things when setting/changing scenes with devices that ISY interprets as i2 compatible even though they're not? Also, can someone clarify whether the i1/i2 setting impacts - positively or negatively - the day-to-day use of my devices, i.e. just turning them on/off and executing scenes. I will say things certainly do work much better with i2 for devices that support it when it comes to reading device links table. Turns a 20+ minute process for my KPLs that sometimes has to be restarted into a 5 min affair.

what's the downside or risk of using i2? why is it not recommended? is there any chance of device corruption that can't be fixed with a return to i1 and a restore?

Thanks, LeeG. The problem is not limited to the Icon Relay. I've attached event viewer logs for device link query of a v41 i2CS KPL and a v.36 KPL. While not on the same circuit both occasionally suffer from not doing what they're told although less often. The v.36 KPL seems to struggle just as much as the Icon Relay here while the v41 KPL doesn't seem to struggle as much with hops left but there are a number of unexpected responses. Things certainly finish faster with the i2CS device. It's quite painful waiting for a 70-80 link KPL to get through it's table - and with the problems I'm having it usually needs more than one attempt in order to get through it. To compare, I also queried the device links table of an v36 IOLinc that is about 30 feet away from the PLM on the same phase and not in what I consider a problematic area of the house. A few hops left=0 are seen but they appear to be related to the echo / duplicate commands that occur. Another thing I noticed as I check device links tables is that most I've checked so far end up with record mismatches when compared to the ISY links tables. I went through a round of device updates about a year ago after finding mismatches in a number of devices that I never got to the bottom of and just let go. I might revive that thread with some up to date info (viewtopic.php?f=27&t=10577). I'm wondering, though, if it wasn't/isn't related to this issue and perhaps if I can fix this the other problem won't happen. The reference to metal junction boxes was just to say that any hard wired dual band devices I have, such as the v41KPL I queried for this, do not add (or benefit) notably, if at all, to the RF portion of my insteon network. Not saying it adds anything; just putting it out there as I know this scenario is not common in the US. ISY-Events-Log.v4.1.2__IOLincv36.ClosetoPLM.txt ISY-Events-Log.v4.1.2__KPLv4.1DeviceLinksQuery.txt ISY-Events-Log.v4.1.2__KPLv36DeviceLinksQuery-partial.txt

I'm trying to understand event viewer entries a little better in the hope it will help me understand comm problems and potential fixes better. The trace below is an excerpt from the attached file that was created by doing a Show Device Links Table for an Icon Relay (the value brand version of the ApplianceLinc that's no longer being sold) with address 16.AB.AF. It is in a place where it doesn't always do what it's told. I can see that there are comms issues with Max Hops=3, Hops Left=0 and these happen even when I put an access point on the same circuit. Q1: Shouldn't an access point fix that? Q2: Why would the commands alternate so consistently between hops left=2 and hops left=0, i.e. perfect one time and terrible the next? Wouldn't things be more clearly one way (hops left=2) or the other (hops left=0)? why no hops left=1 sometimes? Q3: It also looks to me like a number of commands are duplicates or an echo of a previous command - is that right? If so, are they from the RF insteon signal, which I think I read somewhere are a half second (or is it half a Hz) after the powerline signal? Q4: Generally speaking, can/should I just add more Access Points or can/will they make things worse sometimes? Should I stick to the minimum needed, i.e. one per phase and only where needed for RF only devices. Currently I have 5 access points installed, 2 on one phase and 3 on the other. I sometimes use a spare PLM I keep as a backup as an access point for testing (I assume it works fine for that purpose, is that right?). I have very few dual band devices and metal junctions boxes that render all but the wall wart variety (Lamplinc and IOLinc) useless. Any info would be appreciated. Tue 04/15/2014 06:43:14 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F Tue 04/15/2014 06:43:14 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F) Tue 04/15/2014 06:43:14 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:14 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:14 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B F8 Tue 04/15/2014 06:43:15 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B F8 06 PEEK (F8) Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B A2 PEEK (A2) Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:15 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F Tue 04/15/2014 06:43:15 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F) Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B A2 PEEK (A2) Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B A2 PEEK (A2) Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:15 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B F9 Tue 04/15/2014 06:43:15 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B F9 06 PEEK (F9) Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:16 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B 00 PEEK (00) Tue 04/15/2014 06:43:16 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:16 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F Tue 04/15/2014 06:43:16 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F) Tue 04/15/2014 06:43:16 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:16 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:16 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B FA Tue 04/15/2014 06:43:16 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:16 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:16 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:16 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:16 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B FA 06 PEEK (FA) Tue 04/15/2014 06:43:17 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B 1E PEEK (1E) Tue 04/15/2014 06:43:17 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:17 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F Tue 04/15/2014 06:43:17 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B 1E PEEK (1E) Tue 04/15/2014 06:43:17 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:17 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F) Tue 04/15/2014 06:43:17 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:17 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:17 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B FB Tue 04/15/2014 06:43:17 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B FB 06 PEEK (FB) Tue 04/15/2014 06:43:18 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B 48 PEEK (48) Tue 04/15/2014 06:43:18 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:18 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F Tue 04/15/2014 06:43:18 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B 48 PEEK (48) Tue 04/15/2014 06:43:18 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:18 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B 48 PEEK (48) Tue 04/15/2014 06:43:18 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:18 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F) Tue 04/15/2014 06:43:18 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:18 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:18 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B FC Tue 04/15/2014 06:43:18 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B FC 06 PEEK (FC) Tue 04/15/2014 06:43:19 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B AD PEEK (AD) Tue 04/15/2014 06:43:19 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:19 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F Tue 04/15/2014 06:43:19 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F) Tue 04/15/2014 06:43:19 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:19 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:19 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B FD Tue 04/15/2014 06:43:19 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:19 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:19 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B FD 06 PEEK (FD) Tue 04/15/2014 06:43:20 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B FF PEEK (FF) Tue 04/15/2014 06:43:20 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:20 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F Tue 04/15/2014 06:43:20 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B FF PEEK (FF) Tue 04/15/2014 06:43:20 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:20 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F) Tue 04/15/2014 06:43:20 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:20 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 04/15/2014 06:43:20 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B FE Tue 04/15/2014 06:43:20 PM : [ Time] 18:43:22 1(0) Tue 04/15/2014 06:43:20 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F) Tue 04/15/2014 06:43:20 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 04/15/2014 06:43:20 PM : [uNKNOWN ] 02 AF ISY-Events-Log.v4.1.2__Tue 2014.04.15 06.44.18 PM.txt

Oh yeah, thanks for mentioning that, Jim, I hadn't thought of it. I went ahead and created programs that report true if variable-to-monitor = 1, false otherwise and made them favorites. Unless I'm missing something, though, I have to have 2 programs/favorites per device, one to see the status and one to change it, which starts to make things a little crowded on my favorites screen. For now, I'm mostly interested in being able to see the state at a glance so I'll use it just for that. If I end up really wanting the full functionality before virtual devices are implemented, maybe I'll just go ahead and use X10 devices and hope the extra traffic doesn't interfere with real commands. Thanks again for posting.

Is there a way to create a status only (virtual) device that shows up in My Lighting? For example, in HomeSeer, which I now only use for its access to forecast data, I have a bunch of virtual X10 devices using house code "z" (and others above "P"). I tried doing this with ISY (I have the X10 module) but it doesn't work. The first time I tried (using "z1") I got an error message and the next two times (using "X1") nothing happened - no message and no device created. Yes, I know I could create a device with a valid X10 address but I'd rather not add unneeded "noise" to my power line if I can avoid it. Ultimately, I'm looking to set a device linked to a variable (0 or 1) such that Mobilinc shows it in it's device "tab" because it currently doesn't present variables very effectively, IMO. For example, I can't set a variable to be a "favorite", and I would very much like to be able to more easily set a variable (to 0/1) when in Mobilinc, i.e. like using a switch. I realize I may need to ask Mobilinc to make a change but I thought the easier route to get to what I wanted was being able to use some sort of virtual device in ISY that doesn't end up involving the PLM and adding unnecessary traffic to my insteon network. (I assume collision avoidance doesn't exist for X10 in the ISY PLM but is that true? - maybe I don't need to worry about it...) Any info or suggestions would be appreciated.

Yes, I realize that (thanks to you and your post early in the thread). I guess I was wondering two things. 1. Why doesn't the event viewer show something like this when queried? Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 2] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 3] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 4] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 5] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 6] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 7] ST 0 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 8] ST 0 2. Does a program with one of the relays 2-8 evaluate when node 1 is queried The first one certainly would have helped my troubleshooting and would have avoided some questions and logical conclusions I drew. For number 2, I just created a test program with only status of relay 2 as the trigger and it works fine. I guess I knew this since when things worked well (i.e. no problems caused by multi-device scenes being called) programs with relays 2-7 did work fine. So I take the 2nd question in my last post back...

Okay, I get it. Sort of. I tested other devices and sure enough querying a device returns it's state and programs with the device will be evaluated even if the reported state is not a change. What confuses me, though, is why isn't the state of all 8 EZIO8SA relays reported back given that a query of node 1 is a query of all nodes? Or to ask a slightly different question, how would I get the same effect, i.e. cause a program evaluation from a query, for relays 2-8 of the EZIO8SA?

Well isn't that special! This is probably the 6th undocumented feature of the EZIO8SA I've encountered, and by far the most expensive one. This morning I changed the 3 scenes I had that contained multiple relays and adjusted the handful of programs that called them so they activated each relay separately. It's been about 12 hours and my inbox does not have a single notification of problems related to relay status surprises. While I've had the odd "good day" like this so I'm going to have to wait a few days to declare victory, I am quite optimistic. This could certainly explain the intermittent nature of the problem with the problems showing up only after some program had called one of the problematic scenes. I also have to wait to see if this solves the problems such as 5 and 6 on my list, which have happened only twice in ~3 months. I will confirm the one thing it has NOT fixed. ISY continues to be surprised by the state of relay 1. For example, the ISY GUI showed relay 1 was ON when I queried the device yet ISY recorded it as a status change to ON. Tue 03/18/2014 08:24:57 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Tue 03/18/2014 08:24:57 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Tue 03/18/2014 08:24:57 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 03 IOCTL (03) Tue 03/18/2014 08:24:57 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 03/18/2014 08:24:57 PM : [ 23 8D 7C 1] ST 255 Tue 03/18/2014 08:24:57 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Tue 03/18/2014 08:24:57 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Tue 03/18/2014 08:24:57 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Tue 03/18/2014 08:24:57 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 I'm not going to ask you if this can be fixed because 1) I don't have any programs that are triggered based only on relay 1 status and 2) if needed, I can work around the issue by picking a different relay and I'd rather see UDI work on 4.x and 5.0 releases. I did want to mention it in case it can help someone else. Perhaps I'll also publish a list of EZIO8SA undocumented features if this ends well to save others a lot of grief.

Yes I have at least three and they work under normal conditions. If I may I’d like to ask what you're thinking might need fixing because it’s not clear to me, particularly given the comment that you "do not see anything that strikes (you) as strange". From where I sit there a number of problems, some seeming to be ISY logic or something ISY could compensate for, others seeming to be problems with the EZIO8SA. The problem with the latter is explaining to Smartenit that the problem is not an ISY issue as right now they don’t seem to take any ownership for the behavior I’m seeing. Which of these problems do you think you might be able to fix or be able to rule out ISY as involved in it or be able to compensate for: 1) relays intermittently yet frequently surprising ISY even when they are already in the reported state (relay 1 being a pretty consistent offender) 2) on query, relays periodically surprising ISY with wrong state then if queried again reversing to actual state (because of extra messages?) 3) scene commands that often don't work during EZIO8SA queries 4) relays that end up stuck ON until EZIO8SA relay unit is power cycled 5) device link DB getting wiped out (according to ISY Device links query) but with some stuff still working 6) The bad sequence, seen when I was using Dual Band PLM viewtopic.php?f=27&t=13528#p106690 viewtopic.php?f=27&t=13528#p106758 7) this: viewtopic.php?f=27&t=13528&start=15#p108872, which I can't figure out how to summarize I’m trying to assess whether this actually has the potential to end well. If all you’re looking at and might fix is, say, number 1, it won’t be enough for me to think the EZIO8SA is going to work out for me.

I did the device restore until I got an identical compare with ISY links table. It took 2 attempts as the first one had 2 record mismatches. I think that's happen to me before with a KPL (lots of links) so I presume it's not an indication of a malfunctioning device. I then ran a few manual device queries of the EZIO8SA and it looks like a duplicate response occurred that may have set off some problems with the state ISY had internally for relays 1 then 5. Relay 1 repeatedly surprises ISY with its ON state. See attachment that ends in "DeviceQuery-relay1ONalready.txt" I did it again, this time watching the state of relay 1 in the GUI, which was ON to start. I would see the star come up beside it and it stayed ON. The trace shows ISY is actually surprised to hear the relay is ON.. twice! See attachment that ends in "DeviceQuery-Relay1ON-2.txt". A visual check of the dampers being controlled confirmed they were physically ON. I also ran the program that does 150 repeated queries. All seems fine until mid way through when the following extended response occurs: Sat 03/15/2014 02:44:31 PM : [iNST-ERX ] 02 51 23 8D 7C 24 1B FE 12 79 B8 CF 32 BD 43 FF FF 1F FF EF FF F0 00 00 AF Sat 03/15/2014 02:44:31 PM : [Ext-Direct ] 23.8D.7C-->ISY/PLM Group=0, Max Hops=2, Hops Left=0 Soon after the INST-ERX message appears a response (in red below) that's interrupting the normal flow of responses seen both before and again later. Sat 03/15/2014 02:44:32 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Sat 03/15/2014 02:44:32 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Sat 03/15/2014 02:44:32 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 4F 21 IOCTL (21) Sat 03/15/2014 02:44:32 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sat 03/15/2014 02:44:33 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Sat 03/15/2014 02:44:33 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 03/15/2014 02:44:33 PM : [ 23 8D 7C 1] ST 0 For the next several queries relays 1, 4, 6 and 7 are reported as having changed, with each changing back to (I assume) its actual state all along. Aside from wondering about what seems like a duplicate response that throws a lot of things off, and wondering why ISY seems to be surprised that relay 1 is ON when it shows it as ON in the GUI as well as in prior query responses, I'm wondering why the ERX message only shows up once in 150 queries. Or, maybe the question is why is there an ERX message at all? Any info would be appreciated. ISY-Events-Log.v4.1.2__150queries.txt ISY-Events-Log.v4.1.2__DeviceQuery-relay1ONalready.txt ISY-Events-Log.v4.1.2__DeviceQuery-Relay1ON-2.txt

Did three different scene tests, HRV Low, HRV High, and HRV Off. All succeeded according to event traces (2 of 3 attached), however the HRV does NOT turn on, so there's definitely something wrong I checked the device links three times and each time only got one record - see attached screenshot. I did see this when I first installed it (using "replace with" to copy from the original dual band PLM), but fixed it with a "restore device". So it seems the PLM loses it's links. But then how come the scene tests worked??? I'll do the restore device again, repeat a bunch of tests (later today) and report back. On a side note, strangely (to me) the scene test causes the event viewer to be cleared. I don't know if this is by design but I learned you have to save what's there before you run a test if you want to keep it. ISY-Events-Log.v4.1.2_SceneHRVHigh.txt ISY-Events-Log.v4.1.2__SceneHRVLow.txt

so what does that mean? could the EZIO PLM be overwhelmed by the query command? a few posts back the "query insteon engine" I ran trumped a device query I also ran while the first one was still running. Or is it because the insteon network was busy at that one moment and caused the scene command to have been completely missed by the EZIO PLM? I believe scene commands only go out once, right? Does collision avoidance not prevent scene commands from getting lost like that?

Hi Michel, it's just above the screenshot. I just successfully downloaded it. edit: it shows it's been downloaded 4 times as of 8:47 PM EDT on Mar 14th

Yes, with both PLM's, although LeeG pointed out an unexplained message as perhaps being the problem with the dual band that has not been seen with the single band. Attached is the event viewer trace from running the following program: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 150 times Set '1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1' Query Else - No Actions - (To add one, press 'Action') You didn't say you wanted all other programs disabled so I left everything enabled. Let me know if you want me to run it with everything disabled. Repeatedly querying caused one of the self healing programs I have to repeatedly run to turn my HRV to Low (relay 5 of the EZIO8SA). Since it's supposed to be running at this time of the day, that's expected when ISY is surprised to see it isn't. I point to the program in the screenshot below. The four circled programs were stopping and starting repeatedly and should not have been doing that. I let it go for a bit but stopped it part way through the testing. Looking at the trace, relay 6 (HRV High) was also going on and off. It doesn't look to me as though a program was involved but it might have been. When there's a heat call, ISY turns the HRV to high (relay 6 on and relay 5 off). After the heat call ends, it sets the HRV back to low (relay 6 off and relay 5 on). A heat call change is recognizable in the trace because the X10 command K8 would have been heard by the PLM, or IO Linc sensor 15.BB.45 reports a change to OFF (although that's not been reliable, hence the need for X10 backup). I didn't find either of those events in the file. ISY-Events-Log.v4.1.2__Fri 2014.03.14 02.50.07 PM.txt

Sorry about a third post in a row but here's more data that I'm thinking (hoping) adds to the story. I manually initiated a number of device queries of the EZIO8SA in a row that occurred while an Office Damper scene was being called by a program. Each time the relay response portion of the queries surprised ISY, except for what looks like a duplicate response with max hops=3 remaining hops=0 (separated from the rest in the event viewer excerpt below) 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Thu 2014/03/13 05:00:22 PM Web Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 05:00:22 PM System Log Scene:1-MISC (Non Lighting) / HVAC / Office Damper for Prgs Off 0 Thu 2014/03/13 05:00:32 PM Program Log 1-MISC (Non Lighting) / HVAC / Old Office Damper (for LED) Status 0% Thu 2014/03/13 05:00:32 PM System Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Status 0% Thu 2014/03/13 05:00:32 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Thu 2014/03/13 05:00:33 PM Web Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 05:00:34 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Thu 2014/03/13 05:00:42 PM Web Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 05:00:43 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Thu 2014/03/13 05:00:50 PM Web Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 05:00:50 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Thu 2014/03/13 05:01:04 PM Web Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 05:01:04 PM System Log Thu 03/13/2014 05:00:18 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Thu 03/13/2014 05:00:18 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Thu 03/13/2014 05:00:19 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 8E IOCTL (8E) Thu 03/13/2014 05:00:19 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:19 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 05:00:19 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Thu 03/13/2014 05:00:19 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Thu 03/13/2014 05:00:19 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Thu 03/13/2014 05:00:19 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:29 PM : [iNST-TX-I1 ] 02 62 00 00 16 CF 13 00 Thu 03/13/2014 05:00:29 PM : [iNST-ACK ] 02 62 00.00.16 CF 13 00 06 LTOFFRR(00) Thu 03/13/2014 05:00:29 PM : [ 15 BB 45 2] ST 0 Thu 03/13/2014 05:00:29 PM : [ 23 8D 7C 4] ST 0 Thu 03/13/2014 05:00:30 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Thu 03/13/2014 05:00:30 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Thu 03/13/2014 05:00:30 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 86 IOCTL (86) Thu 03/13/2014 05:00:30 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:30 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 05:00:30 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Thu 03/13/2014 05:00:30 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Thu 03/13/2014 05:00:31 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Thu 03/13/2014 05:00:31 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:38 PM : [ Time] 17:00:41 0(0) Thu 03/13/2014 05:00:38 PM : [ Time] 17:00:41 0(0) Thu 03/13/2014 05:00:39 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Thu 03/13/2014 05:00:39 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Thu 03/13/2014 05:00:39 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 86 IOCTL (86) Thu 03/13/2014 05:00:39 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:40 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 05:00:40 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 4F 86 IOCTL (86) Thu 03/13/2014 05:00:40 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Thu 03/13/2014 05:00:40 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Thu 03/13/2014 05:00:40 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Thu 03/13/2014 05:00:40 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Thu 03/13/2014 05:00:40 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:41 PM : [ Time] 17:00:44 0(0) Thu 03/13/2014 05:00:41 PM : [ Time] 17:00:44 0(0) Thu 03/13/2014 05:00:45 PM : [VAR 2 66 ] 48 Thu 03/13/2014 05:00:46 PM : [VAR 2 12 ] 1 Thu 03/13/2014 05:00:47 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Thu 03/13/2014 05:00:47 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Thu 03/13/2014 05:00:47 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 86 IOCTL (86) Thu 03/13/2014 05:00:47 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:47 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 05:00:47 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Thu 03/13/2014 05:00:47 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Thu 03/13/2014 05:00:47 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Thu 03/13/2014 05:00:47 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:00:51 PM : [VAR 2 52 ] -820 Thu 03/13/2014 05:00:54 PM : [VAR 2 68 ] 5 Thu 03/13/2014 05:00:55 PM : [VAR 2 58 ] 1837 Thu 03/13/2014 05:00:55 PM : [VAR 2 70 ] 1987 Thu 03/13/2014 05:00:58 PM : [VAR 2 61 ] 2262 Thu 03/13/2014 05:00:58 PM : [ Time] 17:01:01 0(0) Thu 03/13/2014 05:01:00 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Thu 03/13/2014 05:01:00 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Thu 03/13/2014 05:01:01 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 86 IOCTL (86) Thu 03/13/2014 05:01:01 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:01:01 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 05:01:01 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Thu 03/13/2014 05:01:01 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Thu 03/13/2014 05:01:01 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Thu 03/13/2014 05:01:01 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 05:01:03 PM : [ Time] 17:01:05 0(0) Could other activity with error-free comms during a query of the EZIO8SA be at least part of what's causing problems? It would explain the intermittent yet daily occurrence of this kind of problem on a circuit that has only three IOLincs and one EZIO8SA and that is on the same phase as the ISY PLM hanging right off the electrical panel on its own circuit!! Is there anything that ISY firmware changes can fix or somehow accommodate if this is an EZIO8SA problem? Or should I just cut bait and give up on the idea of using insteon for HVAC controls? I've been struggling with this for I think 3 years now, first with IO Lincs (too many it turned out, at least for a solution that tries to be highly reliable and self healing) and now with the EZIO8SA, which, although much more insteon network friendly and efficient for ISY to process has been nothing but trouble (either itself or for ISY or both) from the beginning a short 3-4 months ago and through two units.

I've been querying insteon engine at various times of the day and so far all have been the same flow of responses with max hops=3, remaining hops=2. This afternoon I ran the command BEFORE opening the event viewer and setting it to level 3. ISY was clearly taxed as response time was quite slow. As part of the responses this time, I got a lot of surprise state changes and two Max Hops=3, Hops Left=0. Could they have been because ISY was busy or is that a clear sign of comm problems, if only for a second or two? I added a space to highlight them. Thu 03/13/2014 04:57:08 PM : [All ] Writing 1 bytes to devices Thu 03/13/2014 04:57:08 PM : [23 8D 7C 0 ] May not fully support i2, reverting to i1 Thu 03/13/2014 04:57:12 PM : [ 23 8D 7C 1] ST 255 Thu 03/13/2014 04:57:12 PM : [ 23 8D 7C 5] ST 255 Thu 03/13/2014 04:57:12 PM : [ 23 8D 7C 6] ST 255 Thu 03/13/2014 04:57:12 PM : [ 23 8D 7C 8] ST 0 Thu 03/13/2014 04:57:15 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 29 02 Thu 03/13/2014 04:57:17 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 2B 00 PEEK (00) Thu 03/13/2014 04:57:17 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Thu 03/13/2014 04:57:18 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 29 02 06 POKE (02) Thu 03/13/2014 04:57:18 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 2B 00 PEEK (00) Thu 03/13/2014 04:57:18 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Thu 03/13/2014 04:57:18 PM : [ 23 8D 7C 1] ST 0 Thu 03/13/2014 04:57:18 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 29 02 POKE (02) Thu 03/13/2014 04:57:18 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:18 PM : [ 23 8D 7C 2] ST 0 Thu 03/13/2014 04:57:18 PM : [ 23 8D 7C 3] ST 0 Thu 03/13/2014 04:57:18 PM : [ 23 8D 7C 4] ST 0 Thu 03/13/2014 04:57:18 PM : [ 23 8D 7C 5] ST 0 Thu 03/13/2014 04:57:18 PM : [ 23 8D 7C 6] ST 0 Thu 03/13/2014 04:57:18 PM : [VAR 2 33 ] 301 Thu 03/13/2014 04:57:18 PM : [VAR 2 32 ] 246 Thu 03/13/2014 04:57:19 PM : [VAR 2 12 ] 0 Thu 03/13/2014 04:57:19 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 3F Thu 03/13/2014 04:57:19 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 3F 06 SET-MSB(3F) Thu 03/13/2014 04:57:19 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 3F SET-MSB(3F) Thu 03/13/2014 04:57:19 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:19 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:19 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:20 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 00 PEEK (00) Thu 03/13/2014 04:57:20 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:20 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 29 03 Thu 03/13/2014 04:57:20 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 29 03 06 POKE (03) Thu 03/13/2014 04:57:20 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 29 03 POKE (03) Thu 03/13/2014 04:57:20 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:20 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 0F Thu 03/13/2014 04:57:20 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 0F 06 SET-MSB(0F) Thu 03/13/2014 04:57:21 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 0F SET-MSB(0F) Thu 03/13/2014 04:57:21 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:21 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:21 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:21 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 01 PEEK (01) Thu 03/13/2014 04:57:21 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:21 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 1F Thu 03/13/2014 04:57:21 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 1F 06 SET-MSB(1F) Thu 03/13/2014 04:57:22 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 1F SET-MSB(1F) Thu 03/13/2014 04:57:22 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:22 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:22 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:22 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 02 PEEK (02) Thu 03/13/2014 04:57:22 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:22 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 3F Thu 03/13/2014 04:57:22 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 3F 06 SET-MSB(3F) Thu 03/13/2014 04:57:23 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 3F SET-MSB(3F) Thu 03/13/2014 04:57:23 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:23 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:23 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:23 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 03 PEEK (03) Thu 03/13/2014 04:57:23 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:23 PM : [VAR 2 12 ] -1 Thu 03/13/2014 04:57:24 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 0F Thu 03/13/2014 04:57:24 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 0F 06 SET-MSB(0F) Thu 03/13/2014 04:57:24 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 0F SET-MSB(0F) Thu 03/13/2014 04:57:24 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:24 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:24 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:24 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 01 PEEK (01) Thu 03/13/2014 04:57:24 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:24 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 29 00 Thu 03/13/2014 04:57:25 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 29 00 06 POKE (00) Thu 03/13/2014 04:57:25 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 29 00 POKE (00) Thu 03/13/2014 04:57:25 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:25 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 1F Thu 03/13/2014 04:57:25 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 1F 06 SET-MSB(1F) Thu 03/13/2014 04:57:25 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 1F SET-MSB(1F) Thu 03/13/2014 04:57:25 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:25 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:26 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:26 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 02 PEEK (02) Thu 03/13/2014 04:57:26 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:26 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 29 00 Thu 03/13/2014 04:57:26 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 29 00 06 POKE (00) Thu 03/13/2014 04:57:26 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 29 00 POKE (00) Thu 03/13/2014 04:57:26 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:26 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 28 3F Thu 03/13/2014 04:57:27 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 28 3F 06 SET-MSB(3F) Thu 03/13/2014 04:57:27 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 28 3F SET-MSB(3F) Thu 03/13/2014 04:57:27 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:27 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 2B FF Thu 03/13/2014 04:57:27 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 2B FF 06 PEEK (FF) Thu 03/13/2014 04:57:27 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 2B 03 PEEK (03) Thu 03/13/2014 04:57:27 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:27 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 29 00 Thu 03/13/2014 04:57:28 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 29 00 06 POKE (00) Thu 03/13/2014 04:57:28 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 29 00 POKE (00) Thu 03/13/2014 04:57:28 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:30 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 45 01 Thu 03/13/2014 04:57:32 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 45 01 06 IOON (01) Thu 03/13/2014 04:57:32 PM : [ Time] 16:57:31 3(0) Thu 03/13/2014 04:57:32 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 45 8E IOON (8E) Thu 03/13/2014 04:57:33 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 03/13/2014 04:57:33 PM : [ 23 8D 7C 2] ST 255 Thu 03/13/2014 04:57:33 PM : [ 23 8D 7C 3] ST 255 Thu 03/13/2014 04:57:33 PM : [ 23 8D 7C 4] ST 255 Thu 03/13/2014 04:57:33 PM : [ 23 8D 7C 8] ST 255 The log from a few minutes before up to the final state changes tells me that a query of the IOLincs did occur at about the same time (added space before and after the relevant entry). This IOLinc scene being queried does NOT have any EZIO8SA nodes in it. 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Off 0 Thu 2014/03/13 04:47:42 PM Program Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 0% Thu 2014/03/13 04:47:43 PM System Log X10 K8 Thu 2014/03/13 04:48:15 PM System Log X10 K8 Off (11) Thu 2014/03/13 04:48:16 PM System Log Scene:1-MISC (Non Lighting) / HVAC / HVAC Sensors Status Query Thu 2014/03/13 04:48:22 PM Program Log 1-MISC (Non Lighting) / HVAC / Sensor - Heat Off - Office Da Status 0% Thu 2014/03/13 04:48:22 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) On 255 Thu 2014/03/13 04:48:32 PM Program Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 100% Thu 2014/03/13 04:48:32 PM System Log Scene:1-MISC (Non Lighting) / HVAC / Office Damper for Prgs On Thu 2014/03/13 04:48:35 PM Program Log 1-MISC (Non Lighting) / HVAC / Old Office Damper (for LED) Status 100% Thu 2014/03/13 04:48:35 PM System Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Status 100% Thu 2014/03/13 04:48:35 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Off 0 Thu 2014/03/13 04:49:05 PM Program Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 04:49:06 PM System Log X10 K8 Thu 2014/03/13 04:56:21 PM System Log X10 K8 On (3) Thu 2014/03/13 04:56:22 PM System Log Scene:1-MISC (Non Lighting) / HVAC / HVAC Sensors Status Query Thu 2014/03/13 04:56:28 PM Program Log 1-MISC (Non Lighting) / HVAC / Sensor - Heat Off - Office Da Status 100% Thu 2014/03/13 04:56:28 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 100% Thu 2014/03/13 04:57:13 PM System Log 1-MISC (Non Lighting) / HRV / HRV Low-EZIO.5 Status 100% Thu 2014/03/13 04:57:13 PM System Log 1-MISC (Non Lighting) / HRV / HRV High-EZIO.6 Status 100% Thu 2014/03/13 04:57:13 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 0% Thu 2014/03/13 04:57:13 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Thu 2014/03/13 04:57:17 PM System Log 1-MISC (Non Lighting) / HVAC / Fan On-EZIO.2 Status 0% Thu 2014/03/13 04:57:17 PM System Log 1-MISC (Non Lighting) / HVAC / Furnace Rm Damper-EZIO.3 Status 0% Thu 2014/03/13 04:57:17 PM System Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Status 0% Thu 2014/03/13 04:57:17 PM System Log 1-MISC (Non Lighting) / HRV / HRV Low-EZIO.5 Status 0% Thu 2014/03/13 04:57:17 PM System Log 1-MISC (Non Lighting) / HRV / HRV High-EZIO.6 Status 0% Thu 2014/03/13 04:57:17 PM System Log 1-MISC (Non Lighting) / HVAC / Fan On-EZIO.2 On 255 Thu 2014/03/13 04:57:26 PM Program Log 1-MISC (Non Lighting) / HVAC / Fan On-EZIO.2 Status 100% Thu 2014/03/13 04:57:31 PM System Log 1-MISC (Non Lighting) / HVAC / Furnace Rm Damper-EZIO.3 Status 100% Thu 2014/03/13 04:57:31 PM System Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Status 100% Thu 2014/03/13 04:57:31 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 100% Thu 2014/03/13 04:57:31 PM System Log Does this add anything to the story?

The one related to the most recent set of posts is only about a week or two old but it is using the older type (design anyway) single band PLM. The first one - at the start of this thread - was maybe a month or so old at that time and had a dual band PLM.

I don't have anything connected to the inputs other than 5&6 to gnd and I don't have the kind of busy ISY situation I used to see when I had to query 10 IO Lincs, pre-EZIO8SA. Incidentally, in case anyone is thinking "just stop querying and your problems will go away", the reason I do the querying is because whenever I've not done it in the past, I would sometimes find things that weren't working as they should. The 3AM "query all" would also end up reporting something wrong just about everyday. While one might be tempted to say that at 3AM the insteon network and ISY are busy so it's just that query problem misreporting things, the reality is there aren't that many problems at 3 AM the times where I'm querying throughout the day. Also, while nothing is such that an HA failure will cause damage to my HVAC system, I kind of want my HVAC controls to be reliable and "self healing" when something doesn't work for comms or other reasons, given that insteon does not promise the reliability of a hard wired solution. ISY for its part has been great for reliability and for the self healing aspect when the querying works but the latter does need to work properly for the self healing to work properly. Thinking something is OFF when it's ON causes the system to actually be "self breaking"... For testing purposes I will try disabling all querying for a few days to see what happens, then move to querying only a few times in a day. I'll combine this with some manual "query insteon engine" or scene tests at different times to see if I can uncover (or rule out?) comms issues as the probable cause of these chronic intermittent problems. In the meantime, any other insights and suggestions would be appreciated.

ELA, Thanks for trying to sift through my troubles and for the suggestion. I just ran about 4 query insteon engine commands against node 1 of the EZIO8SA. On the last one I first initiated my query testing "suite" with a 10 second delay before it queries the EZIO8SA. The thinking was that I would create a collision. The results were all similar and I was surprised to find no trace of the device query from my program within the query engine trace. I'm guessing the regular query command was trumped by the query insteon engine command. FWIW, I've attached the result of the last one here. I'll try again at other times of the day and look for other ways to hammer the insteon network when I do it. I presume there's no way to call for a "query insteon engine" from within a program. Otherwise I would add that into the mix. Would a scene test work? I would mention that the only things on the circuit are 3 IO Lincs and the EZIO8SA on a 14 AWG power bar that doesn't have any built in filtering. In the past I had an HRV, chest freezer and 24VAC power supply that were found to cause problems despite being on a 15A ACT filter but they were moved to another circuit. I'm sure I must be missing something so I'd like to tell you what I see when I look at the event viewer entries hoping you can help. I see that ISY sends out a query for the relays, gets a response 4 secs later, considers that too long so waits 5 secs and sends another query for relays. Rinse. Repeat. Until it gets a response quickly enough and then it queries the input. In this case, the response comes twice - perhaps a remnant from a previous query because of comm problems that don't show up in the max hops / remain hops - and ISY confuses it (or the variable that got updated while this is happening) as being a change in status for 4 of the 8 relays with relays 2 & 4 the wrong status. Were relays 5 & 6 ON all along or is that also a reverse status? I also noticed that an output status response came twice too (that one with an indication of a comms issue) but it was handled okay. I see this flow as problematic but figure I must be misinterpreting what's happening. Thanks again for your help.

Thanks for clarifying the querying. Still, why three queries of the relays and such a long wait to query the input? And why does the following summary update of the relays only occur after the input is queried and over 20 secs after the first query? Sun 03/09/2014 07:33:37 AM : [ 23 8D 7C 2] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 4] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 5] ST 255 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 6] ST 255 I've attached the log from 1PM 03/08 to 3:35PM 03/09 and the event viewer L3 log from 9PM 03/08 to ~8AM 03/09. Also, the attached screenshot shows how often a problem is caught by my automated testing. The arrow shows the device I chose to track for my post. Logs20140308-20140309.zip

Thanks for looking through this stuff, LeeG. Here's what I thought were three queries without a response. I guess I meant three queries with only ONE response. I could certainly be misinterpreting what this is but I saw the word "query" three times and what I interpret to be a single response "RINPUT", although is the third instance of "RINPUT" a duplicate? Sun 03/09/2014 07:33:12 AM : [ Time] 07:33:23 0(0) Sun 03/09/2014 07:33:14 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:14 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:18 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:18 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:23 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:23 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:32 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:32 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Sun 03/09/2014 07:33:33 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Sun 03/09/2014 07:33:33 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:34 AM : [ Time] 07:33:45 0(0) Sun 03/09/2014 07:33:34 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 49 30 RINPUT (30) Sun 03/09/2014 07:33:34 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:37 AM : [ 23 8D 7C 2] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 4] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 5] ST 255 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 6] ST 255 The above events were the result of the query test program sequence that ran at 7:33:22, i.e. “the related one at 7:23:22†2014/03/09, 07:33:22, 1-Initiate Query Test ran True If needed, I can upload the complete log file and event viewer trace if you think I might have missed something. Thanks again.