apostolakisl

If you intend to bench test them like @MrBill suggested, then it is easier to factory reset them by holding in the set button while you plug it in. In my case, my bench test setup has an on/off switch which makes it easier yet. I push the button in and flip the switch on. Tends to be a PITA to pull out the air gap and then another PITA to click it back down without your finger slipping off requiring you to start all over.

Is it linked to the motion sensor? This could certainly be turning the light off seemingly randomly. Also, I assume you checked not just for the scene to be in other programs but also the individual device with the load. Turning the light on at sunset will only happen if the status of the dusk/dawn sensor is "on", since it is connected by an "and". You could change the "and" to "or", or just eliminate it from the program. If you set yourself an alarm clock for 18 minutes after sunset, then be sure to sit there and stare at your programs summary page and see that the program runs at sunset plus 20 and runs true. If it runs true, and the light doesn't turn on, then you have some sort of communication issue.

I have also fixed several 2476D's by replacing caps. I can't tell you which caps, by and large, I just replaced nearly all of them provided I had an acceptable replacement sitting around. The trick with them is you have to drill out the rivet holding the heat sink. Then you have to re-rivet it when complete. The issues included failing to boot up, or taking a really long time to boot up and buzzing while booting up, and issues with turning on/off. I don't recall any that just randomly ramped up/down.

If the light was turning off at some random time BEFORE you added the ELSE clause, then you have something besides this program turning the lights off. And if indeed your lights were turning off, seemingly on purpose, before you ever had the else clause, then you were actually relying on whatever that was and whatever that was is now shutting the lights off at an unexpected time. You can do a search of your programs by right clicking and use the find/replace and then search your programs for any mention of the driveway lights. Also, could it be that someone is manually turning them off? And finally, you could have a faulty link on a device somewhere causing the driveway lights to turn off when you turned something else off. I would start with the program search. If that shows nothing, then try creating a new program to send you an email or push whenever status of driveway lights turns off. Then you can see exactly what time it shut off and get notified immediately facilitating you in finding out what might be causing it.

I can't speak to Sunday and Monday having been out of town. But Tuesday everything was fine. The ISY clock shows the correct time and the sunrise/sunset times listed are also correct and programs set to do so are executing at those times. I'm running 5.4.4 IoP.

I was out of town on Sunday, returned last night. When I arrived home, all of my outside lights that were supposed to be on were on (these are based on sunset). They all turned off before I woke up and I assume shut off at the scheduled time. They turned on again tonight 10 minutes before sunset (as scheduled). I am running IoP. In summary, I am not seeing any issues with events based on sunset/rise or the time of day.

There may not be, I haven't checked. But it is easy to work around. For example, write a rule in Elk to turn an output on for 1 second when you push the function key, then have ISY node server trigger a program based on the output turning on. Or you could just have ISY turn on the GDO for 5 minutes every time the alarm changes from armed to disarmed. Elk has hundredes of outputs, most won't actually be an output (unless you bought a boat load of output boards), but you can still turn them on and use them as "flags".

Yes, I forgot to mention I also have a DSC alarm connected by VPN and managed by the same ISY. I use the node server created by ioguy. This node server does not run on the official node server created by UD. I run it on a PC that is on 24/7 but it also runs on rpi. There is a DSC node server on the official UD node server, I don't use it because the ioguy one came first and it works great and I see no reason to switch. DSC is not as fancy and the node server thus does less, but, DSC is way cheaper.

@photogeek54 The Elk module for ISY I suspect is an EOL product. If the new Elk isn't identical to the old regarding integration, the Elk module won't work and UD is not doing any module development. They even threatened to stop native Insteon support (but they backed off on that). As far as I know, only zwave and Insteon will continue to have native support on the UD consumer products. Everything else will go to a node server. I had the module when I had my 994i. I have switched to ISY on Polisy which does not support any modules, so I had to switch to the node server. The node server by @Jimbo.Automates is better in that it integrates more Elk features, but it is worse in that it doesn't present and organize as well as the module. For example, you can't click on a tab and see all your zones, voltages, and status in a nice table all at once. Or all your outputs in a single table along with status. Things are just in folder trees, somewhat mixed together and you can only view the status of one at a time by clicking on it. I don't believe that there is anything @Jimbo.Automates can do within the confines of a node server to change that.

@Blackbird Why can't you let ISY turn the power on when the alarm is disarmed? What are you using to control power anyway, an appliancelinc?

I am familiar with the operation of a synchrolinc. It has gone from working perfectly, to working less and less well over the years. At this point I have to plug it into the same outlet as my PLM to get it to work. Perhaps it would also work if I plugged it into the same outlet as any working device, I haven't tried. I use it on my washing machines, which have dedicated circuits so I am assuming the distance of wire back to the panel is long enough to drop the PLC strength. I have gotten as far as disassembling the synchrolinc, but have yet to pull the caps.

I have a similar issue with some synchrolincs I have. They are quite old. Insteon hadn't made them in years so I was nursing these old ones along. I'm going to give it a try with cap replacement.

