raymondjiii

Yes, I get what you are saying but Optimum (Altice) does not allow anyone access to any such advanced settings. For the same reason that UD insists that EISY uses DHCP - to limit support calls. I'm going to request Optimum put my fiber modem into broadcast mode and I'll use my own router to manage things.

Ahhh, I think that is what I am remembering! In IoX the "Use DHCP" check-box is greyed out (can't be turned off, at least easily) - and (see below) EISY always gets the first (lowest valid value) DHCP IP address. And now that I adjusted my fiber router I find that eisy always takes the first IP address in the DHCP range. This happened in the past regardless of the internet provider modem I was using - EISY ALWAYS grabbed the lowest DHCP address. I wonder how EISY does that. I thought DHCP was like: "hey, give me an IP address", "okay, here you go, it's valid for x minutes", "okay, thank you". I did not realize that this new Optimum router I got, which you can only manage through the optimum.com website, has only 1 setting where you can set "the valid range of IP addresses" - unfortunately, what they should have said was "DHCP range of IP addresses". By default, the range (dhcp range) starts at x.x.x.15. I was having crazy camera problems where a camera would go down and then the washing machine would grab that IP address, and then the camera never works again (and worse). I did not know all of this was happening until today. All of my cameras use static IPs for nvr. So today I changed this config setting to start at x.x.x.151 upward for DHCP. And then I got all of the dishwashers, laundry machines, Feit floodlights, Chamberlain garage door openers, etc to give up their IP addresses and make new DHCP requests and get everything out of what I thought I was using as the static IP range. I finally have full inventory of every network interface MAC address, wifi or wired, static or DHCP. Most importantly, every camera works once again. This wasn't the point of this original post, I was just surprised that my EISY was at a very low IP address...lower than I had ever seen before....which thankfully then led me to discover this "mislabeled IP range". I then started querying all MAC addresses and map them to the corresponding IP address. I figured out what was going on by, I would get the MAC addresses of one camera and then I found its corresponding MAC address mfg-ui was not for the mfg that I thought was using that IP address - because another device was taking over the IP address of what I thought was a static IP. Finally, I was able to fix every issue with every network device (most problems were for the outside cameras). And now I can watch every bird at all of the feeders and bird houses (I have a large bird environment outside). In summary, EISY led me down the correct path for fixing this camera insanity.

I am sorry to ask the question, my EISY has been running pretty flawlessly for years and I simply cannot remember where I saw this: "Somewhere" I remember seeing that EISY "must" use a specific IP address or use an IP address that is greater than ??? I remember when I first bought my eisy years ago I had to fiddle with the router and change the DHCP range so that EISY could use the address that it needed. I remember something about that it was at a static address so people wouldn't mess with it and cause a ton of support tickets for UD when they screw it up. I cannot remember where I saw this! I can find the eisy on the network, with IoX, eisy works - everything is good - nothing is wrong with the eisy. I do not want to change the IP address but I thought it was like a static address of like X.X.X.150. I just remember a screen where it showed that either the eisy IP address had to be X or had to be greater than X but for the life of me I cannot remember where I saw that. I don't think it I saw this via ssh (I do not believe that I have ssh enabled). I do not have an hdmi monitor connected (nor USB keyboard or mouse) to my eisy. I have a new fiber modem and I want to find that setting that I saw years ago so I can set the static IP range and DHCP range appropriately on this new modem. Do I need to plug the eisy into my TV? I do not remember ever attaching the eisy to my tv to view anything. Thank you. Just to clarify, according to my router the eisy is at 192.168.1.41. I'm not asking what address my eisy has, I'm asking what range does it need to reserve it's IP address.

I definitely did not reset the eisy. But when I did not see the "wet off" status (kept seeing "wet on") - then I pulled the battery, put it back waited a bit but nowhere near an hour. I guess next time, I will let it "sit". I just wanted to make sure the sirens didn't go off again during my zoom call. I could have ran around the house unplugging them I guess but I'd rather just learn how they reset automatically or if I need to do anything manually.

So I had a small leak. Found the leak detector that was triggering the alarm - everything worked perfectly. I cleaned the contacts of the leak detector but 1) could not figure out how to reset it that it was no longer wet - I guess you can't. 2) I saw no way in IoX to reset or query anything. Eventually I got the "wet" status to go from On to <blank> I deleted this sensor, re-linked it, added it back as a controller for my sirens. Is there an easier way to do this? Is it just a matter of waiting a period of time maybe? Thank you

