Michel Kohanim

Hello oberkc, How many devices/scenes do you have? With kind regards, Michel

Hello seacordean, In the case where device did not respond, you do not get a -2 for device communications error? If you do not have a -2, how certain are you that the device was not already off. Would you please scroll up the log and find the last Status event for that switch and make sure it was not 0(off)? ISY does not retry commands that are sent through programs or web. The only commands retried are those impacting the database and configuration of devices. With kind regards, Michel

Hello orberkc, I agree with LeeG. In addition, I recommend doing a PLM Link count to make sure your PLM links are still there (Tools | Diagnostics | Show PLM Link Table). With kind regards, Michel

Hello seacordean, Please note that in the log: 1. The first entry is "what the program tried" 2. The second entry is either failure (-2) or the status change if the status ACTUALLY changed. So, if you do not see a -2, it probably means that the unit was already off I totally agree with LeeG with respect to using the Event Viewer to see what's being transpired. With kind regards, Michel

Hi ernie, Thanks so very much. That's quite odd because in addition to UPnP we also use another UDP packet to find ISY on the local network. I guess we have to do more research and figure out why we cannot find ISY. With kind regards, Michel

Hello seacordean, My pleasure. First, please look at the logs. You should see an activation/deactivation (on/off) for that device, initiated by Program, at that time. If the action was successful, the log would be followed by a Status entry for the same device. If not, on the same entry, you would see a -2 in the last column. If the action was against a scene, then it's quite possible that your devices within the scene are not responding. You might want to consider doing Scene Test on those scene within which devices are not responding. Scene Test: right mouse click on the Scene and then choose Scene Test. With kind regards, Michel

Hi ernie, Thanks so very much for the clarification. No, I do not think you should update the procedure. Personally, I think the /99i/admin.jnlp is much more useful since it's not tied to a specific IP address (Admin Console searches for ISY on the network). Is there a problem using /99i/admin.jnlp with Linux? Thanks again and with kind regards, Michel

Hello seacordean, Programs continue their normal execution regardless of error. As a matter of fact, based on input by porscheguy, we are going to make Device Error a condition which can be used in programs. With kind regards, Michel

Hello ernie, THANKS SO very much for your feedback and instructions. One question though, can't you go directly to: http://your.isy.ip.address/admin.jnlp instead of pointing to /99i/admin.jnlp and then editing the JNLP file? With kind regards, Michel

Hello all, We had to put a workaround for SyncrhoLinc since it seems that our initial understanding (documented) that extended messages (i2) would be only in response to extended messages has proven to be wrong for the second time. In SyncrhoLinc version 82, everything should work fine (except setting the options) simply because PEEK and POKE respond with PEEK response and POKE response. In version 8C, PEEK and POKE respond with extended messages that ISY DOES NOT expect. This basically throws off ISY and thus all the spurious messages. Incidentally, iMeter has the same paradigm: it responds with extended messages when given standard commands. I have notified SmartHome to make sure this is indeed what they had in mind. Rod, you do not have to worry about i1 and i2. It's just different methods of communicating with INSTEON devices. With kind regards, Michel

Hi LeeG, Thanks so very much for your vote of confidence! With kind regards, Michel

Hello all, I do apologize for the inconvenience. This is the classic case of i2 commands that work for setting properties but not working for data transfer. This is a bug which shall be fixed in the next release. With kind regards, Michel

Hello thruster999, ISY links and device links comparison shows that they are identical. You can ignore the last record. I know it's difficult, but when you get the 01010 icons, do you put your Motion Sensor in programming mode before trying Write pending updates? Also, do you have any programs that try to change the on level/ramp rate for the responders in that scene based on certain conditions (such as time of day)? With kind regards, Michel

Hello Lee, Thanks so very much for the clarification. I was totally wrong: program execution does not go through message handlers which impose the 3 retry rule. On the other hand, anything that has to do with database write/read is retried 3 times. I am so very sorry for the confusion. With kind regards, Michel

Hello sanders2222, You can ignore UDSockets error; they basically mean that ISY is busy doing something holding up the HTTP task. When you do any type writing to devices (restore, link, writing pending updates) that might take a long time, ONE or more of HTTP tasks are held up till the process is finished. The warnings in the log can be ignored. porscheguy, If you cannot communicate with a devices, there are multiple cases one of which is signal not reaching destination. It's very difficult to figure out why you are having the errors without having the logs for each error and see exactly what transpired. To answer your questions: 1. ISY retries 3 times sending the same command 2. The number of native INSTEON retries is NOT captured in the Event Viewer 3. Above and beyond retrying, ISY does not do anything to resolve communication errors With kind regards, Michel