Ditto on the Phillips. I installed 100 of these in my church running on Insteon switches and am very happy with them. The color is good and when you dim them they turn more orange, like an incandescent. They are now just past their one year anniversary with no failures, running about 20 hours per week. These are more like 60w eq. It cost about $600, but by my math, we have already saved over $600, so it is all bonus now. And that is just based on decreased electricity for the bulbs, not the AC savings from 1/10 the heat load. And they do not flicker at all. However, on one switch I also had a cheap closet LED and there was some weird interaction that caused them to blink. I had to remove that closet light. I did not test these with just one bulb on the switch, I think the least number of bulbs on any one switch is maybe 6. https://www.bulbsdepot.com/bd39-550250.html EDIT: I noticed they have two pictures on the website of different looking bulbs. My bulbs all look like the second picture. The metal base does poke out of the socket and you can see it. This is I assume necessary as a heat sink.

@Panda88 I have updated Polisy using the AC update packages menu to no avail. And I just updated Tesla node and it successfully installed your new version, but still tells me to restart for a new(er) version that doesn't exist.

good enough, but, doesn't the fact that it is showing at all mean there is a bug? Also something goofy about polisy thinking I am on a different ISY firmware than correct.

Well, there is another problem then. I am running 5.4.4 (IoP), not 5.3.3

I did the update and nothing changed. Still have 3 nodes saying they need to be restarted to have latest version even though they already have the latest version. iTach, Push, and Backup are all reporting they need restarting for update but all have the latest. I restarted them individually and the entire PG3. EDIT: And also now the Tesla ap does to. It updated to 0.2.9 which is the latest and it wants a restart also.

I'm running 3.0.63. It is not offering me a newer version. I checked the "use beta versions" box to see if it offers me a newer version. So far, it hasn't done anything. But, now I would be using a beta which may have other issues. Itach for example is one that is telling me there is a new version, even though it appears I am running the latest. I also don't know why "i" is coming at the end of the alphabet instead of up where you would expect "i" to be.

I put his here, because this is the current node server having this issue, but I have had this happen many times. I am running 2.0.6 and it says there is an update. I restart, it briefly shows the new version (2.0.8) and then switches back to 2.0.6 and tells me to restart for the update. I even tried restarting PG3, same thing. I also have several other nodes that tell me to restart for a new, even though the current running version is the same as listed in the store. For example, the itach node currently tells me to restart for a new version even though it is running the current version.

I see this error. And have exclamation points. ????

Probably need to replace them. Are they dual band or the old ones? I had problems like that with the old single band units but have never had a dual band fail. I have 100% replaced my old single band devices with dual band. For fun, I tried replacing the capacitors on my failed single band devices and most of them worked again. That might be more trouble than it is worth. You can probably pick up some used dual band units for $30 or $40.

Just get a VPN and don't worry anymore. I assume that big brother in Canada isn't blocking VPN. And I would have to ask my kids about Netflix, I never watch it. Oh, wait, just remembered, I had insomnia one night and watched 5 episodes of "Never Have I Ever" and there were no commercials. Yes, I am as embarrassed as you might expect about that. But it was narrated by John McEnroe, so I should get a pass for that.

I know it is possible to block service to certain IP ranges. but I don't think Canada is blocked. Based on some threads on Google's website, it looks like they do not block connections over GV to Canada IP addresses. In fact the Google rep suggested to one person to buy an OBI200 unit to use GV in Canada as a VOIP service. I used GV over IP on my phone all over Greece and The Netherlands this summer.

The GV email to text works great and is basically instant. I like it because it shows up across all of my platforms simultaneously. The downside is Tasker can't read them, parse them and act on them like a native text. But now that Tmobile has gotten so unreliable about delivering email to texts (sometimes taking hours), the Tasker profiles have become useless. Regarding Michelle wanting the timeout set to 10seconds, that is fine, I don't care about a few seconds, but they should change the default to 10 seconds then. Like most people with an ISY, you can't be expected to read all the threads on here, so how are you supposed to know it should be 10 seconds? Especially when 1 second has always worked fine and is default. You have a problem and you waste a bunch of time not knowing the root cause. The issue is not waiting a few seconds, the issue is it doesn't work at all and you don't know why and you futz around wasting time and effort and get frustrated.

GV works anywhere you get internet, though I assume you are correct when you say there are no Canada phone numbers. Might not matter if you have a US phone number since I think for the most part calling back and froth from Canada to US is free. To a large extent it doesn't matter since GV mostly works over IP. I was just in Europe and had no issues using my GV number there. But, in short, I don't know what your original question was about the random address. When I use GV it shows it came from my phone number when I send from ISY linked to GM. When I send from ISY email to text to my phone's native number (@tmomail.net) it shows up as having come from me as well. I believe it sees the email address and looks it up in my contacts. Perhaps you are using the default ISY server? When I use the ISY default it always showed as coming from "alerts@universaldevices.com" Anyway, I don't have issues with GM working on the ISY now that I switched to 3 seconds timeout. Same with the using ISY default. I have GM set to 2 level authentication so for outside apps to work you have to go into your GM settings and have GM create a custom password that only works with that app (in this case ISY). EDIT: Also, the whole reason I have ISY using GV instead of native texting is my T-mobile email to text has proven to work like crap. At 9:38 ISY sent me a text simultaneously to GV and to TMobile. The GV text arrived in less than 1 minute. The TMobile text took 45 minutes. Sometimes it comes right away, sometimes it takes hours. Anyone else using TMobile and having different results?