LeeG

Click Action, select Insteon in the left pulldown, select My Lighting/ISY Lighting Scene from the Set pulldown, select Query from the right pulldown. Click 'Add to Then' at bottom of screen.

I think I changed ISY Lighting to My Lighting long ago. Whatever is shown just below Network If Time is 3:00:00AM Then Set Scene 'My Lighting' Query Else - No Actions - (To add one, press 'Action') The Then content is created as any Set Scene would be. Select either the ISY Lighting or My Lighting Scene, whatever is in the device/Scene pulldown and select Query

The Insteon address may be on a sticker on the back just below the hardware level ex rev 2.1 xx.yy.zz The motion sensor is not added using Start Linking. If the address sticker is missing put the motion sensor into link mode with its Set button. Press the Set button on another device to create a Set button link between the two devices. Do a Show Device Links Table on the device that the motion sensor was Set button linked with. The motion sensor address would normally be the in the last active link record. Be sure to unlink the Set button link or Restore Device on the other device to get rid of the Set button link. Once the Insteon address is known use New INSTEON Device, enter Insteon address, Name of choice and Device Type to default Auto Discover. Be sure to put the motion sensor into linking mode before clicking Ok and insure the motion sensor is in RF range of a Dual Band device.

Something is very wrong. When a device is added to the ISY the Controller link from the device to the ISY PLM is established when the device has Controller capability. This has nothing to do with how the device may be added to Scenes, such as adding them only as Responders. I have never seen the ISY add a SwitchLinc without the Controller link. The only means to fix this is to Delete the device from the ISY and add it back. Before assigning to any Scenes do a Show Device Links Table and insure there is a link record that is E2 01 PLM Insteon Address xx xx xx Without this link the Device will not communicate state changes. EDIT: creating a Scene with the SwitchLinc as a Controller should not be necessary. If that Scene is ever accidently removed from the ISY state change will no longer be seen. The device should be Deleted and added back as described above

Depends on what type of device 13.1C.09 is. If this is a SwitchLinc the link database is not correct for a SwitchLinc. There must be a link record in the device link database that starts with E2 for the ISY to be aware of state changes. It gives the appearance the ISY thinks this is a Responder only device. What does the Admin Console show on line two on the right side, below the node name, for the device type and the firmware level? Also what ISY firmware is being used?

Either a problem with the link records in those three Switchlincs or the link records in the PLM for those three Switchlincs. This is assuming good communication between the PLM location and the SwitchLincs. Run a Show Device Links Table for one of the SwitchLincs that is not reporting state changes. When the display is complete click Compare. A right click on the Switchlinc node with a Restore Device will rebuild the device link database. If that does not resolve the problem it is likely a PLM link record problem. A Restore Modem (PLM) will rebuild the PLM link database.

That is the way it is done. Note that If Control is looking for an Off command from each device. It sounds like you want to know if a device is On or Off which is determined by If Status.

RCanuk There is a whole list of issues that can occur when two applications are managing the same set of devices. Change the ISY LED Backlight setting and save. Then change it back to what you want. The ISY keeps track of the values it has sent to a device and does not send them again unless they change.

northportphoneguy Your symptom does not sound like what is reported in this topic. When a simple Query gets the Status out of sync it is the result of using Trigger Reverse. This option reverses the commands the I/O Linc sends for a Sensor state change. When the Sensor turns On it sends an Off command, when the Sensor turns Off it sends an On command. The problem with using Trigger Reverse is it does NOT reverse the Query response. Query returns the True state of the Sensor, not the command reversed state. This situation has become more prevalent when Smarthome started shipping the garage kit with a NC magnetic switch rather than the combined NO/NC magnetic switch. The only good solution is to change the magnetic switch to NO and drop the use of Trigger Reverse.

Is there an ISY Finder on the ISY-26? If the router has not assigned an IP the ISY could have had a static IP which would not be found or of any use anyway.

I no longer think distance is related as the test I ran over the weekend had the devices on the same circuit as the PLM. Could be an RF message from a distant Access Point that took its time getting back through a series of devices before reaching the PLM. Also since multiple devices types show the same behavior it is more likely an issue with the Insteon Mesh network rather an any one particular device or device type. Some of the I/O Lincs (at least what I thought were I/O Lincs) in your trace reported Sensor Off as the normal state. These would not show any external symptom since a duplicate relay response that marks them Off would not change the reported Sensor state. For example, are 17.A4.9D and 15.BB.75 I/O Lincs. It looks like it from the query calls. The Sensors on these I/O Linc (?) show the Sensor as Off to begin with. I'm thinking about getting a new 2413 PLM to see if a later PLM firmware has any affect on this.

Glad the restore resolved the problem. That may be a sign the PLM is developing problems. If it continues to happen a new PLM would be in order.

