simplextech Posted February 21, 2019 Posted February 21, 2019 Continuing my first world struggles with the door sensor controlling a scene... In some testing today with logs on I reduced the level to 1 to get some basic info. Here's what I see in the basic L1 log.. Thu 02/21/2019 17:49:22 : [ 47 FC 4F 1] DON 1 Thu 02/21/2019 17:49:22 : [ 47 FC 4F 1] ST 255 (uom=100 prec=0) Thu 02/21/2019 17:49:22 : [ 50 CA 68 1] ST 255 (uom=100 prec=0) Thu 02/21/2019 17:49:22 : [ 50 C9 CF 1] ST 255 (uom=100 prec=0) Thu 02/21/2019 17:49:22 : [ 50 CA 60 1] ST 255 (uom=100 prec=0) Thu 02/21/2019 17:49:22 : [ 50 D9 3B 1] ST 255 (uom=100 prec=0) Thu 02/21/2019 17:49:32 : [ 47 FC 4F 1] DOF 1 Thu 02/21/2019 17:49:32 : [ 47 FC 4F 1] ST 0 (uom=100 prec=0) 47 FC 4F 1 = Door Sensor (open/close sensor) The other devices are the switches in the scene. Per the log the devices are now ON and in the Admin console it shows them as ON. BUT they are NOT on??? My eyes still work (mostly) and the lights are off and the switches physically (LED) show as Off.... Anyone??? Ideas??? Thinking it may be a scene issue of some kind I have deleted the scene and changed the program to operate directly against only 2 of the switches. I'll see how this goes.
paulbates Posted February 22, 2019 Posted February 22, 2019 Its interesting that nothing turned on. Insteon battery wireless devices send their activation messages twice, a second message 2 seconds after the initial. It seems like that the ISY received the message, but the switches did not. Either the scene had issues and needs to be rebuilt, or, there is significant noise from the loads preventing the switches from getting the message. But your description suggests you were able to program all of the devices and they were off and you were turning on. The ISY/PLM do not participate in the group clean up for scenes. When the ISY/PLM receive the scene on, it "assumes" that everybody go the message and updates status accordingly. (There's a caveat to that statement for some newer devices: , right click>advanced>PLM Communications.) For this situation I would suggest: turning all of the switches off locally so there is no way the load is interfering with the scene programming. Since they all didn't work, I suspect that could be happening put the door sensor in linking mode and rebuild the scene. Also, L3 is most telling about interactions between Insteon devices. Paul
simplextech Posted February 22, 2019 Author Posted February 22, 2019 11 minutes ago, paulbates said: For this situation I would suggest: turning all of the switches off locally so there is no way the load is interfering with the scene programming. Since they all didn't work, I suspect that could be happening put the door sensor in linking mode and rebuild the scene. Also, L3 is most telling about interactions between Insteon devices. The door sensor is not part of the scene. It can't be because I don't want the lights going out as soon as the door is closed. I've rebuilt the scene a couple of times and today before this test I removed the door sensor and did a factory reset and added it back to the ISY. I agree I'm starting to think there's a communication problem but even when running testing in L3 there are no errors. If there are no errors what else should I be looking for? The only thing that's odd to me are the amount of "Previous message ignored" that I see all over the log. Note I am new to Insteon (background is z-wave) and I'm running 5.0.14 so could be a beta issue???
paulbates Posted February 22, 2019 Posted February 22, 2019 1 minute ago, simplextech said: I agree I'm starting to think there's a communication problem but even when running testing in L3 there are no errors. If there are no errors what else should I be looking for? L3 tells other things related to noise / signal problems like hops left. if hops left is 1 or 0, that's a sign. Can you post a segment of the event trace from when you initiated the scene until it thinks its done? 2 minutes ago, simplextech said: I'm running 5.0.14 so could be a beta issue??? I highly doubt that. I'm insteon only and have been using V5 from the beginning. Granted I'm still on 5.13B, but I think there would be others reporting in on this by now. More data will help. Can you post the event trace mentioned above, and images of your scene(s) and what they're supposed to do? Paul
simplextech Posted February 22, 2019 Author Posted February 22, 2019 25 minutes ago, paulbates said: More data will help. Can you post the event trace mentioned above, and images of your scene(s) and what they're supposed to do? More data... as I collect and save it yes. Screenshot no I deleted the scene earlier and what I already posted of the log was the snippet I saved. What I can do is rebuild the scene and record the data. I didn't think it would be the 5.0.14 release but never know. Currently testing against the individual switches outside of a scene just with the program to see what data I can get.
simplextech Posted February 22, 2019 Author Posted February 22, 2019 Here's some more info and the program. The program is basic. Deck Lights-On - [ID 001B][Parent 001A] If 'Living Room / Door Sensor / LR.door.sensor-Opened' is switched On Or 'Dining Room / Door Sensor / dining-room.door-Opened' is switched On Then Set 'Deck / Switch / Flood Lights' On Set 'Deck / Switch / Front Light' On Else - No Actions - (To add one, press 'Action') Devices: 47.FC.4F = door sensor 50.C9.CF = Flood lights 50.CA.68 = Front Light Thu 02/21/2019 20:13:47 : [Std-Cleanup ] 47.FC.4F-->ISY/PLM Group=1, Max Hops=3, Hops Left=2 Thu 02/21/2019 20:13:47 : [D2D EVENT ] Event [47 FC 4F 1] [DON] [0] uom=0 prec=-1 Thu 02/21/2019 20:13:47 : [ 47 FC 4F 1] DON 0 Thu 02/21/2019 20:13:47 : [D2D-CMP 001B] CTL [47 FC 4F 1] [DON] op=is --> true Thu 02/21/2019 20:13:48 : [INST-SRX ] 02 50 47.FC.4F 4C.1B.8A 47 11 01 LTONRR (01) Thu 02/21/2019 20:13:48 : [Std-Cleanup ] 47.FC.4F-->ISY/PLM Group=1, Max Hops=3, Hops Left=1 Thu 02/21/2019 20:13:48 : [INST-DUP ] Previous message ignored. Thu 02/21/2019 20:13:48 : [INST-SRX ] 02 50 47.FC.4F 11.01.01 CF 06 00 (00) Thu 02/21/2019 20:13:48 : [Std-Group ] 47.FC.4F-->11.01.01, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:13:48 : [INST-INFO ] Previous message ignored. Thu 02/21/2019 20:13:48 : [INST-SRX ] 02 50 4D.A7.6D 4C.1B.8A 2B 11 FF LTONRR (FF) Thu 02/21/2019 20:13:48 : [Std-Direct Ack] 4D.A7.6D-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/21/2019 20:13:49 : [INST-SRX ] 02 50 4F.8A.B8 4C.1B.8A 4B 11 01 LTONRR (01) Thu 02/21/2019 20:13:49 : [Std-Cleanup ] 4F.8A.B8-->ISY/PLM Group=1, Max Hops=3, Hops Left=2 Thu 02/21/2019 20:13:49 : [INST-SRX ] 02 50 4F.8A.B8 11.01.01 CB 06 00 (00) Thu 02/21/2019 20:13:49 : [Std-Group ] 4F.8A.B8-->11.01.01, Max Hops=3, Hops Left=2 Thu 02/21/2019 20:13:49 : [INST-INFO ] Previous message ignored. Thu 02/21/2019 20:13:50 : [INST-SRX ] 02 50 4F.8A.B8 11.01.01 CB 06 00 (00) Thu 02/21/2019 20:13:50 : [Std-Group ] 4F.8A.B8-->11.01.01, Max Hops=3, Hops Left=2 Thu 02/21/2019 20:13:50 : [INST-INFO ] Previous message ignored. Thu 02/21/2019 20:13:50 : [INST-TX-I1 ] 02 62 50 C9 CF 0F 11 FF Thu 02/21/2019 20:13:50 : [INST-TX-I1 ] 02 62 50 CA 68 0F 11 FF Thu 02/21/2019 20:13:50 : [INST-ACK ] 02 62 50.C9.CF 0F 11 FF 06 LTONRR (FF) Thu 02/21/2019 20:13:50 : [D2D EVENT ] Event [47 FC 4F 1] [ST] [255] uom=100 prec=0 Thu 02/21/2019 20:13:50 : [ 47 FC 4F 1] ST 255 (uom=100 prec=0) Thu 02/21/2019 20:13:50 : [D2D EVENT ] Event [4D A7 6D 1] [ST] [255] uom=100 prec=0 Thu 02/21/2019 20:13:50 : [ 4D A7 6D 1] ST 255 (uom=100 prec=0) Thu 02/21/2019 20:13:50 : [D2D-CMP 003B] STS [4D A7 6D 1] ST Converted values Event=255 Condition=0 prec=0 Thu 02/21/2019 20:13:50 : [D2D-CMP 003B] STS [4D A7 6D 1] ST op=6 Event(val=255 uom=100 prec=0) != Condition(val=0 uom=51 prec=0) --> true Thu 02/21/2019 20:13:50 : [D2D-CMP 0025] STS [4D A7 6D 1] ST Converted values Event=255 Condition=0 prec=0 Thu 02/21/2019 20:13:50 : [D2D-CMP 0025] STS [4D A7 6D 1] ST op=1 Event(val=255 uom=100 prec=0) is Condition(val=0 uom=51 prec=0) --> false Thu 02/21/2019 20:13:50 : [D2D EVENT ] Event [4F 8A B8 1] [DON] [0] uom=0 prec=-1 Thu 02/21/2019 20:13:50 : [ 4F 8A B8 1] DON 0 Thu 02/21/2019 20:13:50 : [D2D-CMP 0025] CTL [4F 8A B8 1] [DON] op=is --> true Thu 02/21/2019 20:13:50 : [INST-SRX ] 02 50 50.C9.CF 4C.1B.8A 2F 11 FF LTONRR (FF) Thu 02/21/2019 20:13:50 : [Std-Direct Ack] 50.C9.CF-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:13:50 : [D2D EVENT ] Event [50 C9 CF 1] [ST] [255] uom=100 prec=0 Thu 02/21/2019 20:13:50 : [ 50 C9 CF 1] ST 255 (uom=100 prec=0) Thu 02/21/2019 20:13:50 : [INST-ACK ] 02 62 50.CA.68 0F 11 FF 06 LTONRR (FF) Thu 02/21/2019 20:13:51 : [INST-SRX ] 02 50 50.CA.68 4C.1B.8A 2F 11 FF LTONRR (FF) Thu 02/21/2019 20:13:51 : [Std-Direct Ack] 50.CA.68-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:13:51 : [D2D EVENT ] Event [50 CA 68 1] [ST] [255] uom=100 prec=0 Thu 02/21/2019 20:13:51 : [ 50 CA 68 1] ST 255 (uom=100 prec=0) Thu 02/21/2019 20:13:51 : [D2D-CMP 001C] STS [50 CA 68 1] ST Converted values Event=255 Condition=255 prec=0 Thu 02/21/2019 20:13:51 : [D2D-CMP 001C] STS [50 CA 68 1] ST op=1 Event(val=255 uom=100 prec=0) is Condition(val=100 uom=51 prec=0) --> true Thu 02/21/2019 20:13:52 : [INST-SRX ] 02 50 47.FC.4F 00.00.01 CF 13 01 LTOFFRR(01) Thu 02/21/2019 20:13:52 : [Std-Group ] 47.FC.4F-->Group=1, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:13:52 : [D2D EVENT ] Event [47 FC 4F 1] [DOF] [1] uom=0 prec=-1 Thu 02/21/2019 20:13:52 : [ 47 FC 4F 1] DOF 1 Thu 02/21/2019 20:13:52 : [D2D-CMP 001C] CTL [47 FC 4F 1] [DOF] op=is --> true Thu 02/21/2019 20:13:52 : [D2D EVENT ] Event [47 FC 4F 1] [ST] [0] uom=100 prec=0 Thu 02/21/2019 20:13:52 : [ 47 FC 4F 1] ST 0 (uom=100 prec=0) Thu 02/21/2019 20:13:53 : [INST-SRX ] 02 50 47.FC.4F 00.00.01 CF 13 01 LTOFFRR(01) Thu 02/21/2019 20:13:53 : [Std-Group ] 47.FC.4F-->Group=1, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:13:53 : [INST-DUP ] Previous message ignored. Thu 02/21/2019 20:13:53 : [INST-SRX ] 02 50 47.FC.4F 4C.1B.8A 45 13 01 LTOFFRR(01) Thu 02/21/2019 20:13:53 : [Std-Cleanup ] 47.FC.4F-->ISY/PLM Group=1, Max Hops=1, Hops Left=1 Thu 02/21/2019 20:13:53 : [INST-DUP ] Previous message ignored. Thu 02/21/2019 20:13:53 : [INST-SRX ] 02 50 47.FC.4F 13.01.01 CF 06 00 (00) Thu 02/21/2019 20:13:53 : [Std-Group ] 47.FC.4F-->13.01.01, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:13:53 : [INST-INFO ] Previous message ignored. Thu 02/21/2019 20:13:54 : [INST-SRX ] 02 50 47.FC.4F 13.01.01 CF 06 00 (00) Thu 02/21/2019 20:13:54 : [Std-Group ] 47.FC.4F-->13.01.01, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:13:54 : [INST-INFO ] Previous message ignored. Thu 02/21/2019 20:13:57 : [INST-SRX ] 02 50 14.BC.92 00.00.01 CF 11 01 LTONRR (01) Thu 02/21/2019 20:13:57 : [Std-Group ] 14.BC.92-->Group=1, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:13:57 : [D2D EVENT ] Event [14 BC 92 1] [DON] [1] uom=0 prec=-1 Thu 02/21/2019 20:13:57 : [ 14 BC 92 1] DON 1
simplextech Posted February 22, 2019 Author Posted February 22, 2019 Here's another data dump of the log. I apologize now for my ignorance with Insteon. This is just bugging me as I'm coming to Insteon looking for a faster and more consistent lighting solution than Z-Wave. Thu 02/21/2019 20:27:10 : [INST-SRX ] 02 50 47.FC.4F 00.00.01 CF 11 01 LTONRR (01) Thu 02/21/2019 20:27:10 : [Std-Group ] 47.FC.4F-->Group=1, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:27:10 : [D2D EVENT ] Event [47 FC 4F 1] [DON] [1] uom=0 prec=-1 Thu 02/21/2019 20:27:10 : [ 47 FC 4F 1] DON 1 Thu 02/21/2019 20:27:10 : [D2D-CMP 001B] CTL [47 FC 4F 1] [DON] op=is --> true Thu 02/21/2019 20:27:10 : [INST-TX-I1 ] 02 62 50 C9 CF 0F 11 FF Thu 02/21/2019 20:27:10 : [INST-SRX ] 02 50 47.FC.4F 00.00.01 CF 11 01 LTONRR (01) Thu 02/21/2019 20:27:10 : [Std-Group ] 47.FC.4F-->Group=1, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:27:10 : [INST-DUP ] Previous message ignored. Thu 02/21/2019 20:27:10 : [INST-ACK ] 02 62 50.C9.CF 0F 11 FF 06 LTONRR (FF) Thu 02/21/2019 20:27:11 : [INST-TX-I1 ] 02 62 50 CA 68 0F 11 FF Thu 02/21/2019 20:27:11 : [D2D EVENT ] Event [47 FC 4F 1] [ST] [255] uom=100 prec=0 Thu 02/21/2019 20:27:11 : [ 47 FC 4F 1] ST 255 (uom=100 prec=0) Thu 02/21/2019 20:27:11 : [INST-ACK ] 02 62 50.CA.68 0F 11 FF 06 LTONRR (FF) Thu 02/21/2019 20:27:11 : [INST-ACK ] 02 62 50.CA.68 0F 11 FF 06 LTONRR (FF): Duplicate or ACK for a different device Thu 02/21/2019 20:27:11 : [INST-SRX ] 02 50 50.C9.CF 4C.1B.8A 2B 11 FF LTONRR (FF) Thu 02/21/2019 20:27:11 : [Std-Direct Ack] 50.C9.CF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/21/2019 20:27:11 : [D2D EVENT ] Event [50 C9 CF 1] [ST] [255] uom=100 prec=0 Thu 02/21/2019 20:27:11 : [ 50 C9 CF 1] ST 255 (uom=100 prec=0) Thu 02/21/2019 20:27:12 : [INST-SRX ] 02 50 50.CA.68 4C.1B.8A 2F 11 FF LTONRR (FF) Thu 02/21/2019 20:27:12 : [Std-Direct Ack] 50.CA.68-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:27:12 : [D2D EVENT ] Event [50 CA 68 1] [ST] [255] uom=100 prec=0 Thu 02/21/2019 20:27:12 : [ 50 CA 68 1] ST 255 (uom=100 prec=0) Thu 02/21/2019 20:27:12 : [D2D-CMP 001C] STS [50 CA 68 1] ST Converted values Event=255 Condition=255 prec=0 Thu 02/21/2019 20:27:12 : [D2D-CMP 001C] STS [50 CA 68 1] ST op=1 Event(val=255 uom=100 prec=0) is Condition(val=100 uom=51 prec=0) --> true Thu 02/21/2019 20:27:13 : [INST-SRX ] 02 50 47.FC.4F 4C.1B.8A 4F 11 01 LTONRR (01) Thu 02/21/2019 20:27:13 : [Std-Cleanup ] 47.FC.4F-->ISY/PLM Group=1, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:27:13 : [D2D EVENT ] Event [47 FC 4F 1] [DON] [0] uom=0 prec=-1 Thu 02/21/2019 20:27:13 : [ 47 FC 4F 1] DON 0 Thu 02/21/2019 20:27:13 : [D2D-CMP 001B] CTL [47 FC 4F 1] [DON] op=is --> true Thu 02/21/2019 20:27:13 : [INST-SRX ] 02 50 47.FC.4F 11.01.01 CF 06 00 (00) Thu 02/21/2019 20:27:13 : [Std-Group ] 47.FC.4F-->11.01.01, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:27:13 : [INST-INFO ] Previous message ignored. Thu 02/21/2019 20:27:13 : [INST-TX-I1 ] 02 62 50 C9 CF 0F 11 FF Thu 02/21/2019 20:27:13 : [INST-TX-I1 ] 02 62 50 CA 68 0F 11 FF Thu 02/21/2019 20:27:13 : [INST-SRX ] 02 50 47.FC.4F 00.00.01 CF 13 01 LTOFFRR(01) Thu 02/21/2019 20:27:14 : [Std-Group ] 47.FC.4F-->Group=1, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:27:14 : [INST-ACK ] 02 62 50.C9.CF 0F 11 FF 06 LTONRR (FF) Thu 02/21/2019 20:27:14 : [D2D EVENT ] Event [47 FC 4F 1] [DOF] [1] uom=0 prec=-1 Thu 02/21/2019 20:27:14 : [ 47 FC 4F 1] DOF 1 Thu 02/21/2019 20:27:14 : [D2D-CMP 001C] CTL [47 FC 4F 1] [DOF] op=is --> true Thu 02/21/2019 20:27:14 : [D2D EVENT ] Event [47 FC 4F 1] [ST] [0] uom=100 prec=0 Thu 02/21/2019 20:27:14 : [ 47 FC 4F 1] ST 0 (uom=100 prec=0) Thu 02/21/2019 20:27:14 : [INST-SRX ] 02 50 50.C9.CF 4C.1B.8A 2B 11 FF LTONRR (FF) Thu 02/21/2019 20:27:14 : [Std-Direct Ack] 50.C9.CF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/21/2019 20:27:14 : [INST-ACK ] 02 62 50.CA.68 0F 11 FF 06 LTONRR (FF) Thu 02/21/2019 20:27:14 : [INST-SRX ] 02 50 47.FC.4F 00.00.01 C3 13 01 LTOFFRR(01) Thu 02/21/2019 20:27:14 : [Std-Group ] 47.FC.4F-->Group=1, Max Hops=3, Hops Left=0 Thu 02/21/2019 20:27:14 : [D2D EVENT ] Event [47 FC 4F 1] [DOF] [1] uom=0 prec=-1 Thu 02/21/2019 20:27:14 : [ 47 FC 4F 1] DOF 1 Thu 02/21/2019 20:27:14 : [D2D-CMP 001C] CTL [47 FC 4F 1] [DOF] op=is --> true Thu 02/21/2019 20:27:14 : [INST-SRX ] 02 50 50.CA.68 4C.1B.8A 2F 11 FF LTONRR (FF) Thu 02/21/2019 20:27:14 : [Std-Direct Ack] 50.CA.68-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:27:19 : [INST-SRX ] 02 50 14.BC.92 00.00.01 CF 11 01 LTONRR (01) Thu 02/21/2019 20:27:19 : [Std-Group ] 14.BC.92-->Group=1, Max Hops=3, Hops Left=3 Thu 02/21/2019 20:27:19 : [D2D EVENT ] Event [14 BC 92 1] [DON] [1] uom=0 prec=-1 Thu 02/21/2019 20:27:19 : [ 14 BC 92 1] DON 1
paulbates Posted February 22, 2019 Posted February 22, 2019 7 minutes ago, simplextech said: This is just bugging me as I'm coming to Insteon looking for a faster and more consistent lighting solution than Z-Wave. For me it is. Having said that, it has its foibles to be dealt with and worked with... like all HA technologies. This is sometimes compounded a little with the ISY I see one case for the door sensor 47.FC.4F has hops left=0. But in other cases its 3. What I think is going on is that: sensor is activated the ISY program is seeing the first of 2 insteon "switched on" messages from the sensor (wireless devices send 2 messages, 2 seconds apart) ISY starts sending insteon on messages to Set 'Deck / Switch / Flood Lights' On.... at the same time... .....the second of 2 insteon on messages from the sensor is sent these messages collide the devices retry.... athe same time.... .... the ISY is sending insteon on message to Set 'Deck / Switch / Front Light' On One or more of the devices gives up I'm not sure of your application, but here's what i suggest. If your application is to have the lights switch on, and then off again based on different criteria Link the lights and door sensor in a scene Let the insteon network do the work of turning the lights on (and quickly via scene) Have the program watch for the scene to turn on wait whatever period(s) make sense turn the scene back off Paul
oberkc Posted February 22, 2019 Posted February 22, 2019 If this were me, I would simplify the thought process. For now, I would ignore the logs. Are you saying that you turned a scene on somehow, but that some of the device in the scene did not respond as expected? The ISY will assume a device turned on when it is part of a scene and the scene is turned on. If the device did not turn on, I can think of three possibilities (excluding device failure)...the ON level is set to zero, link records have been corrupted, or communication problems. On levels are easy to confirm. Look at the scene definition and confirm that ON levels are set to something other than zero. Link records can be confirmed. Right click on a given device and choose diagnostics>>>show device links table. Once shown, there is an option to compare it to the ISY records for that device. They should match. If neither of those two things, I would look at comms problems. Unfortunately, this can be a bit of trial-and-error.
simplextech Posted February 22, 2019 Author Posted February 22, 2019 29 minutes ago, paulbates said: Link the lights and door sensor in a scene Let the insteon network do the work of turning the lights on (and quickly via scene) Have the program watch for the scene to turn on wait whatever period(s) make sense turn the scene back off I asked about and would like this. How do I prevent the scene from turning Off from the door sensor when the door closes? It's not like a MS II with the on-only option.
larryllix Posted February 22, 2019 Posted February 22, 2019 9 minutes ago, simplextech said: I asked about and would like this. How do I prevent the scene from turning Off from the door sensor when the door closes? It's not like a MS II with the on-only option. As per paulbates above. Unlink the trigger device from the scene, and use a program triggered by 'Switched On' from the device instead, to operate the scene. ISY becomes the only control of the scene.
paulbates Posted February 22, 2019 Posted February 22, 2019 Agreed on Larry's option ... putting the 2 lights in a scene. But add a 1 -2 second wait as the first command of the program to avoid the collisions from the second message from the sensor. Also, the V5 "adjust scene" command I believe addresses this. At the beginning of the program, reprogram the responders in the scene. After some period, program them back. TBH, I've looked at this but I haven't tried it, maybe a member here with experience with it could advise Paul
simplextech Posted February 22, 2019 Author Posted February 22, 2019 2 minutes ago, larryllix said: Unlink the trigger device from the scene, and use a program triggered by 'Switched On' from the device instead, to operate the scene. ISY becomes the only control of the scene. Then we're right back to the beginning of where this all started.... Original setup was 4 switches in a scene each one a controller. A program was used to watch the "Switched On" from the door sensor and turn on the scene. That was having issues of being very slow to not even functioning and ended up with at the point I started this thread with the ISY saying everything was On but in fact it was not and the ISY even saw the messages in the log which is what got me and I started to dig further. I've gone to Insteon support they recommended factory reset of the door sensor. I've done that. I'm watching logs and getting up open/close door check log try and find the beginning of the door sensor sending the DON shuffling through, I see no errors anywhere. There's a few hits of the hops left=1 so I'm sure there's some noise somewhere I have so much gear it would be nearly impossible to filter every single thing throughout the house. I'm starting to think the issue is literally closer to me than I was thinking and it may be too much noise on the circuit the PLM is plugged into. But I would expect/hope to see errors or more misses or something, anything. I don't mind problems but I can't stand transient issues.
simplextech Posted February 22, 2019 Author Posted February 22, 2019 2 minutes ago, paulbates said: Also, the V5 "adjust scene" command I believe addresses this. At the beginning of the program, reprogram the responders in the scene. After some period, program them back. TBH, I've looked at this but I haven't tried it, maybe a member here with experience with it could advise I do this with a motion sensor controlled scene to adjust the light level between day/night. I can give that a try. The 1-2 second delay before the lights turn on? I'm trying to avoid delays. I understand the basis of the idea but the result is a self imposed delay on the action.
paulbates Posted February 22, 2019 Posted February 22, 2019 Yeh I understand that and I try to let Insteon do the work amap but can’t all the time
larryllix Posted February 22, 2019 Posted February 22, 2019 @simplextech IMHO a few hops left means you have done a few jumps and is not a problem with noise. When your hops left varies from sample to saple that would indicate a noise problem. I just went through resolving some of my noise problems and I remember for years people posting about the same sources. Garage Door Openers. I don't know why they would create so much noise on standby but the new one with a battery charger made my system miss about 30% and got me out of my chair to find the older one did some too.
simplextech Posted February 22, 2019 Author Posted February 22, 2019 1 minute ago, larryllix said: I just went through resolving some of my noise problems and I remember for years people posting about the same sources. Garage Door Openers. I don't know why they would create so much noise on standby but the new one with a battery charger made my system miss about 30% and got me out of my chair to find the older one did some too. I'm thankful I still have an older'ish garage door opener then! I have an the IOLinc garage door kit in the mail to test out as well so I'll find out soon enough if that's going to work for me.
simplextech Posted February 22, 2019 Author Posted February 22, 2019 On the discussion of a scene. As the scene will be controlled by the ISY should I add the switches both as resonders or both as controllers? Before I had them all as controller the same way as my 3/4 way lighting switches.
larryllix Posted February 22, 2019 Posted February 22, 2019 Just now, simplextech said: I'm thankful I still have an older'ish garage door opener then! I have an the IOLinc garage door kit in the mail to test out as well so I'll find out soon enough if that's going to work for me. The older GDO still created noise but I always thought it would be coming form my two OutBack Inverters at the same end of the house. It only screwed up the odd signal maybe once per week but when I put it on an extension cord and plugged it into a longer circuit the problems disappeared. I don't get it. A small power supply to a RF circuit board and a motor doing nothing??? I guess the competition for cheap price got to the design or maybe poor quality PS caps and they just wear out like the PLMs did.
larryllix Posted February 22, 2019 Posted February 22, 2019 2 minutes ago, simplextech said: On the discussion of a scene. As the scene will be controlled by the ISY should I add the switches both as resonders or both as controllers? Before I had them all as controller the same way as my 3/4 way lighting switches. Responders. ISY will be the only controller. For non-MS type applications (human finger activated switches) I don't find the Insteon in/out delay too bad. Expect about 0.5 - 1.0 second. For MS to lights I can't tolerate that. I like the control over the logic though.
larryllix Posted February 22, 2019 Posted February 22, 2019 Here is the technique but UDI has added more options in V5+ to the technique. It may be worth a try. What are you trying to control?
simplextech Posted February 22, 2019 Author Posted February 22, 2019 3 minutes ago, larryllix said: Responders. ISY will be the only controller. For non-MS type applications (human finger activated switches) I don't find the Insteon in/out delay too bad. Expect about 0.5 - 1.0 second. For MS to lights I can't tolerate that. I like the control over the logic though. Delay with MS and lights annoys me more than anything. That singular issue drove me to testing every z-wave motion sensor I could get and I switched to Zigbee motion sensors because of the slow speed of 99% of all z-wave Motion sensors and then Zigbee is just a PITA when 99% of your devices are z-wave so I got a Insteon setup to "test" with a motion sensor and now I'm knee deep into a full z-wave to Insteon conversion Ok scene is created with the 2 switches as responders. The program is changed to set 'scene' on. I'll walk back and forth and test. I did notice in the advanced option for the door sensor in PLM Communication I can change the "retries". It can be set to 0 and upwards... would that eliminate the self imposed wait delay of 1-2 seconds to avoid collisions?
simplextech Posted February 22, 2019 Author Posted February 22, 2019 I tested with the retries of 0 and it did not help on the initial testing. I reconfigured the door sensor back to 1 retry and I added a 1 second wait before turning on the deck lights scene that was created. 2 rounds of testing so far and it's consistent. Which is good. I'll know more as I use that door at night a lot to go out on the deck at night to get wood for the fire which is another reason why this has been bugging me
larryllix Posted February 22, 2019 Posted February 22, 2019 I don't think Insteon will wait for retries because it cannot know they will be coming. However, the number of hops allowed (max hops) it should wait for. IIRC I did see a setting for that on somethng.
simplextech Posted February 22, 2019 Author Posted February 22, 2019 5 hours ago, larryllix said: I don't think Insteon will wait for retries because it cannot know they will be coming. However, the number of hops allowed (max hops) it should wait for. IIRC I did see a setting for that on somethng. I didn't think ISY would wait for the retries. But based on the other thought from previous that a retry was colliding with other commands I figured i would test turning OFF the retry. It didn't help. The 1 second wait in the program seems to have helped but I'll know more as I go in/out that door throughout the day/night today. I had a condition of time in the program originally but I removed that so I can test throughout the day.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.