Merging insteon_plm and insteonlocal

teharris1 · July 18, 2018, 4:40pm

The underlying library for insteonlocal is no longer being developed. I have been working with some of those developers to bring hub support to the insteon_plm component. It is close to ready but based on that “merger” it would make sense to do one of two things:

Decommission insteonlocal component and make insteon_plm the only Insteon component
Decommission insteonlocal and rename insteon_plm to insteon.

Option 1 is easier and less change but option 2 may be better for the overall visibility of insteon as a component. What are other people’s thoughts? Keep in mind there is an old insteon component that was the predecessor to the insteonlocal. It was decommissioned a while ago due to issues with the approach they took.

DanO · August 9, 2018, 2:44am

When this is done, should the hub have the same device support as a PLM? I have a motion sensor that appears to not work with the current insteonlocal.

teharris1 · August 9, 2018, 1:31pm

Yes, it will. Currently the motion sensor is supported including the light sensor and the battery sensor.

teharris1 · August 20, 2018, 1:53pm

@balloob sorry to push this at you but I would really value your input here. I was hoping to get more input from the community but I need to make a decision soon.

I am at the point where I can push a PR that will allow the insteon_plm component to support the Insteon Hub too. This would be fully duplicative of the insteonlocal component but would add a lot of functionality to the Hub users and would mean a single component to support Insteon. The insteon_plm and insteonlocal names denote the Insteon Modem technology in use and reflect what other automation systems, like OpenHAB, have done.

The options that I see are:

Depreciate the insteon_plm and insteonlocal components and create one insteon component. That will be a breaking change for all Insteon users but would make it easier for future users to know how to activate Insteon technology.
Keep both insteon_plm and insteonlocal with the only difference between the two being the configuration.yaml settings to connect. This will be easier for the current users and for users coming from other technologies that take a similar approach but will lead to two components to maintain vs one.
Keep insteon_plm and depreciate insteonlocal since it is maintained and the other is not. This will disrupt half of the users and have one component but will be confusing to new users who may assume the Hub is not supported based on the name unless they dig further.

My preference is to bit the bullet and go with Option 1 but before I disrupted all Insteon users I am hoping to get some input.

balloob · August 20, 2018, 2:07pm

I’m fine with option 1.

paulster · August 21, 2018, 12:56am

I would go with option 1, but that’s because it won’t be too difficult for me to execute the change, and I would think that having a single supported platform ultimately benefits us as users since it makes your life easier.

robinson · August 21, 2018, 4:37am

I agree with option 1. I’m having trouble with the current insteonlocal component being quite buggy. Hopefully this new component will have solid performance.

camrun91 · August 21, 2018, 12:50pm

I have been testing it and the plm version is much more reliable with the hub.

teharris1 · August 21, 2018, 1:56pm

Thanks @camrun91.

I have posted the PR

teharris1 · August 27, 2018, 1:01am

This PR has been merged. The Hub and the PLM now support the same devices. This includes the following HA platforms:

Binary Sensor: Motion, leak, door, I/O LInc sensor, other on/off sensors
Sensor: Smokebridge, other variable sensors
Lights: Almost all dimmable devices including KeypadLinc (see below for limitations)
Switch: Almost all on/off switch devices including I/O Linc and On/Off outlets and Keypad Linc (see below for limitations)
Fan: FanLinc
Cover: Micro Open/Close (coming in 0.77 or 0.78)
Thermostat: (coming in 0.78)

Limitations:

KeypadLinc only follows the button lights it does not activate the button scene. This should be coming soon via automations however.
Mini Remote - Does not show as an HA entity. It is available via automation only.
Hub - It may disconnect from the Hub and require both HA and the Hub to be restarted

HA documentation is here (when it gets released):

A technical list of supported devices is here:

github.com

nugget/python-insteonplm/blob/master/insteonplm/devices/ipdb.py#L46


    X10OnOff,
    X10Dimmable,
    X10Sensor,
    X10AllUnitsOff,
    X10AllLightsOn,
    X10AllLightsOff,
)

# pylint: disable=line-too-long
# pylint: disable=too-few-public-methods

_LOGGER = logging.getLogger(__name__)


Product = collections.namedtuple(
    "Product", "cat subcat product_key description model deviceclass"
)


X10Product = collections.namedtuple("X10Product", "feature deviceclass")

Any device that does not have “None” as the last field shoudl work in HA (except thermostat and cover which work in the underlying library but not active in HA yet.)

Madelinot · August 29, 2018, 10:42am

This is a good idea, but will cause me some issues since I have both a Hub and a PLM connected in my setup. I will likely have to get rid of one or the other. Hummm…

teharris1 · November 11, 2018, 9:47pm

@Madelinot I have created a new thread regarding the feature to allow the Hub and PLM to coexist. This is a non-trivial development activity however there has been a second request for this feature. I would like to start a discussion as to what this should include.
Insteon PLM and Hub coexist