larryllix Posted March 4, 2019 Posted March 4, 2019 16 minutes ago, kclenden said: With a little googling, found this blurb from Smarthome about the USB Modem: Congratulations and Introduction PowerLinc USB is the world's first Universal Serial Bus (USB) based transmitter and receiver for X10/PLC (Powerline Carrier) control. Unlike previous solutions that used the slower-speed RS-232 Com Port and required the use of a dedicated interrupt control line (IRQ), PowerLinc USB uses the newer and more flexible USB channel now found on nearly all computers. USB ports support higher speeds and multiple devices can be attached to the computer at the same time. It implies the USB PowerLinc is faster but could just be marketing speak. USB_PowerLinc_Blurb_1132U_web.pdf 294.79 kB · 0 downloads They can make the serial port as fast as they like inside the USB dongle but the whole thing is going to wait for the slowest link anyway...the modem protocol. I read here a long time back, the Insteon Hub was the same PLM daughter board plugged into the backside of the Ethernet to USB adapter. It had PS cap problems the same as the PLM module. Based on that, I would say @mwester is correct in the post above. @Brian H may know more about this.
simplextech Posted March 4, 2019 Author Posted March 4, 2019 13 minutes ago, kclenden said: You may well be right. Still, when trying to explain the significant difference in speed that simplextech saw, an obvious difference between PLMs seems tempting as the ultimate root cause. ? At the moment this is what I'm leaning towards as well. I have no facts but I will say it's not a lack of processing capability of the ISY as there were only the 2 devices and 2 programs with nothing else running. If it was a lack of power then nobody's systems would be usable for anything I think a next step in this will be to get a serial to usb cable and connect the serial PLM to my HS box and see what happens
mwester Posted March 4, 2019 Posted March 4, 2019 Just to followup on my earlier comments -- still can't find my USB PLM... But I DID find the source code for an RPI C app I wrote to sit between the ISY and said USB PLM, while I waited for a replacement serial PLM to arrive. Reviewing the source code, yes, the USB PLM appears to Linux as an ordinary serial port. And per the source code, one sets that port to 19,200 baud in order to drive the USB PLM. So, in other words, the USB PLM is nothing more than a serial PLM with the RS232 driver chip replaced by a USB serial chip. And the protocol -- it's exactly the same. I changed nothing to make the ISY work with the USB PLM. My conclusion -- we have to look elsewhere for the root cause of the speed difference. However, using a USB PLM and an RPI might be an interesting way to interface -- one can easily pass the comms directly from one port to the other whilst logging the data with timestamps... Just a thought.
larryllix Posted March 4, 2019 Posted March 4, 2019 3 minutes ago, mwester said: Just to followup on my earlier comments -- still can't find my USB PLM... But I DID find the source code for an RPI C app I wrote to sit between the ISY and said USB PLM, while I waited for a replacement serial PLM to arrive. Reviewing the source code, yes, the USB PLM appears to Linux as an ordinary serial port. And per the source code, one sets that port to 19,200 baud in order to drive the USB PLM. So, in other words, the USB PLM is nothing more than a serial PLM with the RS232 driver chip replaced by a USB serial chip. And the protocol -- it's exactly the same. I changed nothing to make the ISY work with the USB PLM. My conclusion -- we have to look elsewhere for the root cause of the speed difference. However, using a USB PLM and an RPI might be an interesting way to interface -- one can easily pass the comms directly from one port to the other whilst logging the data with timestamps... Just a thought. Isn't the serial port style protocol used for Ethernet adapters also?
palayman Posted March 4, 2019 Posted March 4, 2019 They're both exactly same except the USB has a small daughter board. Look here (the FCC reports even use the same pictures for most of it). Daughter board is the last pic in the second link. https://fccid.io/SBP2413S/Internal-Photos/Internal-Photos-1070360 https://fccid.io/SBP2413U/Internal-Photos/Internal-Photos-1069165
mwester Posted March 4, 2019 Posted March 4, 2019 1 hour ago, larryllix said: Isn't the serial port style protocol used for Ethernet adapters also? No.
mwester Posted March 4, 2019 Posted March 4, 2019 1 hour ago, palayman said: They're both exactly same except the USB has a small daughter board. Look here (the FCC reports even use the same pictures for most of it). Daughter board is the last pic in the second link. https://fccid.io/SBP2413S/Internal-Photos/Internal-Photos-1070360 https://fccid.io/SBP2413U/Internal-Photos/Internal-Photos-1069165 Nice find! The photo even identifies the USB serial chip -- the ubiquitous FTDI chip.
kclenden Posted March 4, 2019 Posted March 4, 2019 2 hours ago, palayman said: They're both exactly same except the USB has a small daughter board. Look here (the FCC reports even use the same pictures for most of it). Daughter board is the last pic in the second link. https://fccid.io/SBP2413S/Internal-Photos/Internal-Photos-1070360 https://fccid.io/SBP2413U/Internal-Photos/Internal-Photos-1069165 I can't argue with that. And I have wondered why it should take 125ms to transfer 8 bytes (or 22 bytes for extend-length commands) at 19.2K, baud but figured there must be some slow handshaking required before data transmission. I know that the PLM has some buffer in it to hold commands. I wonder if that could have any impact.
palayman Posted March 4, 2019 Posted March 4, 2019 I don't see any slow handshaking (it does echo every command but it -"can be ignored") From the developers guide: IM RS232 Port Settings To communicate to an RS232 IM, set your PC’s COM port as follows: Setting Value Baud Rate 19,200 Data Bits 8 Parity N Stop Bits 1 Hardware Flow Control None Software Flow Control IM echoes bytes received from host The IM buffers IM Commands as it receives them, so you can send a complete IM Command without pause. To maintain compatibility with earlier IM versions, the IM will echo each byte that it receives (earlier versions of the IM used byte echoing for flow control). You can now ignore the byte echos, but in order to avoid overrunning the IM’s receive buffer, you must wait for the IM to send its response to your current IM Command before sending a new one. Note that there is a maximum time between IM Command bytes that you send to the IM. If you do not send the next expected byte of an IM Command within 240 milliseconds after sending the previous one, the IM will reset its message parser and you will have to resend the message from the beginning. You can disable this Deadman feature by setting a configuration bit (see Set IM Configuration255 below).
Brian H Posted March 4, 2019 Posted March 4, 2019 The photos in the FCC Database are the original designed main board with NO Pi Filter in the unregulated +12 volt supply. That I doubt ever got sold. My V1.0 2413S has that board in it but manual rework to add the coil, second capacitor and a fly wire to the solder side of the PCB. They are just hanging off of the PCB. The V2.4 has an new serial port daughter board. New RS232 Chip, TI MAX232EI with a better ESD rating and a suppressor network on the two serial line signals. No unused fuse position for sending power out the RS232 connector like the earlier one had. Since it was also in the 2412S that did send power out of the connector. From what I have read. The old 2442-222 HUB. Was converted to be used as a PLM in countries. Where the standard PLM did no work. Probably different electrical specification. The Ethernet daughter board board was swapped for a serial port daughter board from a PLM. I don't know if it had to have a different firmware in it. The present 2445-222 HUB is a single PCB. I don't think it could easily be changed to RS232.
Michel Kohanim Posted March 4, 2019 Posted March 4, 2019 Hello all, Thank you for all the experimentation and feedback. As I mentioned before, I have never seen HS nor do I think comparing ISY with HS running on a computer would even give us any useful information. ISY is based on a Real Time operating system. As such, everything is deterministic and based on a) priority of the task and b) whether or not there's a blocking event. Communications between task are handled through queues. So, the speed of reading/writing from/to the PLM is not really the question. The question is an atomic unit (we call it message handler) of: TX (send the command to the PLM) ACK (wait for the ACK from the PLM) SRX (wait for the response from the end device) This is an atomic operation that will block all other communications from ISY to the PLM. The reason this has to be done is because INSTEON is primitive and does not have message ids. Major effort is expended to make sure unsolicited messages that may arrive during this operation are NOT discarded and are handled properly. In its infinite wisdom - and in order to make communications more reliable - INSTEON sends the same message twice from all RF and dual band devices. So, the traffic from a sensor is: SRX SRX Which means that ISY would have to detect and discard duplicates. D2D events are handled asynchronously through the queues. This said, however, if a message handler has the serial port (waiting for an ack or srx), then the programs will wait for the message handler to complete (queue). And, of course, comparing a 2Ghz CPU with a 100MHz ISY is just meaningless. With kind regards, Michel
kclenden Posted March 5, 2019 Posted March 5, 2019 15 hours ago, Michel Kohanim said: This is an atomic operation that will block all other communications from ISY to the PLM. Michel - thanks for the explanation. I'm a little confused, though, based on log entries. In the log I posted, I see four [INST-TX-I1] in a row followed by an [INST-ACK], then another [INST-TX-I1] and finally the first [INST-SRX]. If the message handler is atomic shouldn't I see a sequence of [INST-TX-I1], [INST-ACK], and then [INST-SRX]? Or is the log just showing when an outgoing command has been queued by the ISY, and not when it is actually sent to the PLM?
Michel Kohanim Posted March 5, 2019 Posted March 5, 2019 @kclenden, My pleasure. I forgot to mention that, if ACK or SRX are not received within a defined period of time, ISY retries 3 times. The timeouts are configurable in the shell. With kind regards, Michel
simplextech Posted March 6, 2019 Author Posted March 6, 2019 Doing some more digging into this and at this point mostly for my own understanding of reading the information. I did add a couple variables to see program execution and timings. A question about timing, is there anyway to get higher precision than 1 second from logs? Let me know if I'm reading/understanding this. Devices: 47 FC 4F 1 - Open/Close Sensor 50 C9 CF 1 - Switch Deck.Lights-On - [ID 0003][Parent 0001] If '47.FC.4F-Opened' is switched On Then $Int_Start = 1 Set '50.C9.CF.1' Fast On $Int_End = 2 Else - No Actions - (To add one, press 'Action') Tue 03/05/2019 23:39:23 : [INST-SRX ] 02 50 47.FC.4F 00.00.01 CB 11 01 LTONRR (01) Tue 03/05/2019 23:39:23 : [Std-Group ] 47.FC.4F-->Group=1, Max Hops=3, Hops Left=2 Tue 03/05/2019 23:39:23 : [D2D EVENT ] Event [47 FC 4F 1] [DON] [1] uom=0 prec=-1 Tue 03/05/2019 23:39:23 : [ 47 FC 4F 1] DON 1 Tue 03/05/2019 23:39:23 : [D2D-CMP 0003] CTL [47 FC 4F 1] [DON] op=is --> true Tue 03/05/2019 23:39:23 : [INST-SRX ] 02 50 47.FC.4F 00.00.01 CF 11 01 LTONRR (01) Tue 03/05/2019 23:39:23 : [Std-Group ] 47.FC.4F-->Group=1, Max Hops=3, Hops Left=3 Tue 03/05/2019 23:39:23 : [INST-DUP ] Previous message ignored. Tue 03/05/2019 23:39:23 : [INST-SRX ] 02 50 47.FC.4F 4C.1B.8A 45 11 01 LTONRR (01) Tue 03/05/2019 23:39:23 : [Std-Cleanup ] 47.FC.4F-->ISY/PLM Group=1, Max Hops=1, Hops Left=1 Tue 03/05/2019 23:39:23 : [INST-DUP ] Previous message ignored. Tue 03/05/2019 23:39:24 : [INST-SRX ] 02 50 47.FC.4F 11.01.01 CF 06 00 (00) Tue 03/05/2019 23:39:24 : [Std-Group ] 47.FC.4F-->11.01.01, Max Hops=3, Hops Left=3 Tue 03/05/2019 23:39:24 : [INST-INFO ] Previous message ignored. Tue 03/05/2019 23:39:24 : [INST-TX-I1 ] 02 62 50 C9 CF 0F 12 00 Tue 03/05/2019 23:39:24 : [D2D EVENT ] Event [47 FC 4F 1] [ST] [255] uom=100 prec=0 Tue 03/05/2019 23:39:24 : [ 47 FC 4F 1] ST 255 (uom=100 prec=0) Tue 03/05/2019 23:39:24 : [INST-ACK ] 02 62 50.C9.CF 0F 12 00 06 LTON-F (00) Tue 03/05/2019 23:39:24 : [INST-SRX ] 02 50 47.FC.4F 11.01.01 CB 06 00 (00) Tue 03/05/2019 23:39:24 : [Std-Group ] 47.FC.4F-->11.01.01, Max Hops=3, Hops Left=2 Tue 03/05/2019 23:39:24 : [INST-INFO ] Previous message ignored. Tue 03/05/2019 23:39:25 : [INST-SRX ] 02 50 50.C9.CF 4C.1B.8A 2F 12 00 LTON-F (00) Tue 03/05/2019 23:39:25 : [Std-Direct Ack] 50.C9.CF-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Tue 03/05/2019 23:39:25 : [D2D EVENT ] Event [50 C9 CF 1] [ST] [255] uom=100 prec=0 Tue 03/05/2019 23:39:25 : [ 50 C9 CF 1] ST 255 (uom=100 prec=0) 23:39:23 - Insteon signal received and processing begins. 23:39:24 - This is where the program processing happens as validated by the variables. The Start/End variables both have this timestamp and the LTON-F is in this block as well. It also looks like there's still processing of duplicates or extra messages from the door sensor from the "Previous message ignored"? 23:39:25 - Here Another INST-SRX appears with the LTON-F and this block contains the D2D EVENT and the L1 entry of the ST 255 for the switch I tried with normal on and fast on just to see if there was any difference. There should not be since this is a switch and not a dimmer so there's no ramp rate. Just testing to check things. I'm still curious as to the timing of events and trying to understand if this is normal or not. Best case of the log shows a 1 second time frame from receipt of the open to action of switch being turned on. Worst case shows a 2 second period of time.
bpwwer Posted March 7, 2019 Posted March 7, 2019 As an experiment I set up a program to specific messages via a subscription and timestamp them with sub-second precision. I created a simple program on the ISY if switchlinc status is on then <do something> and I varied what <do something> was between setting device on level, querying a device and incrementing a variable. This is what I got Incrementing a variable 0.00 - switchlinc set to 255 0.01 - program running/true 0.02 - program idle/true 0.03 - variable set Querying an Insteon device status and incrementing variable 0.00 - switchlinc set to 255 0.01 - program running/true 0.01 - ISY busy 0.81 - ISY idle 0.81 - program idle/true 0.82 - variable incremented Setting Insteon device and incrementing variable 0.00 - switchlinc is at 255 0.01 - program is running/true 0.01 - ISY busy 0.41 - ISY idle 0.41 - program is idle/true 0.42 - variable set 0.72 - device status updated So assuming the ISY is sending out messages to subscribed clients as soon as it has them, which seems to be true as I'm not seeing anything to indicate they are batched up, this should provide a fairly good representation of how much time the ISY is spending in this flow. My conclusions: 1) There's minimal delay between when a condition happens and a program triggered on it starts execution. 2) Program execution overhead seems minimal based on how quickly a variable is incremented. Note that my times above are rounded to the millisecond and some of the timeframes are actually less than 1 millisecond. 3) It takes the ISY about 0.4 seconds to send a command to a device, maybe slightly less. For the query operation, where we need to send the command and then wait for actual data (vs. a ACK) it's about double which implies most of that time is Insteon device communication . It looks like, for my environment, I can expect it to take about 3/4 second between a trigger activation and using a program to control a device. This all seems normal based on my experience with the ISY and Insteon. In a private message @simplextech had data showing the time between ISY busy and ISY Idle was close to 2 seconds. Which also matches with the event log information posted. If I'm interpreting my logs correctly, the only thing the ISY should be doing between the busy and idle messages is sending the Insteon command to the device and waiting for the ACK back. What conditions would cause this operation to take 4x as long?
kclenden Posted March 8, 2019 Posted March 8, 2019 Based on the log entries I get for my motion sensor, your log looks normal. I do have two suggestions, however: Check the "Options" for your Open/Close Sensor. If there is a "Send Cleanup Message" then uncheck it. You will have to put the sensor into the set mode first. If you change to using state variables instead of integer variables, then their change of value will be shown in the log and you won't have to cross reference the Admin Console "variable" page. This would also allow you to use a single variable to mark different points in your program. Here are some comments specific to your log: On 3/6/2019 at 12:16 AM, simplextech said: Quote Tue 03/05/2019 23:39:23 : [INST-SRX ] 02 50 47.FC.4F 00.00.01 CB 11 01 LTONRR (01) Tue 03/05/2019 23:39:23 : [Std-Group ] 47.FC.4F-->Group=1, Max Hops=3, Hops Left=2 Tue 03/05/2019 23:39:23 : [D2D EVENT ] Event [47 FC 4F 1] [DON] [1] uom=0 prec=-1 Tue 03/05/2019 23:39:23 : [ 47 FC 4F 1] DON 1 This is the first message from the open/close sensor saying it has been switched on. It is a group message that would be received by any device registered in this specific scene. Tue 03/05/2019 23:39:23 : [D2D-CMP 0003] CTL [47 FC 4F 1] [DON] op=is --> true This is the ISY recognizing that open/close sensor switching ON is a trigger for a program Tue 03/05/2019 23:39:23 : [INST-SRX ] 02 50 47.FC.4F 00.00.01 CF 11 01 LTONRR (01) Tue 03/05/2019 23:39:23 : [Std-Group ] 47.FC.4F-->Group=1, Max Hops=3, Hops Left=3 Tue 03/05/2019 23:39:23 : [INST-DUP ] Previous message ignored. This is the second message from the open/close sensor saying it has been switched on. It is a group message that would be received by any device registered in this specific scene. It is my understanding that this second message is sent because the device is battery operated. Or was it RF only? In any case, powerline devices don't send their message twice. Also note that the ISY is ignoring this message because it received the first one. Tue 03/05/2019 23:39:23 : [INST-SRX ] 02 50 47.FC.4F 4C.1B.8A 45 11 01 LTONRR (01) Tue 03/05/2019 23:39:23 : [Std-Cleanup ] 47.FC.4F-->ISY/PLM Group=1, Max Hops=1, Hops Left=1 Tue 03/05/2019 23:39:23 : [INST-DUP ] Previous message ignored. This is the direct group cleanup message sent by the open/close sensor. Controllers will first send a group message meant for all devices in the group (scene). This is so that they can all start acting at the same time. Then the controller will send a direct message to each device in the scene. This is for reliability to make sure all devices received the message. In this case, the PLM is probably the only device in the scene with the open/close sensor. Note that the ISY is ignoring this message because it received the first group message. Tue 03/05/2019 23:39:24 : [INST-SRX ] 02 50 47.FC.4F 11.01.01 CF 06 00 (00) Tue 03/05/2019 23:39:24 : [Std-Group ] 47.FC.4F-->11.01.01, Max Hops=3, Hops Left=3 Tue 03/05/2019 23:39:24 : [INST-INFO ] Previous message ignored. I haven't found any documentation on the "06" command, so what I write next is my guess based on the "to address" and "flags" contained in the data as well as some testing. This appears to be a non-direct group cleanup message that essentially repeats the initial group command. With my MS II, if I uncheck "send cleanup message", the MS no longer sends this message. The ISY ignores this message because it received the first group message. Tue 03/05/2019 23:39:24 : [INST-TX-I1 ] 02 62 50 C9 CF 0F 12 00 This is the ISY loading the ON command for the switch into the PLM. Tue 03/05/2019 23:39:24 : [D2D EVENT ] Event [47 FC 4F 1] [ST] [255] uom=100 prec=0 Tue 03/05/2019 23:39:24 : [ 47 FC 4F 1] ST 255 (uom=100 prec=0) Tue 03/05/2019 23:39:24 : [INST-ACK ] 02 62 50.C9.CF 0F 12 00 06 LTON-F (00) This is the PLM telling the ISY that it received the ON command for the switch and will send it to the switch. Tue 03/05/2019 23:39:24 : [INST-SRX ] 02 50 47.FC.4F 11.01.01 CB 06 00 (00) Tue 03/05/2019 23:39:24 : [Std-Group ] 47.FC.4F-->11.01.01, Max Hops=3, Hops Left=2 Tue 03/05/2019 23:39:24 : [INST-INFO ] Previous message ignored. Same caveat as above about this being a guess. This appears to be a second non-direct group cleanup message that essentially repeats the initial group command. It's probably being sent a second time because this is a battery or RF device. With my MS II, if I uncheck "send cleanup message", the MS no longer sends this message. The ISY ignores this message because it received the first group message. Tue 03/05/2019 23:39:25 : [INST-SRX ] 02 50 50.C9.CF 4C.1B.8A 2F 12 00 LTON-F (00) Tue 03/05/2019 23:39:25 : [Std-Direct Ack] 50.C9.CF-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Tue 03/05/2019 23:39:25 : [D2D EVENT ] Event [50 C9 CF 1] [ST] [255] uom=100 prec=0 Tue 03/05/2019 23:39:25 : [ 50 C9 CF 1] ST 255 (uom=100 prec=0) This is the switch acknowledging the it has received and acted upon the ON command. If you are able to configure the Open/Close sensor so that it doesn't send the non-direct group cleanup messages, that should reduce unnecessary transmissions on the Insteon network which does two things. It keeps from wasting ISY time processing what are redundant messages, and it frees up the Insteon network so that the ON command can be sent to the switch.
simplextech Posted March 8, 2019 Author Posted March 8, 2019 5 minutes ago, kclenden said: If you are able to configure the Open/Close sensor so that it doesn't send the non-direct group cleanup messages, that should reduce unnecessary transmissions on the Insteon network which does two things. It keeps from wasting ISY time processing what are redundant messages, and it frees up the Insteon network so that the ON command can be sent to the switch. That I think would be very helpful in reducing unnecessary traffic. However with these open/close sensors there are no "Options" button or in the right-click menu. Nothing. However oddly 2 nodes are created for them. I have read that older O/C sensors have a jumper to enable On-Only functionality which would explain the two nodes. I have checked my sensors (All new 2843-222) they do not have any jumpers but they do still have the dry-contacts. I've also read that there "should" be software configuration ability with these for the On-Only functionality? If this exists that may explain the two nodes. But back to your topic of the clean-up message. There are no options that I have so I can't change that. I'm running 5.0.14 Beta.
kclenden Posted March 8, 2019 Posted March 8, 2019 4 hours ago, bpwwer said: What conditions would cause this operation to take 4x as long? You may not be comparing apples to apples. Simplextech is using a battery operated device that is configured as a controller. As a battery operated device, I think it send its messages twice. Also as a controller it sends a group message to the entire group. And then it sends an individual message to each group member. The affect of sending its messages twice, as well as sending two messages (group then individual) could account for the difference.
simplextech Posted March 8, 2019 Author Posted March 8, 2019 5 minutes ago, kclenden said: Simplextech is using a battery operated device that is configured as a controller. As a battery operated device, I think it send its messages twice. Also as a controller it sends a group message to the entire group. I haven't configured it as a controller unless just by nature of being a battery device it is a controller no matter what. I have tested the program with a scene and with a device and the results were the same. Direct linking the sensor as a controller in a scene is instant as is expected.
kclenden Posted March 8, 2019 Posted March 8, 2019 9 minutes ago, simplextech said: I haven't configured it as a controller unless just by nature of being a battery device it is a controller no matter what. I think by definition when you link the sensor to the ISY, you create a scene in which both the PLM and the Sensor are controllers. This allows the PLM to receive commands from the Sensor, and allows the Sensor to receive commands from the PLM. I could be wrong though.
kclenden Posted March 8, 2019 Posted March 8, 2019 19 minutes ago, simplextech said: But back to your topic of the clean-up message. There are no options that I have so I can't change that. I gotta say... these open/close sensors seem like real jerks! ?
simplextech Posted March 8, 2019 Author Posted March 8, 2019 1 minute ago, kclenden said: I think by definition when you link the sensor to the ISY, you create a scene in which both the PLM and the Sensor are controllers. This allows the PLM to receive commands from the Sensor, and allows the Sensor to receive commands from the PLM. I could be wrong though. I think you are correct but this would be an internal/hidden scene? I only wanted to clarify this was in a program not a "user created" scene
simplextech Posted March 8, 2019 Author Posted March 8, 2019 1 minute ago, kclenden said: I gotta say... these open/close sensors seem like real jerks! ? You're telling me! I was hopeful when I read about the jumpers on them so I immediately cracked one open only to be disappointed. I even just now opened one that's on my desk just to double check. If there is a software configurable option I really hope to get it someday soon... hey @Michel Kohanim do these 2843-222 support any options?
kclenden Posted March 8, 2019 Posted March 8, 2019 So looking at the Smarthome site, there is an owner's manual for version prior to 1.9 and a manual for 1.9 and later. Both contain this text: Default Mode In default mode, Open/Close Sensor will: • Turn on responders when it opens • Turn off responders when it closes This mode is ideal for garage doors, closets, sheds, etc. The 1.9 and later manual just stops there and never mentions any other mode. The pre 1.9 manual has the following sentence: If you require more flexible functionality, see Using Open/Close Sensor’s Multi-Scene Mode. I know it likely won't work, and please don't take offense, but I'm curious if you tried following the "Multi-Scene Mode" procedure anyway even though you have a later version? Using Open/Close Sensor’s Multi-Scene Mode In multi-scene mode, Open/Close Sensor will: • Activate scene 1 when it opens • Activate scene 2 when it closes This mode is ideal when you need more flexibility: • For rooms where you want lights left on after door is closed – simply don’t link any responders to scene 2 in this case • Turning lights on at full-bright when door is opened and dim when door is closed • Activating two independent scenes when door/window is opened as opposed to closed Linking in Multi-Scene Mode 1) Move Open/Close Sensor magnet away from main case, putting it in open state If Open/Close Sensor was closed, LED will blink once 2) Link desired responders for when Open/Close Sensor opens (scene 1). See Make Open/Close Sensor a Controller. Scene 1 will activate whenever Open/Close Sensor is opened. The Set button toggle sending ON between Scene 1 and Scene 2 when tapped (while Open/Close Sensor is opened). 3) Move Open/Close Sensor magnet close to main case, putting it in closed state Open/Close Sensor status LED will blink once 4) Link desired responders for when Open/Close Sensor opens (scene 2) Scene 2 will activate whenever Open/Close Sensor is closed. The Set button toggle sending ON between Scene 1 and Scene 2 when tapped (while Open/Close Sensor is opened). 5) Test that responders are working as expected by opening and closing your door or window Scene 1 will activate when door or window is opened and scene 2 will activate when closed Unlinking in Multi-Scene Mode 1) Move Open/Close Sensor magnet away from main case, putting it in open state If Open/Close Sensor was closed, LED will blink once 2) Unlink desired responders from scene 1. See Unlinking an Insteon Responder from Open/Close Sensor. Responders will no longer respond when Open/Close Sensor is opened or set button is tapped 3) Move Open/Close Sensor magnet close to main case, putting it in closed state Open/Close Sensor status LED will blink once 4) Unlink desired responders from scene 2 Responders will no longer respond when Open/Close Sensor is closed or set button is tapped 5) Test by opening and closing your door or window Responders will no longer respond when Open/Close Sensor is opened or closed
kclenden Posted March 8, 2019 Posted March 8, 2019 11 minutes ago, simplextech said: I think you are correct but this would be an internal/hidden scene? Definitely an internal scene that doesn't show up under scenes. Actually the "Insteon Whitepaper: The Details" doesn't even mention scenes. It only refers to groups. So I'm not sure who first decided to refer to linking multiple devices as a scene.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.