LeeG

A Query should not cause a change in Status unless the I/O Linc is using the Trigger Reverse option. This option reverses the On/Off commands issued by the I/O Linc Sensor but does not reverse the Query response. It makes the Sensor change state because Query returns the true status of the Sensor rather than the command reversed status. The Trigger Reverse option has been known to cause a garage door to move at the 3AM QueryAll because the Query response is opposite to the last command received from the Sensor.

If the Green LED is On and the ISY shows a Status of Sensor Off (assuming Trigger Reverse is not being used) the ISY Sensor status is not in sync with the I/O Linc. Run tools | Diagnostic | Event Viewer with LEVEL 3 selected. Open and close the garage door several times with the manual button in the garage and watch the Insteon traffic generated. Likely the traffic does not accurately reflect the change in I/O Linc Sensor state. Look at the Hops Left=x count. The smaller the hops left count and/or the hops left count changing across open/close cycles, or state changes being missed altogether indicates a comm issue with the I/O Linc location.

“Correct....then sensor is on when the door is closed. “ "The green lights are on when the garage doors open when they shouldn't. " Are these two results inaccurate. It was my understanding the I/O Linc Green LED is normally On when the door is closed. I understood from the post two back the Green LED was also On when the door was open. That indicates a wiring or magnetic switch problem. The state of the Green LED is key. It reflects the true On or Off status of the I/O Linc Sensor, independent of what has or has not been communicated to the ISY.

The Green LED being On when the door is open indicates a problem with magnetic switch or associated wiring. There is no Insteon communication involved.

vetter What does the Unsupported Device message display for the Cat/Subcat x.yy?

The thermostat enforces a spread between heat and cool set points. I don't think it will let the cool set point below the heat set point. In Auto mode it would be calling for heat and cool at the same time. It will not allow a conflicting definition.

A firmware level of v.00 for most devices means the Device Type was specified when adding the device to the ISY. Using the default Auto Discover for Device Type causes the ISY to query the device for the firmware level. It is best to use Auto Discover so that the device firmware is known. Various device features have been released as their firmware has evolved. Knowing the device firmware level can help in knowing if a device has a particular capability. The Simplehomenet/Smartenit devices do not always present a firmware level even when using Auto Discover. It is nothing to worry about for SHN devices.

I agree that Insteon is not the answer. There are devices that handle pulse detection but the frequency at which they happen cannot be processed by Insteon over a powerline.

Something like this - syntax is not exact but I think it conveys the idea If Status ‘Front Door†is On Then Send Notification ‘Front Door Opened’ Repeat every 5 minutes Send Notification ‘Front Door Open’ Else Send Notification ‘Front Door Closed’

A TriggerLinc can operate in two modes, under control of a single jumper on the PC board. With the jumper installed the Opened node receives On and Off commands as the magnet or external switch is cycled. With the jumper removed the Opened and Closed nodes alternate On commands as the magnet or external switch is cycled. In this mode the TriggerLinc does NOT send Off commands to either node. I suspect the TriggerLinc that sent an On command to the Closed node either has a lose jumper or the battery is low.

Vyrolan The reference to turning Secondary buttons Off with an On command is related to a Scene Responder. For years many devices could be sent a Scene On with 0% On Level and have the device turn Off. Secondary KeypadLinc buttons were the exception. The KeypadLinc firmware turned the Secondary button LED On regardless of the Responder On Level. Starting with v.40 firmware sending a Scene On to a Secondary KPL button with 0% On Level turns the button Off. This single change means it is not longer necessary to have special Programs and Scenes dedicated to setting certain KPL Secondary buttons Off. One of the examples discussed by the user was a FanLinc controlled from multiple KPLs. Within the same KPL it has been possible for Secondary button A turning On to turn Secondary buttons B,C, D Off. Works great when the Secondary buttons are controlling FanLinc Motor speed. The problem arises when more than one KPL is being used to control the FanLinc motor speed. KPL 1 button A turning On could not turn KPL 2 button B,C,D Off with a responder 0% On Level. It required triggering Programs on KPL button press with the Program issuing a Scene Off to control the other KPL Secondary buttons. With the v.40 KPL firmware all that is necessary is to set KPL 2 button B,C,D Responder On Level to 0%. All those special button driven Programs and Scenes for turning Secondary buttons Off go away. Insteon Direct commands cannot control KeypadLinc Secondary buttons. The Insteon Direct On/Off command does not have a place holder for button number making it impossible to indentify a Secondary button to control with the On/Off command.

If Control is checking actual inbound commands from a device. If Control triggers only when there is command flow from the device that matches the command. If Status is checking the device Status the ISY maintains for each node. If Status triggers only when Status changes but can be used in a compound If statement to check current Status when triggered by some other condition. If Control cannot check after the fact because it is looking at actual command flow from the device. A Program checking for If Control 'xxxx' is switched On triggers for each On command. Pressing a paddle On three times in a row will trigger the Program three times. If Status triggers the Program once as the Status changes only once.

dec3169 No way to get multiple PLMs on the same ISY. I have multiple ISY devices each with its own PLM which might be an option if the house could be divided into non-overlapping device allocations between the ISYs. There have been no rumors about a larger PLM in the works. The latest KeypadLinc firmware now allows an On command to turn Off Secondary KPL buttons which can eliminate the need for all the extra Programs and Scenes needed to get Secondary KPL button LEDs to respond as needed.

