apostolakisl

No. I just did the update a few minutes ago so haven't tried. It is now running .8 But since you had never seen this issue, I'm assuming you didn't do anything that might fix it between the .7 and .8 versions. Unless you accidentally fixed it because it was something in common with another issue you did know about. Just seems very odd to me that an entire power cycle of polisy is needed. What issue could persist through a restart of the node or a soft restart of polisy?

It was reproducible. Both time I connected to ElkRP2 I had to power cycle polisy. Soft restarts of the node and PG3 did nothing either time. The first time I also tried power cycling the Elk ethernet module.

@Jimbo.Automates what about the problem with having to power cycle polisy after connecting to elkrp to get it to connect again?

@Jimbo.Automates This has happened again. I needed to use ElkRP, logged in, did what I needed to, logged out. The node server was now not connected. Restart the node, nothing, restart polisy from the PG3 console, nothing. Had to hard power cycle polisy to reconnect. In addition, I am on 3.5.7 while the current is 3.5.8. None of any of these restarts updated to the latest version. My Tesla node server also is not updating even though it is an old version. Something is not right with this.

@arf1410 That works fine, but can be very tedious if there are a lot of dates.

another way to do it is if $x is 0 or $x is not 0

Pretty sure UD is going to say "sorry, can't do anything". I have noticed this at times and am confident it is an Insteon hardware issue.

That is interesting. I wonder just how "shut down" it is and if a bad actor could know about that interface and turn the drives on. Personally, I have done shut down drives two ways, one is with ISY and appliancelinks, I do it like this for my church backups. It is very easy to setup. But someone who knew about it somehow could potentially hack ISY and turn the drives on remotely. For my business backups, I set up a webcontrol board, programmed it using its own internal language and then have relays control the power supply. The webcontrol board is unhackable, the device, once programmed, does not need an internet connection and thus I have it unplugged from the network. It is impossible to turn those drives on remotely. And the hard disconnect also protects against power line spikes and having zero electricity in the hard drive should give some resistance against a water event. Certainly the NAS with this built-in feature is going to be the easiest to configure. My webcontrol board required wiring up some relays in addition to programming it using a somewhat archaic language.

I wrote a program that calculates Orthodox Easter. I am not positive how Western Easter is calculated, but Eastern Orthodox is a bit complex. It is the first Sunday, after the first full moon, after the spring equinox. Sounds easy enough to program, right? Wrong. The issue is they don't use the actual equinox and the actual full moon. They use predictions for when these things would be, not when they actually are. And the math was done thousand years ago and isn't accurate. Also, while these things happen at a moment in time that is the same everywhere, the date on the calendar is different depending on where you are on the planet. In short, it is easiest to just input the dates manually for the next 10 or 20 years or whatever. As far as being the last day of the month. This is not hard, though bulky. You could do this with fewer programs using a else wait 24hours for all of the 30 day months and skip the 31 day month program, also for leap year feb. But I prefer not to use wait 24 hour lines since a reboot will cause issues. If month = 1,3,5,6,8,10,12 and day = 31 Then do backup If month = 2 and leap year =0 and day = 28 Then do backup If month =2 and leap year = 1 and day = 29 then do backup If month = 4,6,7,9,11 and day = 30 then do backup EDIT: You could also ask the maker of the node server to add a field "last day of month" that is either true or false.

The other option if he doesn't want to change firmware or start using node servers is to install the programs I wrote over a decade ago and are on the wiki that do the same thing the node server does. Those programs work perfectly and for the most part I still use them because . .. they work perfect. But if I were starting from scratch, I would do the node server. https://wiki.universal-devices.com/index.php?title=ISY-99i_Generic_Calendar_Using_Programs_and_Variables

This only picks one day. You would have to set an "if" line for every single day you want.

I have similar concerns and manage it similar to what you have suggested. First, installing node servers is a pretty good idea. You will need to upgrade to the newer hardware UD sells (Eisy). There are probably 100 or more node servers now that create nodes on your ISY for boat loads of things that aren't Insteon or Zwave switches. So many things you just need to peruse the list. I have node servers that track my electricity usage from Emporia energy monitor, my water usage via a Flume, my Tesla, my alarm systems, my Blue Iris security camera software, and a bunch of other stuff. The one node that pertains here is one that creates nodes for a bunch of calendar stuff. So you can make a program that turns something on every 15th of the month, every June 3rd, or you get the idea. Each of the items in the screen shot below is a node that you can use in a program. You can also make something happen every 3rd day or whatever using the days since epoch (ie for 3, divide by 3 and run it when the remainder is either 0,1,or 2 depending on your preference). Anyway, back to the data threats, I have a series of hard drives that backups are saved to on a schedule. The hard drives are powered by Insteon appliance links. The hard drives are only powered up while the backup is being made. Furthermore, new backups do not overwrite old backups, so if I get encrypted, I don't ruin my non-encrypted backup I previously made. The appliance link creates a hard disconnect between the hard drive and electricity which protects it from be accessed by anyone wishing harm. It also protects it from power surges. Furthermore, if you have a water event, often times hard drives will survive submersion if you properly dry them out before applying power. At least long enough to get your data off anyway.

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.