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:
- What I just described above where the switch is operated manually and sends to all linked responders
- 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…