Wait a minute....I woke up at 4am, all of the outdoor lights were on. I opened UD Mobile, went to Favorites and hit the Outside lights button and that was it - done. It could be intermittent thing I guess.

7 low voltage (12V AC) transformers and two strings of LED lights - each item is plugged into it's own outlet (the Insteon dual controlled outlets top and bottom). They all couldn't have gone bad at once. But I can try to unplug one every night and see if that makes a difference.

Maybe....but it's been same load since I owned an Isy994 and now and Eisy.

I've had the Eisy for about a year maybe - every thing was fine until 2 nights ago. When I saw that things were not working I did a hard reset, restored from backup and waited to see. The next night things still did not turn off. The thing is other "turn off at" programs are running fine. Just not the outdoor one, there are about 10 devices in that program. From the days of X10 I would always make a second one to run in case the furnace was on when the first one ran (runs like 15 minutes later). Oddly, that one did not shut things off either. Then I wondered, it's cold out - but they do respond to the turn-on program. But, one of the 10 devices is inside (a switch that powers an outside receptacle) and that one did not turn off either. So I am ruling out the cold weather, which I found hard to believe since it was all devices. I'll see what happens tonight and tomorrow night to see if that quirk resolves (but the other turn-off time of days programs are working fine). I believe the firmware was updated to .4 on that hard-reset, but then again the one turn-off program stopped working at .3. The only thing I can think of is too many devices in the program (which was never a problem before).

These is just a sample of what's there. I started looking at this file because a couple of my programs to turn off devices at a particular time do not appear to be running since 2 nights ago despite IoX showing them enabled at start-up. The 'turn-on' at sunset programs works but the 'turn-offs' at 10:45pm do not seem to run. So I was curious what would be in this file. Since it is an "error" file I would generally expect this file to be empty - things are running fine. I also wasn't sure when someone would want to run the "Restore PLM" option in IoX, as if would running that fix all of these random errors? I did not want to try since that requires all battery devices be turned on and to gather them all would be a hassle. In the end I just want my "turn-off" programs to run (which do not involve any battery powered devices) and am very curious why there is so much content in the error file. Also curious why the filename is called ISY Error Log and not EISY Error Log at 2024/12/07 04:26:40 AM 0 -170001 <s:Envelope><s:Body><u:GetISYConfig xmlns:u="urn:udi-com:service:X_IoX_Service:1"></u:GetISYConfig></s:Body></s:Envelope> Sat 2024/12/07 04:26:46 AM 0 -170001 Authenticate Sat 2024/12/07 04:26:47 AM 0 -170001 <s:Envelope><s:Body><u:GetStartupTime xmlns:u="urn:udi-com:service:X_IoX_Service:1"></u:GetStartupTime></s:Body></s:Envelope> Sat 2024/12/07 04:26:47 AM 0 -170001 <s:Envelope><s:Body><u:GetSysConf xmlns:u="urn:udi-com:service:X_IoX_Service:1"><name>/CONF/INTEGER.VAR</name></u:GetSysConf></s:Body></s:Envelope> Sat 2024/12/07 04:26:48 AM 0 -170001 <s:Envelope><s:Body><u:GetSysConf xmlns:u="urn:udi-com:service:X_IoX_Service:1"><name>/CONF/STATE.VAR</name></u:GetSysConf></s:Body></s:Envelope> Sat 2024/12/07 04:26:48 AM 0 -170001 <s:Envelope><s:Body><u:GetVariables xmlns:u="urn:udi-com:service:X_IoX_Service:1"><type>1</type></u:GetVariables></s:Body></s:Envelope> Sat 2024/12/07 04:26:48 AM 0 -170001 <s:Envelope><s:Body><u:GetVariables xmlns:u="urn:udi-com:service:X_IoX_Service:1"><type>2</type></u:GetVariables></s:Body></s:Envelope>

