-
Notifications
You must be signed in to change notification settings - Fork 130
Insteon Link Table Management
As discussed on the Insteon Linking and Scenes page, each Insteon device must maintain a list of all devices that it acts as a controller or responder to. This list is stored in non-volatile memory in what we call the Link Table Database. This database survives even when power is removed from the device, but it can be reset by resetting the device to factory settings as described on the troubleshooting page.
The process of reading a Device's entire Link Table Database can be rather time consuming depending on the number of links. In order to speed the process up, MisterHouse maintains a local cache of the Link Table Database for each device.
The devices notify MisterHouse when the Link Table Databases on the device may have changed. However, the devices do not announce what changes occurred and as a result, MisterHouse must completely abandon the local cache and rescan a device that appears to have changed.
One of the primary features of the Insteon support in MisterHouse is its ability to mange this Link Table Database for you. As a result, MisterHouse contains a number of functions for interacting with the Link Table Databases on your devices. The following is a brief description of some of the voice commands that can be used to manage the Device Link Table Databases. More detail can also be found in the Insteon module POD page.
The following commands may be available on a per device basis. Each of these commands can be found in MrHouse Home -> Browse Categories -> Insteon and then selecting the proper command from the device's drop down list.
Note that if your device is deaf, the following commands will be queued and will not run until the device wakes up. See Deaf Devices for a further explanation of this.
This command can be used to view a copy of the cahced Link Table Database. This will cause MH's archive of the device's link table to be printed in print.log. You can view the print.log by going to Statistics Logged Data -> View Print Log from the website.
Here's sample output from a scan links on a light switch, if you view the log file from the website, it will be displayed in a slightly different order:
Running: f kt island lt ma log links [Insteon::ALDB_i1] Link table for $f_kt_island_lt_ma health: good [Insteon::ALDB_i1] [0x0FF8] contlr(01) record to $f_kt_pantry_lt_ma (01), (d1:ff, d2:1f, d3:01) [Insteon::ALDB_i1] [0x0FF0] contlr(01) record to $f_kt_main_lt_ma (01), (d1:ff, d2:1f, d3:00) [Insteon::ALDB_i1] [0x0FE8] contlr(01) record to $PLM (01), (d1:ff, d2:1f, d3:00) [Insteon::ALDB_i1] [0x0FE0] rspndr(01) record to $f_kt_main_lt_ma (01): onlevel=100% and ramp=0.1s (d3:00) [Insteon::ALDB_i1] [0x0FD8] rspndr(01) record to $f_kt_pantry_lt_ma (01): onlevel=100% and ramp=0.1s (d3:00) [Insteon::ALDB_i1] [0x0FD0] rspndr(01) record to $PLM (16): onlevel=100% and ramp=0.1s (d3:00) [Insteon::ALDB_i1] [0x0FC8] rspndr(01) record to $PLM (17): onlevel=100% and ramp=0.1s (d3:00) [Insteon::ALDB_i1] [0x0FC0] rspndr(01) record to $PLM (20): onlevel=100% and ramp=0.1s (d3:00) [Insteon::ALDB_i1] [0x0FB8] is emptyEven without a detailed understanding you can figure out what this all means. The following briefly describes each entry in order:
- Controller entry used to control another insteon device.
- Controller entry used to control another insteon device.
- Controller entry used to notify MisterHouse when the device changes state. This is the entry that was created by the "link to interface" command.
- Responder entry used by this device to respond to command sent by another Insteon device.
- Responder entry used by this device to respond to command sent by another Insteon device.
- Responder entry used by this device to respond to a virtual PLM button.
- Responder entry used by this device to respond to a virtual PLM button.
- Responder entry used by this device to respond to a virtual PLM button.
This command tells MisterHouse to destroy its cached copy of a devices Link Table Database and to go and scan the device to recreate a new cache. You may want to use this if:
- You have just installed a new device
- You believe the above log links report is wrong
- MisterHouse tells you that its cache for this device is stale (previously we called this out-of-sync)
- You just factory reset the device
To check the progress watch the print.log by going to Statistics Logged Data -> View Print Log from the website. At the completion of Scan Links, MH will print out a report that looks similar to the Log Links report above.
This command will ensure that all controller/responder links for this scene are present on the relevant devices. If a link is missing, it will be added. Note, this command syncs a scene, not a device. Imagine the following links are defined in MisterHouse but not yet written to the devices:
- Controller -> Responder
- Device A -> Device B
- Device C -> Device A
So, if you have added a new scene, you want to run the "Sync Links" command on the controller device. If you are not sure what links need to be synced, you may want to run the batch command Sync All Links described below under the PLM Batch Commands.
The PLM has many of the same commands as individual devices. However, it also contains a number of Batch Commands that perform a specific task on all devices in your Insteon network. These Batch Commands are meant to make certain functions easier to perform.
These commands can be accessed by going to MrHouse Home -> Setup MrHouse -> Browse Categories -> Insteon and then selecting the appropriate command in the PLM's drop down list.
This command will perform the Scan Links command identified above, but will do so on all devices on your network regardless of the state of the cache. Generally, this function has been replaced by the smarter Scan Changed Link Tables command. However, you might perform this if you suspect that through some really odd fluke that MisterHouse has become very confused.
This may take a long time depending on the size of your network and the number of links and scenes that you have. You can monitor the progress in the print log by going to Statistics Logged Data -> View Print Log from the website. At the completion of the scan, you will just see a brief message that says "Scan All Links Complete." The individual device tables will not be logged to the print.log. If you wish to see them you need to do an individual Log Links command for each device as described above.
This routine is similar to the Device level Sync Links command described above. This routine will print a list of all of the links that MisterHouse would add to your devices should you run Sync All Links. This is helpful for checking to see what actions would take place before running Sync All Links. It can be used to double check your Scene definitions before they are pushed to the devices. The output will be sent to the print log, Statistics Logged Data -> View Print Log.
This routine will run the "Sync Links" command on all of your Insteon devices, effectively this ensures that all links defined in MisterHouse are properly written to the devices. To check what links will be added before actually adding them, use the (AUDIT) command above. Depending on the state of your network and the number of links to be added, this routine could take some time to complete, when this routine completes it will print a completion message to the print log.
This routine will print a list of links which MisterHouse thinks are unnecessary to the print log. None of these links will be removed by this process. But if you run "Delete Orphans" MisterHouse will remove these links. See the more detailed discussion below about "Delete Orphans."
This routine will delete all unnecessary links on all of your devices. A link is deemed unnecessary if it:
- Is not defined in MisterHouse; OR
- The corresponding responder/controller link does not exist
Orphaned links can be created by deleting / altering a Scene definition from MisterHouse or by removing a device from your network.
Orphaned links are not a major problem, but they can start to add up. Orphaned responder links don't really cause any problems. But orphaned controller links create unnecessary traffic on your network. This is because every time a device with an orphaned controller link changes state, it will try to notify a devices or multiple devices that don't exist. Since the device doesn't exist no acknowledgement will be received and the message will be retried 3 times before being dropped.
If you see bizarre links that you do not believe exist on your network as potential items for deletion, it is possible that an error occurred when scanning this link due to message corruption. (Generally less than 1% of messages). You should rescan this device before running delete orphans, otherwise MH may inadvertently delete a good link because it had the wrong understanding of its state.
--add
--add