maxnorth

I'm surprised that there aren't many postings here on the problem of LED bulbs flickering when Insteon events are transmitted over the power line network. This is a huge problem for me (maybe it's only me?). I'm increasingly worried about this as incandescents go away. My environment is ISY994 using only three-wire toggle switches and KPLs -- no two wire. I have the flicker problem both with A19 style LED replacements and with a couple of native LED fixtures I've bought (no bulbs). When there is traffic -- an Elk sensor triggers, for example -- the bulb flickers. It seem to flicker also where a program executes, at least where that program includes that fixture. True with toggle switches and KPLs. Nothing unusual about my wiring setup, as far as I know. I have not determined whether this only happens where scenes are involved or not, but it is possible. I don't seem to have the problem at all with R30 style LED bulbs. I have not tried the Phillips Warm Glow. Is this just a problem with using cheap bulbs, or is there some line filter I can use to eliminate the problem. It's really not acceptable in the current state.

Michel, This is interesting, but perhaps I am missing something. How does the notification program send an email if the internet is down?

It's been in use for 3.5 years after I replaced the capacitors. Not too bad. I've got a second one on which I have not yet replaced the caps. Are you saying that the new ones are likely to have a longer life? If not, I'll probably refresh my second one and use that.

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!