shadowb Posted June 8, 2016 Posted June 8, 2016 I'm using an ISY994i and have a program that turns on both outlets in a 2663-222 located outside in a water-proof box to control a fountain pump. The program turns on both outlets at 700a each day ... the problem is the pump has failed to come on about 3 times in the past couple of months. When I open the ISY application the status always shows On for both outlets. If I click On in the app the pump will come on. I thought Insteon was essentially fail-safe with its two-way response system. For the time being I modified the program to Wait 2 secs and send On again. Right now this unit is not as reliable as the X10 unit I used for many years. What's up? I also posted on the Insteon forum but the only answer so far is to ask this forum. Thanks
LeeG Posted June 8, 2016 Posted June 8, 2016 Are you using a Scene or Direct commands to turn On both outlets?
oberkc Posted June 8, 2016 Posted June 8, 2016 My initial assumption in cases like this is to treat as a communication problem. My understanding is that ISY will assume commands issued are followed, and device status tracked according to those assumptions. Even if expected confirmation from device is not recieved, device status will be updated based on assumed response to commands. Obviously, ISY status and truth can conflict when the device failed to respond as expected. Given this, I would start troubleshooting effort to identify comm problems.
shadowb Posted June 8, 2016 Author Posted June 8, 2016 It's a Program that gives direct commands to both outlets to turn On (one at at time of course). I just added a 2 sec Wait and turn on again to see if that makes it more reliable.
LeeG Posted June 8, 2016 Posted June 8, 2016 When Direct On fails there is either a defective device or more likely a comm issue to that outside device. Direct commands are ACKed and retried so a failure indicates an issue. The delay between Direct On commands may help if the second Direct On interfered with the first.
LeeG Posted June 8, 2016 Posted June 8, 2016 If able to run the Event Viewer at LEVEL 3 when testing Program the general Comm situation can be evaluated, even without a failure. Post the event trace if this is done.
diggler Posted June 8, 2016 Posted June 8, 2016 I had the same issue, so far unplugged the 2 devices on that circuit and put thm on a extension cord on same circuit. Its been better. Sent from my SM-G900P using Tapatalk
shadowb Posted June 8, 2016 Author Posted June 8, 2016 Good suggestion about Event Viewer Level 3 ... where can I find a key to reading it? I can figure out some of it but not all. Will search the Wiki unless there is something better. I have tried an Off/On sequence to see what a Level 3 trace is supposed to look like and will monitor now to try and catch a failure. I have now successfully replaced all but two X10 devices with Insteon throughout the house and yard. Very pleased with all of the quick responses and help from this forum. Thanks!
LeeG Posted June 8, 2016 Posted June 8, 2016 From the ISY User Guide 11.1.1 The Event Viewer The Administrative Console’s Event Viewer can be an invaluable tool in helping to diagnose problems. To access the Event Viewer, click on the Tools pull-down menu, then Diagnostics, then Event Viewer. The Event Viewer window displays information on what is happening on your ISY, such as commands sent to devices, information received from devices, programs that are executing, and much more. There are several levels of detail available using the Change Level button (level 3 being the most detailed). Use the Save Log To button to save the current Event Viewer output to a text file. Best to post event trace for now. Does not need to be of an actual failure as this will check basic comm quality.
shadowb Posted June 9, 2016 Author Posted June 9, 2016 The Event Viewer section 11.1.1 and Appendix J give an overview and example of an Excel formatted log. Here's an example of the actual log data that I formatted to make it easier to read. I can pretty well figure out much of it ... 3D BE 9C is the outlet address... I think 3D C7 BE is the ISY address. Not sure what 'I2CS', 'SRX' and some of the other codes mean. Any source for this level of detail? What would I be looking for if there were a communication error? This is a 'normal' On sequence. FOUNTAIN PUMP BOT ON COMMAND Wed 06/08/2016 02:29:15 PM : [iNST-TX-I2CS] 02 62 3D BE 9C 1F 11 FF 02 00 00 00 00 00 00 00 00 00 00 00 00 EE Wed 06/08/2016 02:29:15 PM : [iNST-ACK ] 02 62 3D.BE.9C 1F 11 FF 02 00 00 00 00 00 00 00 00 00 00 00 00 EE 06 LTONRR (FF) Wed 06/08/2016 02:29:16 PM : [iNST-SRX ] 02 50 3D.BE.9C 3D.C7.BE 2B 11 FF LTONRR (FF) Wed 06/08/2016 02:29:16 PM : [std-Direct Ack] 3D.BE.9C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Wed 06/08/2016 02:29:16 PM : [D2D EVENT ] Event [3D BE 9C 2] [sT] [255] uom=0 prec=-1 Wed 06/08/2016 02:29:16 PM : [ 3D BE 9C 2] ST 255
LeeG Posted June 9, 2016 Posted June 9, 2016 (edited) The example indicates good comm to OutletLinc at this time. Wed 06/08/2016 02:29:15 PM : [iNST-TX-I2CS] 02 62 3D BE 9C 1F 11 FF 02 00 00 00 00 00 00 00 00 00 00 00 00 EE I2CS indicates the latest device (I1, I2, I2CS) - 11 = On command - FF is 100% On Level - 02 is bottom outlet Wed 06/08/2016 02:29:15 PM : [iNST-ACK ] 02 62 3D.BE.9C 1F 11 FF 02 00 00 00 00 00 00 00 00 00 00 00 00 EE 06 LTONRR (FF) PLM acknowledges command with 06 which indicates valid basic command structure Wed 06/08/2016 02:29:16 PM : [iNST-SRX ] 02 50 3D.BE.9C 3D.C7.BE 2B 11 FF LTONRR (FF) OutletLinc ACKs the command Wed 06/08/2016 02:29:16 PM : [std-Direct Ack] 3D.BE.9C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Hops Left=2 indicates one device was used to reach the OutLetLinc. Comm good at this time. Wed 06/08/2016 02:29:16 PM : [D2D EVENT ] Event [3D BE 9C 2] [sT] [255] uom=0 prec=-1 Wed 06/08/2016 02:29:16 PM : [ 3D BE 9C 2] ST 255 Information about devices that are I1, I2, I2CS would be obtained from Insteon.com (SmartLabs). Same with things like Max Hops and Hops Left, this is detail the SmartLabs designed. I'm sure there are references to all this information scattered through the UDI/ISY forum but it is SmartLabs designed and that is where all the information is explained.. Edited June 9, 2016 by LeeG
oberkc Posted June 9, 2016 Posted June 9, 2016 Some folks have downloaded the data describing the meaning of all this. I have not done so yet. Stiil, I believe the fouth line may be the axknowlegement from the responder and the hop count suggests pretty good communication at this point in time. Did your outlet turn on? Given appearances that comm is good at least some of the time, I would be considering what intermittent devices (HVAC, washer/dryer refrigerator, etc..) that might explain why comms would be good some time and not others. Also, see if comms are as good when turning OFF the fountain. If not, this could suggest that the fountain pump, itself, could be contributing to comm errors
shadowb Posted June 9, 2016 Author Posted June 9, 2016 All helpful info. Because I like to understand things completely I'll seek the details with Insteon / SmartLabs. In the meantime I'll wait and see if the 2 sec delay between commands to the Top and Bot outlets solves it. I've never noticed the Off command failing, but then it would be near midnight and the fountain would run all night unnoticed. : )
oberkc Posted June 9, 2016 Posted June 9, 2016 When you have noticed comm issues with this device, is the prblem normally the pump failing to come ON? If so, then I would be focusing on factors external to the pump, itself. This is definitely a relay outlet, not dimmer. Correct? Also, be sure to do your best to ensure PLM is on a clean circuit. No other gadgets and computers/ups/routers/modems. Right? Do you ever use filters?
mwester Posted June 9, 2016 Posted June 9, 2016 Exactly what is turned on first, and what fails to turn on? For a while (I've since redesigned my solution), I had a large pump on an applianceLinc, with a syncrolinc and an IOLinc -- I noticed that when my program turned on the applianceLinc, the pump would start, but the messages from the syncrolinc would be lost, and messages sent to the IOLinc would be missed unless I added a several-second delay. The problem is that the pump's startup either sucked down the voltage on the line or injected too much noise on the line, and until the pump motor's internal startup circuitry switched to normal mode, there were no Insteon messages that were making it through. Perhaps whatever you're starting when you switch on the first half of the outletlinc is causing the same sort of temporary startup noise that prevents the second message from being seen by the outletlinc.
shadowb Posted June 9, 2016 Author Posted June 9, 2016 (edited) It's a small fist-size pump on a fountain and the problem is it fails to come on daily at 700a only a couple of times a month. It's a 2663-222 dual outlet. The 2 sec delay between commands to the Top and Bot outlets may solve it. The pump is on the Top outlet, nothing on the Bot. I'll have to give it a month or so to know. This is the only problem I'm having throughout the entire house and yard of Insteon devices. Edited June 9, 2016 by shadowb
Steven Posted June 10, 2016 Posted June 10, 2016 I have a similar problem. It's intermittent, but it just happened now with the log open. I have a program that turns a scene on in the "Then" clause. I just ran the "If" of the program, and its Status is now "True". However, the light in the scene that it is supposed to turn on is still off. The Event Viewer level 3 says this: Thu 06/09/2016 06:05:14 PM : [ Time] 18:05:16 1(0)Thu 06/09/2016 06:05:14 PM : [iNST-TX-I1 ] 02 62 15 14 3B 0F 13 00Thu 06/09/2016 06:05:14 PM : [iNST-TX-I1 ] 02 62 00 00 18 CF 11 00 The device in question (a 2635-222 On/Off Module at address 37.10.02) is off. Why didn't it turn it on? I just tried to query the scene, and I got a communication error. What now?
Steven Posted June 10, 2016 Posted June 10, 2016 Update: I tried rebooting, and now it says my PLM is likely defective. Fortunately, I have a spare.
Recommended Posts