Insteon Troubleshooting

The following is an unorganized list of some problems and solutions that commonly occur. Please feel free to add additional problem/solution statements.

Table of Contents UnAcknowledged Messages Finding a Missing Device ID How to Perform a Factory Reset Debugging PLMTerminal.pl Insteon and filters Troubleshooting - Links and Scenes Other Insteon Pages

UnAcknowledged Messages

Many Insteon devices, but specifically Motion Sensors, RemoteLincs and KeypadLincs, will signal when a message was not Acknowledged. As you recall, the Insteon protocol includes an Acknowledgment message that is sent by responders back to the original controller. If this acknowledgement message is not received if may signal that either the responder didn't hear the message or the acknowledgment from the responder was lost along the way.

When no acknowledgement is received, the device will signal this error by blinking rapidly for a few seconds shortly after issuing the command. If this is happening to you, check the following:

If this is an RF Only device, is there an Access Point or Dual Band device nearby?
If this is an RF Only device, is there some RF interference? See Insteon RFOnly devices for a discussion of this.
Is the controller or responder device on a different electrical phase than all of your other devices? See Insteon RFOnly devices for a discussion of what this means.
Does the device have a controller link to an incorrect device? You can check by scanning the link table of the device and running an audit of delete orphans.
Do you have some form of powerline interference occurring? See Insteon and Filters below.

Finding a Missing Device ID

Sometimes the little device ID stickers fall off of devices. Sometimes we fail to follow the suggestions in Insteon Installing Devices and we put the cover plate on before writing down the device ID. If this happens, don't despair. You can find the device ID by creating a manual link between the unknown device and a known device already in MH.

Generally, to create a manual link, you need to press and hold the set button of the unknown device for about 10 seconds. The device will usually flash or beep in some manner after the ten seconds. You can now let go of the set button.

Now on the known device, press and hold the set button for about ten seconds. Again, it will likely flash or beep once this step is complete. You can now release the set button.

The Unknown Device should now be a controller of the Known Device. Test it out to make sure by turning the Unknown Device on and off.

Now, from within MH go to 'MrHouse Home -> Browse Categories -> Insteon' and find the Known Device. Select the voice command 'scan link table' for the known device. Now go to the print log screen, from the MisterHouse home page click 'Statistics Logged Data' the print log should print to the right.

You may need to click 'refresh print log' a few times (depending on the number of links that exist on this device, this could take seconds to a minute or two), but after the scan completes you should see something like the following:

23/04/2014 12:58:33  [Insteon::AllLinkDatabase] [0x0FF8] rspndr(01) record to $PLM (16): onlevel=100% and ramp=0.1s (d3:00)
23/04/2014 12:58:33  [Insteon::AllLinkDatabase] [0x0FF0] contlr(01) record to $PLM, (d1:03, d2:00, d3:00)
23/04/2014 12:58:33  [Insteon::AllLinkDatabase] [0x0FE8] rspndr(01) record to $PLM (17): onlevel=100% and ramp=0.1s (d3:00)
23/04/2014 12:58:33  [Insteon::AllLinkDatabase] [0x0FE0] rspndr(01) record to AA.BB.CC (01): onlevel=100% and ramp=0.1s (d3:00)
23/04/2014 12:58:33  [Insteon::AllLinkDatabase] [0x0FD8] is empty
23/04/2014 12:58:33  [Insteon::AllLinkDatabase] [0x0FD0] is empty
23/04/2014 12:58:33  [Insteon::AllLinkDatabase] [0x0FC8] is empty
23/04/2014 12:58:33  [Insteon::AllLinkDatabase] Link table for $f_al_bath_lt_ma health: good

In this example, the device ID of my Unknown Device is AA.BB.CC. You can see that a responder link is reported in the 4th line down, that has this device ID. In your case, you are looking for a rspndr record to a device that lacks a variable name. If you have multiple records which lack a variable name, well then you have to either try and figure out the right one by testing each of the device IDs, or clean up your installation so you don't have these "orpahaned links."

Once you get the Unknown Device ID, you can remove the link we created either by using the "Delete Orphans" routines or by following the Unlink Device instructions found in the Device's User Manual.

How to Perform a Factory Reset

Generally, a factory reset is done by disabling power to the device, by unplugging it, removing the battery, or pulling the air gap for 10 seconds. Then simultaneously __restoring power__ to the device and __depressing the set button__ **at the same time**, __holding the set button in for 10 seconds__. Release the set button, and your device should power on. The intricacies of performing a factory reset on each type of device may vary, but the details are always spelled out in the instruction manual for the device. Insteon maintains a decent Repository of Insteon Product Manuals.

Debugging

If you have 2 PLMs, you can use the second one to monitor the traffic, using 'Smartenit Utility Suite' from SimpleHomeNet Utility Suite SHN_Utility_Suite.zip

