Michel Kohanim

Hi jcip, Click on button C within that scene, look to your right and make sure the on level is NOT zero and ramp rate is not 9 minutes for button A (of the same KPL). With kind regards, Michel

Hi Jon, Our hosting is broken but, if you don't mind 2.7.7 alpha, it gets redirected to a different website which works. If you are interested, please send an email to support@universal-devices.com. With kind regards, Michel

Hi WayneW, If the change is only the PLM then there's no need to do restore devices; restore PLM changes the PLM id of all devices with the PLM id of the newly installed PLM. With kind regards, Michel

Hi fastbird1, Right mouse click on the desired program, choose Copy to Clipboard, and then right mouse click on this area where you are posting to and then choose Paste. With kind regards, Michel

Hi mpf541, Apologies for the inconvenience. When ISY starts, it automatically does a query of the system (unless you disable this feature in the Configuration/System tab in the bottom left corner box). Now, the main issue is that, unfortunately so, the IOLinc query ALWAYS returns the status of the relay instead of the sensor. This causes major issues after power failure since, in most cases, after power outage the relay is on (sometimes it does not hold its previous state) while the sensor is not shorted. We have already notified SH of this issue and we are tracking it. At the moment, the only thing I can suggest is the following: 1. Create an All Scene which excludes the IOLinc 2. In the Query All program, replace My Lighting with the All Scene 3. Create a new program which is run at start up and which CLOSES your garage door regardless of its state With kind regards, Michel

Hi jason|99, Good to hear. Yes, it is very possible. May I humbly recommend the perusal of our Wiki for Programming: http://www.universal-devices.com/mwiki/ ... e#Programs With kind regards, Michel

Hello unispeed, My pleasure. I am not sure why you could not reboot from the Configuration Tab. May I ask why you were trying to Restore? Restore should only be done when there system configuration is no longer equal to ISY's configuration. With kind regards, Michel

Hi fastbird1, If your camera can issue network commands, then you can immediately use our REST interface: http://forum.universal-devices.com/viewtopic.php?t=2252 If it has to be a batch file running on a computer, then you would have to use any of our WSDK, JSDK, and/or REST interface to create an application for your specific needs: http://forum.universal-devices.com/viewforum.php?f=2 With kind regards, Michel

Hi Mark, Apologies for the inconvenience. This is a known bug in 2.7.5 and 2.7.6 which has been fixed in 2.7.7 (http://forum.universal-devices.com/viewtopic.php?t=930). There's absolutely no harm done to your system ... all you have to do is to reboot your ISY. With kind regards, Michel

RLIKWARTZ, What URL are you using? It seems a lot like your use of 2.7.6 (or official URL) to access 2.7.7. Would you be kind enough to use either of the following: http://www.universal-devices.com/99i/2.7.7/admin OR http://www.universal-devices.com/99i/2.7.7/admin.jnlp With kind regards, Michel

Hi Xathros, I am going to test it again on our Ubuntu and let you know. RLIWARTZ, this is very strange indeed. Are you sure your cache has been cleared? With kind regards, Michel

Hello again, I have already responded to your trouble ticket. In short, please upgrade your firmware to 2.7.6 or 2.7.7: http://forum.universal-devices.com/viewforum.php?f=25 With kind regards, Michel

Hi deg01004, Yes it does turn on the device with address 99999. And, NO, your browser will be challenged with HTTP BASIC Auth. It's always best to use HTTPS when accessing ISY remotely. With kind regards, Michel

Hello, I thought I answered your questions in the post prior to your most recent question. Here we go again: 1. Notifications are sent one at a time. Yes, this means that each notification will contact the server to be sent. Nothing is batched. 2. The timestamp in the event log could be quite different than the timestamp for the notification. The reason is quite simple: When events happen, they are logged. This does NOT mean that they are evaluated at the same time by the Programming task. Depending on the number of events to be processed, priority of other tasks to perform, and overall system utilization, there might be some lag. Furthermore, the timestamp for the notification is the timestamp when the notification object was created If you are looking for a precise correlation between the event time and notification timestamp, it would be quite impossible with the current design especially since a program may contain many conditions ( ANDed or ORed). With kind regards, Michel

Hi Zick, We do have a requirement for batch processing which is in alignment with what you are suggesting. Unfortunately it has a very low priority mostly due to low number of requests. With kind regards, Michel

Hi again and apologies for a tardy reply. I am so very sorry for the confusion and I take full blame for it. 1. Notification timestamp is the time when the Notification Object is created (not the event). So, if you have a wait, then the timestamp is when Notify All is called 2. Notification task is sequential: it does not send multiple emails at the same time. It sends one at a time 3. The log shows the event time. Event is when the status for a device IS CHANGED or the control for a device is ACTIVATED Hope this clears up your questions. With kind regards, Michel

Hi Carl, Variables are a heavily requested feature and we are working on implementing them. Can't give you an ETA though. Please do be kind enough to watch (subscribe) to http://forum.universal-devices.com/viewtopic.php?t=930 to be notified. The case statement might be a little difficult using our UI. We'll look into it. With kind regards, Michel

Xathros, Please do let me know the status of your experimentation. You might be onto something here. RLIKWARTZ, If the statuses are not populated it means that the Admin Console was not successful in subscribing to ISY. The best thing to do would be to ensure that a) you have cleared your Java Cache and your wireless connection (if any) is stable. skunkiechris, experimental means that we are experimenting with the functionality. We are planning to have this module production ready but there are certain issues that we are working through such as the relationship between node addresses and x10 addresses. So far, it has been working very well. With kind regards, Michel