Hi Peter, We'll do our best but currently all our efforts are focused on ELK. With kind regards, Michel

andyf0, LeeG is right on ... if you want your programs to complete without interruption, then it's best to call another program without a condition. RLIKWARTZ, You might want to check the schedule grace period. Once you hit Wait and if the current time +/- grace period does not evaluate to true, then your program stops. Or, instead of using Dawn, use From/To (i.e from Dawn to Dawn + 1 hour). With kind regards, Michel

Hi Clarence, No ZWave planned ... With kind regards, Michel

Hi Clarence, 992i was a limited production run with external Zigbee SEP module to communicate with SmartGrid meters. 994i is similar to 992 but it has an expansion slot for the Zigbee module. We have two Zigbee modules: 1. SEP to communicate with Smart Grid meters. We cannot sell this module without going through your utility 2. Zigbee PRO which can now communicate with Brultech meters We do not have any Zigbee version that work with HVAC systems; Zigbee is NOT interoperable unless all devices are using the same profile. In short, based on what I hear from you, I do not think any of these devices would meet your requirements. With kind regards, Michel

Hello porscheguy, Actually that would not be a good idea since, in case of extreme communications problems, your system is going to go into an infinite loop keep trying to rectify it. Although we cannot prevent this scenario, but I strongly recommend limiting the actions to a notification. With kind regards, Michel

Hello all, Release 3.1.2 (Beta) is now available at: http://forum.universal-devices.com/viewtopic.php?t=6194 With kind regards, Michel

Hello all, Release 3.1.2 (Beta) is now available at: http://forum.universal-devices.com/viewtopic.php?t=6194 With kind regards, Michel

Hello all, I am happy to announce the availability of our 3.1.2 release! For a list of changes, please take a look at this post: viewtopic.php?t=6015 Things to test: Variables! i2 commands For a discussion of variables, please look at the new Program Variables forum viewforum.php?f=68 Notes: 1. ISY-26 is no longer included in the firmware builds 2. Due to the sensitive nature of supporting MorningLinc, users now must agree to terms and conditions upon Admin Console start up otherwise the dialog keeps popping up every time the Admin Console is started 3. IMPORTANT If you have already installed a self signed certificate and your current firmware is 2.7.10 and below, you must reinstall a new one before the upgrade: http://www.universal-devices.com/mwiki/ ... rtificates Instructions: 1. Please backup your ISY (File | Backup ISY) 2. Please download the firmware for your platform - please do not unzip ISY 99i Series: http://www.universal-devices.com/update ... _3.1.2.zip OR 992i Series: http://www.universal-devices.com/update ... _3.1.2.zip OR 994i Series: http://www.universal-devices.com/update ... _3.1.2.zip 3. Important Due to invalid Java certificate chain in releases 2.8.5 and above, please make sure to remove all Universal Devices certificates from Java: a. Close all browser sessions b. Open Java Control Panel (Java Preferences on MAC) c. Click on the Security tab. Remove all Universal Devices certificates (on MAC, click on the '-' button at the bottom) e. Clear your Java Cache ( http://www.universal-devices.com/mwiki/ ... Java_Cache ) 4. Login to the Admin Console and choose Help | Manually Upgrade [the name of your system] 5. Choose the file saved in step 2 MAC users: if upgrade fails, please add https://your.isy.ip.address to ISY Finder (see 3f above) 6. After the upgrade, ISY reboots. Please do ensure to clear your Java Cache: http://www.universal-devices.com/mwiki/ ... Java_Cache 7. IMPORTANT Once upgrade is completed and ISY reboots, use any of the following methods to access your ISY's Admin Console: a. http://isy/admin - applet (Windows only) b. http://isy/admin.jnlp - Java application (Windows only) c. http://your.isy.ip.address/admin - applet d. http://your.isy.ip.address/admin.jnlp - Java application e. http://www.universal-devices.com/99i/3.1.2 - applet f. http://www.universal-devices.com/99i/3.1.2/admin.jnlp - Java application Thanks and with kind regards, Michel

Hello porscheguy, -2 means device communication error. UNKNOWN means ISY received a message from a device with an unknown address. Subsequent to the Unknown, there's another -2 for your EZIO ... Yes, we are sizing this requirement and hopefully we can included it in a future build. With kind regards, Michel

Hello ELA, Thanks so very much. This is so very mysterious! Do you also have problems with notifications? If you have not tested yet, please try DHCP again and do a Test notification. I just want to figure out if the problem is with DNS resolution or just that NTP address. With kind regards, Michel