apostolakisl

So the backup is stored on your server? And this happens whether you log in or not?

The backup files are tiny. Mine are only a few hundred k and I have a pretty loaded up system. So the data transfer from ISY to your phone should take a split second and the space consumed negligible.

Yeah, a message when you open the admin console that tells you how long since the last backup and a link to "backup now" would be another way. Probably easier to implement than UD mobile since currently UD mobile has no backup isy function, just backup your ud mobile. But since some people may go a really long time without opening the admin console but may open UD mobile daily, more likely to get a backup to a storage location that you are sure to have handy. I end up accessing my admin console from a number of computers and have my backups all scattered about and then losing track of where the most recent one is when you need it might be an issue. But certainly better than having no backup or only ancient ones.

Backing up ISY is one of those things we all know we need to do but tend to neglect. It occurred to me that perhaps UD mobile could have a feature that backs up your ISY to your phone's storage. Perhaps each time you launch UD mobile, it looks for your latest backup and if it is older than some period of time (that you can set), then it runs a backup. Now you have an "offsite" backup of your ISY configuration immune to any hardware failure on the Eisy itself.

I agree. Now that eisy is a system with lots of memory and resources, having it run backups at some interval of your choice and store it internally would be nice. Of course you should still export backups from time to time in case the eisy suffers a catastrophic failure. But certainly it protects you from yourself . . . making mistakes and then not remembering how to get back to where you started. Backups are super tiny. Another option would be to have that feature in UD mobile. It could save to your phone and then the backup is securely on a different physical machine.

You can backup your current eisy config before you restore an old one. You can always reverse that and restore back to your current config that you just saved. But if everything works fine with a restore point prior to the power failure, then you know the eisy got messed up. Although since you deleted and re-added some devices those might not align with your old backup. Also, as mentioned, you can export programs and then import them to the restore. You can also take screens shots of your programs pages for reference. If you are talking about a dozen programs or something it wouldn't be pretty easy. If you are talking about 100 programs it would be more tedious.

my water company told me to buy a flume a few years back. Then a couple years later they came through and replaced meters with one that flume doesn't read. Very annoyed. They actually left the old meter, so my plan ultimately when I have the time is to put the old meter back in after their meter so I can use my flume again. We really liked the flume a lot. The water co app is just terrible. It tells you about potential leaks like a day after it happens. All of these leaks they have warned us about aren't leaks, but if they were, it would have been far too late for their warning to have done any good. Anyway, Flume worked great with ISY until about a year ago when I had to uninstall the flume.

Whatever the issue was, it seems to have been fixed. I received an email today at 9:04am and did a test and it worked as well. @Geddy I am using a gmail account on a different isy and it works great. But on this one I didn't see the point since it was so easy to just click the default. I haven't had issues with it and I have been using it for over a decade. So who knows. I'm sure some server somewhere got messed up and needed to be reset.

I have stopped receiving emails as of early this morning from my ISY set to default mail server. Hitting the "test" button in the email section of the admin console gives me an smtp error. The last email I received at 4:32am today. I should have received quite a few since then. I hadn't touched the system between than and now, so no changes I made could have done anything.

I believe it is possible to set Insteon switches to not blink the green/red leds for comm status. As I understand you, for whatever reason, the switches think they are failing when they aren't. Ideally, you would solve the root problem. But if they all work and you can't figure it out, you could just shut off that feature. I believe if you go into options on the device in the admin console, you can't click "no led".

I don't know why eisy would request a new address and decline to accept the reserved address the dhcp server offers up. As I mentioned before, pretty sure that is all handled by freebsd OS, not ISY application. I would research freebsd network interface configuration and see if you can't overwrite it with default settings. It sounds like something is funky in there.

