Michel Kohanim

aLf et Al, We found a bug: http://forum.universal-devices.com/view ... =4697#4697 . With respect to your question, I really do not think it would be necessary: the most vulnerable piece is the PLM and not ISY or the router. With kind regards, Michel

Hello, For ISY 26/99 versions equal to and below 2.6/1.0 respectively, if you have a power failure and if your ISY boots up faster than your router: ISY tries to get an IP address 3 times and then it quits trying and thus leaves ISY IP-Less and therefore not discoverable and communicable. This was done for cases where the user wants to use ISY without a network connection. In 95% of the routers, 3 times is enough time to provide an IP address and everything succeeds. For others, ISY will no longer be on the network. This has been fixed for the next release. In the meantime, and as a work-around, please try using a static IP address for your ISY. Thanks and with kind regards, Michel

jdva, Excellent idea .... yes! With kind regards, Michel

Mark, Thanks so very much for the clarifications. If you see 0.0.0.0 on the console then it means any of the following: 1. ISY was on DHCP (which it is not) and it couldn't get an IP from the router 2. ISY is defective ... the network interface is damaged Although you've already stated that your neighbor cannot access ISY, I have no choice but to ask: if your neighbor can replace ISY, you can send me your backup file, I can upload it into a new ISY, assign your static IP address, and send it to your neighbor. All he has to do is to replace the cables on ISY. Please do let me know if this is a viable option. With kind regards, Michel With kind regards,

Mark, They are already Tab Delimited. With kind regards, Michel

Mark, We do not use XML in the logs. With kind regards,

DEGoodrich, This device is not supported! Brian H, please do let us know what you find. In most cases, for devices that are unsupported we simply use on/off metaphor. With kind regards, Michel

jgraziano, I don't think this is a CL issue simply because out of the two devices in your scene one works and one doesn't. I believe it has to do with the device itself not getting the group command (or not responding to it). My suggestions: 1. Check your logs for -2 and see if you have any for that device (device comm error) 2. If you do, try an airgap/reboot on the device in question and follow it up with 4 or 5 queries 3. If 1 does not fix the problem, try Restore Device Please do let me know what you find. With kind regards, Michel

d_l, I am so very sorry for the problems and issues. If you do not have Excel (and are running Windows), currently the only way to get to your logs is as jgraziano suggested. On MAC/Linux, you are given the log file as is. We do have a requirement to provide this function without Excel on Windows so, please do be kind enough to use jgraziano's suggestion as a workaround. With kind regards,

Hello maui4marko, I wished you had taken our advice (about 2 months ago) and upgraded your ISY to 2.6 which has a lot of work arounds for PLM spikes due to power outages (and especially those lasting more than 10 seconds). If we can get your system up and running again, the first thing we should do is the upgrade to 2.6. Secondly, please note that when there's a power outage your cable/dsl router is also impacted therefore it's always very important to make your ISY use static IP addresses and thus when it comes back on, it doesn't have to go and reconfigure your router. If your subsequent dim/bright do not work (you keep getting the system busy dialog) then, in all likelihood, your PLM is gone. To troubleshoot, unfortunately so, we have to have your neighbor power on/off and let us know the status of the RX/TX/MEM/ERR lights on ISY. If RX is blinking every 4 seconds, rest assured that your PLM is probably defective. Please do keep my posted. With kind regards, Michel

maui4marko, Thanks so very much for the update and so very sorry for the inconvenience. I have captured it as a bug and we shall take care of it as soon as possible. With kind regards, Michel

Hello gwarthur, Please find my comments below. With kind regards, Michel Yes! Mostly because otherwise you are going to have links in devices that ISY does not know anything about and therefore, upon programming, is going to overwrite links and thus cause unexplained behavior: lights that used to turn on no longer turn on or other lights that never turned on now turn on. With kind regards, Michel

evarsanyi, Now I understand! We shall be working on Trigger 2.0 and some X10 enhancements in the next releases! Thanks so very much, With kind regards, Michel

Hello again, Ok! Now I understand ... thanks so very much for the clarification. With kind regards, Michel

