Michel Kohanim

Rand, Absolutely! Would you be kind enough to send a screen-shot as we do not have neither one of those here right now! As far as a build for the weekend, I think we can manage but no guarantees. A vacation sounds VERY nice at this point. Thanks so very much, With kind regards, Michel It's only cosmetic, but I know you guys like to be meticulous. Any chance of 2.4.x for the weekend? We will have an extra hour to test the time settings Thank you, Rand

Hello DaveGee, Apologies for the delay in my reply ... 2 links for controllers since a) a slave link in the PLM to "hear" button presses and a master link in the PLM and slave in the KPL during the linking phase. It's not 2 per button per se but it's a close approximation. We do not have any RF versions planned!!! Are you referring to IR??? With kind regards, Michel

C Martin, Thanks so very much for the links! I totally AGREE! With kind regards, Michel

C Martin, Yes, true but as far as I know, they have not yet agreed on the standard (ZWave or otherwise) to be used. It's all open for discussion/debate and I think all protocols have an equal chance of succeeding. Have you heard otherwise? With kind regards, Michel

C Martin, That would be excellent. Thanks so very much. With kind regards, Michel

C Martin, Very interesting! Do you have links/info on which states have agreed on using ZWave for their intelligent meters? This will be quite an interesting read and I would sincerely appreciate it. In short, I agree with you except for the "squeezing money part" ... I certainly do believe that "TOB" and Demand Response programs actually save consumers money. With kind regards, Michel

Mark, It's a separate device. With kind regards, Michel

mdcastle, As far as I know, 56 still works at 75% but device communication errors could be of two kinds: 1. Signal Stregnth issues which are usually addressed by adding an AccessPoint on top the PLM 2. PLM non-responsiveness So, 56 and above have solved #2 and it's very promising. With kind regards, Michel

siegeld, Yes there are! Hopefully by 2Q2008 (or sooner). With kind regards, Michel

mdcastle, The power output is the same but handling traffic has improved and thus a lot less lock ups under heavy traffic. With kind regards, Michel

aLf, I really don't think so! But, thank you so very much! Things will get better shortly since we are working together to make sure the next revisions perform better. Mark, You are funny! With kind regards, Michel

Hello All, We all know that the PLMs have some issues but SmartHome has been very helpful in addressing them, coming up with quick fixes, and providing the means to test them without having to go through myriads of paperwork. The reason the PLMs have less power is because the original versions got really warm. PLMs version 52 and above do not have that issue. Furthermore, PLMs version 56 and have (still in Beta but very promising) do not have the 'I am tired symptom' and thus much less "communications error" and much more efficient. slooplinc! Everytime I read your posts I LOL! Thanks and with kind regards, Michel

siegeld, We shall work on it! With kind regards, Michel

Adam, You are 100% correct with one addition: SCENES also let you control the SCENE through ISY. So, you can have triggers/schedules/programs that turn on/off/dim/brighten/etc. a scene (instead of having to do each device independently). With kind regards, Michel

Hello Frank, I like your idea vis-a-vis another tab where you can configure/name your X10 devices. I will surely review it in our meeting. As far as your KPL which has an X10 address assigned, no: ISY does not touch it. But, please be ware of the following: 1. If you turn on your KPL's load/sub buttons via an X10 command, then ISY will not be privy to it 2. In some cases, some of the older KPLs start misbehaving and bombard the network with their X10 addresses. If you experience intermittent/inconsistent behavior from this device, then please consider doing a factory reset on it With kind regards,

yardman 49, Our X10 story is a long one and one which is not that interesting! In short, we were never ever going to support X10. we had a few good reasons: 1. X10 reliability issues 2. PLM/X10 reliability issues some of which still exists 3. X10 performance issues (quite slow compared to INSTEON) etc. But, due to an overwhelming demand by our customers for for X10 support, we added the current functionality. Before doing so, we did have a design session where we decided against adding the X10 devices under the tree and here were our reasons: 1. The tree and nodes represent the actual "relationships" between devices ... in the X10 world, this relationship is implied by the program. i.e. the relationship is carried through an intermediary and not in a peer-to-peer manner 2. The amount of time it would take us to add X10 support into the tree would far outweigh the amount of time we had allocated to this project With kind regards, Michel

yardman 49, For the longest time, we've been waiting for a reasonable touchscreen solution and we had almost given up. As of right now, you can automatically use any Vista Tablet PC (7-12 inches) as a touchscreen and communicate with ISY through Vista Media Center. This said, however - and as MikeB noted - we are doing everything we can to integrate with the new INSTEON touchscreen. In short, you are 100% correct and we are fully aware of this need. Thanks so very much, With kind regards, Michel

Howard, You are most welcome and it's our pleasure! As far as I/O devices, we really wished we could support EZIO alas the cost of support/maintenance currently far outweighs the demand. I will surely let you know if our support status changes or if I find other INSTEON I/O devices which we could support. With kind regards, Michel

Hi Howard, I am so glad that you got it to work. The best thing you can do for us is to give us feedback! Thanks so very much and with kind regards, Michel

siegeld, Thanks so very much. Yes, I'll work it out with MikeB. You could be very well correct. As far as JSDK (as well as our applet) all leading 0s are ignored or parsed out. i.e. you should use the addresses as they appear in http://your.isy.ip:port/WEB/NODESCNF.XML . In all likelihood, and as you suggested, there's a formatting issue when we receive responses back from the PLM. We shall check into it and get it resolved as soon as we get a device to test with. Again, thank you all for finding this bug, With kind regards, Michel

Howard, Please try the following: On the NOD32's Control Center: Click on IMON On the IMON Setup Screen click on the HTTP tab In the Setup box, uncheck "Enabled HTTP checking" With kind regards, Michel

siegeld, Wow, this is amazing! Since we don't have any devices with XX.00.YY address, I would be willing to send you a brand new replacement for your device in exchange for yours so that we can test and figure out where the problem comes from. If this is acceptable to you, please do send your shipping information to tech@universal-devices.com and it shall be taken care of. Thanks so very much, With kind regards, Michel

shpegel, I am so very sorry to hear this. By any chance, do you have McAfee firewall software running? With kind regards, Michel

upstatemike, Thanks so very much. That would be the ultimate solution! With kind regards, Michel Unfortunately I do not know of anyone. I will continue to try to convince the Homeseer folks that it would be in their own best interest to support the ISY-26 by developing a plugin with Homeseer staff.

Hello Adam, Thanks so very much for the update. There's a confirmed issue with PLM FIRM 52 locking up after a lot of traffic. To confirm this scenario, the next time triggers do not respond, please do NOT reboot ISY. Simply reboot the PLM and let me know if that fixed the issue. If it did, then we have to get you a new Beta PLM. The time lag is 100% correct: ISY must wait about 600 m.s. to send the next command to the PLM. Depending on the traffic, the PLM may take up to 500 m.s. to notify ISY of traffic. With regards, Michel