apostolakisl

I have a similar issue with an Elk node. I have two garages that are monitored by Elk alarm. I set them both up to display on my favorites page. But only one of them ever populates without doing a query. The other always populates. They are identical to each other except for the specific Elk sub-node referenced. It has been like this for a very long time. If I close UD mobile and open it back up, the node is again not populated. According to google play store, I am up to date on ud mobile app. If I look at all of my Elk nodes, it seems hit or miss which ones are populated. What can I do about this?

No, you can't. But you don't need to set the on level to 0, just use the controller off button. Of course if you want it so that no matter what action you take at the controller, the scene turns off, then you would need to set on level to 0 for all devices. If it is a kpl, you can set it to non-toggle off instead. Isy used to let you propogate the settings for one controller to all of them, but they got rid of that many moons ago when they added non-insteon products. Apparently the logic broke when applying to node server devices.

I now have 3 connected Venstar thermostats. I just added a 4th, and it won't connect. This makes no sense. Two of the others also wouldn't connect, then one day out of the blue they started connecting. The 3rd unit discovered immediately. I do not understand this. I ask the thermostat to do a firmware update and it says it is already up to date. The others supposedly were also up to date. Perhaps some update is actually happening after being online for a while even though it says not? Two of the connected thermostats are t5800 with wifi key, and one is a t7850 with built in wifi. The 4th is also a t5800 with a key. All of them are connected to the Venstar skyport server without issue.

Speak for yourself. Texas time. . .

Just turn off DST and and use UTC-x hours. No need to pay any attention to the name of your time zone. Like I am in UTC-6. Personally, I am a fan of DST always. I didn't notice any issues with DST except that programs that run continuously looking for failed heartbeats all reported failed heartbeats at 3am. These programs all track thermometers and look for any change in the temp or humidity which restarts the program. They all have a wait time of 10 or 20 minutes and if no re-trigger of the if clause happens in that time, they send an email. So the jump from 2am to 3am was interpreted as no update in one hour. So I guess a wait clause is not a running timer but rather sets a start time upon starting and then loops back every cycle of a code and does some subtraction. Since 2:05 never happened, and the program triggered at 3am, it must do it that way. I would think that things like waits would run on UTC time and be unaffected by the displayed time, but obviously they use the displayed time. I would expect sunrise and sunset to always run on UTC and your latitude/longitude and therefore be unaffected by chosen display time. If ISY just ran on UTC time everything would work fine through DST switch except something scheduled to happen at displayed time between 2 and 3am.

The eisy-ui is stable, it is just not complete. It is not yet a replacement for the java ui. It is mostly just a place to view things, not program things. You can turn lights on and off and stuff like that.

What link doesn't work? The link I posted works. I just did a java update and used that link to reinstall iox finder last week. And clicking it today downloads the file, though I didn't try installing it.

I linked this page to my bookmarks and use it. It has never been changed and still works today since it was posted in 2018.

Iox finder would be perfect if it weren't for Java updates. You would load it once and be done. Any isy that it finds or you direct it to find (port 8080 or an isy on a vpn or vlan) would populate and be there indefinitely regardless of isy firmware current or future. But for some stupid reason java makes you redo it with every update. I just bookmarked the page for the start.jnlp link so I can quickly redo it after each update of java. I have not tried where iox finder lets you save/load your configuration. Probably that would let me not manually add back my off-site isy and port 8080 preference.

Must not have been using finder. The start.jnlp link must be used, not admin.jnlp. The finder can access multiple isy's on different firmware at the same time. For a while I had a 994i and Polisy at the same time with way different firmware. Clearing the cache is still an issue after updating java, not after updating isy. For local credentials you must manually add. Http://xxx.xxx.xxx.xxx:8080. If you let it automatically find your isy it will go through portal credentials. It really would be fine if it weren't for java updates. Seems like every windows update triggers a java update.

I believe that loads a firmware specific IoX launcher. At least it used to, perhaps that has changed. I have had issues with that in the past still getting messed up by cached Java stuff when firmwares change. Again, I haven't messed with this in a long time since I just keep using IoX launcher that I downloaded a long time ago that keeps working on multiple and updated versions of ISY firmware without needing any update to the launcher. The main issue I run into is after updating the actual Java app, not updating ISY. I also manage multiple ISY's at different locations over VPN's so I manually put in the IP addresses. Though you could also go to the ISY portal and copy the portal URL for your ISY and do it over the open internet. In short, either way works. I would suggest that he completely clear Java cache and applets to be sure that everything is starting off fresh.

When you load IoX launcher on your desktop, it will find ISY automatically but it will only automatically give you the portal login. If you want to add the local option, click "add" and then type in the url. ie, http://xxx.xxx.xxx.xxx:8080 or you can use the https://xxx.xxx.xxx.xxx:8443 if you want an encrypted connection (I don't see the point when inside your lan). If you have your ISY across a vpn or on a different vlan, or you have auto-discovery blocked by your router, then you will need to manually enter the ip no matter what. Whether you use the local credentials or portal credentials, it doesn't matter, both work the same. And the login prompt will tell you which to use in case you lose track of what you clicked on. EDIT: This is where you want to delete all the java saved applets and configurations. This is very important. When you relaunch the start.jnlp you will get the iox launcher that autodiscovers the firmware and works across multiple firmwares of ISY. Generally, I have found that it will also not need to be cleared again upon further updates to ISY. But if it starts giving you issues, then just repeat this process.

Clear your java cache. https://www.java.com/en/download/help/plugin_cache.html. If you just type java in the windows search box you'll see the java admin as an option. Delete all temporary files and applets. Then download the following. https://isy.universal-devices.com/start.jnlp It will put the iox launcher icon on your desktop and it will always get the right version. Even multiple versions if you have multiple isy's.

Both units are working now. I don't know why. The only thing I know of is that we had a circuit breaker pop that caused the wifi AP and managed switch that these thermostats use to reboot. But I find it hard to believe that this was fixed by that. Everything else on those devices worked fine before and after and I was able to get responses on port 80 doing "curl" queries from the polisy.

Today, I tried hit "discover" again, and for whatever reason, it finds the t7850 thermostat. The one that was working with nodelink. Still not finding the t7800 with the wifi adapter. I have no idea why today it is finding the one thermostat when it wouldn't before. I changed nothing.