Hello evarsanyi, So, you want the status of the program to be true only for 5 seconds? With kind regards, Michel

evarsanyi, Would you be kind enough to do me a favor: Can you please make sure the status of ISY gets updated when you physically turn on/off your SWLs? It's true that you cannot send immediate commands (they have to be around 500 m.s. apart otherwise sometimes the PLM does not hear them --> ISY does not hear them) but I believe the likelihood of being to accomplish that feat is low. So, there might be some other problems we are dealing with here namely: ISY's status is not updated when physically change the status of your switches. Also, if I am not mistaken, you are using PLM v.52 (or below) some of which had a problem with X10 sensitivity/lockup. With kind regards, Michel

evarsanyi, I am not sure why you would even add the wait in the "Then". The status of a program is independent of it performing any action. With kind regards, Michel

Hello HAS, Long time no see! I don't think this is possible with one command unless your Daughter's night light has a preset dim value of 10% in which case you could use the Preset Dim command. Otherwise, you can use Off and then repeat n number of Bright commands to get to 10% (depends on the light). With kind regards, Michel

Hi All, I didn't want to disrupt the exchange of ideas suffice it to say that I do find this topic very interesting as well. We can maintain the state of a scene internally and it has already been captured as an enhancement feature. I must add that since for ISY there's only a logical difference between a scene/device/button (they are all nodes) thus we do have the concept of implicit states. All we have to do is to make sure the implicit state is actually something useful/intuitive and not one that causes confusion. Thanks again for all your feedback and please do continue! With kind regards, Michel

Hello edfinley, You are correct and we are very very close: we had to change direction due to the very high cost of SSL certificates ($90.00 per year per unit). But, we are very close and you will be able to access your ISY from any mobile phone. With kind regards, Michel

Hello aanthony, Yes: http://forum.universal-devices.com/viewforum.php?f=20 (under help). With kind regards, Michel

Hello gwarthur, Ummm .... based on your statements, I am a little confused as to what you use ISY for? Timers/programs only? My comments below. With kind regards, Michel Yes, correct! When you linked your devices into ISY, did you "...bring Existing Links"? If so, that might explain why your KPL didn't show up in the scene. Under the scene, is the color of the SWLs RED? In all likelihood, ISY does not know about all the manual linkages and thus overwrites what was previously a working version. If you have two isolated switches, I do recommend removing them from ISY, adding them back in using the First Option (do not bring in the links), and try another scene. This will be the ultimate test as to what the problem could be.

Thom, Thank you for the update. It would be very hard to argue with your logic, but please keep in mind that 2 out of the 3 ways above have the word "predict" in them. i.e. ISY predicts what the outcome should be and thus your issue falls within them. Here's how All On/Off works from Insteon perspective: each device turns on to the on level/ramp rate for the FIRST ever entry for the controller in that devices database. So, since those devices do NOT actually turn on, this leads me to believe that one of the two following things are the cause: 1. ISY is predicting incorrectly ... but if your devices are in ANY scene, then that would be quite unlikely 2. Your devices do not have a SLAVE link for the PLM for the initial scene and/or any other scene 3. You have random communication issues between your PLM and those devices. If query works for those devices 99% of the time and/or if you can turn on/off those devices through a scene 99% of the time, then the problem has to be either 1 or 2. To isolate: 1. Do a restore device on one of your devices. If that fixes the problem, then we know that we had a missing link 2. If not, try airgap on your device I have started a root cause analysis to see if we can repeat this problem. With kind regards, Michel those devices are missing the SLAVE link for the PLM. What I suggest is: 1. Try restoring one of the devices, if it works, then we have found the problem 2. If it doesn't, take the device

Wayne, I am sorry for the delay ... I can vividly remember replying to this post but ... umm! Anyway, please find my answers below. With kind regards, Michel Due to a minor bug in 2.4 releases, we could not have modifications (such as 2.5.1) work with AutoUpdate so we had to renumber everything to 2.6. So, the release you are looking for is 2.7.

AD8BC, Thanks so very much. I shall make this topic into a sticky as I am sure most people will find useful. With kind regards, Michel