Guy Lavoie

The eisy has 4 usb ports so there is no problem.

Software problems rarely just "go away". What type of notification is sent? Email? Plugin driven?

If you only need zwave and not zigbee, then you can alternatively get a Zooz zwave dongle (700 or 800 series). The ZMatter price shown on the UDI website isn't the usual price. Seems they put a temporary price like that when it's out of stock. Usual price is $152. Not sure if/when it might be available again. They might be looking for an alternate solution.

I don't know if this could cause it. I'm just giving something to check which could be related. Or not. Let us know if it changes the behavior. A reboot restarts the whole controller (Unix, etc) while IoX restart only restarts the task that runs your programs.

Mine is working, but it's often slower to respond. Sometimes she'll say that the controller is not responding, but the command ends up working anyway, after a delay that can be 10 seconds or more. Another thing I've noticed is that it appears to sometimes be sending a command twice. I haven't yet made a connection with those "non responding" controller messages (like maybe it retries?). You don't noice it with lights, but I did see it happen with opening the garage door, because if it sends another command to trigger the iolinc, the second command will stop the opening door, leaving the door half open. I have a similar issue with a toggle type command that turns on/off a video fireplace. I ask it to turn it off which it does, then it does it again, which leaves it on at the main menu. I'd have to add lockout timer code to avoid this.

On your main Configuration -> System screen, do you have the setting "Catch up on schedules at Restart" checked?

Well let's back up a bit. Does the sump pump programming itself work ok? If it does, then there might be a problem with notifications itself.

Another thing: Send Notification is using a plugin, right? Are you able to send notifications ok and only once in other programs?

Interesting. Well what is in the Gen Sump2 program, and why is it run as a separate program? I have not really used Run statements like that so It might be a bit foggy as to what would happen, but I cannot see why you'd get those notifications if the "if" statement never triggered. You could also try putting the notification statement before the Run line.

As I like to say: there are two groups of computer users, those who have lost data, and those who will.

Looks right. Let me know how it goes!

Was the backup that you used for the restore recent? If it predates much of your scene creation, or worse: if it's a backup from a previous PLM, then there isn't much you can do. There is no "restore scene" utility.

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.