apostolakisl

It isn't the node that fails per se, it is the Tesla server that goes offline, then the node isn't resetting when the server comes back online. I knew that Tesla was offline because my Tesla phone app stopped working too.

I have seen this twice now. Tesla server seems to have gone down for a period of time, the node says "failed", but when the Tesla server comes back online, the node still says "failed". Restarting the node does the trick, but it seems like it should have a mechanism to fix itself in this situation.

Yes, I guess I wasn't clear about the at home car is with sentry off. Sentry definitely uses some battery. Waking the car up once per day doesn't use much battery.

I have been running the tesla node server for about 6 months, basically since it was a thing. The short poll just queries the Tesla server and does not affect the car. The long poll will wake the car up and you will lose quite a bit, maybe 5 percent or more per day if you have your long poll short enough that the car never sleeps. I made this mistake when on a 2 week vacation and checked my car about 1 week in and saw that I lost like 40% of my battery. I turned off the node server and then it lost barely anything for the second week. I did not have sentry mode on at all for this trip. I currently have the long poll set to 24hours and the short poll to 15 seconds. When my car is at home and not plugged in, the battery hardly loses anything, less than 1 percent per day. At the airport, with sentry mode on and long poll at 24hours, the car loses a couple percent per day.

Turns out deleting the java applet and reinstalling fixed the clock. So I guess it was just the time displayed on the admin console and not the time running on the machine.

My Polisy also did not adjust for DST (still on Standard time). I believe that my programs still ran correctly, but probably wrong by an hour. I was out for the evening both Sat and Sunday night so didn't notice. Time zone is set within the admin console to the correct location and the DST box is checked (but greyed out). In PG3, I see no time settings. In PG2 I have the location set, but there is no DST setting available. I don't know anywhere else you might set the time zone. Do I need to change my location to get the time correct until a fix comes out for this? Of course changing my location will screw up sunrise/sunset.

I have been pulling my hair out with geofencing. I am on Android. I take it that UD Mobile on IOS has native geofencing . . .yes? Will this be on Android soon? I have been using the antiquated UDI Mobile with a frustrating level of works almost all the time, which is just good enough for me to keep using it but get super annoyed when it fails.

Looking at maybe doing some yolink stuff. But I want the node server to access locally, no cloud. Can't figure out from the description here is the node server is locally accessing the hub or it is accessing Yolink's server. Thanks

I can't say if this is your problem, but really the only point of ISY failure I have ever seen is the SD card going bad. You might try replacing the SD card and then restoring.

Does it make any difference which flirc? I've never used flirc and I see they have a couple models. Currently, I took my old isy99ir out of retirement and have it accepting the 40 IR codes and then relaying to my polisy. It was fun trying to dig up the admin console software to do that. My needs are not complex. I am using about 20 of the 40 IR codes and doubt I will ever need any more.

Polisy has usb ports, so I could plug a flirc in, but would it work? Also, is it possible to have flirc/your node server automatically load the standard 40 ISY IR codes?

I have tested it and it appears to work now. I connected elkrp2 to the system, disconnected, and ISY still had access to the system. Thanks. @Jimbo.Automates

Wouldn't any processes be reset with a soft reboot? Anyway, I'll test it out tonight.

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.