Multiple battery-powered Insteon Mini Remotes linked to each other in ALDB?

I noticed in the ALDB for my ‘2342-242 1-button mini remote’ that it shows a Responder-link with my ‘2342-222 8-button mini remote’ on Group 1:

The ‘8-button mini remote’ also shows a Controller-link with the ‘1-button mini remote’ on Group 1:

I don’t recall actively creating this link so I guess it must have been automatically created, maybe while I was doing local-link programming?

I was under the impression that a battery powered remote is asleep most of the time and therefore can not be a responder. Is that a valid statement? Can anyone shed some light on how these links may have come into existence and whether or not they are needed / safe to remove?

Based on my experience with insteon, i would suggest that you may have accidentally linked two remotes together. this is pretty easy to do.

i say this mainly because it doesn’t really make sense for there to be a link to a remote as a responder, since there’s really no way for another device to control the remote - i.e., the remote itself can’t do anything like turn on or turn off. the exception to this is that every Insteon device typically gets set up with a responder link to the main system control device on group 0. This is standard and I can see that your remote device does have this link (don’t delete it).

A remote (like most Insteon devices) can be put into linking mode by simply pushing and holding its button for a while (about ten seconds). This can sometimes happen by accident, such as when you sit on a remote or something.

The likelihood of this happening can increase if you have curious or inexperienced users (guests or children) who like to experiment and push buttons and see what happens. Also, Insteon sort of encourages users to try things like push-and-hold operations since it also uses them for some useful operations (e.g. dimming).

1 Like

Sounds plausible. You think it’s safe to remove those links? They don’t seem to be causing any problems but I prefer to keep the ALDB clean so I can make sense of everything when troubleshooting.

short answer: yes, i think its safe.

a few possible approaches: you can delete just stuff you think is not needed or erroneous. or if you’re not sure, you can delete stuff and then check you have the correct essential links by using the “add default links” command provided by the integration. or, you can do a total factory reset of the device and then add the device back into HASS. the latter is the surest way to a “clean slate”. for better or worse, you’ll lose stuff you’ve previously setup like default brighness, ramp rates, etc.


the rest of what follows is a bit more of my own take on insteon/home-assistant (and sorry if it is a bit long-winded).

i have been gradually migrating my (rather large) insteon config from generally having a lot of insteon device<->device links to mostly having ONLY controller<->device links.

the two most common examples: a) a motion sensor or door sensor liinked to a light switch. b) two or more light switches that are “cross-linked” to each other to achieve a virtual n-way switch (e.g. at the top and bottom of a staircase or two ends of a hallway).

at first, it was not an easy decision to make this change. device<->device links in insteon tend to work well. they’re fast. they’re reliable. they fully support all the little bells and whistles built-in to insteon hardware - links encode brightness levels and ramp rates; linked devices support on, off, push-and-hold (to dim), double-click (for instant on/off). i liked insteon hardware look and feel and considered consistency of UX across my whole house to be of great importance.

some things that eventually caused me to change: it was also annoying to be able to control most things in my house thru Home Assistant (automations), but to have to jump through lots of extra hoops to configure insteon devices. for a while my house (at least the lighting and particularly the built-in wall switches) was 90+% insteon, but then insteon (essentially) died as a business i started using home-assistant and started introducing more variety of brands and protocols, i gradually became more comfortable with a “diverse” environment. i was nervous about my Insteon PLM being a single point of failure in my network plus not having any good backup/recovery process for the PLM config. even after removing non-PLM links, my insteon devices are still dependent on insteon PLM, but i feel it would at least be possible to replace the PLM if i had to.

finally, whereas for a while i had an inventory of spares of insteon devices and would do like-for-like replacement when devices failed, i’ve now switched to where i really don’t consider Insteon hardware “current” technology any longer and (except in rare circumstances) am not putting any more of it into my house/network.

all that said, i don’t particularly want to go around and rip out all my insteon stuff that still works, and i do want to make it interact as smoothly and cleanly with HASS and the rest of my gear.

another tangential thought on this topic: roughly a year ago when switching to Home Assistant, i had the idea that HASS would provide complete, high-quality support for all the capabilities of insteon. it looked like there was a solid integration, good support, (at that time) active development, and an active user community. since then, i’ve been somewhat disappointed. progress on the Insteon integration seems to have stopped. my bug reports and feature requests against the integration are getting closed, ignored, and/or marked as “won’t do”. the interface remains clunky and awkward with many conspicous bugs. what i consider “basic” foundational features (e.g., supporting insteon events like fast-on, fast-off, start-dim, start-brighten, etc.) are not implemented and look like they never will be. overall insteon support in HASS is not nearly as good as (for example) the platform i used previously (Indigo). then there is the obvious writing on the wall: other protocols like zigbee are soaring in popularity; nabu casa has joined the z-wave alliance; matter appears poised to dominate.

in retrospect i believe that many of the attributes that seemed like good ideas at the time Insteon was being designed (roughly 2000-2005) turn out not not a good fit with an architecture based on having a smart/powerful central controller (like a typical home with Home Assistant). device<->device links that get stored in NVM on the individual devices and in the PLM are an example of this. they require extraordinary measures to program and setup. they’re also incompatible with how more modern protocols (and HASS) tend to work.

so to summarize, my gradual realization that insteon will probably never really be a well-supported platform in home assistant has driven me to find ways to minimize my dependence it and to seek pathways to migration away while trying to continue to extract value from the insteon gear i already have installed in my walls.