Hi Xathros, Thanks for trying this. I really do think that your Ubuntu is still using the old applet/application for some reason. To test my hypothesis, would you be kind enough to go to the Configuration tab and see if you have settings for Network (i.e. DHCP or setting static IP address)? With kind regards, Michel

Hello brklass1, It depends on the type of link. If there are orphaned links, they are dropped by ISY. If they are slave links to devices NOT yet in ISY, then ISY keeps them. Yes, this could be addressed in the future releases but the main issue is that there's no clean algorithm to automatically figure out what should be done with links. Originally, we dropped everything but there were complaints from those who had the device linked to some other exotic devices (such as PLC) who didn't want those links to be removed. With kind regards, Michel

Hello, Please see my comments below: Based on the time the event occurred + a delta for the time it took construct a notification object (in milliseconds) No. The notification object is queued up and sent by another thread. I do not think this could happen because events are queued and thus are evaluated sequentially.

Hi everyone, Restore device does in fact clear all the link records in a switch. To be precise, restore device does the following: 1. Writes whatever ISY knows about that device into the device 2. Defragments the database In cases when you import existing links during installation, ISY might bring with itself spurious links. As such, restore device will write those links back to the device every time you do a restore. This is the reason why removing a device and doing a factory reset is recommended. In some cases (defective devices), restore device cannot programmatically write links to the device. In these cases, as well, a factory reset is advised. With kind regards, Michel

Hi Xathros, I can think of two things that could cause this: 1. We have added network features so that you can find ISY using http://isy ... this is the only network feature that might interfere with Ubuntu (though I doubt it) 2. Would you be kind enough to reinstall 2.7.7? Please note that you HAVE to use a lower version client to do the install. Using http://www.universal-devices.com/99i/2.7.6 is preferred With kind regards, Michel

Hi legalguy, Please upgrade to either of the following firmware: 1. 2.7.6 Beta (http://forum.universal-devices.com/viewtopic.php?t=3007) OR 2. 2.7.7 Alpha (http://forum.universal-devices.com/viewtopic.php?t=930) With kind regards, Michel

Hello RLIKWARTZ, Please note that the Disable function only disables a device from ISY perspective so that a) it would not be included in any queries and you would not get all those annoying comm. errors. This function is best used for holiday lighting that you unplug but do not want ISY to keep querying them every night. This said, if you have a device that is NOT unplugged, the disable function does not prevent it from participating in INSTEON communications. As such, this is not considered a bug and that's why it's not listed. The bug that was listed was for disabled devices having their status updated while in scenes. That has been fixed. With kind regards, Michel