maxnorth

This may be overkill for you, but I decided I wanted to know if the AQI was increasing or decreasing. I have two thresholds, T1=50, T2=100. I am notified whenever the AQI goes above or below a T. My notification might be, for example, "the AQI in [city] increased above 50 to 62." So, to do this, I needed variables to store the current/new AQI and the previous AQI. By comparing the two, I can tell whether it is increasing or decreasing, and by comparing it to the threshold, which is also a variable, i can tell whether it went above or below the T. I used state variables, except for the previous AQI. To set the previous AQI, I simply evaluated the current AQI, waited 15 seconds, during which my comparison programs would run and my notifications would trigger, and then set the previous AQI to equal the current. The previous AQI is then available for the next evaluation. I did this for sensors in three different cities. I needed four network resources for notifications in each city (increasing T1, increasing T2, decreasing T1, decreasing T2).

Yes. Perfectly. Sent from my iPhone using Tapatalk

I have this same exact problem with polyglot on iPad and iPhone. Even though it logs in successfully, one symptom is that it is not possible to view the Polyglot log. It behaves as if the login is not complete/successful.

And keep in mind that the flicker can be caused by bulbs in other devices. That was certainly my situation. I'm not certain if it's only other devices that share the same KPL or not.

As the OP, I've got some good news for those interested in this topic. I have a single chandelier that uses 4 A19 bulbs. I had severe flicker issues and, to be clear, this was not related to dimming. The flicker would happen when there was sensor activity or other network traffic. I was using Feit. I replaced all the bulbs with Phillips Warm Glow, and the problem is now completely gone. What is very interesting is that my flicker problems on some other fixtures are now much reduced as well. I'm feeling much better about the prospect of replacing all of my incandescents with LEDs now.

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.