apostolakisl

Every time I log in I am told there is an upgrade to install. However, it does not appear that this is the case.

Not sure what that is.

6.1.1-6.1.2

Just did an update packages from eisy ui. It seemed to go fine, didn't take terribly long. Though I needed to restart all my plugins after the update. Something I hadn't seen before is that opening the admin console told me that iox finder was on the new version and iox was still on the old (6.1.1/6.1.2) It asked if I wanted to update iox, I said yes. I was then able to immediately re-open the admin console, so I don't know what update happened, couldn't have ben much in that ime. I have seen the opposite of that message before where I had to clear out Java. I believe this is the first time I have updated from the eisy upgrade packages vs the admin console trigger, not sure what if anything that changes.

Power surges often take out the power supply or make them flaky. I would try that first. Next, try pinging the ip address of your ISY. See if is even booted up. Or just try to ssh into it. Depending on your model, check out the led lights on it. Wouldn't be surprised if you need to open a ticket. Though if it is not an eisy, they no longer support the older stuff.

I have what I believe to be a bug free update to the Pentair plugin in the beta store adding intellicenter support. I'll be moving out over to production here shortly. This single plugin supports two api's and will auto-detect yours. Both work through the same phone/web app, username/password. It is cloud based, there is no local connection option, if Pentair shuts down their server . . oh well. If you have an intelliflo3 and/or a color sync device directly connected to he internet, you are on one api. If you have an Intellicenter where all of your devices first connect to that and then to the internet, you are on a different api. The intellicenter api is tested to work with intelliflo pump, intellichlor, intellichem, color sync, and aux device connections. Pentair does have a few more "smart" devices that I have not had access to. The prowler, intellisync, intelliconnect, and ChemCheck I believe rounds out the list of stuff not in the plugin. Likely these things could be added. If you have any of these devices and are willing to share access with me, I likely can add them in.

Pentrair_beta is now posted to non-production store. Adds Intellicenter functionality. Pentair has two completely different api's that both reside on the same server/login structure, so regardless of whether you have intellicenter or just direct connect of pump/lights, this plugin, username/password setup works. The plugin self-discovers the correct api to use based on how your account in pentair was configured.

@macjeff The possibility is that you are using a different account than your stuff is registered to. Logging out of your account on your phone app and then logging back in manually entering the same username and password that you used in the plugin will test that. The second is maybe more likely and that is you are using a different system that runs everything behind intellicenter. I really don't know the details on how pentair has evolved their system. Currently, I believe they have gone to a system where the devices all connect directly to the cloud, but you may be on a system that everything connects through intellicenter. My pump and my colorsync both have their own wifi and both log directly into Pentair server. Pentair says an IntelliCenter account should now be accessible through the Pentair Pool/Home app after migration, using the IntelliCenter account credentials. Have you done a migration? This is how my app looks on my phone where it all connects directly to the pentair pool app. Are you using this same app or a different one? This plugin may just not work using that different system. When you login, 1) are you using this app, and 2) does it list all your items as primary items or does it list your intellicenter with other things under it?

Please use this thread to ask any questions or comment on my plugin. This is my first plugin, but I think I got it bug free. The Levolor plugin connects directly the Levolor InMotion Hub. You will need to install the InMotion app on your phone and set up your blinds using that if not already done. From the app, if you tap the "about" page 5 times it will report the api key for your hub. You will need this key, plus the IP address of the hub. You should set your router to reserve that IP so it is always the same. From there, install the plugin and set the two parameters (ip address and api key). The plugin should immediately connect to the hub and query it for any blinds you have setup in it. This should take just a few seconds. If you still don't see any number next to the "nodes" field on the plugin, refresh the web page. You will get x+1 nodes where x is the number of blinds you have. Restart your admin console. You should see a new node on your main tree called "Levolor Controller". Sub nodes will exist for each blind you have. Controls include to directly set it to a percent closed (0% is open, 100% is closed) or you can execute an open, close, or stop command. This is the same as the InMotion app. I only have Levolor blinds and only created the plugin for blinds. Basically, open, close, stop, and percent. Other features like tilt exist that I can't test. Perhaps if someone has those types of blinds and wants to work with me, I can update the plugin. The plugin is limited by the communication between the hub and the blinds themselves. In my experience, sometimes the hub isn't accurate. Both the InMotion app and ISY will give you information that is not correct at times. In addition, the app and plugin will both be a bit delayed according to polling between the hub and the blinds and between app/plugin polling of the hub. I have found that ISY and the app both update status nearly simultaneous, so mostly it is a blinds/hub delay. This is a property of the InMotion setup and nothing in the plugin can change that. Regardless of the plugin/app status reporting, executing commands has had 100% success in all my testing. I have the response time to be less than a second consistently.

You can only do this by deleting the old plugin first then the slot opens to re-install. I won't bet my life on this next statement, but, I am pretty sure that if you delete a plugin and then re-install the same plugin in the same slot, any programs that reference any of those nodes will re-populate. When you install the plugin back in, all of the nodes should get the exact same id's and all the programs should put them back in. What won't re-populate is any customization you did on the main page of the admin console. In other words, any folders you put stuff in or any re-naming you did. I would confirm with @Michel Kohanim on this. EDIT: You might also look at the new eisy-ui beta plugin section. It might make things a bit more stream lined for you.

I updated. The update proceeded without issue and didn't take too long, maybe 15 minutes. I got a message requesting a reboot and I went ahead and did that. The system booted up and I was able to access both eisy ui and the admin console. @Javi Bug? I tried to create a random test program in Eisy, but it failed. I selected an insteon on/off module status as the if and an insteon dimmer as the then clause. Eisy UI fails to create the if statement. I got the drop downs and set the parameters and it gives an invalid error after saving. It shows up in the admin console with a yellow icon. I then created the same if clause in the admin console, and it did work. This is my one and only attempt at creating a program in eisy ui. Here is a screenshot. The second line of the if clause is what I created in the admin console. The first was the same line created in eisy-ui which reverted to this error. Before I hit save. The line after the "and" is what I just created in eisy ui. Then after I hit save

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.