Toddimus Posted August 12, 2016 Posted August 12, 2016 I had started another thread regarding issues with motion sensors/timer programs/lights turning off unexpectedly. http://forum.universal-devices.com/topic/19584-weird-behavior-with-motion-sensors-and-program-timers/ I morphed my own thread into a discussion that was off-topic, so I figured I would start a new one here. This idea started at least a year and a half ago with Jim Searle on the Ideascale site for UDI. http://udi.ideascale.com/a/dtd/Allow-disabling-a-device-in-a-program/83037-32911#idea-tab-comments My proposal is slightly different than Jim's but theoretically the outcome is very similar. Here's what I'm suggesting: Once a scene is created, add a programmatic action in the admin console that allows us to UN-Link and RE-Link a responder device from a scene. For all "hard-wired" devices, this should be pretty straightforward, since we can already do it manually using the admin console. When there's a battery powered Insteon motion sensor (MS) involved, it gets a bit more tricky because we can't wake the MS up to change its links table. That's why I propose we only change the responder's links table when un-linking/re-linking. My main motivation for wanting to do this is to make use of the direct link between a MS controller and a dimmer light responder, which has almost instantaneous response time; as opposed to having no direct links between the MS and light and using programs to trigger the light to turn on after motion is sensed. Direct link = no/low latency Programmatic control = variable latency, but at least one second sometimes more But sometimes, I don't want the responder light(s) to be triggered by the motion sensor. One example: my office has a pullout guest bed in it. Under normal use (i.e. no guests), I want the lights to respond to my motion sensor at night. But when there's a guest sleeping there, they definitely don't want to have the light turn on every time they roll over in bed. Here's three possible solutions: If I use program only control (i.e. no direct links between MS and light), then I can create a set of programs that lets me do pretty much whatever I want. I can change ON levels, ramp rates, disable/enable the motion sensor as a trigger, etc. The problem is the variable latency involved in program only control. Sometimes, the light takes a few seconds to turn on when you walk into the room, which makes the automation less useful because you are already 8 feet into the room and stubbed your toe waiting for the light to turn on. I have tried various versions of this setup and tuned them as best I could to reduce latency, but it still leaves a lot to be desired in terms of latency and predictability. This is what I still use for most of my motion response in my HA setup. I just think is could/should be better than this. Use a direct link between the MS and light using a scene, but control the on-level of the light using programs that employ the "scene adjust" feature. This gets us closer but leads to some compromises and a potential web of multiple programs. Compromises include: If I want to effectively "disable" the motion trigger, I have to override the scene response by sending ON or OFF commands to the light after each motion trigger is registered, and/or set a slow ramp rate for the scene response allows the program driven ON/OFF commands to drive the light. Also, in order to get it to work well, you have to use a FAST ON (100%, very quick ramp rate) program-driven command to win the race between the slow ramp rate in the direct MS link to the light. That gives up the nice 0.5 second or 2.0 second "smooth" feeling and adjustable ON levels I like to have for various times of day. It also creates a lot of Insteon traffic and programs firing to keep things working like I want. In my experience, this leads to variable latency and sometimes non-deterministic results and requires quite a few programs to set things up... especially with the multiple ON levels and ramp rates I want to employ at various times of the day. @larryllix and I had a discussion about this a year ago: The thread, http://forum.universal-devices.com/topic/16694-50-latency-question/ and his specific post on how we might set this up http://forum.universal-devices.com/topic/16694-50-latency-question/?p=146852 Use a direct link between the MS and light using a scene, still controlling the on-level (and ramp rate) of the light using programs that employ the "scene adjust" feature, but add the ability to UN-Link and RE-Link the light as a responder of the scene. This way, I can get the benefits of the low latency direct link, keep programmatic control of on levels and ramp rates, avoid the compromises mentioned above AND effectively disable the direct link between the MS controller and light responder. This is exactly what I want to have!!! It seems like there is one major prerequisite to make this work: Before allowing the option to un-link and re-link a responder, you first have to create the scene with links between the controller and responder(s). This adds entries to the links tables of the devices in question. In particular, it adds the links to the controller, which may be a radio only device (like a motion sensor), so its links cannot be changed "on the fly". To test out whether this might work, I simulated the un-link/re-link manually using mouse clicks on the admin console. (The following is copied/pasted/edited from my other thread) Doing things the "regular, old-school, manual" way we've become accustomed to in the admin console: I made a test scene with a motion sensor (as controller) and dimmer switch (as responder). Just as we would expect, the light turns on immediately when the MS triggers the scene. I then did a device links query for both devices: Now, I manually deleted the dimmer switch from the scene, with the MS in linking mode, and did the same set of device links queries. Again, as expected, the light does nothing when the MS is triggered because the light has been removed from the scene. Of course the responder device (dimmer switch) has less links in the second set of tables because it no longer belongs to the scene. What's interesting is that the controller for the scene (MS) kept the fourth row (index 3) but changed one entry from A2 to a 62, which I circled in red in the two sets. So one question is: Can the PLM and MS controller "overlook" or not be bothered by the link that still exists? My presumption is that this is fine because that's the way things would be in our normal usage of the admin console when we add/delete devices from a scene. Everything I did above was done using standard add/delete the responder device from the scene. During and after this process, I ended up with no red exclamation points or green IOIO arrows next to each of the devices in question. As a last step for the above "control" experiment, I re-added the responder dimmer to the scene with the motion sensor in linking mode. This got me ready to to what I really wanted to do next: Manually simulate what I want to do programmatically, let's try the same things as above without putting the motion sensor into linking mode: Here's the responder's links table and a level 3 capture of MS trigger after manually deleting the responder dimmer from the scene without having the motion sensor in linking mode. So that means the motion sensor doesn't know the light was removed from the scene. In this case, the MS entry in the tree on the left of the admin console did have the IOIO arrow next to it, indicating that it had pending updates to write. I also didn't want to "wake up" the MS to sync up its links table so I couldn't query it as I did above. Just as I would hope (and expect), the light did not turn on after the motion sensor was triggered. Thu 08/11/2016 10:58:48 PM : [INST-SRX ] 02 50 37.B6.14 00.00.01 CB 11 01 LTONRR (01) Thu 08/11/2016 10:58:48 PM : [Std-Group ] 37.B6.14-->Group=1, Max Hops=3, Hops Left=2 Thu 08/11/2016 10:58:48 PM : [D2D EVENT ] Event [37 B6 14 1] [DON] [1] uom=0 prec=-1 Thu 08/11/2016 10:58:48 PM : [ 37 B6 14 1] DON 1 Thu 08/11/2016 10:58:48 PM : [D2D-CMP 011C] CTL [37 B6 14 1] [DON] op=is --> true Thu 08/11/2016 10:58:48 PM : [D2D-CMP 00E9] CTL [37 B6 14 1] [DON] op=is --> true Thu 08/11/2016 10:58:48 PM : [D2D-CMP 0154] CTL [37 B6 14 1] [DON] op=is --> true Thu 08/11/2016 10:58:48 PM : [D2D-CMP 013A] CTL [37 B6 14 1] [DON] op=is --> true Thu 08/11/2016 10:58:48 PM : [INST-SRX ] 02 50 37.B6.14 00.00.01 CB 11 01 LTONRR (01) Thu 08/11/2016 10:58:48 PM : [Std-Group ] 37.B6.14-->Group=1, Max Hops=3, Hops Left=2 Thu 08/11/2016 10:58:48 PM : [INST-DUP ] Previous message ignored. Thu 08/11/2016 10:58:48 PM : [INST-SRX ] 02 50 37.B6.14 2F.BA.E7 41 11 01 LTONRR (01) Thu 08/11/2016 10:58:48 PM : [Std-Cleanup ] 37.B6.14-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Thu 08/11/2016 10:58:48 PM : [INST-DUP ] Previous message ignored. Thu 08/11/2016 10:58:49 PM : [INST-SRX ] 02 50 37.B6.14 11.02.01 C7 06 00 (00) Thu 08/11/2016 10:58:49 PM : [Std-Group ] 37.B6.14-->11.02.01, Max Hops=3, Hops Left=1 Thu 08/11/2016 10:58:49 PM : [INST-INFO ] Previous message ignored. Thu 08/11/2016 10:58:49 PM : [INST-SRX ] 02 50 37.B6.14 11.02.01 CB 06 00 (00) Thu 08/11/2016 10:58:49 PM : [Std-Group ] 37.B6.14-->11.02.01, Max Hops=3, Hops Left=2 Thu 08/11/2016 10:58:49 PM : [INST-INFO ] Previous message ignored. Thu 08/11/2016 10:58:53 PM : [VAR 2 30 ] 3 The similar links table and level 3 capture after manually re-adding the responder dimmer back into the scene, still without having the motion sensor in linking mode. Again, the MS did have the IOIO arrow next to it in the tree on the left. The light did turn on, as I hoped and expected. Thu 08/11/2016 11:05:05 PM : [INST-SRX ] 02 50 37.B6.14 00.00.01 CB 11 01 LTONRR (01) Thu 08/11/2016 11:05:05 PM : [Std-Group ] 37.B6.14-->Group=1, Max Hops=3, Hops Left=2 Thu 08/11/2016 11:05:05 PM : [D2D EVENT ] Event [37 B6 14 1] [DON] [1] uom=0 prec=-1 Thu 08/11/2016 11:05:05 PM : [ 37 B6 14 1] DON 1 Thu 08/11/2016 11:05:05 PM : [D2D-CMP 011C] CTL [37 B6 14 1] [DON] op=is --> true Thu 08/11/2016 11:05:05 PM : [D2D-CMP 00E9] CTL [37 B6 14 1] [DON] op=is --> true Thu 08/11/2016 11:05:05 PM : [D2D-CMP 0154] CTL [37 B6 14 1] [DON] op=is --> true Thu 08/11/2016 11:05:05 PM : [D2D-CMP 013A] CTL [37 B6 14 1] [DON] op=is --> true Thu 08/11/2016 11:05:05 PM : [D2D EVENT ] Event [2F D4 90 1] [ST] [255] uom=100 prec=0 Thu 08/11/2016 11:05:05 PM : [ 2F D4 90 1] ST 255 (uom=100 prec=0) Thu 08/11/2016 11:05:05 PM : [INST-SRX ] 02 50 37.B6.14 00.00.01 CB 11 01 LTONRR (01) Thu 08/11/2016 11:05:05 PM : [Std-Group ] 37.B6.14-->Group=1, Max Hops=3, Hops Left=2 Thu 08/11/2016 11:05:05 PM : [INST-DUP ] Previous message ignored. Thu 08/11/2016 11:05:06 PM : [INST-SRX ] 02 50 37.B6.14 2F.BA.E7 41 11 01 LTONRR (01) Thu 08/11/2016 11:05:06 PM : [Std-Cleanup ] 37.B6.14-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Thu 08/11/2016 11:05:06 PM : [INST-DUP ] Previous message ignored. Thu 08/11/2016 11:05:06 PM : [INST-SRX ] 02 50 37.B6.14 11.02.01 CB 06 00 (00) Thu 08/11/2016 11:05:06 PM : [Std-Group ] 37.B6.14-->11.02.01, Max Hops=3, Hops Left=2 Thu 08/11/2016 11:05:06 PM : [INST-INFO ] Previous message ignored. Thu 08/11/2016 11:05:06 PM : [INST-SRX ] 02 50 37.B6.14 11.02.01 CB 06 00 (00) Thu 08/11/2016 11:05:06 PM : [Std-Group ] 37.B6.14-->11.02.01, Max Hops=3, Hops Left=2 Thu 08/11/2016 11:05:06 PM : [INST-INFO ] Previous message ignored. The links tables for the responder dimmer switch with the MS not in linking mode do have differences as well. This time two entries changed in each links table (circled in red). They went from 22 to A2. Apparently, the PLM and devices didn't seem to have problems with the lack of linking because things worked just like I wanted them to work, even though the MS didn't "know" what I had done. Looks to me like this should work programmatically. Am I missing something? This would be so useful and dramatically improve the performance of motion based automation.
LeeG Posted August 12, 2016 Posted August 12, 2016 The process of unlinking/relinking introduces changes to the Motion Sensor and the Responder link record (going to 22 to delete the record followed by creating a new link record with A2). The Adjust Scene has no affect on Motion Sensor with a 0% On Level in Responder which has the same affect as unlink.
Toddimus Posted August 13, 2016 Author Posted August 13, 2016 The process of unlinking/relinking introduces changes to the Motion Sensor and the Responder link record (going to 22 to delete the record followed by creating a new link record with A2). I don't disagree, but my experiments showed that it doesn't seem to matter. What really mattered were the links in the responder, which gave the intended outcome: when it was "unlinked" the light didn't go on and when it was "relinked" the light did go on. In the second set of experiments, I didn't let the controller (MS) update its links table because it was not in linking mode, which is what I was trying to test. Does the scene respond as I want it to when manually linked/unlinked? The answer was YES! ... The Adjust Scene has no affect on Motion Sensor with a 0% On Level in Responder which has the same affect as unlink. I beg to differ... An ON level of 0% in the scene turns the responders to 0% ON, which really means it turns them off... at the prescribed ramp rate. So if the lights are already on and the motion sensor controller in the scene detects motion, it sends a signal that results in the lights turning to 0% at the ramp rate. So a practical implication is that an unsuspecting guest turns the light switch ON and then moves around in the room and the light starts dimming down to 0% "on" (which is really OFF). It does NOT have the same effect as "unlink". When they are unlinked, that effectively uncouples the light as a responder. Motion at the sensor does nothing to the responder.
LeeG Posted August 13, 2016 Posted August 13, 2016 Since the Motion Sensor has not been updated because it is battery powered it will get a timeout error because the Responder does not have a matching link record. The Motion Sensor will retry causing unnecessary traffic. Suggest running Event Trace at LEVEL 3. Also think the Responder link table will grow although I have not verified this. Suggest displaying link table of Responder after several unlink/relink requests.
G W Posted August 13, 2016 Posted August 13, 2016 I don't disagree, but my experiments showed that it doesn't seem to matter. What really mattered were the links in the responder, which gave the intended outcome: when it was "unlinked" the light didn't go on and when it was "relinked" the light did go on. In the second set of experiments, I didn't let the controller (MS) update its links table because it was not in linking mode, which is what I was trying to test. Does the scene respond as I want it to when manually linked/unlinked? The answer was YES! I beg to differ... An ON level of 0% in the scene turns the responders to 0% ON, which really means it turns them off... at the prescribed ramp rate. So if the lights are already on and the motion sensor controller in the scene detects motion, it sends a signal that results in the lights turning to 0% at the ramp rate. So a practical implication is that an unsuspecting guest turns the light switch ON and then moves around in the room and the light starts dimming down to 0% "on" (which is really OFF). It does NOT have the same effect as "unlink". When they are unlinked, that effectively uncouples the light as a responder. Motion at the sensor does nothing to the responder. Explaining Insteon to LeeG is equivalent to explaining Ethernet to Bob Metcalfe. Best regards, Gary Funk
Toddimus Posted August 13, 2016 Author Posted August 13, 2016 Since the Motion Sensor has not been updated because it is battery powered it will get a timeout error because the Responder does not have a matching link record. The Motion Sensor will retry causing unnecessary traffic. Suggest running Event Trace at LEVEL 3. Also think the Responder link table will grow although I have not verified this. Suggest displaying link table of Responder after several unlink/relink requests. It seems like I get those retries anyways, and theoretically, I can cut those down by using the "Communications to the PLM" pop-up and setting it to no retries or maybe one retry. For a counterpoint to that argument, having to do an adjust scene from a program causes a bunch of traffic too. I did post the Event Trace at LEVEL 3 in my post above for the motion response in both the linked and unlinked "state". I'll have to wait until the critters in the house go to sleep to post event traces for the unlink/relink processes. WAY too much traffic now. Telling my wife, 3 year old toddler and two dogs to sit still so I can do an experiment is like... well... I can't think of a good analogy, but you get the picture. Here's the responder link table entries you suggested to test: (note that I edited the screenshot below because it had an error in it originally) Explaining Insteon to LeeG is equivalent to explaining Ethernet to Bob Metcalfe. Best regards, Gary Funk Agreed. LeeG is an undisputed guru, with 12,963 posts on the UDI forum at the time I'm writing this. It's just that this time I think he's actually wrong about something (the 0% ON level thing). The first time I've ever seen it. I honestly can't believe it either but I stumbled upon it by empirically testing things out. Consider this: Einstein proved some of Newton's theories incomplete, who proved some of Galileo's theories incomplete, who proved the Greeks weren't right about everything either. My intent is not to suggest that I'm better, smarter or any superlative compared to LeeG. My intent is to get the ISY to work better, faster and more simply with this new "feature" I'm suggesting. To prove it to yourself... I implore you, him, or anyone else to do this quick experiment: Create a test scene Add a device as a responder Set the scene ON level slider to 0%. ...and for kicks, set the scene's ramp rate to 2.0 seconds Manually turn the responder device ON to something like 75% using the device's slider on the admin console Then, on the scene page, hit the ON button in the admin console Tell me if it doesn't turn the light off at a 2.0 second ramp rate. And for the bonus question... what happens when you hit the scene's FAST ON button on the admin console? Hint: FAST ON always trumps ON level and ramp rate The last thing I want to do is offend anyone, cause anyone undue consternation, or generally raise raise anyone's blood pressure. I just want ISY users and UDI folks to entertain the notion that this new feature idea is plausible. And if it is, try to get it implemented in the ISY firmware! I, for one, would make use of it extensively! And I think others would as well once they realized the possibilities. If my proposed feature isn't possible, then that's the way it is and I'm OK with that. I just haven't been convinced that it isn't possible yet.
Toddimus Posted August 13, 2016 Author Posted August 13, 2016 Ok, everybody went to bed and I temporarily turned off my NodeLink program to minimize traffic interference. LeeG, per your request... Here's the LEVEL 3 log for removing the responder from the scene (without the MS controller being in linking mode): Fri 08/12/2016 11:12:48 PM : [Master Bath Light] Start : Removing from scene 'test2' Fri 08/12/2016 11:12:48 PM : [MNG-LNK-RSP ] 02 6F 80 E2 33 2F D4 90 01 20 41 06 Fri 08/12/2016 11:12:48 PM : [2F D4 90 1 ] Link 2 : 0FE8 [22332FBAE7FF1F01] Saving [22..............] Fri 08/12/2016 11:12:49 PM : [Master Bath Light] Removing 'Motion - Kitchen --Sensor' as Controller Fri 08/12/2016 11:12:49 PM : [2D 9A 81 1 ] Link 3 : 0FE0 [62012FD490010001] Saving [62..............] Fri 08/12/2016 11:12:49 PM : [2F D4 90 1 ] Link 3 : 0FE0 [22012D9A81FF1F01] Saving [22..............] Fri 08/12/2016 11:12:49 PM : [Master Bath Light] Finish : Removing from scene 'test2' was Successful Fri 08/12/2016 11:12:49 PM : [All ] Writing 10 bytes to devices Fri 08/12/2016 11:12:49 PM : [INST-TX-I2CS] 02 62 2D 9A 81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:12:49 PM : [INST-ACK ] 02 62 2D.9A.81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:12:58 PM : [ Time] 23:13:01 0(0) Fri 08/12/2016 11:12:58 PM : [INST-TX-I2CS] 02 62 2D 9A 81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:12:58 PM : [INST-ACK ] 02 62 2D.9A.81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:13:00 PM : [ Time] 23:13:03 0(0) Fri 08/12/2016 11:13:05 PM : [ Time] 23:13:07 0(0) Fri 08/12/2016 11:13:05 PM : [ Time] 23:13:07 0(0) Fri 08/12/2016 11:13:07 PM : [INST-TX-I2CS] 02 62 2D 9A 81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:13:07 PM : [INST-ACK ] 02 62 2D.9A.81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:13:10 PM : [ Time] 23:13:13 0(0) Fri 08/12/2016 11:13:11 PM : [INST-TX-I2CS] 02 62 2F D4 90 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:13:11 PM : [INST-ACK ] 02 62 2F.D4.90 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:13:20 PM : [INST-TX-I2CS] 02 62 2F D4 90 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:13:20 PM : [INST-ACK ] 02 62 2F.D4.90 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:13:22 PM : [INST-SRX ] 02 50 2F.D4.90 2F.BA.E7 2B 2F 00 (00) Fri 08/12/2016 11:13:22 PM : [Std-Direct Ack] 2F.D4.90-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 08/12/2016 11:13:22 PM : [INST-ERX ] 02 51 2F D4 90 2F BA E7 11 2F 00 00 01 0F FF 00 A2 00 2F BA E7 FF 1F 01 31 Fri 08/12/2016 11:13:22 PM : [Ext-Direct ] 2F.D4.90-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 08/12/2016 11:13:23 PM : [2F D4 90 1 ] Link 2 : 0FE8 [22332FBAE7FF1F01] Writing [22..............] Fri 08/12/2016 11:13:23 PM : [INST-TX-I2CS] 02 62 2F D4 90 1F 2F 00 00 02 0F EF 08 22 33 2F BA E7 FF 1F 01 85 Fri 08/12/2016 11:13:23 PM : [INST-ACK ] 02 62 2F.D4.90 1F 2F 00 00 02 0F EF 08 22 33 2F BA E7 FF 1F 01 85 06 (00) Fri 08/12/2016 11:13:23 PM : [INST-ERX ] 02 51 2F D4 90 2F BA E7 16 2F 00 00 01 0F FF 00 A2 00 2F BA E7 FF 1F 01 31 Fri 08/12/2016 11:13:23 PM : [Ext-Direct ] 2F.D4.90-->ISY/PLM Group=0, Max Hops=2, Hops Left=1 Fri 08/12/2016 11:13:23 PM : [Ext MH ] Unexpected Response (i.e. DB range): ignored Fri 08/12/2016 11:13:24 PM : [INST-SRX ] 02 50 2F.D4.90 2F.BA.E7 2B 2F 00 (00) Fri 08/12/2016 11:13:24 PM : [Std-Direct Ack] 2F.D4.90-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 08/12/2016 11:13:25 PM : [MNG-LNK-RSP ] 02 6F 80 E2 33 2F D4 90 01 20 41 15 Fri 08/12/2016 11:13:25 PM : [PLM ] Group 51 : Deleting Controller Link matching [2F D4 90 1 ] Link 2 : 0FE8 [22332FBAE7FF1F01] Fri 08/12/2016 11:13:25 PM : [2F D4 90 1 ] Link 3 : 0FE0 [22012D9A81FF1F01] Writing [22..............] Fri 08/12/2016 11:13:25 PM : [INST-TX-I2CS] 02 62 2F D4 90 1F 2F 00 00 02 0F E7 08 22 01 2D 9A 81 FF 1F 01 47 Fri 08/12/2016 11:13:25 PM : [INST-ACK ] 02 62 2F.D4.90 1F 2F 00 00 02 0F E7 08 22 01 2D 9A 81 FF 1F 01 47 06 (00) Fri 08/12/2016 11:13:26 PM : [INST-SRX ] 02 50 2F.D4.90 2F.BA.E7 2B 2F 00 (00) Fri 08/12/2016 11:13:26 PM : [Std-Direct Ack] 2F.D4.90-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 08/12/2016 11:13:26 PM : [INST-SRX ] 02 50 2F.D4.90 2F.BA.E7 23 2F 00 (00) Fri 08/12/2016 11:13:26 PM : [Std-Direct Ack] 2F.D4.90-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 And the LEVEL 3 log when I added it back, again with the MS not in linking mode: Fri 08/12/2016 11:15:25 PM : [Master Bath Light] Start : Adding to scene 'test2' Fri 08/12/2016 11:15:25 PM : [Master Bath Light] Making 'test2' a Controller Fri 08/12/2016 11:15:25 PM : [MNG-LNK-RSP ] 02 6F 40 E2 33 2F D4 90 01 20 41 06 Fri 08/12/2016 11:15:25 PM : [2F D4 90 1 ] Link 2 : 0FE8 [A2332FBAE7FF1F01] Saving [A2332FBAE7FF1F01] Fri 08/12/2016 11:15:25 PM : [Master Bath Light] Making 'Motion - Kitchen --Sensor' a Controller Fri 08/12/2016 11:15:25 PM : [2D 9A 81 1 ] Link 3 : 0FE0 [E2012FD490010001] Saving [E2012FD490010001] Fri 08/12/2016 11:15:25 PM : [2F D4 90 1 ] Link 3 : 0FE0 [A2012D9A81FF1F01] Saving [A2012D9A81FF1F01] Fri 08/12/2016 11:15:25 PM : [Master Bath Light] Finish : Adding to scene 'test2' was Successful Fri 08/12/2016 11:15:25 PM : [All ] Writing 24 bytes to devices Fri 08/12/2016 11:15:25 PM : [INST-TX-I2CS] 02 62 2D 9A 81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:15:25 PM : [INST-ACK ] 02 62 2D.9A.81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:15:34 PM : [INST-TX-I2CS] 02 62 2D 9A 81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:15:34 PM : [INST-ACK ] 02 62 2D.9A.81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:15:43 PM : [INST-TX-I2CS] 02 62 2D 9A 81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:15:43 PM : [INST-ACK ] 02 62 2D.9A.81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:15:47 PM : [INST-TX-I2CS] 02 62 2F D4 90 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:15:47 PM : [INST-ACK ] 02 62 2F.D4.90 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:15:48 PM : [INST-SRX ] 02 50 2F.D4.90 2F.BA.E7 2B 2F 00 (00) Fri 08/12/2016 11:15:48 PM : [Std-Direct Ack] 2F.D4.90-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 08/12/2016 11:15:48 PM : [INST-ERX ] 02 51 2F D4 90 2F BA E7 11 2F 00 00 01 0F FF 00 A2 00 2F BA E7 FF 1F 01 31 Fri 08/12/2016 11:15:48 PM : [Ext-Direct ] 2F.D4.90-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 08/12/2016 11:15:48 PM : [2F D4 90 1 ] Link 2 : 0FE8 [A2332FBAE7FF1F01] Writing [A2332FBAE7FF1F01] Fri 08/12/2016 11:15:48 PM : [INST-TX-I2CS] 02 62 2F D4 90 1F 2F 00 00 02 0F EF 08 A2 33 2F BA E7 FF 1F 01 05 Fri 08/12/2016 11:15:48 PM : [INST-ACK ] 02 62 2F.D4.90 1F 2F 00 00 02 0F EF 08 A2 33 2F BA E7 FF 1F 01 05 06 (00) Fri 08/12/2016 11:15:51 PM : [INST-SRX ] 02 50 2F.D4.90 2F.BA.E7 2B 2F 00 (00) Fri 08/12/2016 11:15:51 PM : [Std-Direct Ack] 2F.D4.90-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 08/12/2016 11:15:51 PM : [MNG-LNK-RSP ] 02 6F 40 E2 33 2F D4 90 01 20 41 15 Fri 08/12/2016 11:15:51 PM : [PLM ] Group 51 : Writing Controller Link matching [2F D4 90 1 ] Link 2 : 0FE8 [A2332FBAE7FF1F01] Fri 08/12/2016 11:15:51 PM : [2F D4 90 1 ] Link 3 : 0FE0 [A2012D9A81FF1F01] Writing [A2012D9A81FF1F01] Fri 08/12/2016 11:15:51 PM : [INST-TX-I2CS] 02 62 2F D4 90 1F 2F 00 00 02 0F E7 08 A2 01 2D 9A 81 FF 1F 01 C7 Fri 08/12/2016 11:15:51 PM : [INST-ACK ] 02 62 2F.D4.90 1F 2F 00 00 02 0F E7 08 A2 01 2D 9A 81 FF 1F 01 C7 06 (00) Fri 08/12/2016 11:15:53 PM : [INST-SRX ] 02 50 2F.D4.90 2F.BA.E7 2B 2F 00 (00) Fri 08/12/2016 11:15:53 PM : [Std-Direct Ack] 2F.D4.90-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 I know there are retries in there. The thing is, it just doesn't seem to matter! In one of my attempts of adding (or removing), I turned on another, unrelated light using the admin console. It worked fine too, so the traffic didn't seem to hinder its response. For another timing/traffic reference, I created a test program which had two entries in the THEN clause: test3 - [ID 0179][Parent 0001] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then In Scene 'test2' Set 'Master Bath Light' 1% (On Level) In Scene 'test2' Set 'Master Bath Light' 8.5 Sec (Ramp Rate) Else - No Actions - (To add one, press 'Action') Here's the resulting LEVEL 3 log from running the THEN clause: Fri 08/12/2016 11:25:17 PM : [ Time] 23:25:18 0(0) Fri 08/12/2016 11:25:17 PM : [2F D4 90 1 ] Link 2 : 0FE8 [A2332FBAE7021F01] Saving [..........02....] Fri 08/12/2016 11:25:18 PM : [2F D4 90 1 ] Link 2 : 0FE8 [A2332FBAE7021801] Saving [............18..] Fri 08/12/2016 11:25:18 PM : [All ] Writing 10 bytes to devices Fri 08/12/2016 11:25:18 PM : [INST-TX-I2CS] 02 62 2D 9A 81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:25:18 PM : [INST-ACK ] 02 62 2D.9A.81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:25:27 PM : [INST-TX-I2CS] 02 62 2D 9A 81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:25:27 PM : [INST-ACK ] 02 62 2D.9A.81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:25:36 PM : [INST-TX-I2CS] 02 62 2D 9A 81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:25:36 PM : [INST-ACK ] 02 62 2D.9A.81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:25:40 PM : [INST-TX-I2CS] 02 62 2F D4 90 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:25:40 PM : [INST-ACK ] 02 62 2F.D4.90 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:25:42 PM : [INST-SRX ] 02 50 2F.D4.90 2F.BA.E7 2B 2F 00 (00) Fri 08/12/2016 11:25:42 PM : [Std-Direct Ack] 2F.D4.90-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 08/12/2016 11:25:42 PM : [INST-ERX ] 02 51 2F D4 90 2F BA E7 11 2F 00 00 01 0F FF 00 A2 00 2F BA E7 FF 1F 01 31 Fri 08/12/2016 11:25:42 PM : [Ext-Direct ] 2F.D4.90-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 08/12/2016 11:25:42 PM : [2F D4 90 1 ] Link 2 : 0FE8 [A2332FBAE7021801] Writing [..........0218..] Fri 08/12/2016 11:25:42 PM : [INST-TX-I2CS] 02 62 2F D4 90 1F 2F 00 00 02 0F EF 08 A2 33 2F BA E7 02 18 01 09 Fri 08/12/2016 11:25:42 PM : [INST-ACK ] 02 62 2F.D4.90 1F 2F 00 00 02 0F EF 08 A2 33 2F BA E7 02 18 01 09 06 (00) Fri 08/12/2016 11:25:51 PM : [INST-TX-I2CS] 02 62 2F D4 90 1F 2F 00 00 02 0F EF 08 A2 33 2F BA E7 02 18 01 09 Fri 08/12/2016 11:25:51 PM : [INST-ACK ] 02 62 2F.D4.90 1F 2F 00 00 02 0F EF 08 A2 33 2F BA E7 02 18 01 09 06 (00) Fri 08/12/2016 11:25:52 PM : [INST-SRX ] 02 50 2F.D4.90 2F.BA.E7 2B 2F 00 (00) Fri 08/12/2016 11:25:52 PM : [Std-Direct Ack] 2F.D4.90-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 08/12/2016 11:25:52 PM : [All ] Writing 8 bytes to devices Fri 08/12/2016 11:25:52 PM : [INST-TX-I2CS] 02 62 2D 9A 81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:25:52 PM : [INST-ACK ] 02 62 2D.9A.81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:26:01 PM : [INST-TX-I2CS] 02 62 2D 9A 81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:26:01 PM : [INST-ACK ] 02 62 2D.9A.81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Fri 08/12/2016 11:26:08 PM : [ Time] 23:26:08 0(0) Fri 08/12/2016 11:26:10 PM : [INST-TX-I2CS] 02 62 2D 9A 81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Fri 08/12/2016 11:26:10 PM : [INST-ACK ] 02 62 2D.9A.81 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) As a side note here's the duration of traffic for each of the above actions. Interestingly, the scene adjust program actions took quite a bit longer than the unlink/relink sequences: removing (un-linking) the device took 38 seconds adding (re-linking) the device took 28 seconds modifying the scene's on level and ramp rate took 53 seconds
G W Posted August 13, 2016 Posted August 13, 2016 Telling my wife, 3 year old toddler and two dogs to sit still so I can do an experiment is like... well...It's like herding cats. Best regards, Gary Funk
Recommended Posts
Archived
This topic is now archived and is closed to further replies.