MikeB

Good question. I was actually thinking about something similar a while back when people were discussing ways to have different on-levels for different times of the day. If SwitchLinc Dimmers didn't require a soft-reset to apply on-level changes, I was thinking a good way to accomplish this would be to have a way in the ISY to program new on-levels into devices a couple times per day. This wouldn't work, however, because of the needed soft-reset. Even if it did work, I wonder if this would potentially decrease the life of the switch...

Hey Andrew - If you check this thread: http://forum.universal-devices.com/viewtopic.php?t=769 ..you'll see it's a listed feature for the upcoming v2.7 firmware. A beta for this firmware should be released soon. It's awfully quiet on these forums, which usually means they are hard at work!

I'm not really sure what you're referring to, but my best guess is these threads? http://forum.universal-devices.com/view ... highlight= http://forum.universal-devices.com/view ... highlight= There are no queries at all in those programs. For example, with the 'entire floor status LED' program the only extra powerline activity is actually turning the status LED on or off, which happens only when: - All lights are off, and the first light is turned on. - All lights are off except for one, and that final light is turned off. One of the major features of the ISY, in my opinion, is that it always KNOWS (in a good working Insteon system) what the status of every device is. There really should be no need to query, except for the occasional missed command (caused by simultaneous button presses, etc.), which is why they have their 3am query - just in case. If I depended on even 10 minute queries to know the status of my lights, those programs would be useless to me. That's why it's recommended to fix the source of your comm issues rather than run queries. Now if you think that Smarthome needs to release an improved PLM to fix your particular issues, that's fine - and the topic of another thread. My point is that frequent queries is not a substitute for a good working ISY/Insteon system. If you have a substantial Insteon system, and run queries every 10 minutes, button presses during those queries may be slow to respond, and commands may be more likely missed. If it's working for you, then run with it - but it's not good advice for the majority of ISY users.

Could you possibly have a speed issue at home? Michel or Chris could tell us exactly what happens, but I'm assuming the remote PC simply downloads and runs a Java app when you connect to the ISY. As a test, I just opened my ISY from a remote connection running on a 3Mbps/768Kbps DSL line. My home connection is a 6Mbps/768Kbps cable connection. The ISY has never been opened from this remote connection (so the Java app wasn't cached), but it only about 5 seconds before I got my logon screen. I can't imagine anything wrong with the ISY would cause only remote connections to be slow.

Faster internet connection? Mine takes a few seconds longer than connecting locally, but not much.

Digger - I replied to your post because I don't think scheduling My Lighting queries to run constantly throughout the day is a good idea. If you are having communications problems, that will simply multiply it and possibly interfere with normally working functions. If a user is having problems with the ISY recognizing status changes on their devices, they're far better off fixing the issue (reducing noise, relocating AccessPoints, fixing broken links, replacing bad devices, etc.) than trying to mask it unsuccessfully with 2 queries every hour. If the PLM does have a lower signal output / sensitivity than the PLC, I'm 100% behind efforts to try and get that rectified. However, that doesn't mean people need to live with comm issues in the meantime. Many people (most people?) on here that I know of have good communications to and from their PLM, so it can be done.

Excessive queries of all your lighting, especially on large setups, creates excessive powerline traffic which can cause actual button presses or scheduled events or triggers to not work properly. If you want reliable communications, your goal should be to reduce noise and eliminate excess powerline traffic - not create more. Also, if you have poor powerline communications in your home, I can't see how extra queries are going to help - it'll only make your problems worse. You could have devices whose statuses are accurate, but then you run a query, communications fail, and the ISY no longer knows the correct status. If you're having communication issues, solve it - don't try to mask it with extra queries that are only going to make things worse.

To expand on that further, you could get the black tabletop enclosure to help cut out the light. I don't have one myself, but my understanding is that the black KPL buttons DO NOT let light shine through like the white buttons do, so it might be more appropriate in your bedroom. http://www.smarthome.com/2486pbk.html

As far as I know, later PLM firmware versions have only shown improvements. As for replacing a problematic PLM, I would contact SmartHome and politely explain the issue you are having (lockups during heavy use, etc..).

Check out this thread: http://forum.universal-devices.com/view ... highlight=

