maxnorth

Update: I checked the PLM Links, and there were none. I Restored PLM and got back 557 links. All seems to be working at this point. Am I correct to assume that this is an early sign of PLM failure? Or is there something else that could cause a loss of the links table?

I've been running 5.0.16 for some time with no issues. In the past few days, all of my wireless devices (2844-222 motion sensors and an open/close sensor) have stopped communicating with the ISY. They flash when detecting motion, but the ISY status is not updated. Apart from this, the ISY is performing just fine: programs are running, network resources are working, Mobilinc, Alexa voice commands, etc. All except the wireless devices. I'm also running Polyglot on a Pi with no problems. The ISY reports zero bad blocks with the SD card. I have rebooted the ISY and PLM. The only issue I'm seeing in the error log is a phantom network resource file ("could not find file /conf/net/64.res") and some http error ("TCP Client Read Response Failed, Net Module Rule: 48"), which I believe is also related to a network resource. Resource 64 does not exist, and resource 48 seems to be working just fine. I suspect these errors are unrelated to my wireless device problem. Ideas? It seems strange that only the wireless devices are affected, but could it be the PLM?

Not sure what's going on with this thread. Maybe the OP wants to restate. As I understand it (please let me know if I am off base), the question is, how to detect if the light was initially turned on by the motion sensor (MS). If it was, turn the light off in 2 minutes. How to do this? 1. When (if) the light is turned on by MS, set an integer variable to 1). This is "On by MS variable". Start the timer program for 2 mins. If "On by MS variable" is zero, the timer program does not start. 2. Use control MS On as a trigger, or create an MS On state variable changing from zero to 1, to detect when the MS turns on. 3.The timer program says that if status of the light is on and the motion sensor is off, and "on by MS variable" is 1, then wait 2 mins then turn the light off. (Alternatively, set the wireless MS to "on only" and use a state variable and timer to track whether the MS triggered On n seconds ago). 4. Create a "manual off" program, whereby when the switch is manually turned off, then "On by MS variable" is reset to 0 (and the light is turned off). 5. Create a program that turns the light off every x minutes where "on by MS variable" = 0, just for those manual switchers that forget to turn the light off when they leave. 6,. I also tend to create "timer override" program that stop the timed off program if I turn the switch "On" when the light is already on. I set an integer variable to 1 in that case, and It's handy way of stopping timer programs when you simply want the light to stay on indefinitely. In that case, you also need a "manual off" program that resets that variable to zero when you manually turn off the light. What am I missing?

Thanks, Paul. Yes, unplug and then plug back in. I had noticed that the wiki instructions for replacing your PLM (as I have done a couple of times) specify plugging the PLM in first so that the ISY does not get confused, which is why it occurred to me that perhaps there was a sequencing issue. This only happens to me sporadically.

We have frequent, short power outages where I live. I do not have a UPS for my ISY or PLM. I've had multiple instances after a power outage where I have poor device communication after power returns. I have solved these by manually rebooting: PLM first, followed by the ISY. It appears that if both these units reboot simultaneously without intervention (as would normally occur when the power comes back on), then the system does not function properly. If this is the case (I'm asking), would it not make sense for UDI to change the ISY firmware so that there is a reboot delay, giving the PLM time to reboot fully first?

Same problem in California. All skills and SmartHome, not just ISY.

Thanks very much for the detailed explanation, Taken. This is now working for me.

I do not understand step 2 in your instructions. I do not have that option in my File menu in the Admin console.

Yikes is right. That's not a good way to go. Thanks! Have you used any of these with the ISY?

Has anyone played with this yet? I assume the network module would support it?

Teken, I know this post is a bit old, but can you tell me how many months you get out of a rechargeable on a motion sensor, roughly? Also, is there a brand you've had good luck with?

Ok, let me try to recap: 1. All-On events don't seem to "involve" the ISY, meaning that programs and scenes are not triggered by an All On event. 2. All-On events seem to be confined to Insteon devices, and may involve the PLM in sending an All-On signal to all devices. (I have replaced my failing PLM and have not yet had any more All-On events). 3. Therefore, an Insteon action triggered (exclusively) by a scene or program should not be triggered by an All-On event. 4. To insulate a garage door from All-On risk, remove the IO Linc as a garage door controller. If there is no Insteon device to trigger the door, it should be safe. 5. Instead, use an output on the Elk board (output 3 directly or any other output triggering an external Elk 912 relay board), to open or close the door. This would be wired to the same device as was the IO Linc (in my case, a wireless remote door opener). 6. Use any sensor, including an IO Linc-connected sensor, to sense whether the door is open or closed. (The ISY can be used to sense the door state, just not to control it). 7. The Elk output can be triggered by any ISY scene or program, without any risk of getting triggered by an All-On event. Please let me know if there are any corrections/revisions to this.

