ELA Posted December 30, 2012 Share Posted December 30, 2012 Thanks IndyMike, I guess I should have just asked if HL could read the PLMs links data base in order to populate its device table. Sounds like it cannot. The disable retries is nice to know but not required in my tester. The tester is able to distinguish between what are the original message hops and what are retries. It logs whether or not retries are being used and thus no need to disable the retries. Always looking for zero retries being used of course as the best communications. 100% communications on all devices with zero hops and 0 retries would be impressive ( kinda like X-10 For the most part I come close. As you know time of day can make a big difference. Certain times of day my "problem child" living rm with 11 devices in one room has one or two devices that require retries. Too bad that HL requires an expert level of attention to use in an ISY based system. I am always hopeful that a good, easy to use diagnostic tool was generally available so that people could quantify their installs in a meaningful way. Link to comment Share on other sites More sharing options...
IndyMike Posted December 30, 2012 Share Posted December 30, 2012 Managed to run some tests with my 2477D I2CS SWL. As usual, the results were not what I had expected. Step 1: Linked the 2477D to the ISY and my 2412S PLM @0C.A8.B4. Verified the link table as correct. Verified the device function (on/off). Step 2: Linked the device to HL and a spare 2413S PLM @19.84.99. Verified functionality (on/off) and diagnostic capability. Step 3: Performed a link table scan on the 2477D to determine what records had been changed. For some reason, HL overwrote the ISY link at 0xFF8 in the device table and created a new record at 0xFE8. HL does not do this on my NON-I2CS devices. Curious, but it doesn't really hurt anything. The link to the HL PLM is placed at the end of the link table Step4: Restored the 2477D, verified the link table. Step 5: Checked on/off functionality with HL. After the ISY restore, HL can no longer control the device (expected). Curiously, HL can query and correctly determine the device status (on/off). I expected it to return a NAK. Step 6: Ran diagnostics using the Ping command. Even without link records, the device responded correctly to both SD and ED ping requests. This surprised me. I had expected the device to return a NAK since it no longer contained a link to the HL PLM. Step 7: Tried the "read record", "Failed Starts" and "Signal to Noise" options. The 2477D returned NAK for all. Overall, not nearly as bad as I had anticipated. If a person had a spare PLM, and was willing to perform an ISY restore on the modules after linking them to HL, this isn't all that bad. This assumes that all I2CS modules act similarly and HL doesn't revert to "synch mode" for some reason (still bothers me). IM Link to comment Share on other sites More sharing options...
LeeG Posted December 30, 2012 Share Posted December 30, 2012 IM Did you notice the Flag byte of AA that HL created. Second time have seen that Flag posted but do not know what the x8 bit means. Normal Responder link would be an A2 rather than an AA. I'm thinking the I2CS protocol requires the authorization link to be in the first slot (a guess). Otherwise why did HL make it the first link and move the existing link to another location. Sure wish new things like this could be answered with doc rather than having to piece the information together from observations. Link to comment Share on other sites More sharing options...
IndyMike Posted December 30, 2012 Share Posted December 30, 2012 Hi Lee, I did see the AA flag and remembered you commenting on it in another thread. I can't locate that thread now. Would you mind pointing me to it? I was reading up on the I2CS requirements over on JDales site. He stated that I2CS modules must first be linked as responders (A2 Flag) before being linked as a controller. After reading your post, I was thinking you were correct that the AA flag was some sort of "special" authorization flag. With the above in mind, I reversed the previous linking process: 1) Factory reset the SWL. Curiously, this was difficult to do. It took me three tries to achieve a reset. The key appeared to be waiting ~ 20 seconds with the airgap open (stored charge?). 2) Linked the SWL to the HL PLM @19.84.99 3) Linked the SWL to the ISY PLM @0C.A8.B4 Results below - very different from the previous link process. I'm confused again. I agree totally on the design documentation. An updated white paper would clear up many of the details that we are trying to infer by inspection. Quite honestly, when I2CS came out I stopped posting. There is no effective way to learn all the protocol requirements without actually going through the process. I was afraid that I would be misleading others with my ignorance. After two days of playing and watching Oscilloscope traces, I'm still not there... I do applaud the fact that SmartLabs continues to improve it's product line. I fully believe that the I2CS protocol was instituted to correct deficiencies in the original messaging design. It implies that SmartLabs is monitoring/analyzing returns and reported field issues. That's a level of investment that I don't often see in HA products. From my perspective, it means that SmartLabs is in this for the long haul - I love that. If Insteon were a standalone product like a TV or a car, the above would be sufficient. On the contrary, Insteon is a system of networked modules that must be integrated into widely varying environments. We are the system Integrators, and we now have insufficient knowledge to troubleshoot the system when things go wrong. How about it SmartLabs? Updated design documentation would hopefully eliminate our guesswork and allow us to help ourselves and others properly integrate these new units. By educating your customer you should see improved the market reception of these updated modules, and reduced customer service calls and returns. Too many times I've seen brilliant designs fail in the field because the customer did not possess the proper integration/troubleshooting knowledge. Please don't let that happen here. Invest some more into your design documentation so the field implementation can be a success. Link to comment Share on other sites More sharing options...
Brian H Posted December 30, 2012 Author Share Posted December 30, 2012 There is a HouseLinc Manual dated 12/27/2012 here. Along with a Hub Manual also dated 12/27/2012. http://www.insteon.net/support.html Link to comment Share on other sites More sharing options...
LeeG Posted December 30, 2012 Share Posted December 30, 2012 IM This is one link viewtopic.php?f=28&t=10153&hilit=responder I think there is another but have not found it yet. Cannot search for AA alone so it has been hard to find. Might have been in an image file which would not be found by Search anyway. The latest link database display is really hard to explain! Link to comment Share on other sites More sharing options...
IndyMike Posted December 31, 2012 Share Posted December 31, 2012 Lee, Thanks for the link. My I2CS unit appears fully functional with the AA record. Can't say it matches the symptoms of the referenced thread. I'll continue to play and post back if I learn anything meaningful. Link to comment Share on other sites More sharing options...
IndyMike Posted December 31, 2012 Share Posted December 31, 2012 Brian, Thank you for the link. I had missed this. I'm Happy to see that SH is updating the HL documentation (3 days ago??). Alas, I'm really looking for details on the protocol and RF/powerline design. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.