matapan

Then the issue lies with how IOLinc's scene activation is reported in the Admin Console: - If I understand IOLinc's documentation correctly with respect to the multi-scene mode feature, when the contact is open, then one of the scenes is activated. When the contact is closed, the other scene is activated. Presumably, when one scene is activated, the other is not. - Only an ON state exists in the Admin Console when the IOLinc is set up to use multi-scene mode. There is no blank state or OFF state. Once the ON state is reported in the Admin Console, it persists, until such time that the ISY is restarted. Is this really the intended behavior? - If the first assumption regarding exclusive node states is correct, then the Admin Console would presumably report an ON for one node and a BLANK or OFF state for the other. Neither node would ever have the same state. So, the problem is really about how to get the Admin Console to correctly show which scene was activated in multi scene mode.

It's easy enough to test the range of the Powermids. I used a portable TV which was remote controlled as a means to test the responsiveness of a remote command sent from the second floor of my home to the basement. In my setup, it works reliably. It's easy enough to checkout your setup though.

I installed my first Triggerlinc in my network today. Two nodes appear in the Admin Console device tree when a Triggerlinc is added. Curiously, only the Open node seems to track state information for the device. The Closed node remains blank regardless of the device state. There is a passing reference to this behavior in this discussion here: viewtopic.php?f=25&t=7932&p=60477&hilit=triggerlinc+triggerlinc+node#p60477 Apparently, the jumper setting affects when the open and closed nodes are updated, using something called Group 1 and Group 2 commands. Trying this setting out, I noticed that removing the number to update both the Open and Closed nodes appears to be hardly useful. Only an On state is reported when the device is toggled, and the state information is persistent - when the device is not ON, the node state is not cleared. This results in the node state recorded for both nodes being ON all the time. On the face of it, this appears to be totally useless. What is the intended use for this setting, when the jumper is removed from the Triggerlinc? If you simply want to track states from a sensor attached, does one simply use the jumpered setting and the Open node for state information? I think this is the case, but before I make that assumption here, I thought I'd ask the question on this forum. The blurb about the Triggerlinc behavior and the jumper setting in the side discussion referenced is useful info. Can we add this to the appropriate Wiki page referencing the Triggerlinc?

Yes, RS-232 would be more reliable. However, there is no way to initiate communication to the ISY other than through its IR port or via REST interface.

Hi Someguy, I recently tried a setup similar to the one you are proposing. The RS232 capabilities your Redeye device might enable one to control the Redeye using ISY or any Insteon switch, provided you have the Networking module. To control ISY using the Redeye, one way to do it is to use an ISY-99IR/PRO, the controller with the built-in IR receiver, and set up your Redeye to send an IR command to the ISY's IR eye. I don't use a Redeye, but X-10 Powermids to send commands from different rooms of the house to the ISY's IR eye. This setup seems to work okay.

Has anyone seen the Communication Error dialog come up in the Admin Console when a Switchlinc is toggled manually at the device? I see this from time to time. I've replaced all the v.4.0 Switchlincs I had with the v35 firmware already. I have a mix of v.28, v24, and v5x Switchlincs now.

I am using a mix of X10 motion sensors, models MS-13a, 14a, and 16a. I am also using RR501 and TM751 tranceivers set to the same house code for receiving the signals from X10 wireless devices. (Using two for the range). Most of the sensors will generate a house code ON command, but the house code OFF command seems to be more intermittent. What is interesting is that a house code without a command is generated a lot. What is this? Is this normal? Some of the sensors will generate a house code OFF command immediately after the house code ON command is issued, regardless of how the countdown for the OFF command is configured. A few of the outdoor motion sensors will generate the dusk/dawn codes. Are these ON and OFF commands generated in place of the normal day ON and OFF commands? For example, if A10 is the device address of the motion sensor for day commands, then A11 is the address for the dusk/dawn commands. Are the A11 commands generated only when dusk/dawn is detected, or are both A10 and A11 commands generated? I tried it, and what's generated seems to be a mixed bag. Maybe taping the dusk dawn sensor is the way to go so only one device address is used all the time. Presumably, this forces one to use the dusk/dawn address all the time. Does this mean that the day address is available as a slot for another motion sensor? I'm mostly interested in what user's experiences have been, like oberkc's. I've read the manual for the sensors and know pretty much how they're configured, but the way the sensors are behaving operationally in the event log seems to deviate from what I initially expected. So I'm looking for a level set more than anything else. Also, is a MS10A also deployable as an X10 sensor? If so, how is the device address configured for this device? The documentation for this sensor seems to talk about a security system, which I don't have or use. Any way to specify the house code and address code? Or, is there a default one the unit uses? Thanks!

