johnnyt

I only saved the "before" device table (after the compare), thinking the results of the compare would be saved with it but looking at the xml it doesn't look like it. Let me know if there's any point in posting just half the story.

Ended up missing a couple of KPLs in my sweep. Both of those had at least one record mismatch. One had records missing. In the latter case I decided to take a before and after screenshot. For the others previously I did save the file but the XML produces means nothing to me, while screenshots I can read, even if I'm not clear on what all the codes mean. If the xml would be of use, I can post one of those from previous compare. I tried to upload the before-and-after (restore) screenshots I took combined into one image but got the message that board attachment quota has been reached (which had been fixed a few days ago but I guess is back). In hindsight I think I should have tried reading the device table again - Could missing records be because the query quit midstream for some reason? Although most of the events were hops =2, there were some 1's and 0's, as well as a bit of normal (other) traffic happening. I'll try again to upload tomorrow or in a few days...

by the way, sometimes when restoring the device, the green "writing" arrow would disappear rather quickly even though the event viewer was still showing lots of updates being sent out for quite a while after. Kind of a problem if one doesn't have the event viewer open, perhaps thinks things are done, and tries other stuff that struggles as it competes with the device restore traffic. This was intermittent - noticed it once or twice as I went through restoring 6 KPLs.

I was checking device links tables using a KPL to generate traffic in an attempt to troubleshoot an intermittent comm trouble spot in my kitchen area. The area comm can vary from hops left 2 down to 0 depending on the time of day or the alignment of moon and sun - not sure what exactly. For fun I did a compare while I was there and it showed a couple of record mismatches. I went through and checked other KPLs and found only one that didn't have record mismatches. For the mismatches I checked, they were not insteon addresses I could find under My Lighting, i.e. not devices on my network, according to ISY anyway. I religiously follow the prime directive and link all my devices to ISY, never to themselves outside ISY. The ones I checked showed addresses like 15.A1.CF in the device and 15.A1.FF in the PLM. I didn't check them all but this was the case in a couple of instances. Seems like kind of a strange coincidence that the addresses were so close. I have had some intermittent weird things happen in my (problematic) kitchen area like turning a scene on, having all the lights in it go on as expected, then having one of the lights go off. In one case that I investigated I attributed it to what I noticed in the log was a command to turn another device off at the same time or within a second. The rest of the time, I would just write it off as related to my intermittent powerline comm issues. Weird things don't happen that often (although enough to degrade the WAF a little) and not consistently enough to blame an errant link in the affected device. I didn't investigate all mismatches but have restored all the devices, checked them again and they are fine now. Will check them again in the future but wanted to mention it here in case someone has a suggestion as to what might be happening.

Doesn't have to be bare (and no doubt can't be). My garage door openers both have an insulated antenna wire hanging down from themThe wire exiting the garage door opener is not exiting a high voltage junction box.wouldn't insulated make a difference? I'm not an electrician and I don't know all the code details but I would think the fuse would blow long before an insulated antenna wire hanging from a metal box that's grounded would be live. But maybe that's one of the differences between metal and plastic boxes, and hence maybe a code requirement where plastic boxes are permitted...

the 4-tap test? for a dual band device? I have a new dual band KPL relay (they only sell dual band kpl relays now so I got DB whether I wanted to pay for it or not) so after reading the comment I went looking on the smarthome wiki but could not find reference to the 4-tap test for it. That said the manual is for the pre-dual band model so maybe it's just missing that info. How do I test my dual band KPL relay's ability to talk to the network via RF instead of powerline? Certainly I've done the 4-tap test with my access points, although I thought in that case it was for testing that they are on separate phases, not in RF range. It turns out my kpl and the whole circuit it's on is in a marginal area for powerline insteon signals and having one of my access points 3 feet from it (on the wall behind with my metal junction box between the two) didn't help. see viewtopic.php?f=27&t=10513&p=79841&hilit=less+than+feet+away+from+access+point#p79841. You'll see veteran poster LeeG makes a few comments that might help you too.

Nor the WAF. unless you have a hole in your wall, you wouldn't see a wire hanging out of the back of a junction box...