PLMTerminal.pl

Add notes re use of Michael's script.

Insteon and filters

If you use Insteon, you should expect to deploy filters if you have high tech equipment plugged into your house's electrical system.

In my house, it was specifically:

UPSes / Surge protectors
Plasma TV

but you want to see the list in this pdf and you should at least put a filter in the PC you run mh on so that it doesn't mess with the signals going to and from the PLM that is likely plugged into the same circuit.

If you are affected, you'll want one of these: Smarthome 10 Amp filter or Smarthome 5 Amp filter

When mh starts, with insteon debugging on, you'll see:

[Insteon_Device] received status request report for $mbr_lamp1 with on-level: 0%, hops left: 2

A good way to check if you have signal propagation issues is to check for "hops left" smaller than 2. Ideally you should have all of them be 2. The more 1s and 0s you get, the more signal loss/noise you're likely to have. In my house, I went from several 1s and 0s to all 2s by putting 2 filters in the right place. Also, If you ever notice that you get half a second or a second delay between hitting a switch and the paired switch or lamplinc/appliancelinc responding, this is because Insteon had to retransmit a unacked command. If that happens while you had no other insteon traffic, you are very likely having signal loss, forcing the retransmits, and need to install one or more filters on that line (i.e. one of the devices that get turned off when you turn off the breaker serving the device you were trying to control). You will also find some hints in the X10 Signal Suckers page (although Insteon is more resistant to them as X10 is, so not everything applies to Insteon).

If there is one piece of advise you listen to after setting at least 2 Insteon Access Points to bridge your phases (I personally got 4 as part of 2 starter kits for better resending and reach), is that with Insteon, it is almost certain that you will need filters to prevent a few high tech devices from sucking up the DC signaling Insteon reaches from the line, making some devices hard to control otherwise, even with Insteon sending the command up to 3 times. To be more clear, if you deploy Insteon, you are almost guaranteed to need 2 to 4 filters (see section below, and read this pdf) **just like you absolutely want an X10 phase coupler if you use X10** (preferably an active amplifier like this 3 prong or this 4 prong). For starters, put your computer running mh behind a filter so that it doesn't mess with the PLM plugged into the same line :)

Troubleshooting - Links and Scenes

First, always be certain to set debug=insteon within your private ini file. Detailed logging will be output that should be posted to the main list when/if problems cannot be resolved.

Second, a "slight rant"... if you use a ramp rate in a scene to control a device, that device will continue to use that ramp rate until it is set by another scene. This means that if you want to use scenes to shift multiple lights en masse and then resume more traditional single light management (e.g., on/off), the last scene's ramp rate is remembered rather than the local ramp rate. At present, the only "work around" is to create a "mirror scene" that performs the same settings only with the desired "normal" ramp rate (e.g., 0.1 sec). It is likely that some method will be added to the existing Insteon_Link library so that scenes can be automatically "chained" (i.e., set on after that last ramp rate is complete for the first one). At best, this is an oversight; some would call it a bug.

It is helpful to understand that links are managed within both the controller's and responder's device memory. The insteon_item_commands module contains functions that allow the PLM's and devices' memory to be scanned and logged. Because scanning can take a notable time to complete, it is suggested that you use the "log links" function first. The following is an example from a KeypadLinc:

12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0FA0] controller(02) record to
$family_room_pedestal_light
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0FD8] controller(05) record to $plm
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0FF0] controller(02) record to $plm
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0F98] responder record to
$plm(83): onlevel=45% and ramp=540s
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0FE0] controller(04) record to $plm
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0FD0] controller(06) record to $plm
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0FF8] controller(01) record to $plm
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0F90] controller(05) record to
$living_room_lights
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0FB0] responder record to
$plm(82): onlevel=0% and ramp=19s
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0FC0] controller(08) record to $plm
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0FA8] controller(03) record to
$family_room_track_light
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0FC8] controller(07) record to $plm
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0FB8] controller(04) record to
$kitchen_swag_light
12/20/07 04:19:07 PM [Insteon_Device] $recessed_lights adlb [0x0FE8] controller(03) record to $plm

Note that the all of the buttons map as controllers to the plm. In addition, the device is also a responder to a couple of plm-controlled scenes (groups 82 and 83). Also, note that it is possible to set an on-level to 0% so that setting a scene/link to ON can actually result in a device dimming to a final state of off.

If you do not see a link entry that you expect, try running the "scan links" function and then looking at the log again. You will also need to review the links defined in the PLM to be certain that it contains the reciprocal pairing defined for device links.

If you experience a device failure (hopefully, this never happens) and you need to permanently remove a device from service, use the PLM "delete orphan links" function. You may also attempt to unlink a device unless the linked device has actually failed, then manual unlinking will not work.

Please read Getting Help in the Insteon Devices - Quirks and Hints