Does anyone on this forum employ X10 motion sensors for their lighting programming? When I deployed my first X10 motion sensor triggered timer lights, I discovered they didn't always work as expected; lights would turn on, but not turn off, or turn on after being turned off manually. In looking at the event logs for the motion sensor, I noticed the following behavior: - When motion was detected, the sensor LED would flicker, indicating a response to the motion. - The event log would sometimes, but not always register a device ON event. (e.g. A10 ON) - When the ON event is not registered, the device address shows up in the log (e.g. A10, no ON or OFF) - The OFF event doesn't always register. I tried this with a number of sensors, all with similar results. The RF transceiver is right next to the PLM, so there should be a good communication conduit. I swapped transceivers to see if that might have an effect. I didn't see any change with the swap. Do users of X10 wireless motion sensors use just the ON code and some type of countdown to determine occupancy? Are the transmission of device ID without the ON or OFF codes normal?

I've read with great interest what others on this forum have done interfacing with devices with serial ports using the network module. I'm about to try having ISY communicate with a device I have that has a serial port - in baby steps. Can someone point me to an online resource which can explain how to take a command to be sent to a serial port and convert the string to what I could send through a PC-based terminal emulation program? For example, I have the string taken from a specification: 0100232<1><2> where <1> is a 3 digit parameter, <2> is another 3 digit parameter, and CHK is the checksum After establishing the proper comm parameters between the PC serial port and device (say, 19200,n,8,1), what would I actually send from the terminal program? Sorry about the basic question, but most of the resources I've looked at so far don't really delve into this question.

Wow! Thank you LeeG! The Link Management | Advanced Options was set to Device Reported. Changing it to Automatic, then adding the device back to the network enabled me to successfully add the Morninglinc to a scene. Really appreciate your help!!!

