Since I updated packages to use the new eisy-ui, I have had a problem for several weeks when I try to use "Alexa" (I mostly loathe Alexa) to turn on a light or other. "She" constantly says that the hub is OFFLINE. I can still turn things on/off locally but when I go to myISY it shows OFFLINE. I have found only a reboot via the U-D app or Admin Console fixes it for a day or two and then it happens again.

Any suggestions why I am having this problem that I've never had before?

On 11/15/2025 at 7:45 PM, Riggins44 said:

Any suggestions why I am having this problem that I've never had before?

@Riggins44 Simple answer might be to open a support ticket with UD to see if they can trace the issue if your portal account isn't staying active.

https://www.universal-devices.com/my-tickets

Since this happened following an update make sure that you've fully rebooted the system. Perhaps even a power cycle (press and hold the power button until it turns red, wait 10 seconds +/-, press the button and allow the system to fully boot before attempting to log in (I would suggest using java admin console).

Is your device (I assume eisy) hard wired to your network or are you using wifi to connect? If wifi, is it possible to get a wired connection to where your device is in relation to your network equipment?

Lastly, make sure your portal subscription is active. (UD Portal -> Select Tool... -> Information -> ISY Portal Access License)

I have had trouble with ISY994 devices and Polisy devices (two) with power line grid reclosers. In an effort to minimise outages the power companies install devices to clear lightning discharge from the overhead power lines by dropping the HV breakers for one second and then reclosing them, the first time. This gets longer each time for worse fault clearing.

This short one second clean outage reboots my router and most equipment OK but my UD boxes have always had a problem with it, either not rebooting or not rebooting properly.

Of course, after years of this happening I have also discovered the Ethernet drivers do not seem to make any longer term attempts at IP recovery with the DHCP servers in my routers. IOW: They try a few times and then just give up forever, leaving your home automation dead without an IP connection to your router. This never heals itself and requires a power off/on with a few seconds of dead time. Mine ISY/PolISYs have always had hardwired Ethernet connections to my routers.

This brings me back to the OP's problem. Do you experience short term power grid disruptions frequently?

48 minutes ago, larryllix said:

This short one second clean outage reboots my router and most equipment OK but my UD boxes have always had a problem with it, either not rebooting or not rebooting properly.

Sounds like you could use a power on delay circuit module, to delay the startup of your controllers for several seconds. Most of these are sold as low voltage devices with relays, but you could install it inline with the low voltage power going into the controller.

11 hours ago, Guy Lavoie said:

Sounds like you could use a power on delay circuit module, to delay the startup of your controllers for several seconds. Most of these are sold as low voltage devices with relays, but you could install it inline with the low voltage power going into the controller.

Before I moved I had a WiFi controllable receptacle running my ISY994 and an Insteon controlled OnOff module controlling my router.
When I was away if Internet or Ethernet signals were found bad it would run a power cycling routine that increased duration with each trial.
Then I could also remote power cycle my ISY994 with the remote controlled receptacle.

I was locked out of my home monitoring too many times while away for weeks.

I never bothered since I moved and moved to a polISY but may have to get back on that track.

I just can't believe, after all these years, UD equipment just gives up, and doesn't attempt to heal it's connections. I have never seen another piece of Ethernet equipment that doesn't heal, even if it takes days.

11 hours ago, larryllix said:

I just can't believe, after all these years, UD equipment just gives up, and doesn't attempt to heal it's connections. I have never seen another piece of Ethernet equipment that doesn't heal, even if it takes days.

