September 8Sep 8 7 hours ago, hart2hart said: You are describing Restore PLM where the PLM is being replaced. (I think having a Replace PLM would make it clearer but command does double duty) I commented on when you restore PLM and it’s same PLM so nothing changes in devices. It’s in effect just a refresh PLM. My bad. I thought the thread was about him replacing the old one.
September 8Sep 8 Status shows connected.I would say good morning but…. Are you contacting UD to confirm next steps? Likely gonna either be a factory reset of PLM to see if that takes and the Restore can finish or somehow confirming all the queued links to current PLM are cleared so you can replace it with the other one. My bad. I thought the thread was about him replacing the old one.No worries. It looks like it may have fully upgraded to replace PLM VS restore current PLM.
September 8Sep 8 Author 1 hour ago, hart2hart said: I would say good morning but…. Are you contacting UD to confirm next steps? Likely gonna either be a factory reset of PLM to see if that takes and the Restore can finish or somehow confirming all the queued links to current PLM are cleared so you can replace it with the other one. No worries. It looks like it may have fully upgraded to replace PLM VS restore current PLM. Yes Michel reached out this morning asking for a file and some screenshots. Thanks for asking.
September 8Sep 8 Author 3 hours ago, hart2hart said: I would say good morning but…. Are you contacting UD to confirm next steps? Likely gonna either be a factory reset of PLM to see if that takes and the Restore can finish or somehow confirming all the queued links to current PLM are cleared so you can replace it with the other one. No worries. It looks like it may have fully upgraded to replace PLM VS restore current PLM. Michel says the PLM needs to be replaced. I have a serial plm model EZICOmm #5010k. Will this work? Also as you suggested, how do I factory reset my PLM and try that first? Thanks
September 8Sep 8 1 hour ago, Blackbird said: Michel says the PLM needs to be replaced. I have a serial plm model EZICOmm #5010k. Will this work? Also as you suggested, how do I factory reset my PLM and try that first? Thanks I personally would not use it. The EZICOmm #5010k depending on its age could be the real old 2412S PLM or short time sold dual band 2413S. The 2412S has unregulated 12VDC (typically ~18.5VDC) on one of the serial pins on the PLM. It is also quite old and may have the smaller link database memory in it depending on its age. If it has a date sticker on it at may give you a clue.
September 8Sep 8 Michel says the PLM needs to be replaced. I have a serial plm model EZICOmm #5010k. Will this work? Also as you suggested, how do I factory reset my PLM and try that first? Thanks I agree with Brian and would not use that PLM as there were several issues as I recall. You'd be better served to get a current Serial PLM. The PLM reset instructions are: Unplug the PLM from the power source. Press and hold the black "set button" on the PLM. While holding the button, plug the PLM back into power. Continue holding the button until the PLM beeping stops then release it. This procedure performs a factory reset and clears all linked devices, requiring you to re-establish communication. Did you mention doing the reset to Michel and then seeing if all the queued up restore PLM links would process after the reset. I don't want you to do something that complicates the situation as I've never had a PLM fail like this and not allow a Restore PLM. Same applies to doing another restore where a different PLM will be plugged in and it goes through updating all devices. I know what I would do if it were my setup, but I don't want to roll the dice at this point for you.
September 8Sep 8 Author 2 hours ago, hart2hart said: I agree with Brian and would not use that PLM as there were several issues as I recall. You'd be better served to get a current Serial PLM. The PLM reset instructions are: Unplug: the PLM from the power source. Press and hold: the black "set button" on the PLM. While holding the button, plug the PLM back into power. Continue holding: the button until you hear the PLM beep, then release it. This procedure performs a factory reset and clears all linked devices, requiring you to re-establish communication. Did you mention doing the reset to Michel and then seeing if all the queued up restore PLM links would process after the reset. I don't want you to do something that complicates the situation as I've never had a PLM fail like this and not allow a Restore PLM. Same applies to doing another restore where a different PLM will be plugged in and it goes through updating all devices. I know what I would do if it were my setup, but I don't want to roll the dice at this point for you. I just asked him about this. Thank you
September 8Sep 8 6 minutes ago, Blackbird said: I just asked him about this. Thank you Keep us posting how its going for you.
September 8Sep 8 Author 48 minutes ago, hart2hart said: Keep us posting how its going for you. Will do thanks. Im sure I will still need help.
September 8Sep 8 I agree. That is a uncommon problem. It almost sounds like the Link Database ram is starting to go bad and can not be written to above a certain memory location.
September 8Sep 8 21 minutes ago, Brian H said: I agree. That is a uncommon problem. It almost sounds like the Link Database ram is starting to go bad and can not be written to above a certain memory location. Weren't the earlier PLMs limited to about 256 links in their EARROM space? This sounds like the old problems returned. Edited September 8Sep 8 by larryllix
September 9Sep 9 Author 1 hour ago, larryllix said: Weren't the earlier PLMs limited to about 256 links in their EARROM space? This sounds like the old problems returned. Would factory reset clear all that?
September 9Sep 9 8 hours ago, Blackbird said: Would factory reset clear all that? So I am also currently experiencing issues with my eISY/PLM setup. I won't go into details of my issues at this point, but suffice to say I've been using "Backup IoX", "Restore IoX", "Restore PLM", "Restore Device", "Show Device Links Table", and "Show PLM Links Table" quite a bit lately. Here are bits of information that I think might be useful: My PLM Links table also returns 292 links. I have about 60 Insteon devices. I find it quite interesting that we have the same number of PLM links. Probably doesn't mean anything . . . The PLM has memory that holds a link for every device it controls, every device that controls it, and every device that is either a scene responder or scene controller. Each device has memory that holds a link for every device it controls, every device that controls it, and every device that it either responds to in a scene, or controls in a scene. When you first link a device to your ISY/Polisy/eISY two links are stored in the PLM and two links are stored in the device. The links stored in the PLM tell the PLM that it is both a controller and a responder for the device. The links stored in the device tell the device that it is both a controller and a responder for the PLM. You might think it strange that the device is a controller for the PLM but that is what allows the device to communicate manual status changes to the PLM. It's not really controlling the PLM just updating it with its status. Every link stored in the PLM and Device Links Tables has either a device address or the PLM address. When the PLM or a device receives a message, it checks the message for the address from which the message originated and then looks in its Links Table to see if that address exists. If it does, then it executes the command that is also stored in the message. If the address does not exist in its Links table, it will ignore the command. Usually when it executes the command it will respond with an ACK message, and if it ignores the command it will respond with a NAK message. The ISY/Polisy/eISY maintains a backup of the PLM and devices Links Tables so if the PLM or devices have their table corrupted, you can fix them with the backup from the ISY/Polisy/eISY. I provide that context to help you understand why a failing PLM memory, or corrupted device memory might cause problems. An example: to communicate a manual status change (say from OFF to ON), a device will send a message to every device for which its Links Table shows it to be a controller. By default it will always be a controller of the PLM, but it may also have been assigned as a controller for a scene. If its Links Table has become corrupted and a controller link has been lost, then it will not send a message to the device that was in the missing link. Likewise, after the device sends its message with its status change, all devices will receive that message, but only devices that have the address of the sending device in their Links Table, including the PLM, will actually accept the message. So if the PLM Links Table memory if failing, and it has lost links that tell it that it is a responder to a device, it will not accept messages from that device even if the device sends them. By not accepting the message, the PLM won't accept the manual status change and communicate it to the ISY/Polisy/eISY. So what happens when you get a new PLM and perform a "Restore PLM"? What I describe below is if you have connected a new PLM to your ISY/Polisy/eISY. Since the address of the new PLM is different than what the ISY/Polisy/eISY last knew to be the PLM's address it will execute what follows. If the currently connected PLM has the same address as the last known PLM address, I think it was hart2hart that suggested only the PLM will be updated (next paragraph) and not the individual devices (second next paragraph), but I've never done that so I can't confirm. None of the links that exist in your old PLM will exist in the new PLM. So the first thing that happens is that ISY/Polisy/eISY will use its backup PLM table to fill the new PLM with all the links that currently exist in your old PLM. This happens via the serial or USB connection between the ISY/Polisy/eISY and the PLM so occurs relatively quickly. If all those links weren't put into the new PLM, it would not accept manual status updates from devices, nor know anything about any of the scenes you might have defined. Next the ISY/Polisy/eISY will update every link in every device that has the old PLM address with the address of the new PLM. This happens over the power-line and can take quite a long time. If the old address wasn't changed to the new address in the device Links Table then the devices would simply ignore the new PLM because its address did not appear in the device's Links Table. Power-line devices are always waiting for commands, so they'll automatically accept the link updates, but wireless device spend most their time sleeping are won't likely be awake when the new link commands are sent. That is why you want to unselect the little battery icon just below the menu row before running "Restore PLM". That way the new link commands aren't sent to wireless devices until you right-click on the wireless device and select "write updates". Before doing that, you go to the device and put it in setup mode by holding down its set button for 3-5 seconds so that it is awake to receive the new link commands. If the ISY/Polisy/eISY is not able to communicate with a device during it's attempt to update the device's links, it will leave all those message queued up. This can leave your ISY/Polisy/eISY is quite a bad state, as it will try to send all those message later. You'll notice that there are messages to be sent because "1001" will appear in green or gray next to the device's name. The only way I know of to wipe out all those queued up messages is to use "Restore IoX" to the last known good backup. If you've made it this far, based on what you've reported so far, I'd start with "Show PLM Links Table". If you get the 292 links that you've been getting all along, I'm not sure you need to try to update the PLM. If you aren't getting the 292 links you were getting before, I'm not sure there's any reason not to factory reset the PLM and try a "Restore PLM". I will mention that the factory reset procedure laid out by hart2hart above has an error. When you plug in the PLM while holding the black set button, you need to hold down the set button until the PLM stops its continuous beep. Don't let up when you first hear the beep. It's important to "Backup IoX" before doing a "Restore PLM". Your system can be left in quite a state if lots of messages for devices are queued up as they'll flood the power-line at the most inconvenient time, and if you're having power-line communication issues, the queued message may never clear. The only way I know to get rid of queued message is to either have them successfully reach the device such that the device sends back and ACK message, or to "Restore IoX" using a the last known good backup. This is way longer than I intended, but one last thing. A failing PLM can be caused by a lot of things. As laid out above, if its memory fails the links lost from its memory will cutoff communication with the specific devices whose links have been lost. If it is losing signal strength then commands that it sends may not reach the intended devices. Both memory loss and signal strength loss are things that should be able to be diagnosed using the Event Viewer and/or "Show PLM Links Table" and "Show Device Links Table". The PLM may also lose signal strength receptivity, but that is a little harder to diagnose using the Event Viewer because only things that the PLM hears appear in the Event Viewer so you don't know what you don't know. Still if it has been confirmed that a responder link with the device's address appears in the PLM Links Table, and a controller link appears with the PLM's address in the device's Links Table, but no messages are appearing in the Event Viewer when you manually change the status of the device, then either there's too much noise on the power-line, or the PLM's sensitivity has been diminished, or the device's transmit signal has been diminished. All of that is my way of saying that with some sleuthing, I would expect Michel to be able to posit a guess as to whether he thinks the PLM is experiencing memory issues, signal transmit issues, or signal reception issues since you indicated he says the PLM should be replaced. Edited September 9Sep 9 by kclenden
September 9Sep 9 @Blackbird I updated Restore PLM instructions above (for someone reading later) to correctly state hold until beeping stops. The PLM reset instructions are: o Unplug the PLM from the power source. o Press and hold the black "set button" on the PLM. o While holding the button, plug the PLM back into power. o Continue holding the button until the PLM beeping stops then release it.
September 9Sep 9 Author 4 hours ago, kclenden said: So I am also currently experiencing issues with my eISY/PLM setup. I won't go into details of my issues at this point, but suffice to say I've been using "Backup IoX", "Restore IoX", "Restore PLM", "Restore Device", "Show Device Links Table", and "Show PLM Links Table" quite a bit lately. Here are bits of information that I think might be useful: My PLM Links table also returns 292 links. I have about 60 Insteon devices. I find it quite interesting that we have the same number of PLM links. Probably doesn't mean anything . . . The PLM has memory that holds a link for every device it controls, every device that controls it, and every device that is either a scene responder or scene controller. Each device has memory that holds a link for every device it controls, every device that controls it, and every device that it either responds to in a scene, or controls in a scene. When you first link a device to your ISY/Polisy/eISY two links are stored in the PLM and two links are stored in the device. The links stored in the PLM tell the PLM that it is both a controller and a responder for the device. The links stored in the device tell the device that it is both a controller and a responder for the PLM. You might think it strange that the device is a controller for the PLM but that is what allows the device to communicate manual status changes to the PLM. It's not really controlling the PLM just updating it with its status. Every link stored in the PLM and Device Links Tables has either a device address or the PLM address. When the PLM or a device receives a message, it checks the message for the address from which the message originated and then looks in its Links Table to see if that address exists. If it does, then it executes the command that is also stored in the message. If the address does not exist in its Links table, it will ignore the command. Usually when it executes the command it will respond with an ACK message, and if it ignores the command it will respond with a NAK message. The ISY/Polisy/eISY maintains a backup of the PLM and devices Links Tables so if the PLM or devices have their table corrupted, you can fix them with the backup from the ISY/Polisy/eISY. I provide that context to help you understand why a failing PLM memory, or corrupted device memory might cause problems. An example: to communicate a manual status change (say from OFF to ON), a device will send a message to every device for which its Links Table shows it to be a controller. By default it will always be a controller of the PLM, but it may also have been assigned as a controller for a scene. If its Links Table has become corrupted and a controller link has been lost, then it will not send a message to the device that was in the missing link. Likewise, after the device sends its message with its status change, all devices will receive that message, but only devices that have the address of the sending device in their Links Table, including the PLM, will actually accept the message. So if the PLM Links Table memory if failing, and it has lost links that tell it that it is a responder to a device, it will not accept messages from that device even if the device sends them. By not accepting the message, the PLM won't accept the manual status change and communicate it to the ISY/Polisy/eISY. So what happens when you get a new PLM and perform a "Restore PLM"? What I describe below is if you have connected a new PLM to your ISY/Polisy/eISY. Since the address of the new PLM is different than what the ISY/Polisy/eISY last knew to be the PLM's address it will execute what follows. If the currently connected PLM has the same address as the last known PLM address, I think it was hart2hart that suggested only the PLM will be updated (next paragraph) and not the individual devices (second next paragraph), but I've never done that so I can't confirm. None of the links that exist in your old PLM will exist in the new PLM. So the first thing that happens is that ISY/Polisy/eISY will use its backup PLM table to fill the new PLM with all the links that currently exist in your old PLM. This happens via the serial or USB connection between the ISY/Polisy/eISY and the PLM so occurs relatively quickly. If all those links weren't put into the new PLM, it would not accept manual status updates from devices, nor know anything about any of the scenes you might have defined. Next the ISY/Polisy/eISY will update every link in every device that has the old PLM address with the address of the new PLM. This happens over the power-line and can take quite a long time. If the old address wasn't changed to the new address in the device Links Table then the devices would simply ignore the new PLM because its address did not appear in the device's Links Table. Power-line devices are always waiting for commands, so they'll automatically accept the link updates, but wireless device spend most their time sleeping are won't likely be awake when the new link commands are sent. That is why you want to unselect the little battery icon just below the menu row before running "Restore PLM". That way the new link commands aren't sent to wireless devices until you right-click on the wireless device and select "write updates". Before doing that, you go to the device and put it in setup mode by holding down its set button for 3-5 seconds so that it is awake to receive the new link commands. If the ISY/Polisy/eISY is not able to communicate with a device during it's attempt to update the device's links, it will leave all those message queued up. This can leave your ISY/Polisy/eISY is quite a bad state, as it will try to send all those message later. You'll notice that there are messages to be sent because "1001" will appear in green or gray next to the device's name. The only way I know of to wipe out all those queued up messages is to use "Restore IoX" to the last known good backup. If you've made it this far, based on what you've reported so far, I'd start with "Show PLM Links Table". If you get the 292 links that you've been getting all along, I'm not sure you need to try to update the PLM. If you aren't getting the 292 links you were getting before, I'm not sure there's any reason not to factory reset the PLM and try a "Restore PLM". I will mention that the factory reset procedure laid out by hart2hart above has an error. When you plug in the PLM while holding the black set button, you need to hold down the set button until the PLM stops its continuous beep. Don't let up when you first hear the beep. It's important to "Backup IoX" before doing a "Restore PLM". Your system can be left in quite a state if lots of messages for devices are queued up as they'll flood the power-line at the most inconvenient time, and if you're having power-line communication issues, the queued message may never clear. The only way I know to get rid of queued message is to either have them successfully reach the device such that the device sends back and ACK message, or to "Restore IoX" using a the last known good backup. This is way longer than I intended, but one last thing. A failing PLM can be caused by a lot of things. As laid out above, if its memory fails the links lost from its memory will cutoff communication with the specific devices whose links have been lost. If it is losing signal strength then commands that it sends may not reach the intended devices. Both memory loss and signal strength loss are things that should be able to be diagnosed using the Event Viewer and/or "Show PLM Links Table" and "Show Device Links Table". The PLM may also lose signal strength receptivity, but that is a little harder to diagnose using the Event Viewer because only things that the PLM hears appear in the Event Viewer so you don't know what you don't know. Still if it has been confirmed that a responder link with the device's address appears in the PLM Links Table, and a controller link appears with the PLM's address in the device's Links Table, but no messages are appearing in the Event Viewer when you manually change the status of the device, then either there's too much noise on the power-line, or the PLM's sensitivity has been diminished, or the device's transmit signal has been diminished. All of that is my way of saying that with some sleuthing, I would expect Michel to be able to posit a guess as to whether he thinks the PLM is experiencing memory issues, signal transmit issues, or signal reception issues since you indicated he says the PLM should be replaced. Wow thats a hell of a reply. Thanks for the detailed explanation. 1 hour ago, hart2hart said: @Blackbird I updated Restore PLM instructions above (for someone reading later) to correctly state hold until beeping stops. The PLM reset instructions are: o Unplug the PLM from the power source. o Press and hold the black "set button" on the PLM. o While holding the button, plug the PLM back into power. o Continue holding the button until the PLM beeping stops then release it. Thank you and this was Michel's reply "There's no queue. Every time you click on Restore, the same set of files are reset to their original state and then IoX starts from scratch. What you are getting is a failure for "resetting the PLM". This means that the PLM is not honoring the request to have it reset. If communications are OK (i.e. Tools/Diagnostics/PLM Status/Info shows Connected), in 99.99% of the cases, the issue is the PLM itself."
September 9Sep 9 20 hours ago, Blackbird said: Would factory reset clear all that? No. AFAIK the PLM has a simple self management system for links inside. The link overflow is when the attempted amount of links becomes more than the hardware would hold. This was subsequently replaced by about 1024 links of space and then about 2048 more recently, IIRC. I am not sure ISY can tell when the PLM is full making the link storage unsuccessful and we get weird things missing but other parts of the Insteon remote device may work fine. Each Insteon devices uses up about 3-6 links spaces, basic, plus one for every scene it is used in.
September 9Sep 9 7 hours ago, Blackbird said: Wow thats a hell of a reply. Thanks for the detailed explanation. Thank you and this was Michel's reply "There's no queue. Every time you click on Restore, the same set of files are reset to their original state and then IoX starts from scratch. What you are getting is a failure for "resetting the PLM". This means that the PLM is not honoring the request to have it reset. If communications are OK (i.e. Tools/Diagnostics/PLM Status/Info shows Connected), in 99.99% of the cases, the issue is the PLM itself." When you perform "Restore Modem (PLM)", it's a two step-process. First the PLM is restored then all the devices are restored. I agree with Michel that there is no queue for the first step. If the attempt to restore the PLM is unsuccessful, your Polisy will not try to restore it later unless you again choose "Restore Modem (PLM). For the second step, restoring the devices, there is most definitely a queue as evidenced by the "1001" that shows next to each of your devices. If those updates do not complete, the Polisy will try to complete them later. Having said that, I don't know what happens to the queue of device updates if you were to perform another "Restore PLM". From Michel's response, it sounds like they may be wiped out and be replaced by the device updates created with the new "Restore PLM" command. So from Michel's response, it appears that he is saying that he believes the PLM is the issue because you are unable to restore it, not because of any communication issues he sees in the Event Viewer when the PLM attempts to talk to devices. I can't argue with his logic. If it were me, I'd probably try factory resetting my PLM and then attempting another "Restore PLM". Recognize, however, that if you do that and you are still unable to restore the PLM, all the things that currently work will no longer work. Device statuses won't update in UD Mobile or the Admin Console. Any programs that are activated by a device status change will no longer work. Any programs that send commands to devices, or use scene commands will not work. Hmmm . . . After writing those four sentences, maybe I wouldn't try factory resetting my PLM until I had received the new one. Edited September 9Sep 9 by kclenden
September 9Sep 9 Author 14 minutes ago, larryllix said: No. AFAIK the PLM has a simple self management system for links inside. The link overflow is when the attempted amount of links becomes more than the hardware would hold. This was subsequently replaced by about 1024 links of space and then about 2048 more recently, IIRC. I am not sure ISY can tell when the PLM is full making the link storage unsuccessful and we get weird things missing but other parts of the Insteon remote device may work fine. Each Insteon devices uses up about 3-6 links spaces, basic, plus one for every scene it is used in. Are you thinking that factory resetting my plm then restoring it wont help?
September 9Sep 9 Author 15 minutes ago, kclenden said: When you perform "Restore Modem (PLM)", it's a two step-process. First the PLM is restored then all the devices are restored. I agree with Michel that there is no queue for the first step. If the attempt to restore the PLM is unsuccessful, your Polisy will not try to restore it later unless you again choose "Restore Modem (PLM). For the second step, restoring the devices, there is most definitely a queue as evidenced by the "1001" that shows next to each of your devices. If those updates do not complete, the Polisy will try to complete them later. Having said that, I don't know what happens to the queue of device updates if you were to perform another "Restore PLM". From Michel's response, it sounds like they may be wiped out and be replaced by the device updates created with the new "Restore PLM" command. So from Michel's response, it appears that he is saying that he believes the PLM is the issue because you are unable to restore it, not because of any communication issues he sees in the Event Viewer when the PLM attempts to talk to devices. I can't argue with his logic. If it were me, I'd probably try factory resetting my PLM and then attempting another "Restore PLM". Recognize, however, that if you do that and you are still unable to restore the PLM, all the things that currently work will no longer work. Device statuses won't update in UD Mobile or the Admin Console. Any programs that are activated by a device status change will no longer work. Any programs that send commands to devices, or use scene commands will not work. Hmmm . . . After writing those four sentences, maybe I wouldn't try factory resetting my PLM until I had received the new one. Thats my dilemma, things work now but take time or multiple retries. I was able to order a PLM USB that was the last one in stock and should get here in about 5 days. Maybe I am best to wait as I rely on so many things on the ISY.
September 9Sep 9 2 minutes ago, Blackbird said: Are you thinking that factory resetting my plm then restoring it wont help? It might help, but it also might leave you in a much worse state if after the factory reset you are still unable to restore the PLM.
September 9Sep 9 Just now, Blackbird said: Are you thinking that factory resetting my plm then restoring it wont help? If there is some complete scrambling of the link table, and/or crashed firmware inside the PLM, it may help. However, if the PLM link table is an antique with only 256 link spaces, and you are overloading it (likely these days), then nothing is going to help that PLM except to remove many links (scenes, devices) ie: use for a smaller system?
September 9Sep 9 1 minute ago, Blackbird said: Thats my dilemma, things work now but take time or multiple retries. I was able to order a PLM USB that was the last one in stock and should get here in about 5 days. Maybe I am best to wait as I rely on so many things on the ISY. In view of the tech updates n the PLM, I would get one and keep it as a backup unit. If you cannot re-furb the older one, you have a head start on the replacement timing. I would avoid the RS-232 (serial port) PLM, as new microCPU boxes do not support RS-232 typically. It is a dying/dead interface.
September 9Sep 9 3 minutes ago, larryllix said: However, if the PLM link table is an antique with only 256 link spaces, and you are overloading it (likely these days), then nothing is going to help that PLM except to remove many links (scenes, devices) ie: use for a smaller system? The issues he has reported don't seem to me to be the kind that are caused by a full PLM Links Table. For example, he reported being able to control a device via UD Mobile a couple times, and then not being able to control the device and/or having a significant delay between commanding the device and it actually responding. A full PLM Links Table wouldn't cause this kind of issue. Either he'd be able to command the device, or he wouldn't. His ability to command the device wouldn't come and go.
September 9Sep 9 Given what you have learned about the PLM, I’d likely stay put and replace it with new PLM since a reset will clear it with no guarantee that it will let links be written back to it.
September 9Sep 9 Author Thanks guys. Yes I would say things are currently working normally, 60% to 70% of the time. Sometimes a device turns on instantly using udmobile and other times I have to turn that device on 3 or 4 times before it will turn on. Same with programs running. For example the light on my shed shuts off at sunrise and out of the past week it failed to turn off two separate days after sunrise.
Create an account or sign in to comment