Guy Lavoie

I'm slowly picking up Python. I hate the lack of braces for framing code sections. Depending on white space for proper grouping is ugly and error prone.

Is there at least some kind of contact closure that you could detect when it's armed or tripped? Something like a 12 volt siren output could be useful to detect a tripped alarm, using a IOlinc for example.

Brings back memories of X10 days.

I don't see any such setting in the configuration screen or menus.

Oh yes, looking forward to the conclusion on this. Kind of surprised that you can get communications errors between the Polisy and the PLM. I'd venture that it's more about message timing or buffering than actual comms, since serial or USB ports aren't a collision domain.

Very interesting @IndyMike .The description of a PLM Reset would certainly explain a lot of odd problems. I'm here to learn too 🙂

That's the million dollar question. Two million dollars actually because you have two different PLMs doing this. It's almost as if there was a phantom "Delete PLM" going on, or it was being factory reset. Neither of which can be scheduled. Adding to the mystery is that you clearly say that outgoing commands keep working. Links need to be there for that too. Hopefully @IndyMike can tell us a bit more about what he sees in the event log as being relevent.

Yup, long posts are fine when they contain lots of information 🙂 One PLM entry per device actually sounds kind of low. You must have less Insteon scenes than many of us. The 100% consistency is a plus, yes! Aloows testing and troubleshooting. The next time you do a device restore, capture the device communications log, so that you can see what the messages that write to a device link table look like. This could help you in finding any unplanned writes that this problem seems to be doing. To be clear: please tell us if scheduled commands from the Polisy to devices are still working ok, even when this problem occurs. Your mention of: "The one exception to programs running properly during the fault, those that rely on a report of state of devices (switch positions, motions, etc.), the logic may fail as the state is not updated at the PLM/Polisy." seems to indicate that outgoing Polisy commands are working, as long as they don't rely on updated device statuses.

Yes, the "Show PLM Links Table" would be my next move. It can also be saved to a file, for analysis and comparison later.

@IndyMike Has it been established that the PLM link table is getting modified? All along my perception is that it's the device's link tables that were. It's true that a restore PLM writes to both devices and the PLM, if indeed whatever is causing the problem is updating links. Orest hasn't really indicated if scheduled commands going out from the Polisy to Insteon devices also stopped happening. The original post was mainly about wireless sensors and keypads seemingly not sending anything to the Polisy. @oskrypuch , could you tell us if sending out scheduled commands also fails? Just so we're all seeing the same thing.

What it does is write out it's saved configuration of that device's link table to the device. It's handy as a backup, but is also used with the device replacement function when replacing a bad device with a new one.

It's so unusual that I don't really have a going theory. But having a whole bunch of link device link tables getting modified, seemingly all in a short time period, can't be done by many different things. Another alternative could be to just disconnect the PLM from the Polisy, if it's also involved in doing non-Insteon things. In fact if you try this and it tries unsuccessfully to update devices overnight, maybe you'd get telltale error messages in a log file. Weird problems like this sometimes need to be tested by proceeding by elimination.

If it really does this over the 24 hours following a device restore and you suspect the Polisy, would you be willing to try device restores and then powering off the Polisy for 24 hours, as a test?

Yes, you could simply move your current Zwave dongle to a new eisy.

The r2 is still very new, less than a year old. There is a documented procedure for migrating from the Zooz dongle to the ZMatter dongle...but it doesn't work. Myself and others have not succeeded in doing it. However the Zooz dongle will also work with the eisy, so it's not mandatory that you upgrade to the ZMatter dongle unless you actually want the additional Zigbee functionality. It's also not clear if the ZMatter dongle is still available.

Weird that it apparently worked ok for a day. On a lark, I'd try plugging the PLM into a different electrical circuit. Use a long extension cord to have it connected to an outlet elsewhere that you know is working ok with your other devices. I'm just wondering if there is something on your existing circuit that could be killing the signals.

Tried it?

Happening with both heat pump and AC makes much more sense. Seems to point to the compressor. If the compressor runs on straight line power then you could try noise suppression tricks (ferrite cores, etc). If the compressor is variable speed and driven with electronics, then that could be a challenge. It would be easier to add filtering to the line powering the heat pump.

Another possibility could be a bad Insteon device transmitting noise or garbage. You might try turning off one breaker at a time and seeing if it stops the blinking.

Tried the same test with just AC? Heating with heatpump?

Have tried to go into the event log, level 3, and if there are Insteon signals being sent? I've had a similar thing happen with what appeared to be a feedback loop, possibly between the eisy and sone lights. The lights controlled by 2 switches turned off for a couple of seconds, then back on. Repeatedly. Rebooting the eisy stopped it.

Save it, and then also configure your router to reserve the current ip address for that device MAC address.

Sounds about right.

The first post in this thread details the procedure. The important thing is to power off the controller, as explained:

A Polisy has two USB ports, so you should be able to just plug it right in. Yes, the 2413U comes with a standard USB cable.