Teken

Really? When did this happen and why?? Teken . . .

This is the log files upon making the timer changes and the end results. It appears nothing is being written to the device? Teken . . . Fri 01/27/2012 10:28:08 AM : CLI-WBug: Connecting to datafeed.weatherbug.com Fri 01/27/2012 10:28:08 AM : CLI-WBug: Successfully Processed WBug Response Fri 01/27/2012 10:28:08 AM : [MOD 2 2 1 11] 110000.000000 Weather - Wind Speed = 11 km/h Fri 01/27/2012 10:28:08 AM : [MOD 2 2 1 12] 110000.000000 Weather - Wind Average Speed = 11 km/h Fri 01/27/2012 10:28:08 AM : [MOD 2 2 1 22] 5822.000000 Weather - Evapotranspiration = 0.5822 mm/day Fri 01/27/2012 10:28:17 AM : [iNST-ACK ] 02 62 11.DC.42 0F 1F 00 06 GOF (FLAGS) Fri 01/27/2012 10:28:18 AM : [iNST-SRX ] 02 50 11.DC.42 13.24.E1 2B 1F 00 GOF (FLAGS) Fri 01/27/2012 10:28:18 AM : [standard-Direct Ack][11.DC.42-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 01/27/2012 10:28:18 AM : [All ] Writing 0 bytes to devices Fri 01/27/2012 10:28:18 AM : [iNST-ACK ] 02 62 11.DC.42 1F 2E 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 06 (00) Fri 01/27/2012 10:28:18 AM : [iNST-SRX ] 02 50 11.DC.42 13.24.E1 2B 2E 00 (00) Fri 01/27/2012 10:28:18 AM : [standard-Direct Ack][11.DC.42-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 01/27/2012 10:28:19 AM : [iNST-ERX ] 02 51 11 DC 42 13 24 E1 11 2E 00 01 01 00 FF 20 00 00 F2 00 00 00 26 B3 00 Fri 01/27/2012 10:28:19 AM : [Extended-Direct][11.DC.42-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Fri 01/27/2012 10:28:19 AM : [All ] Writing 0 bytes to devices Fri 01/27/2012 10:28:28 AM : [iNST-ACK ] 02 62 11.DC.42 1F 2E 00 01 06 0F 00 00 00 00 00 00 00 00 00 00 00 06 (00) Fri 01/27/2012 10:28:29 AM : [iNST-SRX ] 02 50 11.DC.42 13.24.E1 2B 2E 00 (00) Fri 01/27/2012 10:28:29 AM : [standard-Direct Ack][11.DC.42-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 01/27/2012 10:28:29 AM : [All ] Writing 0 bytes to devices Fri 01/27/2012 10:29:07 AM : CLI-WBug: Connecting to datafeed.weatherbug.com Fri 01/27/2012 10:29:07 AM : CLI-WBug: Successfully Processed WBug Response Fri 01/27/2012 10:29:07 AM : [iNST-ACK ] 02 62 11.DC.42 0F 1F 00 06 GOF (FLAGS) Fri 01/27/2012 10:29:08 AM : [iNST-SRX ] 02 50 11.DC.42 13.24.E1 2B 1F 00 GOF (FLAGS) Fri 01/27/2012 10:29:08 AM : [standard-Direct Ack][11.DC.42-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 01/27/2012 10:29:08 AM : [All ] Writing 0 bytes to devices Fri 01/27/2012 10:29:08 AM : [iNST-ACK ] 02 62 11.DC.42 1F 2E 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 06 (00) Fri 01/27/2012 10:29:08 AM : [iNST-SRX ] 02 50 11.DC.42 13.24.E1 2B 2E 00 (00) Fri 01/27/2012 10:29:08 AM : [standard-Direct Ack][11.DC.42-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 01/27/2012 10:29:09 AM : [iNST-ERX ] 02 51 11 DC 42 13 24 E1 11 2E 00 01 01 00 FF 20 00 00 F1 00 00 00 2F FC 00 Fri 01/27/2012 10:29:09 AM : [Extended-Direct][11.DC.42-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Fri 01/27/2012 10:29:09 AM : [All ] Writing 0 bytes to devices

This device will not allow me to keep the new values? Once you enter the new time *15 minutes* upon re-opening the options window. The value returns back to 255 minutes? Regards Teken . . .

Hello Michel, I am receiving this error with two SwitchLinc Timers. Both devices show the ability to make changes to the parameters. But, upon making any changes I am presented with this error message. Regards Teken . . .

andyf0, That was a most excellent write up as to how to solve this problem! You're going to be my next best friend when I receive my 8 AC transformers for the remote TSTATS! Teken . . .

Hello AlanF, I shall most definitely try this to see if it works. Much thanks for your reply and feed-back! Teken . . .

I would advise you to relocate the ISY in a interior controlled environment. Air born debris, salt, chemical fumes, in the future will be your next problem. Using a 35 foot CAT5e cable will not present any problems to you what so ever. Please relocate this device so you're assured long term reliability and use. Regards Teken . . .

andyf0, You're fantastic and I thank you for the follow up and testing. I would have done this test straight away but it is currently -36'C in my garage right now so fumbling around with little frozen wires 10 feet in the air wasn't going to be fun. If the results proved unproductive or helpful . . . Much thanks again Sir! Teken . . .

Rick, Please click on the help, then about . . . This will populate the firmware version along with the ISY UI version. You will need to go to the 2nd link in the forum and follow the steps to download the current ISY firmware release. Please ensure you follow all steps outlined by Michel . . . EDIT: Here is the link you need to read and follow: viewtopic.php?f=25&t=7878 Teken . . .

andyf0, Would you mind performing a test for me and see if the *ALL OFF* does indeed operate as you indicate above. I would greatly appreciate it . . . Teken . . . I hit ALL OFF. Everything turned off and the garage door closed. I hit it again and the garage door stayed closed. As I anticipated. I also have two Venstar thermostats and their settings were maintained, they were not reset. I know you tested as indicated above. But, could you please confirm 4 more times for me while the door is down and closed. Pressing the *ALL OFF* button and confirming the door does NOT attempt to open. If so, I will rewire the I/O link accordingly. I thank you so much for doing these tests for me and the UDI membership. Teken . . .

andyf0, Would you mind performing a test for me and see if the *ALL OFF* does indeed operate as you indicate above. I would greatly appreciate it . . . Teken . . .

May I humbly suggest that you provide a check box for the I/O device, and RF TSTATS. To allow the user to determine IF this command is required. I do not want to take away something from the masses, just because (I) do not see a benefit. There may be others who do like this strange behavior and use this to their benefit. I believe having a option check box for these two devices would allow the best balance for all parties concerned. As always your continued support, guidance, and feed-back is greatly appreciated. Regards Teken . . .

LeeG / Bcall, Thank you both for the clarification on this matter. I just find this part very hard to understand and accept to be honest. I understand based on how it is described by LeeG now. But, it truly boggles my mind knowing a *ALL OFF* command would turn something *ON*?? What I am trying to grasps is this so please bare with me. Right now everything (keeping the I/O Linc out of the picture) is off. If I select the *ALL OFF* from the ISY Admin Center, everything that is OFF, will remain OFF. If I turn everything on, or random devices to a on state. Selecting *ALL OFF* will in fact send a off command and those things will turn off. There will be no device which was off, will turn on. Now, we have this I/O device . . . It is off, for both relay and sensor. I am trying to grasp why a OFF command would even have any play into this situation?? OFF is OFF . . . It is not ON !! I apologize for the rant - But, realize that my home is extremely secure and I have two things I value the most. My family, and then the possessions which I have worked very hard for, for more than three decades for. Having the whole family dead asleep one moment, then having the entire house in an alarming state, all zones being locked down, sirens, strobes, alarm company, police coming in the dead of night. Is NOT something I take lightly . . . The only saving grace is that I am aware of this strange behavior and will NOT use it any further. As aside I checked all the configurations and the only scenes created is for the I/O link to the KPL to control the OH Door. The only other links / scenes are those attached to the SmartLinc device. This device is also linked to a Appliance Linc, to provide a status feed back with respect to the doors open / close status. There is nothing else linked, or attached to the Insteon Network. I know this because this time last week the entire ISY melted down and I literally had to erase all links manually in all 70 plus devices in my home. Then, do a hard reset of the PLM, and the ISY. Just to bring that device back to a usable state . . . For reference: When this ISY meltdown occurred the device indicated some cryptic message about the ELK module (I don't have one, nor did I purchase it) then everything took a shit and died! Regardless, I just wanted everyone who has a Garage I/O kit know if they use the *ALL OFF* they may be inadvertently opening the biggest door in your home to strangers and potential thieves! If other members could please confirm / validate this does happen I would appreciate it. If it does NOT happen. Please do be kind enough to let me know how your environment is different to allow this to operate as expected. Lastly, besides this none sense. The latest firmware release is working as expected, and much thanks goes to the UDI team for their continued support and endless commitment to their customers! Regards Teken . . .

Michel, Could you please explain this to me in layman's terms? When I look at my ISY tree all of the devices are off. If I review the status of garage door sensor / relay, it too is in a off condition. If I look at the SmartLinc (Which is the only thing linked) it too is in a off state. I do not understand how a global off command can make something which is already off, turn on?? The Garage I/O kit is set up with momentary C, the KPL is set for toggle. As far as I am aware there are no other related links / scenes attached to this device. Regards Teken . . .

Michel, Tonight I observed a serious issue upon sending a *ALL OFF* command via the ISY Admin Center. When I pressed the *All Off* command the garage door opened up! I can't begin to tell you, when the central alarm system went off showing a breach in the perimeter of my home, I almost jumped out of my skin! Please let me know why this happened and how to resolve this issue . . . Regards Teken . . .

This is indeed what I have observed this evening . . . Teken . . .

LeeG, Thanks for the clarification . . . I will perform some more tests and reply in kind if there are more questions as they pertain to the half links. Teken . . .

I am trying to understand if there is a part failure. Or that there is more things happening that may be affecting my install site. Taking a existing switch which was enrolled via the ISY, and selecting *delete all existing links* appears to enrolled the switch fine. Upon using the HL2 to look at this device it shows *half links* which I question . . . Basically, I am trying to affirm that if I do the following that the device will be in fact empty and blank as if it came out of the box. Having said all of this: Doing a factory reset I believe would accomplish this first ask. Using the ISY and simply *deleting* the same device from the ISY system should also accomplish this same task. While using *add new device* and selecting *delete all links* seems to leave links which another application (HL2) being able to trace and find said links. I am trying to fully understand what half links are, and how they impact the system. While doing a lot of reading on the forum there has not been a definite answer in this Q. Teken . . .

Are you sure?

If a person uses the default setting of adding in a new Insteon device via the ISY. Will adding a new device and selecting *delete all existing links* is this process 100% in removing all pre-existing links?? Teken . . .

I currently use all three software solutions: 1. ISY as the primary interface for myself. 2. HL2 for added diagnostics and trouble shooting. 3. SmartLinc for a simple interface for the family. I would like to add that using the SmartLinc interface is the perfect balance of access and control for 99% of the time for the general populace. Allowing the family (read small kids) access the ISY Admin Counsel would be disaster waiting to happen! Also, in my case having the SmartLinc it provided me a extra level of redundancy for the family and I. While I marched on in various upgrades (ISY) and platform adjustments while still allowing control and access with the alternate SmartLinc solution for the rest of the family. Teken . . .

I believe what he may be referring to is hearing the buzzing from the immediate area of the ISY, but in fact the buzzing is coming from the PLM. I have experienced this exact same thing when the device was in some frantic state and the PLM was mimicking this distress. Teken . . .

There are several things I would like to bring to light. As your experience mirrors my own only a few weeks back. Upon installing a *Dimmer Style KPL* and turning on the load switch there was a horrendous buzzing coming from the KPL. I found out that the default ramp rate was set for 0.5 seconds. This caused the (not dimmable) CFL to buzz and pulse! Please check via the ISY that the ramp rate is NOT in fact set to 0.5 seconds, and if so change it to instant on. The delay may be enough to throw the whole garage I/O set up out of sync. Also, I noted that I had troubles using the actual load (Main on/off) button to control the garage I/O set up from another KPL used solely for control & indicator until I moved the function to another button. This may be a instance of a firmware level that may be causing this odd behavior which many people may not be aware of. I hope this brings some insight and solutions to you. Regards Teken . . .

You must do this change locally at the outlet. Teken . . .

7-9 feet is the optimum height for most PIR sensors. Keep in mind, you can very well increase the sensitivity on the device to ensure the most coverage is detected. One thing to keep in mind is that you do NOT want to install the motion sensor too close, or in direct ambient light. This will disrupt the sensors ability in detecting moving heat signature of your Mother. In the interim, just use some double sided tape to affix the sensor so you're able to move the motion sensor around with out all the ugly holes left behind. Teken . . .