Bert2013 Posted August 16, 2016 Share Posted August 16, 2016 Hi, I have an "Insteon Diagnostic Keypad 2993-xx2". I would like to add this device to the ISY so I can program the Diagnostic Keypad to control certain lights and then walk around with the Diagnostic Keypad and troubleshoot. Unfortunately, the ISY does not want to link the Diagnostic Keypad. Errors are: "Cannot determine Insteon Device type". Is the only way to push these set buttons in the right order? Very painful... Also, my Diagnostic Keypad in "Traffic" mode beeps a lot. The documentation says that beeping means "corrupt message" due to "collisions/noise". I do have many dual-band devices and a number of motion sensors, so I conclude that "collisions" are possible, and even likely. That makes this "traffic" mode not very useful... What has been your experience? Thanks, Bert Link to comment
Teken Posted August 16, 2016 Share Posted August 16, 2016 I don't believe the diagnostic keypad has as much relevance given the latest hardware offers many of same LED feed back. Link to comment
Bert2013 Posted August 19, 2016 Author Share Posted August 19, 2016 Teken, I guess you mean that I could program any controller to control any receiver and watch the white or red blinking LEDs as to what the result was... One thing that the Diagnostic Keypad does in addition is report on "corrupt messages" due to "collisions/noise". It does that by beeping in "report" mode. Unfortunately, I cannot conclude if these "corrupt messages" are normal due to motion sensor collisions, or if it is really a corrupt message or really noise potentially causing havoc. That is where my question about beeps came from. In my particular case, I have a lot of havoc going on: - I encounter regular all-lights-on events. Luckily, I automatically recover from it by combining info from my GreenEye Energy Monitor and the ISY. - the link table of devices is getting corrupted on a regular basis. I found that out when things misbehave, or when I comnpare the device link table with the ISY's link table. So I have to use the ISY to "restore the device". I would like to automatically "restore devices" but, from what I found out so far, the RestoreDecive SOAP command is not implemented in the ISY (I'm using Peter Shipley's python code for that). - my IOLinc turns on or off unexpectedly at least once a day. (It is controlling the opening and closing of a catfeeder... so cats go hungry and skunks get fat). Luckily, I have a program that checks the state of the IOLinc throughout the day and corrects it if needed. Because of the above, I have no time for fun new stuff and instead worry about how to find the (probably several) bugs in my system. I have done the usual stuff: - put FilterLinc on a log to devices - disabled my PowerLine Phase coupler (I know that Teken doesn't like these couplers...) - disabled my whole-house surge protector - replaced suspected bad switches (they were not bad...) - go around and test with an old X10 appliance link to see if my ISY's plm signals can control the appliance link properly. - I try to interpret the ISY event log, but it is hard to conclude much from that because there is not enough information in it. When an error is encountered, it just says ERR without the reason... Thanks, Bert Link to comment
Teken Posted August 19, 2016 Share Posted August 19, 2016 Teken, I guess you mean that I could program any controller to control any receiver and watch the white or red blinking LEDs as to what the result was... One thing that the Diagnostic Keypad does in addition is report on "corrupt messages" due to "collisions/noise". It does that by beeping in "report" mode. Unfortunately, I cannot conclude if these "corrupt messages" are normal due to motion sensor collisions, or if it is really a corrupt message or really noise potentially causing havoc. That is where my question about beeps came from. In my particular case, I have a lot of havoc going on: - I encounter regular all-lights-on events. Luckily, I automatically recover from it by combining info from my GreenEye Energy Monitor and the ISY. - the link table of devices is getting corrupted on a regular basis. I found that out when things misbehave, or when I comnpare the device link table with the ISY's link table. So I have to use the ISY to "restore the device". I would like to automatically "restore devices" but, from what I found out so far, the RestoreDecive SOAP command is not implemented in the ISY (I'm using Peter Shipley's python code for that). - my IOLinc turns on or off unexpectedly at least once a day. (It is controlling the opening and closing of a catfeeder... so cats go hungry and skunks get fat). Luckily, I have a program that checks the state of the IOLinc throughout the day and corrects it if needed. Because of the above, I have no time for fun new stuff and instead worry about how to find the (probably several) bugs in my system. I have done the usual stuff: - put FilterLinc on a log to devices - disabled my PowerLine Phase coupler (I know that Teken doesn't like these couplers...) - disabled my whole-house surge protector - replaced suspected bad switches (they were not bad...) - go around and test with an old X10 appliance link to see if my ISY's plm signals can control the appliance link properly. - I try to interpret the ISY event log, but it is hard to conclude much from that because there is not enough information in it. When an error is encountered, it just says ERR without the reason... Thanks, Bert Hello Bert, Have you tried to implement some of the tips and suggestions offered in the UDI Wiki? Would you be able to offer some insight as to how many ALL ON / ALL OFF conditions you have encountered this year? With respect to phase couplers I don't have any real issues using one vs the other. Besides the fact a plugin unit offers more flexibility and repeats Insteon RF signals and bolsters them. A hardwired phase coupler only repeats the power line signal and does not boost the signal if required. A whole house surge protector is absolutely needed as one of the primary means to protect the home and its valuable electronics please consider reinstalling it. With respect to (newer) Insteon hardware they offer confirmation of signal sent and received. It also offer the ability to know if there was an error while other features are turning on / off RF & Power Line signaling. Others are smart hop, send cleanup messages, etc. Lastly can you offer more insight about how you're using the GEM / ISY for the above unless I misunderstood? Link to comment
Bert2013 Posted August 23, 2016 Author Share Posted August 23, 2016 Teken, About my experience with all-lights-on events. It comes in burst for me. In the worst case, 2 per day. In bad weeks, 3 per week. What I feel is that , if all the Insteon devices are programmed clean (i.e. no errors, no differences between the device link table and the ISY view of the links) all-lights-on does not happen very often. That is the reason I wish there was an implemented SOAP (or REST) message to 'restore device'; it would allow me to restore devices blindly every night. Or even better, a way to check if the device's link table is corrupted. Of course, the root cause of why the link table of my devices get clobbered would be nice to know... I have replaced my PLM at least 2 times, and after replacement, things work a lot better. Of course, that might be because the device link tables are all re-created... My system recovers automatically from an all-lights-on event. I get important input from the GEM data which I make the GEM send to my app-server. My app-server interprets the amps of a few chosen channels, it basically looks for high-amp usage which might indicate an all-lights-on event. My app-server then checks the ISY if it thinks the lights on that GEM channel are on. If the ISY thinks the lights are on, it is not an all-lights-on event and it is ignored. If the ISY thinks the lights are not on, then it is an all-lights-on event and my app-server instruct the ISY to turn lights on and then off (via running a program via REST). Thanks for pointing me to the UDI wiki again. I'm evaluating what parts are relevant to me. I already have deployed almost 10 FilterLinc and a few Access Points. One thing I encounter regularly is an ERR which seems to clear (the ISY clears it) after 10-20 seconds. I already replaced the on/off switch once with no change in behavior... I see these things more clearly now that I use the SOAP event trace of events from the ISY... Recently, my (wireless) RemoteLinc 2 keypad failed. I cannot "restore device" it anymore. I'm guessing that it probably was degrading for a while and might cause havoc on the power line... Lastly, I don't know much about "smart hop", "send cleanup messages". I also don't know about "With respect to (newer) Insteon hardware they offer confirmation of signal sent and received. It also offer the ability to know if there was an error while other features are turning on / off RF & Power Line signaling.". Can you point to something to read about it? Thank you for always being ready to answer questions and help people out. Bert Link to comment
Teken Posted August 24, 2016 Share Posted August 24, 2016 Hello Bert, Below is my interpretation of the following features as the developer notes have once again been pulled from the Insteon website?!? Smart Hops: Newer devices which support Smart Hops (Dual Outlet / On-Off Plugin Relay) will dynamically reduce the amount of hops if the transmission warrants or increase it based on the 3 hop limit. Send Cleanup Message: If this feature is enabled it will send the group message clean up dynamically. Blink on Error: If the end device does not Ack after the 3 hops the sending device will blinks its LED red indicating a communication issue. If the end device receives and operates as expected the sending devices LED will blink green. RF / Power Line: Each feature can be enabled - disabled which essentially could mimic RF only devices like Z-Wave / ZigBee. The ability to disable the RF was primary driven by consumers who either don't want RF or wish to reduce the amount of RF pollution in their homes. Having the ability to turn off power line helps in those fringe cases where line noise can't be filtered out. So using the RF portion only could ideally solve those comm issues. Please let me know if there is anything else I can offer insight to. Link to comment
Recommended Posts