This binding provides access to the Insteon network by means of either an Insteon PowerLinc Modem (PLM), a legacy Insteon Hub 2242-222 or the current 2245-222 Insteon Hub.
The modem can be connected to the openHAB server either via a serial port (Model 2413S) or a USB port (Model 2413U.
The Insteon PowerLinc Controller (Model 2414U) is not supported since it is a PLC not a PLM.
The modem can also be connected via TCP (such as ser2net.
The binding translates openHAB commands into Insteon messages and sends them on the Insteon network.
Relevant messages from the Insteon network (like notifications about switches being toggled) are picked up by the modem and converted to openHAB status updates by the binding.
The binding also supports sending and receiving of legacy X10 messages.
The openHAB binding supports minimal configuration of devices, currently only monitoring and sending messages.
For all other configuration and set up of devices, link the devices manually via the set buttons, or use the free [Insteon Terminal](https://github.com/pfrommerd/insteon-terminal) software.
The free HouseLinc software from Insteon can also be used for configuration, but it wipes the modem link database clean on its initial use, requiring to re-link the modem to all devices.
The Insteon PLM or hub is configured with the following parameters:
| Parameter | Default | Required | Description |
|----------|---------:|--------:|-------------|
| port | | Yes | **Examples:**<br>- PLM on Linux: `/dev/ttyS0` or `/dev/ttyUSB0`<br>- Smartenit ZBPLM on Linux: `/dev/ttyUSB0,baudRate=115200`<br>- PLM on Windows: `COM1`<br>- Current hub (2245-222) at 192.168.1.100 on port 25105, with a poll interval of 1000 ms (1 second): `/hub2/my_user_name:my_password@192.168.1.100:25105,poll_time=1000`<br>- Legacy hub (2242-222) at 192.168.1.100 on port 9761:`/hub/192.168.1.100:9761`<br>- Networked PLM using ser2net at 192.168.1.100 on port 9761:`/tcp/192.168.1.100:9761` |
| devicePollIntervalSeconds | 300 | No | Poll interval of devices in seconds. Poll too often and you will overload the insteon network, leading to sluggish or no response when trying to send messages to devices. The default poll interval of 300 seconds has been tested and found to be a good compromise in a configuration of about 110 switches/dimmers. |
| additionalDevices | | No | File with additional device types. The syntax of the file is identical to the `device_types.xml` file in the source tree. Please remember to post successfully added device types to the openhab group so the developers can include them into the `device_types.xml` file! |
| additionalFeatures | | No | File with additional feature templates, like in the `device_features.xml` file in the source tree. |
The Insteon device is configured with the following required parameters:
| Parameter | Description |
|----------|-------------|
|address|Insteon or X10 address of the device. Insteon device addresses are in the format 'xx.xx.xx', and can be found on the device. X10 device address are in the format 'x.y' and are typically configured on the device.|
|productKey|Insteon binding product key that is used to identy the device. Every Insteon device type is uniquely identified by its Insteon product key, typically a six digit hex number. For some of the older device types (in particular the SwitchLinc switches and dimmers), Insteon does not give a product key, so an arbitrary fake one of the format Fxx.xx.xx (or Xxx.xx.xx for X10 devices) is assigned by the binding.|
|deviceConfig|Optional JSON object with device specific configuration. The JSON object will contain one or more key/value pairs. The key is a parameter for the device and the type of the value will vary.|
The following is a list of the product keys and associated devices.
These have been tested and should work out of the box:
How do Insteon devices tell other devices on the network that their state has changed? They send out a broadcast message, labeled with a specific _group_ number.
All devices (called _responders_) that are configured to listen to this message will then go into a pre-defined state.
For instance when light switch A is switched to "ON", it will send out a message to group #1, and all responders will react to it, e.g they may go into the "ON" position as well.
Since more than one device can participate, the sending out of the broadcast message and the subsequent state change of the responders is referred to as "triggering a scene".
At the device and PLM level, the concept of a "scene" does not exist, so you will find it notably absent in the binding code and this document.
A scene is strictly a higher level concept, introduced to shield the user from the details of how the communication is implemented.
Many Insteon devices send out messages on different group numbers, depending on what happens to them.
A leak sensor may send out a message on group #1 when dry, and on group #2 when wet.
The default group used for e.g. linking two light switches is usually group #1.
## Insteon Binding Process
Before Insteon devices communicate with one another, they must be linked.
During the linking process, one of the devices will be the "Controller", the other the "Responder" (see e.g. the [SwitchLinc Instructions](https://www.insteon.com/pdf/2477S.pdf)).
The responder listens to messages from the controller, and reacts to them.
Note that except for the case of a motion detector (which is just a controller to the modem), the modem controls the device (e.g. send on/off messages to it), and the device controls the modem (so the modem learns about the switch being toggled.
For this reason, most devices and in particular switches/dimmers should be linked twice, with one taking the role of controller during the first linking, and the other acting as controller during the second linking process.
To do so, first press and hold the "Set" button on the modem until the light starts blinking.
Then press and hold the "Set" button on the remote device,
e.g. the light switch, until it double beeps (the light on the modem should go off as well.
Now do exactly the reverse: press and hold the "Set" button on the remote device until its light starts blinking, then press and hold the "Set" button on the modem until it double beeps, and the light of the remote device (switch) goes off.
For some of the more sophisticated devices the complete linking process can no longer be done with the set buttons, but requires software like [Insteon Terminal](https://github.com/pfrommerd/insteon-terminal).
## Insteon Features
Since Insteon devices can have multiple features (for instance a switchable relay and a contact sensor) under a single Insteon address, an openHAB item is not bound to a device, but to a given feature of a device.
For example, the following lines would create two Number items referring to the same thermostat device, but to different features of it:
The battery, light level and temperature level are updated when either there is motion, light level above/below threshold, tamper switch activated, or the sensor battery runs low.
This is accomplished by querying the device for the data.
The motion sensor II will also periodically send data if the alternate heartbeat is enabled on the device.
If the alternate heartbeat is enabled, the device can be configured to not query the device and rely on the data from the alternate heartbeat.
Disabling the querying of the device should provide more accurate battery data since it appears to fluctuate with queries of the device.
This can be configured with the device configuration parameter of the device.
The key in the JSON object is `heartbeatOnly` and the value is a boolean:
Since the motion sensor II might not be calibrated correctly, the values `20.53` and `24.61` can be adjusted as necessary to produce the correct temperature.
### Hidden Door Sensors
Similar in operation to the motion sensor above.
Link such that the modem is a responder to the motion sensor.
Create a contact.map file in the transforms directory like the following:
To control the relay, link the modem as a controller using the set buttons as described in the instructions.
To get the status of the contact, the modem must also be linked as a responder to the I/O Linc.
The I/O Linc has a feature to invert the contact or match the contact when it sends commands to any linked responders.
This is based on the status of the contact when it is linked, and was intended for controlling other devices with the contact.
The binding expects the contact to be inverted to work properly.
Ensure the contact is OFF (status LED is dark/garage door open) when linking the modem as a responder to the I/O Linc in order for it to function properly.
For safety reasons, only close the garage door if you have visual contact to make sure there is no obstruction! The use of automated rules for closing garage doors is dangerous.
> NOTE: If the I/O Linc contact status appears delayed, or returns the wrong value when the sensor changes states, the contact was likely ON (status LED lit) when the modem was linked as a responder.
Examples of this behavior would include: The status remaining CLOSED for up to 3 minutes after the door is opened, or the status remains OPEN for up to three minutes after the garage is opened and immediately closed again.
To resolve this behavior the I/O Linc will need to be unlinked and then re-linked to the modem with the contact OFF (stats LED off).
That would be with the door open when using the Insteon garage kit.
Before you attempt to configure the keypads, please familiarize yourself with the concept of an Insteon group.
The Insteon keypad devices typically control one main load and have a number of buttons that will send out group broadcast messages to trigger a scene.
If you just want to use the main load switch within openHAB just link modem and device with the set buttons as usual, no complicated linking is necessary.
But if you want to get the buttons to work, read on.
Each button will send out a message for a different, predefined group.
Complicating matters further, the button numbering used internally by the device must be mapped to whatever labels are printed on the physical buttons of the device.
Here is an example correspondence table:
| Group | Button Number | 2487S Label |
|-------|---------------|-------------|
| 0x01 | 1 | (Load) |
| 0x03 | 3 | A |
| 0x04 | 4 | B |
| 0x05 | 5 | C |
| 0x06 | 6 | D |
When e.g. the "A" button is pressed (that's button #3 internally) a broadcast message will be sent out to all responders configured to listen to Insteon group #3.
This means you must configure the modem as a responder to group #3 (and #4, #5, #6) messages coming from your keypad.
You can even do that with the set buttons (see instructions that come with the keypad).
While capturing the messages that the buttons emit is pretty straight forward, controlling the buttons is another matter.
They cannot be simply toggled with a direct command to the device, but instead a broadcast message must be sent on a group number that the button has been programmed to listen to.
This means you need to pick a set of unused groups that is globally unique (if you have multiple keypads, each one of them has to use different groups), one group for each button.
The example configuration below uses groups 0xf3, 0xf4, 0xf5, and 0xf6.
Then link the buttons such that they respond to those groups, and link the modem as a controller for them (see [Insteon Terminal](https://github.com/pfrommerd/insteon-terminal) documentation.
In your items file you specify these groups with the "group=" parameters such that the binding knows what group number to put on the outgoing message.
The Insteon Terminal wiki describes in detail how to link the thermostat, and how to make it publish status update reports.
When all is set and done the modem must be configured as a controller to group 0 (not sure why), and a responder to groups 1-5 such that it picks up when the thermostat switches on/off heating and cooling etc, and it must be a responder to special group 0xEF to get status update reports when measured values (temperature) change.
Symmetrically, the thermostat must be a responder to group 0, and a controller for groups 1-5 and 0xEF.
The linking process is not difficult but needs some persistence.
Again, refer to the [Insteon Terminal](https://github.com/pfrommerd/insteon-terminal) documentation.
It is worth noting that both the Inseon PLM and the 2014 Hub can both command X10 devices over the powerline, and also set switch stats based on X10 signals received over the powerline.
This allows openHAB not only control X10 devices without the need for other hardwaare, but it can also have rules that react to incoming X10 powerline commands.
While you cannot bind the the X10 devices to the Insteon PLM/HUB, here are some examples for configuring X10 devices.
Be aware that most X10 switches/dimmers send no status updates, i.e. openHAB will not learn about switches that are toggled manually.
Further note that X10 devices are addressed with `houseCode.unitCode`, e.g. `A.2`.
Flipping this switch to "ON" will cause the modem to send a broadcast message with group=2, and all devices that are configured to respond to it should react.
Channels can also be configured using the device configuration parameter of the device.
The key in the JSON object is `broadcastGroups` and the value is an array of integers:
When an Insteon device changes its state because it is directly operated (for example by flipping a switch manually), it sends out a broadcast message to announce the state change, and the binding (if the PLM modem is properly linked as a responder) should update the corresponding openHAB items.
Other linked devices however may also change their state in response, but those devices will _not_ send out a broadcast message, and so openHAB will not learn about their state change until the next poll.
One common scenario is e.g. a switch in a 3-way configuration, with one switch controlling the load, and the other switch being linked as a controller.
In this scenario, the "related" keyword can be used to have the binding poll a related device whenever a state change occurs for another device.
A typical example would be two dimmers (A and B) in a 3-way configuration:
The implemenation of the _related_ keyword is simple: if you add it to a channel, and that channel changes its state, then the _related_ device will be polled to see if its state has updated.
Turn on DEBUG or TRACE logging for `org.openhab.binding.insteon.
See [logging in openHAB](https://www.openhab.org/docs/administration/logging.html) for more info.
### Device Permissions / Linux Device Locks
When openHAB is running as a non-root user (Linux/OSX) it is important to ensure it has write access not just to the PLM device, but to the os lock directory.
Finding the Insteon product key can be tricky since Insteon has not updated the product key table (<https://www.insteon.com/pdf/insteon_devcats_and_product_keys_20081008.pdf>) since 2008.
If you can't build a new device out of the existing device features (for a complete list see `device_features.xml`) you can add new features by specifying a file (let's call it `my_own_features.xml`) with the "additionalDevices" option in the network config parameters:
In the example below a new feature "MyFeature" is defined, which can then be referenced from the `device_types.xml` file (or from `my_own_devices.xml`):
Use the [Insteon Terminal](https://github.com/pfrommerd/insteon-terminal) for that.
If using Insteon Terminal (especially as root), ensure any stale lock files (For example, /var/lock/LCK..ttyUSB0) are removed before starting openHAB runtime.
- Using the Insteon Hub 2014 in conjunction with other applications (such as the InsteonApp) is not supported. Concretely, openHAB will not learn when a switch is flipped via the Insteon App until the next poll, which could take minutes.