Looking back at the original post, he says it changes every 20 minutes or so. That is hard to explain. The device (eisy) asks for a lease via a network wide request (the first time), the router hands out an ip with a lease length. Check the router to see what that time is set to, 24 hours is common. The device keeps track of its lease time and it requests an extension at the half way point. At this time, the router could give out a new address (but wouldn't unless you changed settings on the router). Devices usually don't put out a broadcast request for lease renewal, it usually goes directly to the dhcp server IP that gave its current lease, so a second dhcp server shouldn't even know about it. If it asks for a renewal and gets back crickets, it will just keep the current IP address and keep trying. At least this is how I understand it all works. Anyway, for the ip address to change in 15 minutes, that would imply the lease time was only 30 minutes and that the request for renewal came with a change of IP. I expect that FreeBSD is handling all of this. I don't know how that could get corrupted in such a way to do this weird behavior. I'm assuming all of the IP addresses that eisy is using are on the correct subnet. Assuming that FreeBSD was going bananas and just giving itself random numbers, they would not all be in the same subnet. IF you telnet into eisy, there are commands to see the status of the dhcp client, you would have to look them up, I don't know them off the top of my head. You can also assign a static IP address via telnet. Again, need to look up the commands.

Is it possible you have two dhcp servers on your network? If the mac address is always the same, but the ip address is changing, this has to be a problem with whatever is assigning the ip address. When you see the non-correct ip address getting assigned, is it always the same "other" address, or is it always seemingly something random? If it was an issue with it switching back and forth between wifi and ethernet, you would get a different mac address for wifi and ethernet, but I would expect it to keep getting the same ip address when on wifi and the same for every time it is on ethernet, even if you don't have static dhcp assigned to both. DHCP servers generally give the same IP address to something over and over unless it has been offline for an extended period of time. I doubt ISY firmware plays a role in IP address at all. The Eisy/Polisy firmware runs on top of FreeBSD which I am sure is handling all of that.

It appears that the https://trigger.esp8266-server.de/ server is now a gonner. Other options included voice monkey and ifttt. But both of those have very limited free options and I have no intention on getting into one of those recurring charge things that I forget about and a decade later you gave them $1000 for something you forgot you even had. Anyway, I decided to go with virtualsmarthome.xyz which is free, but you can (and should) make a donation. It works the same going through network resources so all I had to do was update the network resource and update the routine in Alexa to switch from the esp8266 setup. chat monkey works the same as well. virtualsmarthome.xyz nodes in Alexa default to being doorbells, so you have to also shut that off, assuming you don't want alexa to make a doorbell announcement every time you trigger the url. The process is 1) enable the virtualsmarthome.xyz skill in Alexa 2) login to the virtualsmarthome.xyz website using your primary alexa account 3) Where it says "create . .. " fill in a name for your trigger. I include the words "virtualhome.xyz" in the name so I don't get confused about it later on when I can't remember what the heck I was doing way back when. 4) A few seconds later, Alexa discovers it and you will see it under the devices tab. Open it up and uncheck the doorbell function. 5) In Alexa, create a routine and put the virtualsmarthome.xyz device you just made as a trigger for the routine. 6) Return to the virtualhome.xyz website and open up the trigger you just created. You will see the following info. Copy everything starting with to the end </url_. . . > I used the json response. 7) Create a network resource in ISY and format as below. Paste into path what you copied from above. Set the it to "get", fill in the host and delete from the header section all the stuff not listed below. 8) Create a program in ISY that triggers the network resource as you desire. Note: I decided not to use ISY portal connection to Alexa that can directly trigger routines because of the 30 second time out after each trigger. This just doesn't work for me. You may ask, why do this? For me, the whole reason is that I have several items in my home that do not have ISY polyglot nodes but do have Alexa integration. Specifically, Levalor motorized blinds and some ceiling fans that use the Tuya control system. Both of these have Alexa skills, but not ISY polyglot nodes. This allows ISY to control those devices using Alexa as an intermediary. In short, anything that has an Alexa skill can be controlled by ISY in this fashion.

Google voice allows email to text, but it is slightly tricky to set it up, but once set up it works perfectly every time. You need to enable google voice to send a copy of all your texts to your email. First thing is to receive a text from the phone number you want to send texts to. This could be you sending a text to yourself. Then copy the from address in that email copy of the text and put that as the to address in ISY. That address defines for google voice where to send it, both the phone number and the text thread. Of note, the email account that ISY sends emails must be the same one you have google voice copy texts to. It follows this format <yourphonenumber>.<thetophonenumber>.<stringofnumber/lettersthatidentifythethread>@txt.voice.google.com I sent myself a text to get the thread going so the two phone numbers in my case are the same. I set this up this many many years ago and the thread still keeps going. If you want to send the text to someone else, you would need them to send you a text or reply to a text from you to get that email address format I showed above..