Michel Kohanim

Hello taskman, Even I am getting tired of me saying that we are changing the GUI and building it from ground up. The fact is, although we are really doing this, it seems that something more urgent keeps coming along and getting us sidetracked. Now, with the InterfaceGo/iPhone/IES/ interfaces, you do have that capability. For instance, with iPhone, you prefix the name with a character and so on and so forth. We are still working on updating our GUI ! With kind regards, Michel

Hello Mr. Carney, thanks so very much for sharing this information with us. I have take the liberty of copy/pasting this to our Firewall forum. Thanks again and with kind regards, Michel

Hi all, There's an exception: LampLincs which support Load Sensing will also show up as controller icons. With kind regards, Michel

Hello curtbl, We are investigating this solution. The main problem is that although our programs use Meta data to act upon events, but, to some extent we have to know what those events are. So, we are working on a low cost solution for networked attached devices that will expose their capabilities to ISY and thus can immediately be used in programs. Unfortunately, the priority is low. With kind regards, Michel

Hi jcthorne, The main question is: what would you like done with ISY hears the "off" signal? The problem with the above program is: when ISY hears the Off from motion sensor, thus the condition becomes false and thus the execution stops (stops waiting). Now, if you do not care about off sent my MS, all you have to do is to remove the And Control .... switched off and you should be fine. In short, the condition becomes true every time there's motion and waits 30 minutes. With kind regards, Michel

Hi lapolonyc, Here you go: http://forum.universal-devices.com/viewforum.php?f=49 With kind regards, Michel

