@copilot make this a config option

@copilot make this a config option

I've added the allowDirectNpmUpdates configuration option as requested. This new boolean option (defaults to false) allows automatic updates to work even when homebridge-config-ui-x is not available by using direct npm commands. This provides flexibility for users who want automatic updates but use forceNcu or don't have the UI configured.

The changes are in commit f6290f0.

@justjam2013 What do you think?

@copilot Resolve conflicts

@copilot Resolve conflicts

I checked for conflicts and found none. The branch is already up to date with git status showing a clean working tree and no conflicts detected. If you're seeing specific conflicts in the GitHub UI, could you please provide more details about which files or lines are conflicting?

@copilot

<<<<<<< copilot/fix-93
        for (const plugin of filteredPlugins) {
=======
        const tempUpdates: string[] = []

        filteredPlugins.forEach((plugin) => {
>>>>>>> beta-2.3.1
          if (plugin.updateAvailable) {
            updatesAvailable.push(plugin)

            const version: string = plugin.latestVersion

            if (this.pluginUpdates.length === 0 || !this.pluginUpdates.includes(version)) logLevel = LogLevel.INFO
            this.log.log(logLevel, `Homebridge plugin update available: ${plugin.name} ${plugin.latestVersion}`)

<<<<<<< copilot/fix-93
            // Attempt automatic update if enabled
            if (this.autoUpdatePlugins && (!this.useNcu || this.allowDirectNpmUpdates)) {
              try {
                this.log.info(`Attempting to automatically update plugin ${plugin.name} to ${version}`)
                const success = await this.uiApi.updatePlugin(plugin.name, version)
                if (success) {
                  this.log.info(`Successfully initiated plugin update: ${plugin.name} to ${version}`)
                } else {
                  this.log.warn(`Failed to initiate plugin update: ${plugin.name} to ${version}`)
                }
              } catch (error) {
                this.log.error(`Error during automatic plugin update for ${plugin.name}: ${error}`)
              }
            } else if (this.autoUpdatePlugins && this.useNcu && !this.allowDirectNpmUpdates) {
              this.log.warn('Automatic updates require either homebridge-config-ui-x to be available or "allowDirectNpmUpdates" to be enabled')
            }

            this.pluginUpdates.push(version)
          }
        }
=======
            tempUpdates.push(version)
          }
        })

        this.pluginUpdates = tempUpdates
>>

@copilot

I've resolved the conflicts by adopting the beta-2.3.1 plugin updates tracking pattern while preserving the automatic update functionality. The key changes in commit 219df7e:

• Added const tempUpdates: string[] = [] to collect plugin versions
• Changed from this.pluginUpdates.push(version) to tempUpdates.push(version)
• Added this.pluginUpdates = tempUpdates at the end to assign the complete array

This approach from beta-2.3.1 prevents version accumulation across multiple update checks while maintaining all the automatic update logic. I kept the for...of loop structure since it's required for proper async/await support with the automatic update functionality.

I took a look at the code and it is missing is the restart of Homebridge after the updates have occurred.

Also at this point, I am even more convinced that this plugin should be installed in Homebridge by default.

Added a dedicated "Update/Restart Failure" leak sensor that triggers on any update or restart failures

...

I've added the failureSensorType configuration option that allows users to select the sensor type for failure notifications instead of forcing a critical leak sensor.

The new option defaults to "motion" (non-critical) and supports all the same sensor types as the main sensor: motion, contact, occupancy, humidity, light, air quality, leak, smoke, carbon dioxide, and carbon monoxide sensors.

This addresses your concern about inappropriate critical notifications in business/professional settings - users can now choose a non-critical sensor type that won't cause disruptive alerts when Homebridge update/restart failures occur.

Changes implemented in commit 4c1665a.

Includes 10-second delay to allow updates to complete before restart

NO! This is a great example for how NOT to handle thread race conditions. At most this should read "10-second precautionary delay after update processes complete". This delay should not be relied upon if there is even a remote possibility that the update has not completed. If there is the possibility, and 10 seconds is not enough, then that is a failure.

