This is a rework of the Insteon binding adding some much needed improvements for OH3.
Apart from simplifying the user experience by retrieving all the configuration directly from the device when possible, and improving the way the Insteon things are configured in MainUI, here is an exhaustive list of the changes:
- Introduced device configuration automated determination
- Converted mode-based number items to string type with descriptive states
- Added number items uom support
- Added scenes and X10 device things
- Added distinct bridge things for supported Hub/PLM devices
- Added button event trigger channels
- Added device products configuration layer
- Added device link database support
- Added device cache storage
- Added device operating flags controls
- Added modem configuration flags controls
- Added related devices synchronization feature
- Added ability to link a device to the modem
- Improved console commands
- Improved discovery service
- Improved thing status
For more details, see the updated documentation.
It is important to note that this is a breaking change. This means that users that are currently using the official binding will be required to reconfigure their Insteon setup. However, that process should be much easier with the new improvements.
To install this beta version, you must first uninstall the official Insteon binding.
If you are deploying the jar file, you need to install the transport serial feature via the console:
- Prevent offline not responding thing status for battery-operated devices
- Fix siren device integration
- Latest release kar file: here
- Latest release jar file: here
- Source code: here
- Pull request: here
As so happens I’m in the process of recovering from a broken upgrade and a migration to a new Pi, so I’ll give your binding a spin tonight. What are the advantages of your binding over the official one, and what tests would you like to see run?
The binding improves the overall user experience taking advantage of what the latest OH framework has to offer, such as triggered events.
It also reduces the amount of configuration needed to control devices as it now downloads each device product data and link database to automatically determine the device type and the related devices/groups.
Optionally, the state of related devices can be synchronized based on their link databases when sending commands removing the need to use rules to accomplish that.
Ideally for this testing, you would disable/remove your old bridge/thing configuration and add a new bridge matching your modem type via MainUI preferrably. Once the modem database is downloaded, all your linked devices should be discovered automatically with the corresponding product name. For battery-operated devices, you would need to wake them up or wait until the next heartbeat for the actual product name to show in your inbox. You can also just directly add such device and it will be automatically updated the next time it is awake.
When adding a new thing, the associated device link database will get downloaded the first time within the poll interval cycle, or when it is awake (battery-operated). That information along other data points are cached to speed up the process on subsequent server restarts.
As far as testing channels, a lot of the underlying code has been updated. So far, I was able to test successfully with the below devices. I would need help in testing other modem types, devices and also larger setup if possible. I added some untested code to download the link database from older I1 devices using the older peek/poke method. If anyone has a Smartenit EZIO device to test with, that would be great.
- Insteon 2245-222 Hub (Bridge)
- Insteon 2456S3 ApplianceLinc
- Insteon 2475F FanLinc
- Insteon 2845-222 Hidden Door Sensor
- Insteon 2334-232 Keypad Dimmer 6-Button
- Insteon 2334-222 Keypad Dimmer 8-Button
- Insteon 2852-222 Leak Sensor
- Insteon 2843-222 Open/Close Sensor
- Insteon 2477D SwitchLinc Dimmer
@jeshab I have a few switches/dimmers, appliance/dimmer modules, keypads, motion detectors, and leak sensors. Some of them were configured through the Main UI and are being used in Rules. Will the new binding continue to use the old definitions or update them based on the modem/device databases?
If by old definitions, you are referring to the thing/item configuration, the new binding is not backward compatible as a lot of the channels have changed in name and also type.
However, the configuration with the new binding should be much easier as it is using modem/device databases to determine most of the configuration automatically.