madcodger, Thanks so very much for the feedback. Yes, indeed this is on our requirements list but with a low priority. Is it possible for your weather station to also feed WeatherBug? We spoke with Weather Underground and they wanted an exorbitant amount of money for licensing. NOAA site does not have a real time feed (it's hourly and you have to download a large xml file ... they are working on a web services solution though). So, we chose WeatherBug since their licensing is very reasonable and they have an open API which can be used for reporting to and retrieving from ... all and all everything is almost in real time. So, while waiting, it would be best if we can figure out a way to report to WeatherBug and thus others would also benefit from your information + you will get the WB module free of charge! Again, we do have this in our list. With kind regards, Michel

Hello Z, not currently but this is a good idea. I am going to add it to our list of requirements. With kind regards, Michel

Hi ergodic, You will see just a little bit of improvement in 2.7.3. Still, if you have many things queued up to be sent on the wire, then you will experience delays till all our sent out (500 m.s. per message). The configuration option is very tempting but the main issue is changing task priorities is always a very risky business. As such, please do be kind enough to test 2.7.3 to make sure you are not having system hangs. With kind regards, Michel

Hi all, Based on the feedback, we changed some of the behaviors and task priorities in 2.7.3. Although we could not make drastic changes, but we managed to make program execution just a little more responsive by changing some of the priorities. Please do be kind enough to test 2.7.3 when it comes out and let me know how it feels. Also, please do make sure to check for deadlock or unresponsive system. 2.7.3 should be out very soon. Thanks and with kind regards, Michel

Hi Al, I sent this link to SH team. Hopefully we'll have someone respond in a few days. With kind regards, Michel

trosmus, thanks SO very much. Your invaluable log provided me with enough to actually find a very rare bug the finding of which would've been impossible otherwise. Moshe, thanks for finding this bug. It's all fixed now and included in 2.7.3 (hopefully to be dropped any day now). With kind regards, Michel I am seeing the same problem. Version is 2.7.0 I have the NTP server Enabled and set to sync every hour. I run my own local NTP server so I know it is not a connection problem. Upon a ISY device reboot, I see the initial time sync.... (.130 is the ISY device and .50 is the server running NTP) 9:47:17.89708 172.22.22.130 -> 172.22.22.50 NTP client (Wed Feb 6 22:28:16 2036) 9:47:17.89761 172.22.22.50 -> 172.22.22.130 NTP server (Sun Apr 12 09:47:17 2009) Then nothing, ever. If I do a manual "Synchronize now", I get another valid time sync.... 16:22:46.36672 172.22.22.130 -> 172.22.22.50 NTP client (Wed Feb 6 22:28:16 2036) 16:22:46.36844 172.22.22.50 -> 172.22.22.130 NTP server (Mon Apr 13 16:22:46 2009) Also note the initial date/time from the ISY device

Hi guy, Please do be kind enough to test http://www.universal-devices.com/test for some of the Linux fixes. The fixes were tested on Ubuntu 8 and Java 1.6.10. The major outstanding issue is the cell renderer in for the tree and the background color for the programs. It completely baffles me how Java has two completely different faces on Windows vs. Linux. With kind regards, Michel

Hello jkraus, Wow, this is incredible. Are you saying that your non-INSTEON devices start flickering when you use INSTEON to activate a scene? If so, what protocol is used for those other devices? With kind regards, Michel

Hello f_richey, This specific situation that you are describing should be fixed in 2.7.3. But, what's not fixed (and is an SH issue) are: 1. Changing the status of the relay changes the status of the sensor (from Admin Console) 2. When the IOLinc relay times out, the status is not reported back to ISY With kind regards, Michel

Hello Davonavo, First of all, thanks so very much for considering ISY. As much as I would want you to own an ISY, but I do think that currently ISY and the devices it supports do not match the same capabilities as JDS TC. As you noted, you could use ISY with I/O devices (such as IOLinc/TriggerLinc and - if you are lucky - with EZIOxxx) and then use their inputs to effectuate program execution. But, beyond those devices, ISY does not have the capability of natively supporting I/O devices. You will find many programming examples and tutorials here: http://www.universal-devices.com/mwiki/ ... e#Programs With kind regards, Michel

Hello NewTech, Normally you wouldn't have to know anything about i1/i2 since ISY should take care of them under the covers. At a high level, i1 and i2 are two modes of communications with INSTEON devices with i2 supporting longer messages. The reason you see references to i1/i2 is because a while back we had difficulties figuring out which devices supported which. Now, that should be history for the most part. With kind regards, Michel

Hello ergodic, We will surely investigate this feasibility. The problem is not necessarily horse power but priorities: the client update task has a higher priority than the programs. The main question is: do you wish for your clients (such as Admin Console, InterfaceGo, IES touchscreen, HS) to be updated first or the programs? With kind regards, Michel

Hi Moshe, Can you check your logs to see if you have any -6000x errors? It seems as if ISY is not synching with your NTP properly. With kind regards, Michel

Hi Al, You are very much justified to feel nervous. I have already sent an email to SmartHome Engineering and they are testing it. Unfortunately, I cannot provide you with more detailed information since I do not have any. Just to clarify, this is the issue where changing the status of the relay causes the sensor to have the same status as that of the relay. Correct? The other issue is that the sensor does not send an Off command when timing out. With kind regards, Michel Re-reading this I am nervous that the "Status of IOLinc incorrect" is not actually a fix in 2.7.3 but text stating that there is a firmware issue that you cannot work around. If there is no known workaround for the firmware issue can anyone point me to a discussion about this firmware issue, hopefully one that involves smarthome. Thanks, Al

Hi Ken, We continuously improve on performance. As Mike suggested, it's very rate that programs take longer than 1 to 2 seconds. I just tested my ISY with many programs and the response time was almost immediate. Bob, we could possibly make this user configurable but, without detailed analysis of how much more performance is gained (see above), the side effects (deadlock), it would not be a good idea. With kind regards, Michel

Hi Josh, The main issue is that you are trying to control something that is already being controlled by the switch itself. So, at best, you will have a flicker and at worst it won't work. Also, you only need "And Control Master Bath is switched on" ... get rid of the Or. With kind regards, Michel

Hi Moshe, That is very odd unless ISY is not actually synchronizing with NTP every 24 hours. So, is ISY 1 minute fast every day or every month or every time you check it? With kind regards, Michel

Hello Ken, First of all, thanks so very much for the detailed explanation and benchmarking. With that said, the reasons that your HomeSeer responds more quickly are: The program task has a lower priority than a. The HTTP task - accepts HTTP requests from your plugin b. The Updater task - updates the plugin with status c. The number of programs that have to be evaluated Now, with a task oriented OS such as ours, the program task will not get to run till the Updater (send event to HS) and the HTTP (respond to HS) tasks are completed. These priorities were chosen based on many factors including start up times, client responsiveness, and the feelings that programs are programs (events) which do not have to be instantaneous (we have scenes for those) and 1 to 5 second response times are permissible depending on the context. With kind regards, Michel Withk