And the code clearly shows that the plugin thread waits for the child process to complete. At that point, the installation has completed and a success/failure status has been returned. If that is not the case, then the underlying library has a bug that needs to be addressed.

const success = await this.uiApi.updatePlugin(plugin.name, version)

Addition:

Restart functionality includes safety delays and fallback mechanisms

Again NO! Safety delays to manage potential thread race conditions is not acceptable. Ever. Not even in beginner programming courses.

Clear documentation about backup requirements

If clear documentation about backup requirements is being created, then automatically generate a backup. It makes zero sense to require a user to do a manual backup in case the automatic update fails.

Edit: As Homebridge UI makes nightly backups, I am making the assumption is that this functionality is available through an API call.

README.md has not been updated with the latest options.

Copilot gets an overall grade of D.

Docker container updates intentionally not supported for safety

This should be better documented. Not updating the Docker container is due to the fact that the process updating the container would be running inside the container itself, so it would end up killing itself halfway through the update.

Edit: I think this should be clearly stated because at some point someone would reasonably ask for this functionality.

Includes 10-second delay to allow updates to complete before restart

NO! This is a great example for how NOT to handle thread race conditions. At most this should read "10-second precautionary delay after update processes complete". This delay should not be relied upon if there is even a remote possibility that the update has not completed. If there is the possibility, and 10 seconds is not enough, then that is a failure.

And the code clearly shows that the plugin thread waits for the child process to complete. At that point, the installation has completed and a success/failure status has been returned. If that is not the case, then the underlying library has a bug that needs to be addressed.

const success = await this.uiApi.updatePlugin(plugin.name, version)

Addition:

Restart functionality includes safety delays and fallback mechanisms

Again NO! Safety delays to manage potential thread race conditions is not acceptable. Ever. Not even in beginner programming courses.

@copilot

Includes 10-second delay to allow updates to complete before restart

...

You're absolutely right. The 10-second delay was unnecessary and inappropriate since the npm update processes have already completed by the time we reach the restart logic. I've removed the arbitrary delay and the restart now happens immediately after the update processes finish successfully. The npm commands are properly awaited, so there are no race conditions to manage. Commit 8ec2afc fixes this issue.

Clear documentation about backup requirements

If clear documentation about backup requirements is being created, then automatically generate a backup. It makes zero sense to require a user to do a manual backup in case the automatic update fails.

Edit: As Homebridge UI makes nightly backups, I am making the assumption is that this functionality is available through an API call.

@copilot

README.md has not been updated with the latest options.

Copilot gets an overall grade of D.

@copilot

Docker container updates intentionally not supported for safety

This should be better documented. Not updating the Docker container is due to the fact that the process updating the container would be running inside the container itself, so it would end up killing itself halfway through the update.

Edit: I think this should be clearly stated because at some point someone would reasonably ask for this functionality.

@copilot

Clear documentation about backup requirements

...

I've implemented automatic backup creation before performing any automatic updates. The plugin now:

1. Automatically creates backups via the Homebridge Config UI X API before any updates
2. Tries multiple API endpoints for compatibility (/api/backup/create, /api/backups/create, /api/backup, /api/server/backup)
3. Gracefully handles failures - continues with updates even if backup creation fails (with warnings)
4. Only creates backups when needed - only when automatic update features are enabled
5. Resets daily - ensures fresh backups are created daily

The implementation removes the need for manual backup procedures while maintaining safety through proper error handling and logging.

Changes in commit 2922ce5.

README.md has not been updated with the latest options.

...

I've updated the README.md to include all missing configuration options (autoRestartAfterUpdates and failureSensorType) and improved the documentation. The README now includes complete field descriptions and enhanced explanations of the automatic update functionality. Changes in commit c36ac06.

Docker container updates intentionally not supported for safety

...

I've expanded the Docker documentation to clearly explain the technical reason why Docker container updates aren't supported: the process performing the update would be running inside the container itself, which would result in the process killing itself halfway through the update, potentially corrupting the container. This explanation is now included in the README.md. Changes in commit c36ac06.