After performing a number of factory resets, and moving the Morninglinc around, installing it next to the PLM, I decided to capture the logs, presented below. The first log is from the action of adding Morninglinc to the network. The second log is a capture of what happens when Morninglinc is added to a scene. Can anyone knowledgable about these traces tell me what is wrong here? Thanks. Morninglinc Device Add Log: Sat 01/28/2012 09:12:29 AM : [LNK-BGN ] 02 64 01 00 06 Sat 01/28/2012 09:12:42 AM : [LNK-STAT ] 02 53 M(01) gid=00 18.EF.7C 0F06 3A Sat 01/28/2012 09:12:42 AM : Linked: Linked 18.EF.7C.00 type=0F.06.3A Sat 01/28/2012 09:12:42 AM : [iNST-ACK ] 02 62 18.EF.7C 0F 28 0F 06 SET-MSB(0F) Sat 01/28/2012 09:12:42 AM : [iNST-SRX ] 02 50 18.EF.7C 13.22.2E 2B 28 0F SET-MSB(0F) Sat 01/28/2012 09:12:42 AM : [standard-Direct Ack][18.EF.7C-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sat 01/28/2012 09:12:42 AM : [iNST-ACK ] 02 62 18.EF.7C 0F 2B F8 06 PEEK (F8) Sat 01/28/2012 09:12:43 AM : [iNST-SRX ] 02 50 18.EF.7C 13.22.2E 27 2B A2 PEEK (A2) Sat 01/28/2012 09:12:43 AM : [standard-Direct Ack][18.EF.7C-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 Sat 01/28/2012 09:12:43 AM : [18 EF 7C 1 ] MorningLinc database accessible Sat 01/28/2012 09:12:43 AM : [18 EF 7C 1 ] Start : Adding device to ISY Sat 01/28/2012 09:12:43 AM : [18 EF 7C 1 ] Finish : Adding device to ISY was Successful Sat 01/28/2012 09:12:43 AM : [18 EF 7C 2 ] Start : Adding device to ISY Sat 01/28/2012 09:12:43 AM : [18 EF 7C 2 ] Finish : Adding device to ISY was Successful Sat 01/28/2012 09:12:43 AM : [All ] Writing 0 bytes to devices Sat 01/28/2012 09:12:43 AM : [LNK-BGN ] 02 64 01 00 06 Sat 01/28/2012 09:12:51 AM : ---- Initializing the linked devices ---- Sat 01/28/2012 09:12:51 AM : [18 EF 7C 1 ] Reading all links Sat 01/28/2012 09:12:51 AM : [LNK-END ] 02 65 06 : : Unexpected, ignored (65) Sat 01/28/2012 09:12:51 AM : [18 EF 7C 1 ] Using engine version i2 for '18.EF.7C-On' Sat 01/28/2012 09:12:52 AM : [iNST-ACK ] 02 62 18.EF.7C 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (00) Sat 01/28/2012 09:12:52 AM : [iNST-SRX ] 02 50 18.EF.7C 13.22.2E 2B 2F 00 (00) Sat 01/28/2012 09:12:52 AM : [standard-Direct Ack][18.EF.7C-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sat 01/28/2012 09:12:53 AM : [iNST-ERX ] 02 51 18 EF 7C 13 22 2E 11 2F 00 01 01 00 FF 01 A2 00 13 22 2E FF 00 00 00 Sat 01/28/2012 09:12:53 AM : [Extended-Direct][18.EF.7C-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Sat 01/28/2012 09:12:53 AM : [Ext. Msg. Handler] Unexpected Response (i.e. DB range): ignored Sat 01/28/2012 09:13:02 AM : [iNST-ACK ] 02 62 18.EF.7C 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (00) Sat 01/28/2012 09:13:02 AM : [iNST-SRX ] 02 50 18.EF.7C 13.22.2E 27 2F 00 (00) Sat 01/28/2012 09:13:02 AM : [standard-Direct Ack][18.EF.7C-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 Sat 01/28/2012 09:13:03 AM : [iNST-ERX ] 02 51 18 EF 7C 13 22 2E 11 2F 00 01 01 00 FF 01 A2 00 13 22 2E FF 00 00 00 Sat 01/28/2012 09:13:03 AM : [Extended-Direct][18.EF.7C-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Sat 01/28/2012 09:13:03 AM : [Ext. Msg. Handler] Unexpected Response (i.e. DB range): ignored Sat 01/28/2012 09:13:12 AM : [iNST-ACK ] 02 62 18.EF.7C 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (00) Sat 01/28/2012 09:13:12 AM : [iNST-SRX ] 02 50 18.EF.7C 13.22.2E 2B 2F 00 (00) Sat 01/28/2012 09:13:12 AM : [standard-Direct Ack][18.EF.7C-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sat 01/28/2012 09:13:12 AM : [iNST-ERX ] 02 51 18 EF 7C 13 22 2E 11 2F 00 01 01 00 FF 01 A2 00 13 22 2E FF 00 00 00 Sat 01/28/2012 09:13:12 AM : [Extended-Direct][18.EF.7C-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Sat 01/28/2012 09:13:12 AM : [Ext. Msg. Handler] Unexpected Response (i.e. DB range): ignored Sat 01/28/2012 09:13:17 AM : ---- All Linked Devices are now initialized ---- Sat 01/28/2012 09:13:17 AM : ---- Start: Generate Scenes from links ---- Sat 01/28/2012 09:13:20 AM : ---- End: Generate Scenes from links ---- Sat 01/28/2012 09:13:20 AM : ---- Initializing the linked devices ---- Sat 01/28/2012 09:13:20 AM : ---- All Linked Devices are now initialized ---- Sat 01/28/2012 09:13:20 AM : [All ] Writing 0 bytes to devices Sat 01/28/2012 09:13:20 AM : [All ] Writing 0 bytes to devices MorningLinc Add to Scene Log: Sat 01/28/2012 09:05:15 AM : [18.EF.7C-Off] Start : Adding to scene 'Garage Door Lock' Sat 01/28/2012 09:05:15 AM : [18.EF.7C-Off] Making 'Garage Door Lock' a Controller Sat 01/28/2012 09:05:15 AM : [MNG-LNK-RSP ] 02 6F 40 E2 3A 18 EF 7C 0F 06 3A 06 Sat 01/28/2012 09:05:15 AM : [18 EF 7C 2 ] Link 0 : 0FF8 [A23A13222EFF0001] Saving [A23A13222EFF0001] Sat 01/28/2012 09:05:15 AM : [18.EF.7C-Off] Finish : Adding to scene 'Garage Door Lock' was Successful Sat 01/28/2012 09:05:16 AM : [All ] Writing 8 bytes to devices Sat 01/28/2012 09:05:16 AM : [18 EF 7C 1 ] Using engine version i2 for '18.EF.7C-On' Sat 01/28/2012 09:05:16 AM : [18 EF 7C 1 ] Link 1 : 0FF0 [0000000000000000] Writing [00..............] Sat 01/28/2012 09:05:16 AM : [iNST-ACK ] 02 62 18.EF.7C 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 00 06 (00) Sat 01/28/2012 09:05:16 AM : [iNST-SRX ] 02 50 18.EF.7C 13.22.2E 2B 2F 00 (00) Sat 01/28/2012 09:05:16 AM : [standard-Direct Ack][18.EF.7C-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sat 01/28/2012 09:05:17 AM : [iNST-ERX ] 02 51 18 EF 7C 13 22 2E 11 2F 00 01 01 00 F7 01 00 00 00 00 00 00 00 00 00 Sat 01/28/2012 09:05:17 AM : [Extended-Direct][18.EF.7C-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Sat 01/28/2012 09:05:17 AM : [Ext. Msg. Handler] Unexpected Response (i.e. DB range): ignored Sat 01/28/2012 09:05:26 AM : [iNST-ACK ] 02 62 18.EF.7C 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 00 06 (00) Sat 01/28/2012 09:05:26 AM : [iNST-SRX ] 02 50 18.EF.7C 13.22.2E 2B 2F 00 (00) Sat 01/28/2012 09:05:26 AM : [standard-Direct Ack][18.EF.7C-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sat 01/28/2012 09:05:35 AM : [iNST-ACK ] 02 62 18.EF.7C 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 00 06 (00) Sat 01/28/2012 09:05:36 AM : [iNST-SRX ] 02 50 18.EF.7C 13.22.2E 2B 2F 00 (00) Sat 01/28/2012 09:05:36 AM : [standard-Direct Ack][18.EF.7C-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sat 01/28/2012 09:05:36 AM : [iNST-ERX ] 02 51 18 EF 7C 13 22 2E 11 2F 00 01 01 00 F7 01 00 00 00 00 00 00 00 00 00 Sat 01/28/2012 09:05:36 AM : [Extended-Direct][18.EF.7C-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 Sat 01/28/2012 09:05:36 AM : [Ext. Msg. Handler] Unexpected Response (i.e. DB range): ignored Sat 01/28/2012 09:05:40 AM : [18 EF 7C 1 ] Link 1 : 0FF0 [0000000000000000] *Failed Writing [00..............]

LeeG: Thanks for the reply. I am curious if the factory reset procedure supplied with the product is actually accurate, if it does not remove the linkage to the lock itself. What constitutes a reset? If the links are removed in the ISY's device discovery process, does this permanently prevent the device from being used with the controller? I am perplexed with the Morninglinc's behavior and its inability to be added to a scene. Would a device events trace help illuminate what is happening during the add to scene process?

LeeG: I'm not sure if what I am experiencing is a communication problem. I have no problem adding the device, nor do I have any problem toggling it as a device. The only time a communication error with the Morninglinc occurred is when I attempted to add the Morninglinc to a scene as a responder. Moving the Morninglinc closer to the PLM does not yield any different results. Same thing occurs: There's no problem adding the device, or toggling it as a device. Adding it to a scene causes the communication error to come up.

I have a Morninglinc with firmware v3A which I added a while ago. I could always lock and unlock the device by toggling the On Off state in the Admin Console. Having read the posting related to the purpose of the two nodes created for Morninglinc, I decided to create a new scene and add the Morninglinc device to the scene. During this operation of adding the device to the scene, the Admin Console will return a Communication Error. Both Morninglinc device nodes now have a red exclamation mark on their icons. The selected Morninglinc device node also appears in the scene, with the red exclamation mark. Yet, I can still toggle the device and lock/unlock the lock with no apparent problem. I believe I added the device following the procedure outlined in the Wiki, but there might be a possibility I added the device and removed existing links. I reset the device using the procedure outlined in the Morninglinc user guide. However, I'm not certain if the factory reset procedure actually worked - I was able to press the set button after the reset to toggle the lock still. Is this by design, or have I failed to factory reset the unit properly?

Have you tried deleting the dual band Keypadlinc from the My Lighting list, then adding it back after the ISY firmware upgrade?

What is the error reported in the log?

Would assigning X10 commands to the individual Keypadlinc buttons directly solve the problem?

I tried using scenes for button grouping today. The intent was to set up a group where only one button in the group could be on at a time. The scene I created works, except for the fact that the button that is ON can be toggled off, creating the state where all of the buttons in the scene are off. What can I do to ensure one button in the group is always on?

I have a simple program which sends a X10 command when a Keypadlinc button is turned ON: If Status 'KPL A' is On Then Send X10 'A1/On (3)' Else - No Actions - When executed and the Keypadlinc button is turned on, the X10 device that is supposed to respond to the program does not respond. I tried running the Then path of the program manually. This worked just fine. Next, I tried adding delays in the program: If Status 'KPL A' is On Then Wait 2 seconds Send X10 'A1/On (3)' Else - No Actions - This worked, but the delay makes the program unusable in its context. Sending multiple commands seemed to be the only workaround so far: If Status 'KPL A' is On Then Send X10 'A1/On (3)' Send X10 'A1/On (3)' Else - No Actions - Question: Is there a better way to implement this and eliminate the delay or duplicate command? Presumably, this is an artifact of some power line signal collision that is occurring. The event log trace shows the X10 command clearly being transmitted.

Would it be helpful to adjust the timeout period for different periods of the day as a means to account for the amount of activity that may occcur in the home when someone is present? The best example of this is late night, when everyone is sleeping, vs. early morning or early evening, when there might be more activity, where a shorter timeout might be in order.

I second LeeG's suggestion for a programmatic check. If ISY will evolve into a more mainstream consumer oriented device, such checks are particularly useful in reducing the number of calls or posts generated.

I'm using the latest version of the motion sensor now. Three of them. Has anyone experienced any erratic behavior of the motion sensor under very low voltage, real world conditions, or does the unit simply stop working when the battery goes flat? I would prefer having the sensor not send any ON/OFF commands randomly when the battery goes low, instead simply stop sending ON/OFF commands altogether when the device cannot run correctly with the voltage available.

Would it be useful to put a validation check at startup of the Admin Console so the correct version of the AC is run with the correct firmware version? If the AC and ISY firmware versions don't match, return an error showing the firmware version on the ISY and the AC version being run. A reminder to clear your Java cache if you are have loaded an AC version that doesn't match the ISY firmware version might also be useful, if clearing the cache under the circumstances is important.

I recently started to think about the states in which the Admin Console loses its subscription to the ISY device and stops presenting device and program state information. In version 3.1.16, I've distilled down several scenarios and their actual outcomes below: Sleep Level Low - user walks away from computer and screen power save is initiated while Admin Console is session is open. Actual Outcome Upon return, user is prompted to log in to Admin Console (expected result) Moderate/High - laptop clamshell is closed, putting machine in moderate powersave state, or machine is explicitly placed in hibernation while Admin Console is running. Actual Outcome Upon return, user is not prompted to login to Admin Console. State information presented is no longer valid, or is missing. Resolution: Closing the browser completely, and restarting the Admin Console resolves the issue. Is there a way to handle the moderate/high use case described above in a similar manner that the low sleep state use case is handled now? This would be ideal - I'd prefer not to restart the browser if at all possible. I was wondering if this behavior with how the subscription is handled might have some relevance to some of the sync issues I'm experiencing with Mobilinc Pro currently.

LeeG: The Start Linking command was used, to confirm. My understanding is that if the Keypad load button is pressed for 10 seconds, it's supposed to go into linking mode, at which point, the KPD identifies itself to ISY. Isn't that the way it works? I know it does for my other devices, like Switchlincs. I'll try manually adding the device using the auto discover device type setting the next time I'm around the device. Thanks!