Michel Kohanim

Hi Jim, I think they are related removed devices which were removed but the associated configuration files were not removed. Quick questions before applying the procedure to fix: 1. Do you have any of your scene which cannot be programmed (on level/ramp rate)? 2. Do you have any of your devices which are not operating properly and/or are missing? If the answer to both of these questions is NO, then please: 1. Telnet to your ISY 2. Login 3. Issue FN (Fix Nodes) With kind regards, Michel

Hi dss, You can add them just like KPL buttons but the main issue is that they will all be toggled. As of right now, we do not know how we can change that function: it's a memory location which needs to be programmed for each button and we do not have the specs for it. With kind regards, Michel

Hello mozman, ISY goes into SAFE mode if it cannot communicate with your PLM and thus you will have all those socket errors if you have a faulty PLM. Please also note that on some firewall software (McAfee and Avast), disabling them does NOT help since they still have resident programs that filter out the packets. We'll be able to figure out these problems tomorrow and hopefully from then on you'll have a more enjoyable experience with your unit. With kind regards, Michel

Hello Tim and jkraus, I just checked two of my KPLs (neither of which are 2C; they are 29 and 31), and the both work fine: A and C in 8 button configuration Load and C in 6 button configuration A and C in 6 button configuration So, I assume the load button is the issue in both cases, right? With kind regards, Michel

Hi again, NO. With kind regards, Michel

Hi jkraus, Two questions: 1. Are these buttons in any other scenes as responders? 2. Are these buttons used in any programs? Would you be kind enough to try and restore the device and report the results? Thanks and with kind regards, Michel

Hi dss, Unfortunately not ... there's nothing in the documentation that tells us where this information is stored. Could it be done while linking to ISY? With kind regards, Michel

Hi Frank, For your 26, please do make sure you actually have 2.7.0 installed. For best performance and most stable system + motion sensor and IOLinc, please move to 2.7.6. With kind regards, Michel

mozman, I do apologize for the inconvenience. What you are experiencing is not normal and it should not happen. Before spending too much time on it, please give our tech support a call or contact us so that we can figure out what's causing all these issues. SocketTimeout happens in the following cases: 1. Your PLM is defective and ISY is in the Safe Mode ... this explains why you have these problems more often when you are linking 2. You are on a wireless network with not so good of signal reception 3. Internet Connection Sharing on Windows 4. Firewall ... especially McAfee, Zone Alarm and Avast 5. Defective unit With kind regards, Michel With kind regards,

Hi matapan, Good question! All events go to a queue and are processed sequentially in the order they are received. So, the best thing would be to break up any OR conditions into new programs, check for exception, and stop those offending programs in the face of exceptions. In the case of ANDed conditions, I do not think you will have any problems since as soon as one of the conditions is false, the whole program stops. With kind regards, Michel

Hi Rich, The first question I have is: do you really want ISY to send you en email every 2.5 minutes as long as the door is open? Have you checked the event viewer to see if you actually get DOF when the door is closed? Please note that Control and Status are too different things. ISY status for a device is NOT equal to whether or not a control was issued. I think, in this case, you might want to use Status instead of control. With kind regards, Michel

Hi David, Thanks for the update and yes it does make sense. Unfortunately, the only way to remove X10 address is via Factory reset. With kind regards, Michel

Hi AutomationNut, At a very high level: INST-ACK is the PLM acknowledging the receipt of an ISY command INST-SRX is whatever signals the PLM receives from the powerline So, what you have is: INST-SRX to Group 1 So, it seems that you pressed the button associated with the first IRLinc node. Since you do not have any scene being controlled by this node, no other status changes you see. The last piece is issued by your IRLinc trying to make sure all responders have done what they were supposed to (cleanup). With kind regards, Michel

Hi Allan, Thanks so very much! I have indeed received the calculations and it's currently planned to be supported after we are done with ECM1240. In short, it's in our plans ... Thanks again so very much, With kind regards, Michel

Hi David, Yes, you are very correct: ISY reevaluates conditions only when one or more conditions have changed. Now, we have to figure out why ISY misses the status changes! With kind regards, Michel

Hi David, Ah, yes! How could I have not seen that? So, sending All Unit's off via the REST interface (which calls the program) works fine but the program itself does not (once in a while). So, as you suggested, the problem could either be that ISY does not receive GDO Outlet Vehicle's status or that the X10 signal is not getting to its destination. Would you be kind enough to open the Tools | Diagnostics | Event Viewer on level 3 and make sure you get status feedback from GDO Outlet Vehicle. If so, then would you be kind enough to try and send the off command twice? The difference between Status and Control is this: Status changes with every change in status! This means that when a switch is ON and then you press the ON button again, the status does NOT change. Control is the actual physical activity imposed on the devices. So, if the device is ON, and you press the ON button, your program will receive another ON event. With kind regards, Michel

Hello someguy, I think it's about time to call our tech support so that you wouldn't have to waste more time trying to get the motion sensor to work. With kind regards, Michel

Hi davidn70, Very neat! The first thing I would do is to add 1 (or a little more) wait between the X10 offs. The second thing I would do is to ensure that the lights controlled by these X10 devices are not generating noise when they are on. Perhaps, you can unplug them one at a time and retest the program. With kind regards, Michel

Hi Rich, This is excellent and it should work fine. Please keep us posted. With kind regards, Michel

Hello ergodic, The first thing I would do is to run the Scene Test to see if the status of all the lights in the Garage Scene are tracked properly. If not, then that would certainly explain some of the issues you are seeing. With kind regards, Michel

Hi MSM, Thanks so very much for the update and I am so very delighted to hear that you are happy with the unit. With kind regards, Michel

Hi Mike, I actually like this idea. I would like to add it to our list of requirements (low priority). Thanks so very much. With kind regards, Michel

MSM, This is quite surprising: going to http://www.universal-devices.com/99i searches the network for your ISY. If this URL does not find your ISY, then perhaps the problem is that your ISY has a static IP address which is not in the same subnet as your new router. The only way to change the IP address is to connect your ISY to your computer, use Hyperterminal, and change ISY's IP address to something with in the current router's domain. Here are some instructions: http://www.universal-devices.com/mwiki/ ... IP_Address With kind regards, Michel

Hi cslee, There seems to be communications errors (-2). Would you be kind enough to try and query the devices and see if they respond? Also, you might want to check and see whether or not these issues are time related and, if so, we'll have to try and figure out what's causing the communications errors. With kind regards, Michel

Hi, This is a bug which we are working on. With kind regards, Michel