Well it might be more a function of the hardware platform or FreeBSD, depending on how far it gets or where it stalls in the reboot after a power glitch. It would be interesting to have a screen and keyboard attached to the controller (though that's not possible with a Polisy, only a eisy) to see what exactly happens.

But an external delayed power on would probably be the best workaround.

On 11/19/2025 at 10:13 AM, Guy Lavoie said:

Well it might be more a function of the hardware platform or FreeBSD, depending on how far it gets or where it stalls in the reboot after a power glitch. It would be interesting to have a screen and keyboard attached to the controller (though that's not possible with a Polisy, only a eisy) to see what exactly happens.

But an external delayed power on would probably be the best workaround.

I have found that there are many devices called "Refrigerator Surge protectors" that not only have MOV protection for spikes etc. but detect low and high voltage and then disconnect with 30 seconds, 3 minutes (mostly) and some 3, 5, & 7 minutes selectable, on delays after voltage stability. I was originally thinking 30 seconds would be about right but now I am thinking this router takes a long time to get setup so 3 minutes may be better.

Another clue is, I have a freezer plugged into the same outlet (lack of enough receptacles here) and the motor glitching may be crashing the polISY during a 1 second power blink. Any on delay may be OK, in that instance.

The negative would be detecting voltage disturbances and disconnecting frequently when not needed. For $40 CAD it will be worth a try. Moving to the other end of the another city in April and since I worked at that grid utility I know they do not do the 1 second reclose stunt inside the city. My current city does.

You gotta' keep trying.... SIGH ...LOL

On 11/15/2025 at 6:45 PM, Riggins44 said:

Since I updated packages to use the new eisy-ui, I have had a problem for several weeks when I try to use "Alexa" (I mostly loathe Alexa) to turn on a light or other. "She" constantly says that the hub is OFFLINE. I can still turn things on/off locally but when I go to myISY it shows OFFLINE. I have found only a reboot via the U-D app or Admin Console fixes it for a day or two and then it happens again.

Any suggestions why I am having this problem that I've never had before?

I've come to research and note the same thing. I've had to reboot 4 times as it is unresponsive from all aspects, the App, Alexa, etc. It is usually pretty dang hot - I unplug and let it boot back up and all is good. The first time was about a month ago and I found the 0.7.2 update, so I updated and it has happened twice again in the last 2 weeks. Figured there might be others in the same situation. I've not made updates, no new programs or fundamental changes - only the new GUI. Guessing I'll open a ticket if nothing comes of this thread. Seems more like a runaway process on the device causing it to heat up and become unresponsive.

13 hours ago, gdntx said:

I've come to research and note the same thing. I've had to reboot 4 times as it is unresponsive from all aspects, the App, Alexa, etc. It is usually pretty dang hot - I unplug and let it boot back up and all is good. The first time was about a month ago and I found the 0.7.2 update, so I updated and it has happened twice again in the last 2 weeks. Figured there might be others in the same situation. I've not made updates, no new programs or fundamental changes - only the new GUI. Guessing I'll open a ticket if nothing comes of this thread. Seems more like a runaway process on the device causing it to heat up and become unresponsive.

I've been running into a similar issue, it seems the isy process on the eISY box is crashing regularly. I've been trying to isolate what might be triggering it, I have not reached out to support yet about it but I intend to. I run some stuff that may be uncommon so I've been toggling things to see if I can figure it out.

I'm curious if you have noticed the same thing? You can ssh into the eISY (admin/admin) and then type dmesg to see the kernel print messages about crashes.

@Michel Kohanim I've been chasing this for a bit now, I'm trying to figure out if some of my older stuff (ISYBackup, mqtt bridge, constant variable updates via REST) before opening a ticket. Would you want to analyze the core dump/logs or should I continue trying to isolate?

pid 3594 (isy-freebsd-x64), jid 0, uid 349: exited on signal 11 (core dumped)
pid 14819 (isy-freebsd-x64), jid 0, uid 349: exited on signal 11 (core dumped)
pid 32128 (isy-freebsd-x64), jid 0, uid 349: exited on signal 11 (core dumped)
pid 54784 (isy-freebsd-x64), jid 0, uid 349: exited on signal 11 (core dumped)

[root@eisy /var/isy]# lldb -c isy-freebsd-x64.core /usr/local/bin/isy-freebsd-x64
(lldb) target create "/usr/local/bin/isy-freebsd-x64" --core "isy-freebsd-x64.core"
Core file '/var/isy/isy-freebsd-x64.core' (x86_64) was loaded.
(lldb) bt
* thread #1, name = 'LDU', stop reason = signal SIGSEGV
  * frame #0: 0x0000000830240932 libc.so.7`___lldb_unnamed_symbol6062 + 1106
    frame #1: 0x000000083024043e libc.so.7`___lldb_unnamed_symbol6061 + 78
    frame #2: 0x00000008301f7e6a libc.so.7`___lldb_unnamed_symbol5411 + 842
    frame #3: 0x00000000005190dd isy-freebsd-x64`UpdateLogicalDeviceText(ld=0x00000a8ba5482f00, control="_4", action="5", node=0x0000000000000000, ei="<status>0</status>", eiByteLen=18, eiFormatter=0x0000000000000000, text=0x0000000000000000, sid=8394, alarmQueueEventInfoOk=false) at UDLogicalDeviceUpdater.cpp:399:5
    frame #4: 0x00000000004d4198 isy-freebsd-x64`UpdateLogicalDevice(ld=0x00000a8ba5482f00, control="_4", action="5", node=0x0000000000000000, ei="<status>0</status>", sid=8394) at UDLogicalDeviceUpdater.cpp:523:11
    frame #5: 0x00000000004dade6 isy-freebsd-x64`UpdateSystemConfig(action="5", ei="<status>0</status>", sid=8394) at UDLogicalDeviceUpdater.cpp:570:2
    frame #6: 0x00000000004ab95f isy-freebsd-x64`LogicalDevice::updateBatchMode(this=0x00000a8ba5482f00, sid=8394) at LogicalDevice.cpp:314:4
    frame #7: 0x00000000004af197 isy-freebsd-x64`LogicalDevice::get_device_state_now(this=0x00000a8ba5482f00, sid=8394) at LogicalDevice.cpp:1401:4
    frame #8: 0x0000000000519c74 isy-freebsd-x64`LogicalDeviceUpdaterThread(mpx=0x0000000000000000) at UDLogicalDeviceUpdater.cpp:794:28
    frame #9: 0x0000000000c324f7 isy-freebsd-x64`UDXThread::doRun(this=0x00000a8ba54b6470) at UDXThread.cpp:84:6
    frame #10: 0x0000000000c32d05 isy-freebsd-x64`startThread(arg=0x00000a8ba54b6470) at UDXThread.cpp:39:31
    frame #11: 0x00000008270e4b82 libthr.so.3`___lldb_unnamed_symbol565 + 306
(lldb) 

Edited 4 hours ago4 hr by nathan