Guy Lavoie

Have you tried removing power from your eisy for 30 seconds, then reconnect the power and turn it back on?

Well your secondary condition is actually taken care of automatically by the status change of the same input that triggers the program. In essence, if the triggering condition is detected as a status, it remains true until the status chnges again (level sensor closes again). If you hadn't wanted the 10 minute delay, it would be a straight if/then like this: program 1 If Status level sensor is ON Then Turn on pump program 2 If Status level sensor is OFF Then Turn off pump The desired 10 second wait before turning on the pump is done by adding a line to program 1: program 1 If Status level sensor is ON Then Wait 10 minutes Then Turn on pump That works because the status of the level sensor will remain at ON during the time that the program is waiting 10 minutes before continuing and turning on the pump. Adding a wait like that is a good practise, it adds hysterisis to the control system, preventing short run cycles of the pump.

When your program has a Wait statement, make sure it's triggered by a static condition, like a status change. Looking for control events ("is switched on") won't work because it doesn't remain true other than the first time it's detected. One effect is that if the detector turns off before the 10 minutes is up, then the pump won't turn on at all, which is what you might be wanting here.

In fact, you can't "restore" to a previous version. Backups are of your devices and program information.

Rebooting the eisy will usually resolve this issue. You might need to redo the module linking. Check first. The last (bottom) option is usually to remove existing links. If you cannot successfully link it to your eisy, you might need to factory reset the switch first. In that case, also recreate the direct link with the mini controller, though I'd use a scene would be better.

I've never done upgrades from within eisy-ui but that's likely how you would do them, yes.

The best one stop shop for version numbers is in eisy-ui. Set your browser to http://<eisy ip address> This should bring up a black login screen, where you enter your UDI account information. Once in, click on the three little lines at the top left, and then choose "System". You'll see all your version numbers.

Use a variable and two programs. Like this: If event trigger is True Then Variable = 1 If Variable = 1 Then first thing Wait x Then second thing Wait x .... Then Variable = 0

@IndyMike That would work for sending option changes, but not for a PLM replacement, since the motion detector would be sending it's on/off events to the old PLM Insteon address, and doesn't know about my new one yet.

Yes, two antennas: zigbee and zwave. The dongle isn't used for Matter, well not yet. If it does eventually, it would likely eliminate the need for a border router for Thread devices.

Update: I went ahead and replaced my PLM. Another thing I noticed a few days ago is that it was unreliable at sending X10 commands. I only have a couple of X10 devices, but one important one is sending a command to my Ocelot, to trigger an automation routine involving transmitting IR commands. Replacing the PLM is a pain because I have about two dozen battery powered devices (motion detectors, leak and open/close sensors), so I have to go to each one, put it in linking mode, and tap on "write changes" for that device in UD Mobile. Ugh. I then took the bad PLM and installed it in place of the usual one on one of my test Polisys, and tested turning an X10 appliance on and off. It works, but with varying delays, up to 8 or 10 seconds. I saw retries on the Elk ESM1 meter. Put back the usual PLM and X10 commands are very consistent. So trying out sending X10 commands might be another test to add for a suspected bad PLM. We all have a few old X10 modules in a box somewhere!

I don't think you can "learn in" an existing PLM. Part of the module linking process is to learn the module type and create the appropriate node(s).

Yes, I'll wait, to see if this was just a freak one time occurance. For the link count, are you suggesting that I check if the link count has changed, or just if the link count is getting high? I only have about 340 links.

I had an interesting Insteon hiccup this morning. I first noticed it when my Insteon motion sensors wouldn't trigger programmed actions in the eisy. The troubleshooting steps I took: Used my good ole ELK ESM1 X10 signal strength meter to see Insteon transmissions from the motion sensor. Yup. It's handy for that. Tried activating am Insteon wall switch to see that it wasn't updating it's status in admin console. Event log showed no events either. Tested a 3 way switch, confirmed that the slave switch was activating the one with the load. Could also control switch from admin console. So outgoing Insteon comms and signals between devices was ok. Rebooted the eisy, in case something wasn't working right or stuck with Insteon reception. No change Now focused on the PLM: unplugged it and plugged it back in. No change Alright, launched a "PLM Restore". That fixed it. Sign of a failing PLM? That's my thinking. Opinions, comments? 🙂

That Powerwall thread is the first thing that came to mind too. The powerline noise seems to be backfeeding through the pole transformer.