krkeegan / insteon-mngr

An Insteon management platform and python interface.

Abandoned

I started work on this and then Insteon abandoned me. Insteon stopped updating the Hub as new devices were released. As a result, the Hub was never able to fulfill my hopes of handling the device config. In addition, Insteon stopped allowing people to sign up for API keys, so very few people would even be able to use this software.

This is probably all of the best, as I found Insteon-MQTT, and its local control is not subject to cloud restrictions.

I am going to leave this code here for reference, but in an archived state since it will never be revived.

The Problem

The Insteon Hub can:

• control devices (on/off)
• manage device attributes (default on levels and ramp rates)
• link devices to hub scenes
• provide access through the Insteon Restful API

The Insteon Hub cannot:

• manage links between devices in your network!

Recently I have learned that Insteon has become very stingy with handing out API keys, with some users waiting weeks to months.

Others have also expressed a desire not to rely on a cloud based service for home automation because of potential security and privacy concerns as well as a lack of reliability of the cloud service.

The Goal

Initially, the goal was to create a simple interface for defining, scanning, and managing the links between the devices on your network. With the hope of using the Insteon API to enable home automation platforms such as Home Assistant https://github.com/balloob/home-assistant to add insteon support.

Now this project has expanded slightly to add support for local control of Insteon devices.

My hope is to keep this project tight and focused. The Insteon stack and protocol is a mess and would quickly engulf this project if I tried to add support for all Insteon features. Instead, I would like to add the minimal amount of support necessary to enable:

• device link management
• support for home-assistant or other home automation platforms

Status

A long way from being done. I have taken much of the code from other half-completed (or less) projects that I have started.

insteon-mngr's Issues

Set High Water Mark in ALDB

Add Delete Links

Start with device level then global

Auto Refresh Link View Page

Cleanup Javascript File

The organization is a mess, many of the functions are too complicated.

Control Device State

Add Constants File To Cleanup Code

ALDB Write Sequence Bind Address Might be Bad

I don't think this solution is good either, or is at least incomplete. Simultaneous queued sequences would still bind to the same address.

Bind needs to do something so that subsequent items see the address as taken

Add Link: Don't show already used responders

A responder can only have one link to a controller. Removing the used ones from the list would likely make things easier to understand

Add Tabs to Modem Page on Small Screen

Vertical responsive page doesn't really work for small screens.

Get rid of Functions classes

These are unnecessary I think we can move everything into the groups

User Interface - Manage Links

Track Device State

Adopt More Acceptable Logging; Display in Web Interface

Add Ability to Force ALDB Scan from Web

Show Group Number When Showing Responders on the Web Interface

On PLM Scan Re-Adopt the Link Keys

The PLM keys are not fixed and so may change on a scan.

Trigger Timeouts

I think we need to add a timeout to the triggers, and a failure callback when the timeout is hit.

Otherwise, the ALDB Sequence could stall

Add Address Class to Unify Address Functions

Should User Be Notified if no Responder Link exists on Modem for a Device

Or should this just be added automatically whenever it is discovered?
Should there be some button to force a re-initialization? Maybe just a rescan button?

Create a Base Scan_ALDB Sequence

Call the specific i1 or i2 sequences from that. Get rid of specialized calls everywhere else.

Hide Undefined and Unknown Links if Empty

Add Sync Links

Start with single device level then global level.

Some way to Clean Bad Links

Links that would otherwise not appear in the group links page such as:

• Controller links on a device for a group that DNE

Create Queue for ALDB Operations

I don't know if this could reuse the existing state_machine or not, or maybe all state_machine entries should be a queue?

But currently sending multiple aldb_Record deletes causes them all to try and run at the same time, which results in generally only one working.

In an ideal world, subsequent calls would skip the check_aldb_delta call and perhaps other things like the set_msb and such.

Individual ALDB and User Links Should Be Objects

Rather than passing a record location in the ALDB, we should return the actual object which itself has all the necessary methods

Add Ability to Delete Modem

Change Message Failure Callback to List

Likely need to make better use of message failure callbacks as well, at minimum look in aldb sequences, should be catching and sending to failure

Should Device/Group Link Status Be Viewable Everywhere

Does this add a lot of overhead in a big system?

Stage or Queue Check ALDB Delta Calls

When calling the check_aldb_delta function, call the success function immediately if the delta value has been checked recently

Also when calling the check_aldb_delta function, check to see if the scan function is already running, and then just append the success function onto that sequence.

On change of Hub attributes, need to restart hub connection

User Interface - Add/Delete Object

Better Flow for Device Handlers (Send, Rcvd, Functions)

Right now when creating an InsteonDevice the flow resembles

1. on init set to generic
2. init calls functions.initialize_device which creates the groups and at least adds the root as group 0x01
3. init also calls send_handler.intialize_device which runs a bunch of inits steps and calls Insteon_Device.update_device
4. update_device uses the dev_cat data to re-init the various handlers to their proper type

This seems circuitous. Some of this is needed, for example we need a generic send and rcvd handler to do a dev_cat query. But if we could condense this down, I am sure we would avoid some gnarly errors.

Check Manual Linking Entries and Hub App Entries

A few things to test:

• Do i2_modem_links still use group 0x00?
• What do device->modem links look like

Identify Duplicate Links

Some links such as unknown and undefined should be fine.

But duplicate modem links and possibly defined links are obscured