MrBill

Clear your java cache, including installed apps and applets, then download a fresh copy of the launcher by clicking https://isy.universal-devices.com/start.jnlp It's also helpful if you delete any and all versions of start.jnlp and/or admin.jnlp from your hard drive before you proceed with the above. Also remember after the new copy of the launcher is installed to expand the java cache. Personally I use -Xmx1024m rather the -Xmx512m noted in the wiki

What makes you think the GFCI isn't doing it's job? that is tripping because there is a ground fault. GFCI's are a very misunderstood electrical device. A Ground Fault Circuit Interrupter is designed to shut the power off as soon as it detects a very small 6 milliamp imbalance of power. What is an imbalance of power and how does it occur? Briefly disregarding the 3rd ground pin the electric circuit consists of a "hot" and "neutral"... the power travels out in the hot, and back on the neutral. A GFCI measures the power going each direction, when they are VERY EQUAL the power is allowed to flow. As soon as the GFCI detects that just a few milliamps of electricity got loose and didn't come back on the neutral the GFCI shuts off the power. It does that to protect people from getting shocked. (Conversely, a circuit breaker has a different job, it protects the circuit from overload-- to much current-- which causes fires.) Now that we know what a GFCI is, there are a number of ways to attack the problem but none of them are quick and easy. First you could plug the fountain pump into a different GFCI elsewhere and let it run a long time, plug it and unplug it several times... if the other GFCI never trips, then likely your problem isn't the fountain pump. Then there is that Insteon plug... you're correct those weren't designed to be used outdoors and moisture inside the unit may very well be the issue. This is a hard one to test for tho. The other problem could be a micro crack in the insulation of the wire going outside, whether it's in conduit or not, whether it goes underground or not. But consider that a micro crack in the insulation might not leak any current until the area around it gets damp and conducts a little bit of electrical leakage. Finally, it's not unheard of for the GFCI itself to be bad. Especially if it's an older GFCI (those manufactured back in the 90's or before for example). GFCI's also get less reliable as they trip more often, so if yours trips 12 times a year and has been tripping that way for 3 or 4 years... it might just be bad. So as you can see, YES you have a component, or perhaps components that need to be replaced. figuring out which is the problem.... or task.

turn off wireless writes: Press that button so that it's greyed out. Once you get your unactive devices deleted, you need to study the device tree looking for 1011 icons. those are wireless devices that need data written. Unfortunately it will probably be a slow painful process if you have very many. When you get to this phase put as many of the wireless devices with 1011 icons on the tree into setup mode that you can each time you do wireless writes. What's happening now is that every time you are writing to devices to delete and item it's trying to write to wireless devices.. and it's taking a lot of time to error out.

@ndorny The update you need actually came at the 4.73/4.75 So do as @Geddy mentions and update your firmware v4.9. I think due to the websocket vulnerability addressed at 4.73/4/75 you won't get the portal to work with 4.6.2

there are some .state files, but the names don't indicate theme, font, etc... see: https://wiki.universal-devices.com/index.php?title=Main_Page#Admin_Console_Minimized.2FInvisible_and_Cannot_be_Restored

Actually several things appear to be back in stock that were out of stock just 3 days ago...

Follow THIS INSTRUCTION to increase the Java Cache. Personally i use -Xmx1024m instead of -Xmx512m Keep in mind that anytime you clear your Java cache or a java update installs you will need to repeat this procedure.

1) Your Firmware and UI versions need to match. You're on a Mac so I'm not going to say you should be using the ISY Launcher as some Mac users seem to not have success. But you must clear your java cache, delete any files you have named admin.jnlp and then use http://<IP.OF.YOUR.ISY>/admin.jnlp to save a new admin.jnlp. when you're done and you launch the admin console both versions should be v4.9.0 2) the program you are showing us doesn't do what you have described. it works entriely on time, at sunset +30 minutes a scene is being turned on and a notification is being sent. At Sunrise minus 2 hours there is an attempt to send a notification, but the program says nothing about turning the scene off. The Sunrise part won't work tho, because it needs to say "(Next Day)" on the sunrise line of the IF statement. Also note this program has been changed/modified and is UNSAVED, which means it's not working. A program must be Saved before it takes effect. the green arrow on the program name is the clue. 3) the better way to post programs to the forum is to RIGHT CLICK the Program name and select Copy to Clipboard. Then in your forum post use the "<>" symbol on the tool bar and paste your program into the window that opens when you press "<>"/

I think it only prevents manual linking/programming... I think the PLM still can send changes.

I've only had it happen once. Depending how many devices you have, it may not be worth it... just fix it if you ever get a ghost link again. I also am not sure it would necessarily solve the problem, it prevents accidental linking.. maybe the ghost link didn't come from accidental linking, maybe it was a comm error.

I've had this happen. It's likely a ghost link I'd first try to factory reset the switch that's turning on when it shouldn't, then right click the device in the ISY and pick Restore Device.

