Michel Kohanim

RLIKWARTZ, Please read: http://forum.universal-devices.com/viewtopic.php?t=459 Apologies for the inconvenience, With kind regards, Michel

Hello GPG, This is indeed interesting. None of the past releases have changed anything by the way of communicating with devices. The only change was that ISY "considered" devices with 00 in first/second byte as "group" commands and thus didn't update the status "in ISY" correctly. This had nothing to do with communications on the "outbound" pipe. Please do let us know of the outcome of your experiments. Thanks and with kind regards, Michel

Marko, Thanks so very much for taking the time and going through the trouble of diagnosing the issues. If I understand it correctly, your PLM is reset, your ISY is factory reset, your KPL/SL are reset, and in the first scene you create, the controllers do not control each other but ISY can control both. If this is the case, then the PLM is NOT the culprit simply because ISY can control the scene. Device to device links (i.e. your KPL to SL) do not require PLM to be functional. So, this leads me to believe one or more of the following: 1. We have a bug in ISY ... for which I have already started the root cause analysis 2. Are you sure you are putting both of your devices as "controllers" in the scene? 3. If 2 is "true", then could it be that "one" of your devices (the responder usually) is defective The next step is please allow me to figure out if we have a bug in ISY. This should not take longer than late tonight or early tomorrow morning. If we cannot find a bug/reproduce the probelm, and if the answer to #2 above is "yes", then we have to figure out which one of your devices are causing the problem. Again, please accept my sincere apologies for the troubles you're experiencing. With kind regards, Michel

Rand, You are 100% correct. The minimum delay IS 500 mS. Anything lower simply confuses the PLM and only "random" data is written to the network. The commands to change the delay/timeout/baudrate have been removed from the shell menu system but they are still accessible if you know them! With kind regards, Michel Where did you find the option for Requests Delay? I thought 500ms was the minimum for Insteon (send/receive), but only nerdlincs need to know this. You have confused me now! Rand

Frank, With sincere apologies for tardy reply. I must tell you that, at the moment, I do think that there are too many unexplainable issues in your dealings with ISY (which really trouble me): 1. Querying a device should only take one Progress Bar run. If it takes more, there is a problem 2. If ISY cannot control your scene, it means only one thing: your devices in the scene do not have the responder/slave links in them or the signal is not going out of PLM to the group In short, INSTEON signals do not get to their destinations! All of which lead me to suspect that in all likelihood we will never be able to have a stable system unless we figure out why! So, the variables are: 1. ISY 2. PLM ... you have the Beta PLM so this shouldn't be the problem 3. INSTEON network/powerline/noise issues 4. One or more defective devices on the network In order to ascertain which is the culprit, I would be delighted to send you another ISY and you can redo your experiments. If the other ISY also exhibits the same issues, then it would take the Master of INSTEON to figure out what is causing the signal loss. Again, please accept our sincere apologies for all the troubles you've been experiencing. With kind regards, Michel

Scott, At the moment, it's only receive. We do have plans for transmit but not till much later in 2008. With kind regards, Michel

Rand, Yes! It shall be done ... With kind regards, Michel

MikeB, If the calculator says you have 448 links, then rest assured you have either gone beyond the max links or you are very very close. With kind regards,

maui4marko, Ah, I had totally forgotten that you have the Beta PLM. No, I don't think the PLM is the issue. I think something is "seriously" wrong somewhere. The reason that factory reset/restore device does not fix the problem is that the the responders in the scene have to have a slave link pointing to your KPL. It seems that the responders in your scene do not have that link. Would you be kind enough to let me know what happens if you remove of the responders from the scene and then try adding it back? Thanks and with kind regards, Michel

maui4marko, Thanks so very much for the update. The fact that the status of your devices were always off means that the "links" were not written to the PLM. Two cases: 1. The PLM was locked up 2. You have reached the 417 max number of links allowed by the PLM. How many devices do you have? This said, however, I still can't figure out why your would lose your scenes. This, to me, is a much more serious problem which requires more investigation. Please do let me know if you find other strange behavior. With kind regards, Michel

maui4marko, Apologies for the inconvenience. You do not have to use that link. What you are doing it correct (going directly to the device's URL). We might have a bigger problem than the update to 2.4.13 if you've lost your previously created scenes/updates. Would you do me a favor? Please create one scene, call it Test, add a device into it as a Responder, and then reboot ISY. Please let me know if still have the scene and the device after reboot. With kind regards, Michel

MikeB, As of right now, we would have to count each link in the PLM. In the future generations of the PLM, we would know how many more links are available. With kind regards, Michel

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