Since you are running an early Beta I suggest moving to 4.0.2. You may have a defective PLM if a Restore Modem (PLM) did not fix the Scene Test issue. Once the ISY has been updated the devices that actually worked will no longer be falsely marked failed. You can run a Show PLM Links Table followed by a Count to see how many link records exist. The Show PLM Links Table can be difficult to get an accurate count as any Insteon traffic reaching the PLM during the Show PLM operation can produce a false high or low count.

I made the assumption the I/O Linc Sensor is On when the temperature reaches 20 degrees. If the Sensor remains On for the full 10 minutes an email is sent. If the Sensor turns Off before the Wait 10 minutes completes the Program is triggered due to the change in Status to Off. The If is now False so the Else runs taking no action. The next time the temperature reaches 20 degrees the Sensor turns On and the Wait 10 minutes starts again. If Status ‘IOLinc – Sensor’ is On Then Wait 10 minutes Notify Else

There are no independent tools for evaluating powerline issues. You can try unplugging/disconnecting everything on that circuit except the ToggleLinc and see if it operates correctly as the only thing on the circuit. The Air Gap switch can be used to remove power from devices on that circuit controlled by Insteon devices. If the ToggleLinc runs for a week or so without issues restore power to a few of the devices and see what happens. If the ToggleLinc is working correctly eventually you will identify what is causing the interference.

The PLM has lost its link database. The lights that physically turned On indicate those devices have the required Scene link record in their link database. The PLM should have sent a follow up command to every device in the Scene which requires an ACK. The only device for which this was done is 12.0C.BF. This device was marked failed because of a bug in an older ISY image. What does Help | About show for Firmware? What does Help | About show for UI? The PLM link database can be restored with a File | Restore Modem (PLM).

The Status changes in the event trace mean nothing unfortunately. There are no ACKs to a Scene On/Off. The ISY is marking the devices as they should theoretically be responding without any direct knowledge that the devices actually responded. Suggest running Scene Test which does get an ACK from every device in the Scene. The success or failure will be noted by device.

Kram When the device primary function will not work, toggle/paddle/button will not control the physical load, the device is hung up. It is either the device itself or something on the powerline is causing the device to hang. Replace the ToggleLinc. If the new one has the same issue look for something on the powerline generating interference. Look at what else is on the circuit, appliances, lighting (type), motors, etc.

Does the Toggle control the load when the switch cannot be controlled remotely.

I suggest looking at the forum category Variables. Lots of good information there. To the specific question, State Variables trigger Programs, Integer Variables do not.

The Program looks to be using Adjust Scene statements which do not turn the Responder On and Off. Button A is probably a Controller of a Scene with '20.F9.C8-Relay' as a Responder which is why the device turns On to begin with. Use a Set Scene alone Set Scene 'SceneRelay' On Wait 10 minutes Set Scene 'SceneRelay' Off or turn the device On/Off directly Set '20.F9.C8-Relay' 100% Wait 10 minutes Set '20.F9.C8-Relay Off If you want the Program to turn the Relay On and Off Button A should not be a Controller in the Scene

The trace is correct for button 5 On.

belias The situation is not limited to I/O Lincs. I ran 4 QueryAll tests and found several devices besides the I/O Lincs that have duplicate ACKs with Hops Left=0 . The PLM in use for my local tests is a 2413S at v.99 These are from the last trace you posted. 12.FA.3C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 13.32.2D-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 14.73.02-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 1F.C2.B7-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 17.A4.9D-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 14.37.A0-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

belias This is the same problem seen by another user. There are duplicate Relay ACKs being processed, the later one being received and processed after the ISY has moved on to the next Query Sensor. Since the duplicate Relay ACK looks like the Sensor response and the Relay Status is Off the Sensor is marked Off. This trace provided some additional information. Device 13.32.2D produced a duplicate Query Sensor response. The Sensor change for 12.FA.3C was the result of a duplicate Relay response as was the other user with the same symptom. This is the first Query Sensor response duplicate I have seen traced. The actual cause of these duplicate responses with Hops Left=0 (other responses are coming back with Hops Left=2) is not known. The working theory is the additional ACK is taking a different path back to the PLM, coming so late that the PLM does not realize it is a duplicate. Since this happened essentially on demand by running the QueryAll this morning, is it possible to move 12.FA.3C temporarily to the PLM plug point and run a few QueryAll requests to see if it is distance/location dependent or simply related to an I/O Linc. If this test can be done let me know and I will PM an email address of where to send the event trace files. Too much data to post all of that on the forum. The other user decided to suspend the 3AM Query. I have no solution at this point. What is the PLM firmware level? Tools | Diagnostics | PLM Info/Status

Need an Event Trace at LEVEL 3 to determine what is happening.