@Michel Kohanim Here's a second vote for hoping it's added back. (actually I said the same in a different thread months ago too). While the differences between custom and the nearest timezone city are not often great, they are still different... and there is a nerd factor here... that said I guess there are two nodeservers... Sun and TimeData that would do the job.

Did you try Factory Reset, then Restore Device from the ISY?

I don't think there was a formal list of invitee's... I think @asbril just typed the names of the people that came to mind at the moment to gauge interest level. Heck how could there be a list, we don't even know the date yet!

Yes, but i'll add to this one: The nodeserver store for local Polyglot on Polisy (or rpi) is much larger than the the cloud store. To see the nodeservers available via the Polisy (or rpi) use this link: https://polyglot.universal-devices.com/

It moves the functionality of your ISY-994 from that piece of hardware to the polisy hardware... ISY runs as a process on polisy rather than its dedicated hardware. The first release will use the java admin console still... converting the admin console to something else (html5 perhaps) is on the grand roadmap, but it's still half a country away down the highway. yes.

I'd also suggest that you open a ticket and get some direct one on one help from support@universal-devices.com They'll get you back on track...

@dinostop I've noted from other threads that you also have Polisy/Polyglot. A much more reliable notification platform is the notification nodeserver which sends Pushover notifications. (Pushover has a one time charge for the app, with 30 day trial period.) There are a couple problems with email in general... the three biggest are your message can suddenly and unknowingly stop being delivered due to spam traps, sent mail counts etc. email can be delayed hours or days without notice or explaination the ISY only tries once to send an email, if it fails or times out waiting for the smtp server it doesn't retry. In general the Notification nodeserver is a better solution, but there might be a slight learning curve, an depending on how many different notifications you have it might take time to get things converted over. Earlier this summer the Norification nodeserver was updated to that it retries if a send fails, since that update I've completely abandoned email notifications.

to clarify, are you using the ISY Portal, or Mobilinc Connect? Edit to clarify: ISY Portal and Mobilinc Connect are two different portals, only one or the other can be used, they can't be used concurrently. I suspect you are using Mobilinc Connect as it has geolocation capabilities whereas with ISY portal there is no built in functionality. If mobilinc connect, please also click the 3 dots in the upper right corner of you post and select "report", and then in the popup window type "please move this to the mobilinc subforum"

You might want to open a ticket, support@universal-devices.com so that @bmercier can check the portal logs. Be sure to specify your portal login and a date/time and timezone (specifying the time as UTC is likely the simplest.)

so it's definitely a GH/Portal issue then. I have Alexa and no GH's so I can't make more suggestions beyond documentation. I'd try completely removing the close routine from GH, and the portal and then recreating it from scratch.

What happens if you right click the program name and pick "Run Else"?

Because you're interested, He was trying to do exactly what you said, but was in over his head. It was a Multi-wire Branch Circuit (MWBC) feeding the kitchen counter circuits and the pantry light (where he was trying to install the motion sensor). Because it was a MWBC it was fed by a two pole breaker (as required)(which was also a GFCI breaker, instead of counter outlets being GFCI themselves--the kitchen designer didn't want GFCI outlets "because they are ugly and have little green and red lights that don't belong in the tile colors", therefor it was a GFCI breaker instead) which is how he turned both circuits off from the start. The reason the romex got hot is because when you directly connect opposite poles the wire becomes a heating element, it gets hot very quickly. The reason it takes a few seconds to trip breaker is because every circuit breaker out there has a "trip curve" to prevent nuisance trips. Yes the trip curve will let the wire get hot... that happens very fast.. but the breaker trips before it gets too hot. The only thing that wasn't to code in the original installation is the kitchen counter outlet circuit shouldn't be feeding (under today's electrical code) anything else including the pantry light or the entryway light that that was also tapped into the circuit (I don't know but think they forgot to feed those two lights during pre-wire, on finish when they discovered they had covers unfed they made a "fix".

Your best bet is to do exactly as you have said. Install a smart switch in one location, and leave notes for the future about where the other wires starts and ends. You need to figure out which fixture contains the magic splice tho, and get in and re-work that.

You stated this: And I replied that it was a code compliant diagram, CURRENT CODE requires the WHITE wire to be installed as neutral whether it is used or NOT, regardless of the price of copper. Therefore I pointed out that it was a CODE COMPLIANT diagram, and why the code was created. You're absolutely correct in the OP of this threads case he must re-wire the circuit from wherever the source is and re-purpose conductors. If this circuit was being installed in new construction today, the 4th wire would be required if the circuit was created the way OP's circuit was created, it doesn't matter the price of copper, every switch location must have that circuits neutral wire present without re-wiring the circuit to get neutral. That's why I stopped and said the drawing is made to be compliant with current electrical code, not because it was made before the price of copper shot up.