No, it's not there when you right click. "Open With" is still there but nothing in the list worked for start.jnlp. I just searched for how to get around the restriction on running a jnlp file on Sequoia and .... "AI" found running it on the command line.

Also, before this in "Privacy & Security" down near the bottom you will see a little box saying that start.jnlp was prevented from starting (because it's not signed by a developer or whatever) so you have to enable that first - it's hard to see and you would not think to even look there - at least I didn't. I was trying to do "Open With..." etc and that's when I found that at cmd prompt you could run: javaws ./start.jnllp and that did not have any issues. But I do see javaws in the list now (the same list you are showing above.) Every upgrade, I think more is broken than added. Maybe it will be nice that I can access the iphone screen on the Mac - time will tell if that's useful for me.

It wasn't adding it. I knew exactly what the IP address as I could see it's MAC address in the router (MAC address is on the bottom sticker) - so I was 100% positive I had the right IP address. I tried http:8080 and https:8443. As I said after "pushing buttons"...for a while...it was able to show and then I had to restore it from a backup.

Okay thanks I'll try that. Currently I have 10 items there including "IoX Launcher". I was just going to create a shortcut to run "javaws start.jnlp" - that avoids all of this (at least it did last night). I had a ticket open with UD but that was for the weirdness I was experiencing with the Eisy - which I think is also resolved...I hope. I just installed Sequoia last night. I was waiting until December when I knew that if something would be altered (like my other programs) I would have time to resolve but I wasn't expecting this problem. I doubt apple is going to fix this anytime soon. I have a large list of UI bugs in MacOS Apple Music (been there since day 1 when it was "iTunes") not a single one was fixed. These are not common things that the average person would do but I spend a large amount of time using Music but you'd think Apple's QA department would have caught some of these. Thanks for your reply!

Well, I wish I knew what the hell I did....pushing the button 10 times, 5 times, 2 times (not in that order just trying different things) IoX Launcher found the Eisy once (after countless failures) but couldn't could not connect to it again, even though it was right there in the IoX list. So I deleted it from IoX, got it showing up in IoX again - did a restore which oddly was from a 5.8.3 firmware backup made back in June 2024 (I have not added any devices since before June 2024). Then, either before or right after the restore I see that I am now at 5.8.4. I think the only safe way to do a firmware update is through UD Mobile. IoX is very odd in the UI when you try to update firmware. It does not give you any status, and tells that you need a reboot - really? After 0.0001 seconds from claiming to "start" to do the firmware update it has to be rebooted? What a mess. I was about to try the HDMI video and USB keyboard and mouse next (never tried that). I still cannot figure out how UD Mobile "lost" contact with this Eisy. UD Mobile must get into a state or save something about the Eisy and that after the hard reset, reboot, failure, whatever - it loses access even though everything goes through UD portal. I eventually got UD Mobile going with 2 Eisy's (1 was ending with a (1) I think). I got my favorites listed but there was a big red triangle at the top of UD Mobile anyway. I just did a synchronize on one device and trashed the other. Thank god, I had a lot of lights on outside that I didn't want the neighbors bitching about and I really didn't want to be out in the 20 degree weather fiddling around on the snow trying to turn off every damn outlet outside at 2am. Even after a reboot, shouldn't the Eisy automatically show-up in UD Portal? UD-Portal was stating that it had not seen my device online since XX:XX:XX (a couple of hours before I was trying to resolve this). Also, what does "holding" the Eisy button do, which turns the power button red - I assume that turns it off??? Okay, but if you push it again it immediately goes blue but I guess it's not really "online" for a couple of minutes or so. There is a bit of documentation that said to not try to connect to it until after 5 minutes from starting and if you try to connect before the 5 minutes then bad things will happen (I'm paraphrasing here). It would be nice if maybe the indicator light went red (off) to yellow (starting) to blue (ready) - or something like that so you know exactly when things are online and ready to go. I find it odd that you could screw things up by "trying to connect to the Eisy too early" - at least that's how I read it. I would think/hope that the connection would just fail if the device was not ready and there would be no long term effects to the device, IoX or UD Mobile configs. Well, hopefully "at least" another couple of years before another "connection" problem.