I'd use the PLM with the latest firmware, so 61.

Hey Frank - I normally add devices by address. However, with my v1.5 KPLs, it does not work - the ISY gives a 'Request Failed' error. Adding the KPL by the 'Start Linking' command works fine. The v1.6 KPLs, however, don't seem to work at all. At least some of them.

Check the device in the ISY. If it shows as a "LampLinc', then that's your issue. Apparently some v1.6 KPLs are being incorrectly identified as LampLincs. I have one here doing the same.

YES

I believe your problem is that your STATUS OFF program should have ANDs and not ORs. Your STATUS ON program is turning the LED on, but then since one of your devices is probably off the status light gets turned back off.

That's right.... with a separate AC adapter, I bet you could go quite a distance.

It's not any kind of safety issue. Low voltage, no worse than POE. I'm not sure at what distance the voltage drop would be too much. If someone knows the power output of the PLM and the power requirements of the ISY-99, this page should help figure it out: http://www.demarctech.com/techsupport/poecalculate.htm Keep in mind you could always get an RF IR extender as well, and relocate your ISY to a more reliable location. I just saw one at my local Best Buy for $45. Or, if you're going to run a Cat5 anyway, you could use a hardwired IR repeater.

Well thanks for the suggestion. We're all learning here, and I'll often change my programs 3 or 4 times based on other people's ideas and optimizations. That's why I like posting what I'm using for programs. These threads benefit everyone!

Maybe.. but my head is spinning and my programs are working well, so I think I'm going to leave them as-is for now. I'm going to go through mine today as well.

Thanks! That's a good suggestion. Do we know for certain that the order of the conditions matters? Does the ISY evaluate the entire IF no matter what, or does it process the conditions line by line and stop if a line makes it false? I'm all for it.

Maybe I'm missing something, but I don't think that's the case. This code: If ( Status 'KitchenBar1' is not 90% Or Status 'KitchenMain1' is not 50% Or Status 'KitchenTable1' is not Off ) And Status 'KitchenControls1G' is not Off ..will only run the THEN if my status light is on, AND one of the scene contained lights is adjusted. If it's adjusted, the status light will go off and not run again unless the scene is re-activated. So ISY traffic is minimized. This code: If Status 'KitchenBar1' is 90% And Status 'KitchenMain1' is 50% And Status 'KitchenTable1' is Off ..is false any time any of those lights are adjusted. This code: If Status 'KitchenBar1' is 90% And Status 'KitchenMain1' is 50% And Status 'KitchenTable1' is Off And Status 'KitchenControls1G' is On ..is also false any time any of those lights are adjusted. Adding an additional conditional doesn't make it any less likely to be false. Unless I'm not grasping what you're suggesting? Which is possible, because I'm pretty tired.

No, because I'm also checking to see if the KPL button is on. If it's not on, then the progam won't run.

I believe that would work, but the ISY would process this program any time a light contained in that scene was adjusted.

You must use a PLM with either ISY.

Thanks for the reply Jeff. What you say makes sense, but unless I'm missing something there's no way to for me to do that without creating some redundant powerline traffic (which I'm always trying to avoid). The basic premise is that the only way my scene is set is if the appropriate KPL button is pressed. If that button is pressed, then it is already on. That's why I focus on turning that button off rather than turning it on. I believe the code you have here would work OK: If Status 'KitchenBar1' is 90% and Status 'KitchenMain1' is 50% and Status 'KitchenTable1' is Off Then Wait 2 seconds Set Scene 'KitchenBreakfastStatus' On Else Wait 2 seconds Set Scene 'KitchenBreakfastStatus' Off The only thing I don't like is that if this scene is set, then I've pressed the KPL button and it s already on. Your code above would then, 2 seconds later, send a 2nd on command to it. I could add a check to see if the button is on already, like this: If Status 'KitchenBar1' is 90% and Status 'KitchenMain1' is 50% and Status 'KitchenTable1' is Off and Status 'KitchenControls1G' is not On Then Wait 2 seconds Set Scene 'KitchenBreakfastStatus' On Else Wait 2 seconds Set Scene 'KitchenBreakfastStatus' Off ..but then the program would loop and my status light would keep turning on and off. I do see what you're saying though.