apostolakisl

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?

@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?

I use google voice which is set to copy all texts to my gmail. For this to work, you must use the same GM address in ISY as you use in GV. Send yourself a text, go to your email version of the text, copy the "from" address and use in your ISY as "to" address in ISY. The email address will look like this: yourphonenumber.yourphonenumber.randomlettersandnumbers@txt.voice.google.com The texts show up as coming from my phone number to my phone number, and the email version of it shows up as coming from my GM address. EDIT: Occurred to me that if you wanted ISY to have its own "from" address on texts, you could create a gmail address for ISY and get a google voice number for that email address. Send a text from yourself to your ISY GV number. Then, open that text in GM (the one for ISY) and copy the from address. Use that email address as the "to" address in ISY. The only trick is that GV is short on phone numbers. You might have to keep trying and trying before GV has an available phone number. Also, GV will cancel your phone number if you don't use it, I think that ISY sending email to texts will suffice to keep the number alive, but I can't be certain. I do know that sending texts from the GV webpage keeps a number alive since I have a GV number for just that and only that. It might be that you need to periodically send a text from the GV app or make a phone call from the app.

Since switching to IoP I had issues with email. They would work, or they wouldn't, randomly. I used the default mail server and then switched to gmail. My old 994 was on gmail as is another 994 I have currently running gmail. Also I have Blue Iris using gmail. All had the timeout set to 1000ms and all worked perfectly for many many years. In my frustrating trial and error trying to resolve this issue wit the new IoP, I tried increasing timeout to 2000ms. Low and behold, it started working better, but not perfect. Then 3000ms, now it seems to work 100% of the time. Anyway, it seems to me you shouldn't need a timeout of 3000ms unless something is wrong with the way IoP is handling mail. Anyone else having issues like this?

I checked my notifications and last time it worked was Aug 28. That could be when I switched to pg3 version. Edit. Yes, pg2 worked pg3 did not. I switched that day.

Any ideas? This is not a fresh restart, been running for weeks with a gazillion zone violations having occurred. Other info is correctly displayed. If I open an individual zone and violate/restore, it shows correctly. EDIT: Just to be clear, it is only on this screen that I'm not seeing zone violations. Last zone violated and last zone triggered. I tried a full reboot of polisy and it all the same.

So I have not read all the posts here so I might be repeating. I read the first few. What can happen with the query all is the following: If a program is set to run on the status of a device, and that device has an incorrect status in ISY because of a previously missed communication, then the query all will update that device's status to the correct status and in so doing, trigger any programs that included the device status in the "if" clause. So this issue will not happen every time there is a 3am query all. It only happens when the pre-query-all status is incorrect and the query updates it to the correct status. You should be able find the program that is being triggered by looking at your program summary page and finding programs that ran at ~3am. A potential way to avoid this issue is to use device "control" rather than "status" if possible. "control" will not trigger on a status change. Also, figuring out why the device status is wrong (or in other words why you have a com problem).

This is a bit confusing because of the way Insteon works. It is not a bad thing, it allows for great scene versatility, but with versatility comes confusion. First, remember the PLM/ISY is a member and controller for every scene. It is listed in the admin console tree as the root folder of each scene, but it is effectively no different than any other controller in the scene. To your specifics, you have to do all 3. 1) Scene on level when controlled by PLM. In other words, if ISY (or ud mobile) turns the scene on, the on level and ramp rate you set for each device is what will happen. 2) There is the local device on level. This is what THAT device does when you push the on paddle. You will need to set this for all devices in the scene. This does not need to be the same as when it is a responder to the scene. 3) There is the on level for the other devices in the scene SPECIFIC to which device turned it on. Basically this is the same thing as number 1 except instead of the plm being the source of the on command, it is what happens when any of the other devices in the scene initiate it. Because of how things are presented in the admin console, this is a bit different looking when you set it up, but it is the same thing as number 1. The way Insteon is set up, a scene is defined globally ONLY as the devices in the scene and whether they are controllers/responders, not how the devices respond. There is no global on level or ramp rate. If you have 3 devcies in a scene, you can have the 3 devices turn on differently depending on which of the 3 devices (plus PLM for a 4th version of the scene) you initiate it from. It is 1 group of devices that can behave 4 ways depending on which of the 4 controllers initiated it (3 devices or plm). In short, if you want a regular 3 way where you have 2 switches and ISY, all controlling the scene and you want the scene to behave the same regardless of which device you use to turn it on, then you have to set the on-level and ramp rate 3 times to the same values. Once for the scene as controlled from plm, once for the scene as controlled by each of the 2 devices, plus the local on level for each of the 2 devices. This allows for huge versatility, but it also means if you have a large scene with lots of controllers, you have a lot of settings to put in. It used to be that ISY had a "copy to all devices" button where you just clicked that button and it set all the devices levels in the scene to the same settings as the main PLM controlled scene. But they did away with that when they started adding non-insteon nodes since I guess it got too complicated.

Two "disable" options would do it. Easy enough to add it to a drop down menu, not sure how hard it would be to add it to the back end. "disable" "disable auto-triggering"