Note sure what I'm missing here. I can certainly control the garage door from my Elk, but if any Insteon devices are linked to a program that would trigger an Elk output for the garage door (as they are), then why shouldn't I worry that an "All On" event would trigger that device and program and open my door through the Elk? Example: I have a KPL button that currently opens my garage door. Do I have to give that up to be more secure?

Following up on the garage door security/safety issue, what's the recommendation for a solution more secure than the IOLinc? I have an Elk as well that could be used. Could someone post details of their solution?

As the OP on this string, I thought I'd post an update. I've had no further All On events, but now my PLM is failing. So, consider this a possible additional data point: Is an All On event caused as a PLM is in the process of failing? It's a 2413S, v9b, V1.B hardware level, 1325. Almost exactly two years old. What the current read on the PLM? I've seen the cap replacement topic. Better to upgrade the caps, or simply buy a new one with v2 hardware (and new warranty)?

I agree it seems impossible. Maybe it's just the NSA testing that backdoor UDI put in the ISY for them

Ah, thank you. Hence the need to poll like in your setup.

Thanks, Xathros. My plan is to pick 5 or so disparate devices and create a 5 second timer for each (control method). Then create a program that says that if any of those devices goes on (control) while all timers are still active, then consider it to be an All On event.

Thanks, Michael. I thought the wiki had become stale, so I don't normally check there. My bad. I don't use "control" in my programs, so that is really not a helpful summary (or likely correct). Teken, I share your extreme frustration. It does not seem to make sense, and it feels like we are missing something. In the meantime, I'm simply going to have to create some monitoring programs and rely on my remote capabilities to shut things down if this happens while I'm not at home. (or perhaps shut them down automatically if I can detect the event reliably.) I get that the "all on" event is supposedly not "sent" by the ISY, but has anyone explained why the ISY does not detect the status of the devices that are turned on by the event? Does that not suggest that the problem lies with the ISY?

Thanks all. Teken, I went through the master "all on" string you linked to (funny that my "all on" search did not bring that up initially). I must say, 36 pages of posts is not a very efficient method of troubleshooting. Too bad UDI can't simply summarize the issue and keep the summary current. It's pretty essential to separate fact from speculation with a problem like this. I'll have to watch this to see if it gets worse and will consider updating my PLM (I'm at V9B still). I have also introduced some wait times into my scenes where possible, especially those updating LEDs. I do have multiple motion sensors. I am considering removing the IO Linc on my garage door opener, although I already have it set to notify me whenever it opens, so I can always close it remotely should the need arise.

Twice now, my ISY994i has turned on all my devices at once, randomly. This includes opening my garage door, which is a real security concern. It happened today and once maybe six weeks ago. I do not have an "all on" program or scene anywhere. I pulled the error log and there are no errors logged for today. There was nothing in particular going on at the time. I also notice that it turned them on, but my normal timer programs designed to turn things off did not run. I manually turned everything off. Other than the glitch with the timers, the ISY appears to be functioning normally now (without me rebooting it). All of this suggests a glitch with the ISY, including a freeze of some sort that preventing my timers from being triggered. Suggestions for diagnosis? I've got an Elk, Mobilinc and the Z-Wave module, but no network module. Static IP, 4.3.26 and 1755 MB free.

LeeG, that's got it. For some reason, I didn't see that in the manual. Resetting it locally took care of the problem. Thanks so much!

I've got around 50 devices I'm controlling from my ISY-994i. I've had some challenges with the first/main button on one of my 8-button KPLs. When I press the button, the circuit comes on, but at the dim-level it was at when last on. The "local on-level" is set at 100%, but seems to have no effect. I've looked at all my scenes and programs to see if there might be something interfering with normal operation here, but I see nothing. I'm left with the impression this is a hardware issue. I have not yet tried a factory reset. Any suggestions? (If I do a factory reset, I assume I'd have to remove all 8 buttons from all scenes first and then re-establish them? )

I haven't seen another post on this topic so here I go. I've got an Insteon motion sensor in my wife's 10 by 20 foot office and programs to bring the light on when motion is detected and keep it on so long as the sensor is active. The light is programmed to go off after 10 minutes with no motion. Works fine so long as she moves around regularly. The problem comes when she does some quiet activity, such as sitting at her desk with her back to the sensor, or sitting in a side chair while knitting or something. I've thought about adding more sensors, and I may have to try that to know for certain, but my concern is that the Insteon sensor may not be sensitive enough even when pointed directly at a quiet subject. That seems to be the case with the current sensor, which is located about 10 feet above and behind her desk chair. Are there any clever ideas for dealing with this, or different sensors I should be looking at? Yes, I do have a program that enables her to "override" the timer by pressing the On button, but she often forgets to do that until it's too late, and her patience with me is running short. "Just waive your hands" is getting old.

Update to my own question. I had a chat with Insteon today and they report that this behavior can occur when one of the bulbs is close to failing. I will have to replace my bulbs and see if that fixes it. Also, in my testing, the Level 3 event viewer shows no device communication occurring during these intervals, so the issue is completely internal to the switch.