larryllix

I always seem to prefer to do these things last thing at nights so I can be up all night trying to recover. When it finally works about 10 AM the next day the sleep quality is the best you will ever get!!

Maybe he prefers kermit to faxes?

Sounds like time to open a ticket with UDI. They are fast and very helpful. Don't expect Saturday responses, usually though. Sometimes the UUID database may get messed up.

Have you checked your subscription timing to make sure it hasn't expired. IIRC you would get a notification about that but accounts can change and things get messed up, warning can be incorrect or forgotten about. IIRC those stats are found at the top right corner menu of the ISY Portal. Recently updated your java version? Going to ping @bmercier, our ISY Portal creator and resident expert. Maybe he can shed some light on this.

Were you attempting to update something when this happened?

That always worked for me but it appears some of those commands have been erasedfrpm the freeBSD os to force users to use the provided tools. That update command has never functioned properly for me since polisy came out. The ssh method always worked though and was used to recover each time. We will get there to a user level system eventually. Sent from my SM-G781W using Tapatalk

Perhaps we need an individual "Do not query" selection for each device instead of a group select/deselect. I have three MS II on AC and several MS 1's on battery power but some were planed to be on AC originally, also. I find the battery device query hasn't stayed turned off since IoP was released, anyway. UPDATE: Just checked on v5.5.0 and it kept it's Off setting with A/C reload, finally. Now to see if I can get Insteon to fix the MS II timer bug before re-releasing it.

I used the laughing emoticon 'cause there was no finger bird.

Yeah @Michel Kohanim reported they found the initial update process was flawed and was fixing it. Sure caused some commotion here for me for a night though.

See (to fix)

Seems to be the winner for me! The pkg utility version was the snag. Despite all the rrors the system threw at me it seemed to upgrade it and made all the other upgrades possible. sudo pkg install -r udi pkg After that, I reset udx and isy, and then ISY booted properly, finally. sudo service udx stop sudo service udx start sudo service isy restart I remembered some of the last ticket help with @Michel Kohanim how udx controlled the UUID assignment (mine was coming up 00.00.00.00.00.01) and the outdated pkg utility was prevented it from installing the newer packages. Thanks all! /Panic off

Thanks. already been done many times now. Best was service stop service start of each udx, isy polyglot Mongol that got me up with an actual UUID but after few minutes the UUID collapses again to 00.00.00.00.00.01 again and Insteon, and all i/o stops functioning again. This thing is just continuously crashing. Power cycled several times and clicked update several times now. May have to try my spare polisy or return to my ISY for the third time. Sent from my SM-G781W using Tapatalk

It seems the update package is permission locked. [admin@polisy ~]$ sudo pkg install -r udi pkg Password: Updating udi repository catalogue... udi repository is up to date. All repositories are up to date. New version of pkg detected; it needs to be installed first. The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pkg: 1.18.4 -> 1.19.0 [udi] Number of packages to be upgraded: 1 8 MiB to be downloaded. Proceed with this action? [y/N]: y [1/1] Fetching pkg-1.19.0.pkg: 100% 8 MiB 8.6MB/s 00:01 Checking integrity... done (0 conflicting) [1/1] Upgrading pkg from 1.18.4 to 1.19.0... [1/1] Extracting pkg-1.19.0: 100% Updating udi repository catalogue... udi repository is up to date. All repositories are up to date. process with pid 17542 still holds the lock process with pid 17542 still holds the lock process with pid 17542 still holds the lock pkg: Cannot get an advisory lock on a database, it is locked by another process [admin@polisy ~]$ [admin@polisy ~]$ sudo pkg install -r udi pkg Password: Updating udi repository catalogue... udi repository is up to date. All repositories are up to date. New version of pkg detected; it needs to be installed first. The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pkg: 1.18.4 -> 1.19.0 [udi] Number of packages to be upgraded: 1 8 MiB to be downloaded. Proceed with this action? [y/N]: y [1/1] Fetching pkg-1.19.0.pkg: 100% 8 MiB 8.6MB/s 00:01 Checking integrity... done (0 conflicting) [1/1] Upgrading pkg from 1.18.4 to 1.19.0... [1/1] Extracting pkg-1.19.0: 100% Updating udi repository catalogue... udi repository is up to date. All repositories are up to date. process with pid 17542 still holds the lock process with pid 17542 still holds the lock process with pid 17542 still holds the lock pkg: Cannot get an advisory lock on a database, it is locked by another process [admin@polisy ~]$

After mine rebooting and showing v5.5.0 it has now crashed and shows v5.4.5 with UUID:00.00.00.00.01 ISY Portal cannot find it. Currently running sudo reboot again. UPDATE: IoX Finder found proper UUID but would not launch Admin Console after IoX refresh now shows UUID 00.00.00.00.00.01 and now launches IoX but System Busy will not go away.

Modulus arithmetic is still defective and hasn't supported decimal fractions since v5.0.1. Notification customisations still hasn't been fixed as reported the last three or four versions. Selection menus also fail occasionally.

Interesting how these tags can remember eons of data updates internally but when the server goes down there is just permanent holes. Do the Tags only get one shot at updating their data and then the memory is cleaned out or does the Tag server just not bother recouping missing data? Am I missing some refresh cycle process to get missing data?

Mine are missing all data from 3:04 AM to 12:55 PM today.

Tag server down from Dom. Rep. also. Sent from my SM-G781W using Tapatalk

@Michel Kohanim

I thought the migration software was complete. I moved mine when there was more mess than savings over to polisy. However, all is good living on the polisy exclusively. Much faster but a few outstanding quirks yet. Sent from my SM-G781W using Tapatalk

Sound slike the classic non-technical management micro-managing things. When things get tough they make it cheaper and eventually the product is crap. Wrong path.

Sounds like a barrel connector should be installed and use external power supply adapters to feed it that can be replaced every few years and protect/isolate the grid power from the electronics. Oh yeah, the grid signals would require some passthrough...hmmmmm.

Oh Jeeezzzz! I never thought of that! I love the support in this group.

Since a good portion of us live close to this repair guy, we could ship to, and then drive over to pick it up again. Would be several days faster and also save a shipping fee. Square One would be a side trek making it more worth while. Tell the wifely you are taking her shopping. Maybe the guy would try same day service with a shopping mall gap in the timing??