InsteonPLM and Linking Devices to PowerLinc V2 USB Modem Database

Try running insteon terminal as root using sudo. This will eliminate permission problems with the tty device. Also, I’d also call trackPort() before connecting to the database.

Might have found the problem.

According to a post I stumbled across on the Insteon website the 2414U is a PLC and not a PLM. The protocol differs from the PLM.

Apparently the 2414U is older than the 2413U. (That’s not confusing at all.)

If the 2414U is a PLC what is a recommended replacement? The 2413U or something else?

Thanks again for everyones input.

(Egg on Face)

1 Like

I use a 2413U

Ahhh - OK that makes sense. I forgot that PLC existed. Now I know why It was connecting to a /dev/ttyUSBx port.

I have a 2413S with a USB->Serial converter.

Depending on exactly what you want to do with Insteon, it seems that the perference is somewhat in this order:

  1. ISY device with Insteon support connected to OH via the ISY plugin (I’ve never used it but others report it makes managing your Insteon Devices nice, where you have to use Insteon-Terminal without some other 3rd party config like ISY).
  2. Insteon 2413U or S PLM connected to OH via the Insteon Plugin. This is good but not great. If you are OK with configuring devices with Insteon-Terminal and OK with some wireless sensors not really functioning (like hidden door sensors - we say they are supported, but they frequently miss events) then this is cool and inexpensive. This is what I use, I don’t mind Insteon Terminal and I use Zwave wireless sensors instead of Insteon.
  3. Insteon Hub connected to OH via Insteon Plugin. Same issue as above, except add a ton of lag. Don’t waste your time trying to use motion sensors in any situation where time is important. Also, you have to basically abandon the iOS/Android app for the hub as it changes devices but has no way to inform OH of these changes so item states and actual device states get out of sync. You can use the app for some device config/linking, but it isn’t very advanced and you end up having to use Insteon-Terminal for things anyway.

These is a 4th option, but I don’t know anyone who has tried: That is using the 2413 PLM with 3rd software called Python Insteon <–> MQTT Bridge:

This software basically takes all incoming messages from the Insteon PLM and puts them onto the MQTT bus and and messages sent to the MQTT bus and executes Insteon commends. You then connect OH items to the MQTT plugin. This is supposed to be super nice and allows device configuration (thereby no longer needing Insteon Terminal) and supports all of the devices that the Native OH plugin does. It may even support the wireless devices better than the native plugin. Its on my long term list of things to play with at some point. Just havne’t gotten that far yet.

1 Like

Rob N

Thanks for the input.

Hello Tom

The 2413U seems to be the less expensive route.

I’ve read the 2413U self-destructs every year or so.

Is this happening with the newer revisions of the 2413U?

Disappointing if true as the 2414u has been operational for approximately 12 years.

With the ISY wouldn’t a PLM still be required?

Can a switch be paired with both the 2413u and the 2414u?

I’m interested, while transitioning systems, on having a backup trigger for some of the exterior lights that come on at night.

Will provide and update once I get the new device installed.

Thanks again for your input.

I’ve had my PLM for 3 years and it hasn’t destructed yet, although I’ve read the same stuff and I’m always just waiting. It sucks, but isn’t the end of the world to go and replace a PLM.

Any insteon device can be paired with a number of devices (256 I think?) including your PLM and PLC. The only issue is that if you are basically using two systems to control a device one system is always going to be out of sync. This is kind of that I described as being an issue with the Hub where you can use both OH and the Hub’s phone app.

The way this works is this:
You cross link your dimmer with your PLM (making it both a controller and responder to the PLM and the PLM is both a controller and responder to the dimmer)

If you command the dimmer On via OH, OH sends the command from the PLM (since it is a controller of the dimmer), and since the dimmer is a responder to the PLM it will turn on and send an ACK.

In the above even if the dimmer is cross linked also with the PLC, the PLC will ignore the PLM’s message to the dimmer since it is not traffic intended for the PLC and it also ignores the ACK sent from the dimmer to the PLM for the same reason, so the PLC has no clue that the state of your dimmer has changed.

Also, if you command from your PLC, for the same reason illustrated above, OH will not know that you have changed the state of the dimmer.

From the other direction, if you manually operate the dimmer locally at the paddle, all devices that are linked as responders to the dimmer will learn that the dimmer was tuned on, so that direction works.

The basic problem is at the hardware level, insteon devices do not send messages to all responders about a change in state unless is it from a local paddle / button push.

There are, however, actually two ways that OH can learn the state of the device:

  1. What I just described above where the switch is operated manually and sends to all linked responders
  2. Every so often OH polls every device on our network to which it’s PLM is linked and asks for its state. If the state is different than the OH known state for that associated item it will update the item.

Note: These polls are very infrequent and cause issues. Know that the bandwidth of the Insteon bus is EXTREMELY limited. polling can take up much of this bandwidth. So the default poll is set to 5 minutes (in your insteon.cfg file 300000ms). So every device on your network is trying to be polled every 5 minutes by default. Many people with bigger networks turn this number down to once every 30 mins or 60 mins to reduce the impact to the bandwidth of the bus. I say all of this because many people trying to deal with the issues I described above want to just dramatically shorten this polling time to get both systems to sync up faster. I’d highly recommend against that.

If you have rules in openhab that get triggered by Insteon devices changing state, this out of sync issue can cause all kind of strange behavior where you’ll change a device state from your other system, but OH doesn’t know until the next poll some minutes later, then fires your rule creating a “Gremlins in your house” effect.

I definitely get the desire to have some transition time, I’d try to keep it as short as possible, because your system will be pretty unstable in the mean time.

On the ISY device, yes, the ISY still uses a PLM, its just basically a device between the PLM and OH that makes configuration much simpler, but of course at a price…

Hello Everyone

Ordered the 2413U on Wednesday, received Friday and installed tonight.

Success. Was able to turn lights on and off via Alexa and Hue Emulation.

That is once I remembered to change the IP address in hueemulation.config. I configured WiFi on the Pi using a different IP and removed the ethernet cable.

Thanks again for everyones input.

1 Like