yesterday I upgraded from 3.3.9 to 3.3.10 and after the update the browser closed but I could not reconnect to ISY. Cleared the cache, tried connecting over a span of about 5 mins but kept getting browser timeout. I went down to the ISY where the PWR, TX and RX were steady on. Pull the plug, waited a few secs, and plugged it back in. Everything was fine after. Upgrade did work and nothing was lost but thought I would mention it.

Doesn't have to be bare (and no doubt can't be). My garage door openers both have an insulated antenna wire hanging down from them

They don't help if you have metal junction box (required by code in Canada.) I think it would be nice if the antenna was a little wire that could be fed out of a hole in the box so it could dangle in the wall a little further away from metal parts. Personally the only time I would have chosen to purchase a dual band switch (if I didn't have metal boxes) is if I had to communicate with a motion sensor near the switch that was maybe a little far from my access points. Do you have any/enough access points? I don't think you can replace the need for access points with dual band devices. Sent from my iPod touch using Tapatalk

Hi Michel, If I had an unused motion sensor I could add in then cascade down through my affected sensors using "replace with" functionality (if that would even work toward troubleshooting the problem), I would gladly do that but unfortunately I don't. Removing the sensors, adding them back in and fixing the many programs that will be affected along the way seems like a lot of work unless I'm missing something about what would need to be done. Even if a factory reset fixed the problem, would that go toward identifying the root cause or would it just make the problem go away? and maybe only for a while? At least one and maybe two of the affected sensors has had its battery replaced since I went from 3.2.6 to 3.3.4 (am now on 3.3.9) if that helps narrow this down, although another one that has not been affected (yet, anyway) has also had its battery replaced not long ago. I'm due to replace the battery on another one soon and will keep an eye out for a message coming from that one in particular both before and after in case that helps.

Am getting an error dialog message in Admin Console that ISY cannot communicate with motion sensors. Been happening for several weeks. The actual motion sensor varies. None indicate low battery. The one today just had a lithium battery put into it a week ago. They have all been working okay (in range of access points) for the last couple of years, except for one that started not reaching ISY when I moved an access point, however: 1) that access point is back where it was, and 2) I wasn't getting that message for it when it wasn't working; I just noticed that things that should have triggered didn't. Overall I'm confused because I haven't seen these until recently and didn't think ISY checked the status of motion sensors given that they sleep most of the time to conserve battery power. Any info would be appreciated.

LeeG is right that the initial problem was different than what my test this morning showed. Since I deleted the IO Linc from the scene that was causing the problem I had to move the slider from 100 to 0 in another one and that's what I reported on. But if the slider move does not get written then I can't replicate the situation because I don't have another IO Linc that's already set at 0% in a scene.

Using a scene and regardless of trigger reverse setting: 1. setting the scene OFF turns IO Linc OFF whether the IOLinc was on or off before. So OFF works as expected. 2. Setting the scene ON turns or leaves an IO Linc ON that is set to 0%; something that would have turned a light off. There's no toggling (reversing) going on. The only aberration is that 0% turns the device ON instead of OFF. I think "trigger reverse" setting comes into play when one uses the sense and sets "relay follows input" - I don't use it in this case and can't confirm that right now. If this is something UDI can fix with ISY code, I personally can't think of a situation for "latching mode" where it shouldn't work like a light (0 means off), however you or others may have examples where that is the case. I might add too that there's precedent for fixing this otherwise presumably factory default behavior. I would point to the fact that ISY changes the factory default latching mode to momentary mode when linking in or restoring an IO Linc, which caused me grief a number of times before I posted about it earlier this month and the issue came to light. Thanks again to LeeG for working through these things in detail with me.

