johnnyt

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

Would a blank status allow one to set the trigger to if "low battery indicator" is not Off causing the program to run again at startup? Perhaps things could be set up so only a manual "pseudo" query or a user program would set it to off (not an ISY startup). That or maybe persist the state for these devices and recall it at startup?

About a week ago one of my motion sensor's low battery indicator came on. In the past I've seen them happen then clear themselves only to have the device stop working about a month later and not really knowing what happened. This time I was watching more closely. The program that runs is this: If Status 'MISC (Non Lighting) / Dusk and Low Bat Sensors / Laundry Room Motion-Low Bat' is On Then Repeat Every 24 hours Send Notification to 'me' content 'Low Battery' Else - No Actions - (To add one, press 'Action') It ran fine for several days until I rebooted ISY. I did the reboot just to see what would happen and sure enough the program stopped running and the low bat node is now off. I did not query it - which is how I understand one clears these - however I believe ISY queries all at startup and it appears to include the low battery indicators. Is there something I need to do to prevent a reboot from reseting low battery indicators? If not, is there something UDI can do? As well is there a better way to program this event? I'd like to delay being notified for several weeks since the low battery comes on with quite a bit of life left in the battery and I want things to (efficiently) live through everything that can happen during the month or more of use left in the battery. A wait 500 hours doesn't seem like the best approach.

had a similar thing happen a little while back. I turned on a light and all my insteon devices turned on. It had never happen in the 2.5 years I've been using insteon or the 10 years before that using X10 - although i have had individual x10 devices go on by themselves. Hasn't happen since. It was nothing in my ISY programs or scenes so I just assume it was some kind of power event. I had been resisting automating garage doors and going with an insteon thermostat (actually any kind of RF thermostat) - these occurrences, even though they seem quite rare, reinforce that. Sent from my iPod touch using Tapatalk

Depends how long you want power. APC and Tripplite web sites have runtime calculators. What your putting on the UPS will probably only take a few watts in terms of 120v draw. (1W @ 12v = 0.1W @ 120v) If you want really long runtimes look at the units that allow you to connect external batteries - models typically end in XL. You might want to get one that can be configured internally to shutdown with some runtime left. It keeps the batteries from completely running out, which is bad for them but for that I think you might have to go to a "smart" UPS, which will cost more. I've only used smart one myself because I back up a computer and need the UPS to power off and restart in order for the PC to restart. Cheaper ones don't do that. Sent from my iPod touch using Tapatalk

II don't have an elk so don't know how ISY and it talk (do you need the PLM or does it communicate over the (ethernet) network?) At any rate having a PLM on the UPS (which should be on a filter) will block its power line commands. I think you can get around this by putting an access point in range (but not UPSed) to pick and pass on the command over the power line, however there are two problems with this. Access points don't pass on X10 (if you need that), and things not UPSed will not have power during an outage to respond to what the PLM sends so there's little value (unless elk uses it and is also on the same UPSed circuit.) Sent from my iPod touch using Tapatalk

Just double checked and my other KPL also does not do non-toggle mode properly. so I have two KPLs that don't do non-toggle mode as advertised in the brochure...

or a v40 KPL?

I set several buttons on one of my KPL's to non-toggle mode after deleting and re-adding the KPL, which had given me grief in that area - and with LED brightness - because I had done a "replace with" to it in the past (I dealt with tech support at the time, which was not long ago). I added it using 3.2.6 and have since upgraded to 3.3.4 and 3.3.5 (not yet at 3.3.6) and non-toggle mode has never turned off a button on it without the help of a program. I do, however, have another KPL next to it where non-toggle mode does work. (both KPLs are v36)

For $50 I can give you a 1 hour personalised "getting started" tutorial using your ISY, my ISY and windows remote assistance. I'll include a 30 min follow up session a week or so later after you've had a chance to try a few things. Judging from my own experience it'll save you quite a bit of time, especially if you don't have much programming experience although even with programming experience I would have benefitted from something like this myself when I got started. PM me if you're interested. Sent from my iPod touch using Tapatalk

sorry, I'm confused. Are you saying they never worked properly for you, or that they just failed after a "restore device"? have you tried manually setting them to non toggle mode? would that a bad idea - does ISY care about it or just report whet the KPL tells it? Thanks.

I recently set up a bunch of keypadlinc secondary buttons to non toggle OFF and a number of them don't turn off after I push them but do send only off. It seems one of them does turn off though. I have a program to turn them off after 4 secs but the one that turns off does so in less than 2 secs. What is supposed to happen? I've had problems in the past setting buttons to non toggle mode (as well as setting LED brightness) using ISY and am wondering of this is a glitch or if it's working as designed. The KPLs are v36. Sent from my iPod touch using Tapatalk