Michel Kohanim

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

Hello, Yes, that should have the same effect. With kind regards, Michel

Hi Sean, We were hoping that it would be included in 2.7.7 but it didn't make it. It should be available in the next release. With kind regards, Michel

Hi lloverin, Two cases: 1. ISY cannot communicate with the KPL or defective KPL 2. ISY cannot communicate with the responder or defective responder What I recommend is this: Try querying each device and see if you get any comm errors. If not, then it would be best to factory reset your KPL and then do a Restore Device on it (right mouse click on the node). If that works, do the same for the responder. If anyone fails, then I suspect first comm errors and second defective device. With kind regards, Michel

Hi brklaas1, The main question for me would be why is this switch turning itself off. Is it possible that this switch was programmed before as a responder to some other INSTEON device? May I humbly recommend the following: 1. Please remove the switch from ISY 2. Do a factory reset on it 3. Add it back to ISY Please let me know if this fixes the issue. With kind regards, Michel

Hi, I do very much apologize for the inconvenience. The link provided is for purchasing modules. Since we have migrated our store front to a new server, the links through the Admin console do not work. As such, if you would like to purchase modules, you will need firmware 2.7.7 which is due out over the weekend. Again, sincere apologies for the inconvenience. With kind regards, Michel

Hi GerryFr, This is not the intended nor designed behavior. I do not want to ask you to upgrade to 2.7.6 since it's still beta (although very stable). It would really be best to talk to have our tech support take a look at your system to ascertain where the problem is. With kind regards, Michel

Hi kcrossly, It's always best to take advantage of INSTEON protocol where possible. As such, my recommendation is to use a scene. With kind regards, Michel Yep, that's the problem. I spoke with SimpleHomeNet tech support and they confirmed that the device needs to be added as a controller. Once 2.7.7 is out is it better to setup this device as a Scene or a Program?

Hi GerryFr, Run then should run regardless of the condition. If you have 2.7.0, that might explain the issue but it would be best if you called our tech support so that we can ensure there's no bug. With kind regards, Michel

Hi Mark, You do not have to pick the type; just use Auto Discover (from the list). Unfortunately the addresses MUST be entered correctly otherwise, ISY is going to look for a device that does not exist and that might take up to 1 minute. With kind regards, Michel

Hi GerryFr, I specifically need to know if you get to the Admin Console via http://192.168.020 or via http://www.universal-devices.com/99i ? With kind regards, Michel

Hi aLf, Hopefully you still have the serial cable that came with your ISY. The only way to factory reset the 26 is to use Hyperterminal and connect to your ISY using a serial port on your computer (http://www.universal-devices.com/mwiki/ ... erial_Port). Once connected, and logged in: 1. To make your ISY have a dynamic address, issue CT followed by 0.0.0.0 for the IP address 2. To factory reset your ISY, issue FR With kind regards, Michel