apostolakisl

I set it to trigger the geofence node already created by the portal's occupancy function. So both UDI mobile and/or Alexa can set it now. So, no need to change any geofence programs since they already used that node.

Perhaps I am missing something. I added alexa to isy and synchronized some devices and can control them from the alexa app. I set up a routine with a geo fence and then when to add an action using "skills". It says no skills are active. I go to the skills and games section and it says ISY is active. Plus, I have Insteon switches linked to ISY that actually work, so clearly the ISY skill is active. What am I doing wrong? EDiT: NEver mind. I see it isn't under skills, it is under "lights".

what are you using for geofence then? I understand that macrodroid is basically a simpler version of tasker (never used marcodroid). With tasker I have used the wifi connected as a pseudo geofence to trigger a tasker task. The udi mobile is great except that randomly it doesn't work . . . which kind of means it isn't great.

I had this setup years ago, hadn't used it but am using it again. I was able to keep udi mobile even though it is no longer on the app store because it transfered over from an old phone. I don't know if you can set up occupancy without the app. If not, you would have to use ifttt/webhook section and use a variable or program or something. There is a tiny little blue symbol at the left edge of the webhook (just to the right of the red x) (also on the occupancy 2.0 screen) that you click on and it gives you a url. You can enter that url into a generic geofence app. Also, you can use tasker. So for example if you connect to wifi at home, it can trigger the url that says you are at home. I have been told the udi mobile app is no longer up to the latest security, not sure in what way, I still use it. But it isn't 100%. EDIT: It looks like you can use the occupancy 2.0 without the UDI Mobile app. This is just a node server. When you set this up, you will have nodes in isy that can be turned on/off by a url that gets created by this process. You first need to use the configure button to create the node architecture on your ISY. Then you add a mobile device. Your just putting a name into ISY here, there is not actually a need a for a real device. Then you add a geofence. Again, this is just a name. Without the app, the geofence doesn't have any geography associated. After you sync this up with your ISY, you will have a node(s) named with the geofence name(s) and a sub node(s) for the device(s). Now you can copy that url I mentioned above and put it into anything you want that is capable of sending a url. Likely that means either tasker or a 3rd party geo-fence app.

They must have multiple servers. Just pulled up the 7 day and definitely no holes in data. I also have ISY set to email me after 5 minutes of no new data and I never got any emails.

Just checked and my wireless tags are online and pulling up the graphs, I don't see any holes in the data.

It isn't that. I have an IoP and a 994i on the same internet connection. The 994i works just fine with the default 1000ms but the IoP does not.

I beat my head against the wall as well until I out of desperation increased the time out. The 1000ms timeout worked fine for 994i, but not Polisy. Obviously there is some issue with Polisy sending and receiving acknowledgement since it is certainly not gmail being slow or my old 994 and another 994 that is still using 1000ms would not all work fine. In short, UD either needs to fix whatever their internal delay is, or they need to change the default to something longer. I ended up going with 3000ms which always works for me.

I thought I would share this as a data point. A few days ago, I had an issue with my Elk and needed to change a rule. I logged in and made the change. I also decided while I was there to change the mail server Elk was using. After I finished and logged out, the Elk PG3 node server no longer worked. I was able to log into Elk via ElkRP without issue and confirmed the IP address and port numbers. Next step was trying a power cycle on Elk Ethernet adapter. Nothing changed. Then I tried a restart of the Elk node. No change, Then I tried a PG3 restart. Nothing changed. Then I tried Polisy resart, nothing changed. Then I tried "update packages" from the admin console. After what seemed like an eternity, I got the 4 beeps. But now nothing worked. ISY finder would not find ISY and I could not log into PG3 or PG2 from a web browser. I could login via Putty to Polisy. Finally, after an hour and half of messing around, I did a power cycle on PolISY and things came back online.

I'm pretty sure you get the same result by putting the "then" clause of program 3 into the "else" of program 2 and deleting program 3. Since your variable seems to have only two possible values (0 and 1) the result will be the same. In other words, program 2 will run false on a 1 to 1 basis with program 3 running true.

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.

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?

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