Guy Lavoie

It's been working fine here. Thanks again!

Ah ok yes, it's State. My booboo.

For the purpose here, you need to use a status variable. Go into variables, click on Status at the top. Then add a variable, editing the name to what you want, then click on Save. I like to prefix the name with a "s" for atatus, such as s_rain_flag. You should then be able to select the variable when programming, such as a If variable statement. Let me know if that works.

The problem is that your If statement will test true every time the value changes. So even though the rain value stays above 0.250 inches as it increases, the program will fire when it's 0.0251, again at 0.0252, etc. To avoid that, I would use two programs. One that sets another variable as a flag (that the rain is above 0.250 inches), and another program that sends your notification. Like this: If 'WeatherLink' Daily Rain > 0.250 Inches Then rain_flag = 1 Else rain_flag = 0 If rain_flag = 1 Then Enable Program 'Gen Sump2' Run Program 'Gen Sump2' (If) Send Notification to 'Brooke Text' content 'Rain for Gen Sump ON' The first program will keep setting the flag to 1 every time the rain value changes, but that doesn't matter. The second program will test true only the first time the flag is set to 1.

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.