johnnyt

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

see viewtopic.php?f=7&t=10090&p=77047#p77047 for a description of the programs I have that are not controlling lights (about half of them). When time permits I may post in a separate thread some examples of scenarios that are taking multiple programs in order to see if my programming knowledge could be improved to do things more efficiently.

I didn't have the admin console on level 3 when these messages happened early this morning. could this also be warnings related to exchanges between ISY and services subscribed to it other than the console, in my case HomeSeer and DSClilnk? I ask because I do periodically during the day get timeouts in DSCLink like this: 2012-12-15 23:59:05 - ISY Error: The operation has timed out (vars/set/2/12/1)

Hi, Am getting a number of the errors below on a daily basis. Could not find the error on wiki and my search in the forum yielded many scenarios that had many more error messages at the same time. In my case I'm not getting any other errors when these occur. Sun 2012/12/16 05:34:12 AM System -170001 [uDSockets] HTTP:25 error:6 Sun 2012/12/16 05:34:37 AM System -170001 [uDSockets] HTTP:25 error:6 Sun 2012/12/16 05:40:39 AM System -170001 [uDSockets] HTTP:25 error:6 Sun 2012/12/16 06:30:39 AM System -170001 [uDSockets] HTTP:25 error:6 Sun 2012/12/16 07:02:12 AM System -170001 [uDSockets] HTTP:23 error:6 Sun 2012/12/16 07:08:11 AM System -170001 [uDSockets] HTTP:31 error:6 Sun 2012/12/16 08:30:10 AM System -170001 [uDSockets] HTTP:25 error:6 Sun 2012/12/16 08:38:10 AM System -170001 [uDSockets] HTTP:25 error:6 Sun 2012/12/16 08:45:21 AM System -170001 [uDSockets] RSub:21 error:6

I have a DSC alarm with a PC5401 interface card in it. I run io_guy's DSCLink program on an always on computer and it provides the connectivity between the alarm and ISY. It's been about 90% reliable. I use alarm panel connected motion detectors and door sensors to turn on lights and an "away" keypad button to arm/disarm. I think the reason it isn't 100% reliable might be my (older) interface card but I don't know for sure. Maybe someone with a newer (IT100?) can provide some insight into those. Sent from my iPod touch using Tapatalk

If you have HomeSeer with the ISY insteon plug-in , it gives you all the stats on the status page. I think I sometimes have a performance problem when a program sends a notification, which I do a lot because there isn't good program activity logging. For example I get default messages instead of the custom message I call for, or I get told the program is running false when the notification is triggered in the "then" clause, showing a delayed execution of the notification. When I add a wait 2 secs, everything works fine. That said, I don't think I have that many execution performance problems at this point (other than at reboot, not something that happens often thankfully). The bigger problem is the performance loading, saving, backing up (restores, of course) and updating HomeSeer. I can't be sure, though, and am worried about growing things to a point where there are execution performance problems.

So that's it, no one has more than 100 programs, never mind more than 500? Well I guess that explains some of my problems and why no one else is complaining about them. I'll definitely have to look at some program consolidation, moving to variables for my legacy programs-as-variables, maybe toning down my plans for ISY and keeping HomeSeer...

if you mean my homeseer plug-in, I don't do anything to my iolincs with HS. They are used exclusively with ISY. Can you glean anything from the event log I attached earlier (post 53) as to whether or not the options I set were reported as successful? Sent from my iPod touch using Tapatalk

I don't think I do anything in a program that is better handled in a scene but I'll look again. The only exception I can think of is when I want a different light level at night than during the day. In those case I could use the "adjust scene" command, although I would still have to have a program to adjust the scene and it would only reduce runtime processing load, which I don't think is a problem. So as not to detract from the question I asked here, I may start a different thread to test some of my programming logic and see where I might be able to trim some fat, particularly when multiple programs are needed to do one thing. Even if I took 100 programs off, I'll probably gain that back over the next year or so, particularly if I keep the push on for sunsetting HomeSeer so I'd like to keep the two conversations separate.

set options

I checked all nine of my IO Lincs this morning (all used in latching mode) and one of them changed to momentary after I queried it. I don't know whether or not it was behaving in latching or momentary mode before - I just thought I would query it. It's an older one (not i2CS). I'll keep checking periodically.