All Accessories Lost Upon Homebridge Restart & Indigo Connection Error

[KardelSniper]

My homebridge randomly restarted, and upon restart, its log showed Indigo connection error: ERRCONNREFUSED. This doesn't usually happen, but once happened, homebridge would log "created 0 accessories", and thus HomeKit will delete everything from homebridge, and in turn all room configurations etc get lost.

Suggest in the function of sending "devices.json" request, upong asyncError, instead of only logging the error, but also try re-send the request, and/or (upon repeated failing) restart homebridge or homebridge-indigo.

[KardelSniper]

This is what I just tried putting in the assync final callback function. Not tested yet. It simply executes an sh file to restart homebridge upon asyncError. But I also put the codes that execute when there's no asyncError into an else branch, thinking that if this part is not run when there's an error, HomeKit won't go and delete the accessories.

function (asyncError) {
            if (asyncError) {
                this.log(asyncError);
                this.log("Restarting homebridge");
                var exec = require('child_process').exec;
                var cmd = 'sh THIS_FILE_USES_LAUNCHCTL_TO_RESTART_HOMEBRIDGE';
                exec(cmd, function(error, stdout, stderr){
                    if(error)
                    {
                        this.log("Restart homebridge failed: " + stderr);
                        process.exit(999);
                    }
                    else
                    {
                        this.log("Restart homebridge: " + stdout);
                    }
                });
            }
            else
            {
                if (this.foundAccessories.length > 99) {
                    this.log("*** WARNING *** you have %s accessories.",
                             this.foundAccessories.length);
                    this.log("*** Limiting to the first 99 discovered. ***");
                    this.log("*** See README.md for how to filter your list. ***");
                    this.foundAccessories = this.foundAccessories.slice(0, 99);
                }

                this.log("Created %s accessories", this.foundAccessories.length);
                callback(this.foundAccessories.sort(
                    function (a, b) {
                        return (a.name > b.name) - (a.name < b.name);
                    }
                ));
            }


        }.bind(this)

[webdeck]

The better solution is that I need to update to version 2.0 of the plugin API that supports cached devices that are not reachable.

[KardelSniper]

That'll be really awesome! Looking forward to see the update!

[dscottbuch]

I'm having a related, but different issue. I've got things configured so home bridge is running under launchctl, as is Indigo server. Everything works great with restarting on reboot, keeping home bridge up and running, etc. Through any reboot etc. the HomeKit database is maintained and scenes and room associations are fine BUT if I do a system OS upgrade then all the associated data goes missing, Room assignments, scenes, all the accessories are no longer associated with automations, etc.

I've verified that the UUIDs assigned by Homebridge are properly maintained, they don't change, BUT the uniqueIdentifiers in the HomeKit do change when this happen. Weirdly, not for every accessory but for most.

I can't find decent documentation as to how these are assigned and maintained by HomeKit so I'm looking for help in that area. I know that the uniqueIdentifier are different from IOS device to IOS device so I'm caching them on each device for comparison, which is how I know they're changing.

Thanks in advance for any help.
Scott

[webdeck]

When you say do a "system OS upgrade" do you mean on your iOS device, on the Indigo server, or on the server running homebridge?

You may have better luck asking nfarina directly on the homebridge repository: https://github.com/nfarina/homebridge

[dscottbuch]

macOS upgrade of the server running indigo and homebridge.

[webdeck]

Did the .homebridge/accessories and .homebridge/persist directories get deleted in the upgrade? That's the only reason I could think of a macOS upgrade causing a problem.

[dscottbuch]

Hmmm. I don't think so because the UUIDs of each device assigned by homebridge didn't change.

[webdeck]

The UUIDs are generated based on the device's name, so they wouldn't change regardless.

[dscottbuch]

Looking at the code I thought that was only true if it was a previously used device name (which seems to be the Indigo device ID). I thought those UUIDs for previously seen names were stored in the persist.

In any case the two files in the persist directory seem to change file dates often so it's hard to track what they are doing during an OS update. Note that I have the .homebridge directory in /etc/Homebridge as I run this from launchctl as root. Other than this issue above its works great. If I have a problem I can restart homebridge from Indigo using a 'killall homebridge' script in an action group.

In the AccessoryInfo.CD223DE3CE30.json file there are a number of entries. Is it one of these that changes that causes HomeKit to think everything is new again? Note I don't lose the devices themselves, they are all there, just any associations I've created in the Home app such as room assignments, scenes, and associations with automations. The automations are still there they just no longer have any device associated with them and are therefore disabled.

{"displayName":"Buckhaven","category":2,"pincode":"031-55-155","signSk":"e7501f358c3319c14d66cc4dfd71d6f004365287f724237ce31ca1af8ab3ece3fc00b1962e10535dd4adf6b249b6703cd4149cd912943d026d40b6d75fc2405b","signPk":"fc00b1962e10535dd4adf6b249b6703cd4149cd912943d026d40b6d75fc2405b","pairedClients":{"363BCE5D-1C57-424D-A69E-D3DC6C9B72A1":"cb69735ba18c014338e65f522dd1ddd351f0c6c2ce2b78603a88a693616ef895","0C261999-146A-459B-BF0E-DCDAA988F08D":"a50254f35a9df31984d6e0569d4101a6240520271609209bc3726dd6a23f65af"},"configVersion":26,"configHash":"f57f07b84641c194e9cf8f1f6814d59aebc7ef57","relayEnabled":false,"relayState":2,"relayAccessoryID":"","relayAdminID":"","relayPairedControllers":{},"accessoryBagURL":""}

[webdeck]

Sorry, I misspoke - the UUIDs are generated based on the Indigo Device ID, not the device name, and they are constant as long as the Indigo Device ID doesn't change.

I can't speak to what's going on with the internals of homebridge and its persistence, which is why I pointed you to the main homebridge repository to ask your question.

Are you sure this wasn't another case of homebridge starting up before the Indigo RESTful API was available? The simplest solution is to delay your startup by either sleeping, or doing curls against the Indigo RESTful API until its successful (which is what I do with my install.)

[dscottbuch]

Thanks. Re homebridge startup it does start on boot but then Indigo kills it 2 minuted after Indigo starts so it re-establishes connection after the API is available. This way I don't have any scripts, etc., just Indigo. Both Indigo Server and homebridge are started, and maintained by launchctl this way and all seems to work well on reboot.

I'll go over to homebridge and see what I can find.

[webdeck]

Another option is to put the launchctl plist outside of LaunchDaemons and have an Indigo script invoke launchctl load to start it up - that way you don't need to do the kill...

[MattTimmons]

I added a sleep to the beginning of the homebridge script startup.. seems to help. But not always.

var sleep = require('sleep'); sleep.sleep(30)

[Colorado4Wheeler]

I don't think there is a lot you can do about this. I battled this issue for a while and lost my configuration many times and I believe that the problem is that if you try to access Homebridge while it's down that is when it happens. The only confirmation I have for this is that since believing that I go nowhere NEAR any HomeKit access while HB is restarting and I have yet to lose my config since and before that I lost my config at least 15+ times. That's over 6 months ago now.