Andy C

Michel fixed my unit remotely too (thanks Michel!) - eisy now back to bossing my house!

I was able to break out to a bash prompt by using ctrl&c at the right point when it attempted to boot (and then login with the admin username). I wasn't able to do anything as FreeBSD seems very confused about if it is running v13.2 or v14. There doesn't seem to be a way to conduct a factory reset from shell, which would be nice. Will open a support ticket.

I ran the upgrade to 5.8.4 this morning, and after it told me to reboot, the eisy is now stuck in a constant reboot cycle. Plugging in a screen, I get the following (couldn't capture everything as it scrolled too quickly) attached screenshots. Pressing the power button ten times to do a factory reset doesn't change the outcome. Any clues on how to unbrick?

Thanks @IndyMike for your fast response! I don’t have my alarm system integrated with the eisy (not Elk) so unfortunately nothing else is being called to which I can pin blame! I’ve eliminated any other calls or programs being made from the door opening action to prove it’s the beeping that’s the problem. It’s also happening on more than one door sensor, and I didn’t have the problem with ISY994i. I like your idea of making sure that “Beep” isn’t running before allowing to run a second (or multiple) times, but with the Java interface’s god-like view of what is being triggered in real-time I can see the progression of program execution to the “beep” program, and subsequent stasis there, vs. being cycled repeatedly in the trigger/sensor program that calls it. I’m going to call this as an eisy specific problem given it did work without issue for a long time before its migration, but am very much aware that subtle changes can trigger very different behaviors between platforms.

Insteon Beeps seem to freeze my eisy! I have an interesting challenge with my eisy where it will periodically freeze all work for up to 4 minutes. When this happens, all scripts/programs freeze regardless of their actions, affecting Insteon, Z-wave and network resources equally. Fortunately, this doesn't freeze the Java interface, so over the last couple of months, since my upgrade from the ISY994i, I've finally figured out the "what" if not the "why" of what is going on. For the record, this happens in 5.7.0 and as far as I can tell, earlier versions on the eisy were similarly affected, but not the ISY994i. One of the cool things about Insteon switches, is their ability to Beep on command. In my house, I've written scripts that, when a door opens in the house, the light switches make a short beep and alert us to someone coming or going (such as my teenage kids sneaking back into the house after midnight). This is obviously much more subtle than having the house alarm go off. So I have a program, suitable called "Beep", that looks like this: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'Ground Floor / Kitchen / Kitchen Ceiling' Beep Set 'Ground Floor / Kitchen / Kitchen Table' Beep Set 'Lwr Ground Floor / Family Room / Family Room' Beep Set 'Upstairs / Master Bedroom / Mstr Bed Control.1' Beep Set 'Upstairs / Mstr Bathroom / Mstr Bathroom Light' Beep Set 'Garage+Studio / Studio Ceiling' Beep Else - No Actions - (To add one, press 'Action') I then call this program, whenever I need to be alerted. So programs like this: If 'Lwr Ground Floor / Backdoor-Opened' is switched On Then Run Program 'Beep' (Then Path) Else - No Actions - (To add one, press 'Action') So here is the snag. Whenever any of my programs call Beep, they freeze in place, and put the entire eisy into stasis for a period of time ranging from 30 seconds to a good 4 minutes. Nothing appears in the log files to suggest a problem, and when it comes back to life, it will catch-up with all the scripts actions from all activities that were paused across any/all methods. While I have Z-wave devices, these programs use pure Insteon products, so all the door sensors are Insteon TriggerLinc and the switches doing the beeping are Insteon SwitchLinc devices. So now to debugging - If, from the Java interface, I run the "then" command on either the "Beep" program or any of the programs that call "Beep", the programs work immediately and the system doesn't freeze. However, should the "If" construct be executed (such as a teenager opening the backdoor) then the freeze occurs. I can actually watch this happen through the Java interface, as I can see the program icon turn solid green, and then stay solid green for a long time. Finally the beeps occur and it returns to a thin green line, indicating the program completed in the "then" branch. I've taken obvious steps such as write new programs, limit my beeps to one switch only, and various combinations of beeps, but to no avail. So for the moment, I've had to suspend my beeping until I can come up with a suitable solution. In the meantime, my teenagers are free to come and go without the house betraying their tardiness. Is anyone else using Beeps this way and if so, seeing similar problems (with the eisy, not their children)?

My issue finally went away when I upgraded to 5.7.0 and it behaved exactly as it did on the ISY994i.

I've had exactly the same problem with sunset / sunrise triggering on regardless of the time of day. It didn't matter the order of my syntax, use of brackets, etc. I had to use exact times to make my programs (sort-of) work. This eventually cleared itself on the last upgrade to 5.7.0, and everything is working exactly as it used to on my old ISY994i.

I've just gone through the migration from ISY994i to eisy which like many folks has been non-trivial, especially around Z-Wave. I'm almost back to where I was before the migration, but one nagging problem, at least with 5.6.4 is that Sunset/Sunrise programs just lead to positive results at any time of day (meaning the lights come on): If From Sunset + 1 hour To Sunrise - 30 minutes (next day) And ( 'Outside / Front Yard / Porch Sensor' is switched On Or 'Outside / Front Yard / Front-yard Sensor' is switched On ) Then Set 'Outside / Front Yard / Front Yard Lights' On 100% Else - No Actions Changing the If statement to a specific timeframe solves the issue (albeit poorly): If From 7:05:00PM To 7:05:00AM (next day) Obviously, I've checked the time settings and zone settings (and DST) and everything seems set correctly. So I don't know if this is a bona fida bug, or if the logic interpretation changed somewhere between ISY994i and eisy versions. One note - I did have to edit the device statements in my programs as many of my Z-Wave devices had to be completely deleted and reinserted into the network, so not sure if they would have worked after migration if I hadn't touched them.

Ah - not resolved as it turns out! Once the details for the UUID were reentered, it worked for a while, but after a couple of hours, the connection dropped. I deleted the UUID from the my.iso.io site, revalidated and it worked again for a couple of hours before it stopped working. Again, from both the portal and at the ISY, the connection looks up and stable but nothing moves between the two.

I resolved it by brute force in the end. I deleted the UUID for my unit from the my.iso.io web site. I then reentered the UUID and reinitiated the portal approval process. The only snag with this approach is that it has deleted all the services, including all of my Amazon Echo mappings to rooms and devices. Given the config of the unit hasn't changed for a few months, I guess I will never know why this happened in the first place. Not quite what I had planned for a Sunday afternoon!

Thanks MrBill! I cleared-out the error log and rebooted - this is what I got. Some full queues on the networking front could be a clue: Sun 2021/08/01 01:15:14 PM System -5 Start Sun 2021/08/01 01:15:22 PM System -110022 /DEF/F6/I1/NLS/EN_US.TXT Sun 2021/08/01 01:15:24 PM System -7115 ID 0039 :err=0, tag='cmd', num=4, nest=4, offse Sun 2021/08/01 01:15:24 PM System -7115 ID 001D :err=0, tag='cmd', num=4, nest=4, offse Sun 2021/08/01 01:15:24 PM System -7123 ID 001E :err=0, tag='control', num=6, nest=4, o Sun 2021/08/01 01:15:24 PM System -7115 ID 0022 :err=0, tag='cmd', num=4, nest=4, offse Sun 2021/08/01 01:15:25 PM System -7115 ID 003E :err=0, tag='cmd', num=4, nest=4, offse Sun 2021/08/01 01:15:26 PM System -7115 ID 0052 :err=0, tag='cmd', num=4, nest=4, offse Sun 2021/08/01 01:15:26 PM System -7115 ID 00A2 :err=0, tag='cmd', num=4, nest=4, offse Sun 2021/08/01 01:15:28 PM System -7123 ID 00BF :err=0, tag='control', num=6, nest=4, o Sun 2021/08/01 01:15:29 PM System -7123 ID 00C0 :err=0, tag='control', num=6, nest=4, o Sun 2021/08/01 01:15:29 PM System -7123 ID 00C6 :err=0, tag='control', num=6, nest=4, o Sun 2021/08/01 01:15:34 PM System -170001 [Network] Established Sun 2021/08/01 01:19:57 PM System -170001 UDQ: Queue(s) Full, message ignored Sun 2021/08/01 01:20:17 PM System -170001 UDQ: Queue(s) Full, message ignored Sun 2021/08/01 01:20:28 PM System -170001 UDQ: Queue(s) Full, message ignored Sun 2021/08/01 01:20:38 PM System -170001 UDQ: Queue(s) Full, message ignored Sun 2021/08/01 01:21:26 PM System -170001 UDQ: Queue(s) Full, message ignored For fun, I thought it I would try revoking the Portal (from the admin console) so I could reestablish. After about 10 seconds, I get a "Bad Request" message, and then an interesting new line in the error log: Sun 2021/08/01 01:23:17 PM System -140005 Portal-SEC Regards, -Andrew

About 10pm PST last night, and continuing today, the portal seems to be having connectivity issues to my ISY994i. Local access to the ISY works fine, and from the console, the Portal service is Online, Registered and active. However, none of the services seem to be working. ISY Web access times out when requesting the config (error, Loading: /config/ and the Amazon Echo service comes up with a 500 error. Rebooting the ISY unit doesn't affect the outcome. System is running v.5.3.0 and modules are up to date and paid-up. Through my monitoring tools, I can see active connections from the ISY to proxy.isy.io and various amazon and cloudfront services. Please let me know if it's a portal problem or if I should be looking elsewhere. Thanks! -Andrew