It does sound like comm issues with both the KeypadLinc button and the ISY (PLM) control having errors. Sometimes the quality of communication with a particular device can be evaluated by turning the device On and Off with the Admin Console while the Event Viewer is running at LEVEL 3. Look at the Hops Left=x value over several On/Off attempts. Ideally Hops Left=2 is the best possible value. Hops Left=0 is operating at the outer edge of reliability. A Hops Left=x number that varies across multiple On/Off requests indicates a comm problem. Mon 12/03/2012 03:33:23 PM : [std-Direct Nack] 20.29.E8-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 By tracing On/Off requests to the different devices a pattern may develop showing where comm is good and where there are problems allowing focus only on the problem areas. Link record problems can be found by running Show Device Links Table followed by a Compare. Any missing/mismatch entries (except on last End of List record) indicate the need for a Restore Device.

Either approach, Query or sending an Off command will change the Relay Status. Relay being On or Off does not say anything about whether door is open or closed if using Direct commands. Turning the Relay On moves the door. Could be moving it open, could be moving it closed. The I/O Linc Sensor state indicates door open/close status.

When the outside Scene devices operate correctly they are being controlled by the ISY PLM. When the KeypadLinc button is pressed the outside Scene devices are being controlled/commanded from the KeypadLinc. The Scene devices not turning On can be the result of a number of things 1 the KeypadLinc location/circuit does not have Insteon mesh network access to the outside devices. Coupling could be reason, noise, signal attenuation are all possible causes of Insteon network problems 2 The KeypadLinc or outside devices are missing the required link records. 3 The Responder On Levels for the outside devices are set to 0% On Level when the KeypadLinc button is the Controller

geogecko A Direct On command to the Relay always turns the Relay On. Sensor On, Sensor Off, independent of which Relay mode, Latching, Momentary A,B,C, it makes no difference, a Direct On always turns the Relay On. In any of the Momentary modes the I/O Linc automatically turns the Relay Off. The Relay is a Responder Only device which does NOT report the Relay state change to Off so the ISY shows the Relay as On (reflecting the last command issued) even though the Relay is Off most of the time. Except for changing the Relay Status displayed by the Admin Console (because it is the last command issued) the Direct Off command usually has no affect on the Relay because Momentary mode has already turned the Relay Off. The various On/Off command actions described in the I/O Linc Quick Start and User Guide are discussing what happens when the Relay is controlled with a Scene. Insteon devices always control other Insteon devices with a Scene so the I/O Linc doc does not mention what happens with Direct commands as devices cannot issue Direct device control commands. Of course HA applications can issue Direct commands through a PLM but that is the only way Direct device control commands are issued. Release 3.2.6 handles pre I2CS I/O Linc options correctly. I2CS I/O Lincs require a different command sequence to set the options which was implemented in 3.3.4 and later.

"Can you even have a Lamplinc be a responder to another Lamplinc?" Yes. A LampLinc is both a Controller (with manual On/Off buttons on side or load sensing) and a Responder. Add a small night light or wall wart to the LampLinc load. LEDs are not drawing enough current to keep the load sensing from turning the LampLinc Off.

At 08:24:41 PM device 14.2A.24 turned itself Off. This is likely load sensing turning the LampLinc Off since I doubt it is being reported as turning Off and someone is actually turning the LampLinc or its Load Off. What type of load is connected to the LampLinc?

Look at the ISY Log for entries that reflect the device turning On and Off. Based On the link records 14.1D.DD 13.C1.7A and ISY Scene number 19 can affect the device in addition to Direct commands from an ISY Program and perhaps an X10 message which was not discussed. Does the LampLinc have an X10 address assigned to it. It would not be uncommon for powerline noise to cause a device with an X10 address to react.

Run the Show PLM Links Table and Count I described above.

"How can my motion sensor (wireless) control a wired device (non-DB) by the button, and have nothing show up, but not control the device with motion? I don't understand that one at all." If the options are set for Dusk/Dawn only or there is a very large timeout value specified the Set button would generate a Motion message but motion detection would not. Actually the MS blinking only once when not in RF range is a good thing. It opens the possibility the PLM link database is full. Just had another user over the weekend that had new Motion Sensor and TriggerLincs not working because the PLM could not hold the new Responder link records. Run Tools | Diagnostics | Show PLM Links Table. When all the link records have been read the Count button is active which will produce a count of link records read. The Show PLM Links Table has to be run 3-4 times and produce that same link record count for the count to be believed. Any Insteon traffic reaching the PLM while the Show PLM is running will result in false high or low record counts. If the Show PLM and Count produces a count of 992 consistently the PLM link database is full.

You are absolutely correct that the ISY is not able to push data outbound. That is why the Admin Console does not see status changes nor does MobiLinc. Often this is the result of firewall/AV issues with Kaspersky and Avast but they tend to be absolute until the firewall/AV is configured to allow data from the ISY to its applications. The Icons I mentioned are on line two of the Admin Console screen, below the line with File, Link Management, Tools, etc. The last two Icons do not appear when the Admin Console has not been able to establish an IP connection with the ISY. The lack of this connection prevents the ISY from pushing state change information to the Admin Console.

Thanks for posting the results. Glad to hear things are working.

A single blink normally indicates the Motion Sensor is receiving an ACK from the PLM assuming that is the only device the Motion Sensor is linked to. Move the Motion Sensor far away from any DB device to confirm it blinks multiple times when not in RF range. If it is confirmed the firmware in these Motion Sensors does blink multiple times when no ACK is received there is conflicting results which are hard to explain. The Red LED blinks once which indicates the PLM received and ACKed the Motion On, yet nothing is presented to the ISY (I assume the Event Viewer shows messages from other devices but not from this specific Motion Sensor).