By the way, if this is the way IO Lincs (and other devices) work, can I ask that ISY show the proper state for them? Having programs triggered when the device turns ON (even though it's supposed to be being turned off) would not only be appropriate but it certainly would have helped me (maybe others?) both notice the behavior and be able to more easily identify the root cause of what I thought was a problem... well, actually, still think is a problem, at least for latching mode. Fortunately - or maybe unfortunately since it made it harder to find/track down - I only have one of my 9 IO Lincs (all similar "latching mode" HVAC applications) that I've put in OFF-when-another-one-is-ON scene. But interestingly I had been thinking of putting more of them in those kinds of scenes as a way to cut down on the number of programs I have (now at over 535). That's not going to happen now, of course. Would I need to post this idea in Product Requests or is this good enough?

Am on firmware 3.3.9 and have a v41 KPL 6 button relay setup as an 8 button kpl and was looking up the device links table with event viewer at level 3 when I noticed the message: Unexpected Response (i.e. DB range): ignored The first time I read the device links table it returned only 5 (of the 48) links with the last one being 00 00 00 ... The second time I did the query I got all 48 link records (which matches what PLM has) but still got the above message part way through. What happened? What does this message mean? If I'm to guess at it the DB stands for Dual Band. Interestingly the KPL is less than 3 feet away from an access point (on the wall behind it). I do have metal junction boxes and I know they reduce the range but 3 feet should be close enough to see it, no? Or do metal junction boxes completely block out RF even at that close a range? Overall there were a lot of hops left=2 but there were a few hop lefts=1 and 0, including a 0 just before the message. Here's an extract of the event viewer starting a little before and a couple of events after the message Sun 01/20/2013 10:44:27 AM : [iNST-SRX ] 02 50 20.43.49 1E.48.AD 27 2F 00 (00) Sun 01/20/2013 10:44:27 AM : [std-Direct Ack] 20.43.49-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Sun 01/20/2013 10:44:28 AM : [iNST-ERX ] 02 51 20 43 49 1E 48 AD 11 2F 00 00 01 0F 47 20 A2 05 1A 1D 09 FF 1F 07 4E Sun 01/20/2013 10:44:28 AM : [Ext-Direct ] 20.43.49-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Sun 01/20/2013 10:44:28 AM : [iNST-TX-I2CS] 02 62 20 43 49 1F 2F 00 00 00 0F 3F 01 00 00 00 00 00 00 00 00 82 Sun 01/20/2013 10:44:28 AM : [iNST-ACK ] 02 62 20.43.49 1F 2F 00 00 00 0F 3F 01 00 00 00 00 00 00 00 00 82 06 (00) Sun 01/20/2013 10:44:28 AM : [iNST-SRX ] 02 50 20.43.49 1E.48.AD 2B 2F 00 (00) Sun 01/20/2013 10:44:28 AM : [std-Direct Ack] 20.43.49-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 01/20/2013 10:44:29 AM : [iNST-ERX ] 02 51 20 43 49 1E 48 AD 11 2F 00 00 01 0F 3F 20 A2 05 17 A3 7B FF 1F 03 65 Sun 01/20/2013 10:44:29 AM : [Ext-Direct ] 20.43.49-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Sun 01/20/2013 10:44:29 AM : [iNST-TX-I2CS] 02 62 20 43 49 1F 2F 00 00 00 0F 37 01 00 00 00 00 00 00 00 00 8A Sun 01/20/2013 10:44:29 AM : [iNST-ACK ] 02 62 20.43.49 1F 2F 00 00 00 0F 37 01 00 00 00 00 00 00 00 00 8A 06 (00) Sun 01/20/2013 10:44:31 AM : [iNST-ERX ] 02 51 20 43 49 1E 48 AD 13 2F 00 00 01 0F 3F 20 A2 05 17 A3 7B FF 1F 03 65 Sun 01/20/2013 10:44:31 AM : [Ext-Direct ] 20.43.49-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 01/20/2013 10:44:31 AM : [Ext MH ] Unexpected Response (i.e. DB range): ignored Sun 01/20/2013 10:44:40 AM : [iNST-TX-I2CS] 02 62 20 43 49 1F 2F 00 00 00 0F 37 01 00 00 00 00 00 00 00 00 8A Sun 01/20/2013 10:44:40 AM : [iNST-ACK ] 02 62 20.43.49 1F 2F 00 00 00 0F 37 01 00 00 00 00 00 00 00 00 8A 06 (00)

LeeG, Thanks for the detailed response. The insight is always appreciated. I see this as about basic device behavior and would not personally position it as describing the internals of link records. The concept that sending 0% on level turns a light off is well known and a key benefit of insteon automation. (By the way I use the latching mode of the io linc, not the momentary modes and not for a garage door application.) Maybe there's good reason to have a different story for lighting vs non-lighting but I think it should be better publicized, especially since it's different than the well known behavior. I say that but maybe I'm the only one who didn't know the difference in behavior. I also think the latching mode of an IO Linc should behave like a light. I realize this comment should be made in the Smarthome forum more than this one. Just mentioning it in case UDI can fill another gap, as it so often does, and save others some grief. (Personally, now that I know I'll just work it) Thanks again.

Thanks for pointing out the needle in that haystack, but I'm confused. It's counter to all other scenes I have that turn a device off when the scene is turned on or off when the device is set to 0 on level in the scene. Is this unique to IO Lincs? If so, I guess it means I'll have to take the IO linc I want off out of the scene and write a program to do the work instead. And I guess it would explain past weirdness that I didn't understand (and didn't always notice), but what's up with that approach? Is it useful for garage door applications or something? Where is this in the Smarthome documentation? Did I just miss it? Could it be added to ISY doc (assuming I didn't just miss it there either)? It seems like kind of an important exception for people to know, whatever the application.

Am stumped (again) by an IO Linc that's going on unexpectedly and that ISY doesn't even see going on. I push button 6 on KPL 20.43.49 to turn off a scene that is supposed to turn off IOLinc 15.B9.70 and IO Linc 1F.50.CA as well as button 6, 7 and 8 on itself (the KPL) Here's the event viewer when I turn the scene off using either the admin console or the KPL button (same exact thing happens every time - have done it about 10 times now trying to figure this out myself): Sat 01/19/2013 01:08:44 PM : [iNST-TX-I1 ] 02 62 00 00 1B CF 13 00 Sat 01/19/2013 01:08:45 PM : [iNST-ACK ] 02 62 00.00.1B CF 13 00 06 LTOFFRR(00) Sat 01/19/2013 01:08:45 PM : [ 15 B9 70 2] ST 0 Sat 01/19/2013 01:08:45 PM : [ 20 43 49 6] ST 0 At this point IOLinc 1F.50.CA has turned on although neither the event viewer nor the console shows that happened So I query 1F.50.CA: Sat 01/19/2013 01:08:52 PM : [iNST-TX-I1 ] 02 62 1F 50 CA 0F 19 01 Sat 01/19/2013 01:08:52 PM : [iNST-ACK ] 02 62 1F.50.CA 0F 19 01 06 LTSREQ (01) Sat 01/19/2013 01:08:52 PM : [iNST-SRX ] 02 50 1F.50.CA 1E.48.AD 2B 0F 00 PING (00) Sat 01/19/2013 01:08:52 PM : [std-Direct Ack] 1F.50.CA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 01/19/2013 01:08:52 PM : [iNST-TX-I1 ] 02 62 1F 50 CA 0F 19 00 Sat 01/19/2013 01:08:52 PM : [iNST-ACK ] 02 62 1F.50.CA 0F 19 00 06 LTSREQ (LIGHT) Sat 01/19/2013 01:08:53 PM : [iNST-SRX ] 02 50 1F.50.CA 1E.48.AD 2B 0F FF PING (FF) Sat 01/19/2013 01:08:53 PM : [std-Direct Ack] 1F.50.CA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 01/19/2013 01:08:53 PM : [ 1F 50 CA 2] ST 255 I assure you it was off before. Here's me sending a device OFF command using the console: Sat 01/19/2013 01:09:00 PM : [iNST-TX-I1 ] 02 62 1F 50 CA 0F 13 02 Sat 01/19/2013 01:09:00 PM : [iNST-ACK ] 02 62 1F.50.CA 0F 13 02 06 LTOFFRR(02) Sat 01/19/2013 01:09:00 PM : [iNST-SRX ] 02 50 1F.50.CA 1E.48.AD 2B 13 02 LTOFFRR(02) Sat 01/19/2013 01:09:00 PM : [std-Direct Ack] 1F.50.CA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 01/19/2013 01:09:00 PM : [ 1F 50 CA 2] ST 0 Here's the log during the above timespan: (HRV Low: 15.B9.70; HRV High 1F.50.CA) 1-MISC (Non Lighting) / HRV / HRV Low Speed Status 0% Sat 2013/01/19 01:08:46 PM System Log 1-MISC (Non Lighting) / HRV / HRV High Speed Status Query Sat 2013/01/19 01:08:53 PM Web Log 1-MISC (Non Lighting) / HRV / HRV High Speed Status 100% Sat 2013/01/19 01:08:54 PM System Log 1-MISC (Non Lighting) / HRV / HRV High Speed Off Sat 2013/01/19 01:09:01 PM Web Log I compared the IO Linc's and KPL's device links tables against what ISY has and they were identical in both cases. I would like to show you a screen capture of the scene but the system won't let me upload the file. (board attachment quota reached) Here's the device links table for IOLinc 1F.50.CA: Device Links Table : HRV High Speed-S / 1F 50 CA 1 0 4088 162 0 1984685 16719617 1 4080 162 5 1711369 16711680 2 4072 162 6 2114377 0 3 4064 162 7 1471711 16711681 4 4056 162 7 2114377 16711680 5 4048 162 8 2114377 16711680 6 4040 162 22 1984685 0 7 4032 162 23 1984685 16711680 8 4024 162 27 1984685 0 9 4016 162 32 1984685 16711680 10 4008 162 37 1984685 16711680 11 4000 162 55 1984685 16711681 12 3992 226 1 1984685 16719617 13 3984 0 0 0 0

Thanks for posting, MstrD. My RCS TR40 stopped sending/receiving data over its (wired) RS485 network recently. I was going to get an Autelis bridge to migrate it from HomeSeer to ISY but now I might be in the market for a whole new solution. That said the plus with my current technology and plan was that with the Autelis bridge and a splitter cable I was going to be able run both HS (which has a plug-in for the stat) and ISY in parallel and do the stat migration over time. (see viewtopic.php?f=78&t=9840 for more info) I don't really want a wireless stat because of reliability concerns and because I have all the wiring in place. Plus my stat, furnace, ISY, HS, router, etc. are all on a 2200VA UPS with an external battery pack anyway (furnace has a DC motor and uses max of 700W on stage 2, <300W on stage 1). When power fails I lower the set point and when power returns I call for stage 2 heating to get-while-the-getting's-good in case power goes out again. I personally prefer a solution that puts the stat ultimately in charge, not my HA. For outages that outlast my UPS, on power up I just send the time to my stat. I also have a mechanical stat in the basement for freeze protection - it was in the installation manual to do that and makes perfect sense given the risks and impact of an electronic or user programming failure (I live in Canada). I'll look into this NEST w/pogoplug idea (or maybe the cheaper Raspberry PI?) and will keep watching this and other stat threads closely. Thanks again.

Unless its an easy tweak, I think what I might do is have the low battery event enable a program that counts the number of motion events. After a little trial and error I'll figure out a number that's close to the limit of the battery and have a program send a daily notification based on that number rather than low bat. Sent from my iPod touch using Tapatalk

does no answer mean there's nothing that can be done? Sent from my iPod touch using Tapatalk

http://wiki.universal-devices.com/index ... g_a_Device it's about 7 hits down when one searches for "replace device"

So one is NOT supposed to "Use Find/Replace to Replace in All Programs the old device with the new device"? Can I humbly request that the step be taken out of the manual? I'll make a note to myself but it might save others some grief. This has happened to me before and I thought it was because I didn't follow the instructions but I guess I had and just didn't check or ask anyone.

I carefully followed the instructions below (from the wiki) but ended having a ton of "not specified" in my programs (20 of them) that I had to manually change after. To confirm what I did, I first replaced references to what is my older (pre i2cs) IO Linc with the name of a newly purchased newly added IO Linc (presumably i2cs?) in my programs, then saving all my programs, then removing the (old) device from its folder and doing the "replace with" from old device name to new device, which had as its name its insteon address. Is the documentation wrong? is there a bug? did I just completely blow it and didn't realize it? I would also mention that the admin console closed on me at the end, which I don't remember from last time I did this. Looking at the last run time, ISY did NOT reboot (so why did the console close?). Also, as was the case when I moved to 3.3.4, when I checked "set options" the new IO Linc showed "latching" but when I queried it it changed to "momentary" and I had to select latching again. The latter happened before (complete with momentary behavior rather than latching) but the affected IO lincs where pre-i2CS. viewtopic.php?f=25&t=9834&p=75583p75583