Multiple instances to same Doorbird from 0.2.X

[chrislimk]

Thank you for the great plugin! I have been using this since the very early versions and noticed that UID method has changed recently from 0.2.

I currently run 2 instances of homebridge (1 as master, another as user-family), so having the new method of UID only allows one instance access to the doorbird. The current workaround I have is to run the master at the latest version and the other at 0.1.1

Is there a possibility to bring back the random UIDs or at least allow us to customize it so that 2 instances to the same device can be run?

Thank you

[hjdhjd]

Hi there. Thanks for the feedback. Can you explain a bit more what you’re trying to do?

Are you trying to run multiple Doorbirds? Or multiple instances of homebridge?

Any more detail you can provide?

As an aside...in the most recent version - 0.3.0 - you should be able to use multiple Doorbirds cleanly.

[chrislimk]

I am running multiple instances of homebridge, specifically they are on separate VMs as i encountered problems having just the instance duplicated. The very intent of this segregation is so that I can keep family members off some controls that I don't want them to have, and so far naming the same doorbird differently across both the homebridges has been working nicely until 0.2.X For example:

1. "Doorbird-Master" - In main instance
2. "Doorbird-Slave" - In secondary (family) instance

What i can see after upgrading to 0.2.X is that the UID has been fixed to something statically generated. This basically means that I cannot have the single doorbird connected on both the homebridges as the plugin generates the same UID across both the homebridges, although they are named differently as I explained above.

This differs to how it used to operate which i understand was based on camera-FFmpeg which i also use. camera-FFmpeg is still allowing me to operate in this way as of their latest release.

To summarise, I am looking to run a single doorbird on 2 different homebridges that I own.

Thank you

[hjdhjd]

You are correct. This is an unsupported and potentially problematic configuration, and I have no plans of adding support for it. I understand what you’re trying to do now, though I suspect you will encounter other problems in the future with a setup like this.

You’ve surmised what’s going on, but I’ll elaborate further:

• older versions of this plugin used the name to generate a unique identifier. This was problematic for a number of issues, not the least of which is that if you had another, unrelated device, that had the same name, there would be a unique identifier collision and that’s a problem for HomeKit (and homebridge) and a big nono.

• so what we do now in this plugin is we use each Doorbird’s uniqueness...ideally this would be a serial number, but in our case we use the MAC address, since those are guaranteed to be unique, to generate the unique identifier. This is why one needs to re-add a Doorbird after upgrading to 0.2.x and beyond...the unique identifier that the Home app (aka HomeKit) is looking for has changed and no longer exists.

• doing what you are asking would give the user the option of creating their own unique identifier. The problem is that if you forget in the future what you’ve done, or you change the identifier, you’ll have the same problems as I mentioned above and potentially difficult to troubleshoot. Additionally, if you try to have multiple streams open to the Doorbird at once, things will break as the device isn’t very powerful CPU-wise and can’t handle it.

To do what you want in a “HomeKit nice” way...you could just have three homebridge instances and call it a day:

“homebridge-admin”: for the special stuff only you want. “homebridge-shared”: for the stuff shared across the family and admin. “homebridge-family”: for the stuff that’s just for the family.

You can place the Doorbird in that shared bucket and still not give. them visibility to things in the admin bucket.

Thanks.

[chrislimk]

Thanks for the explanation, indeed it has been challenging implementing this as not all plugins play nice being exposed to 2 homebridges. The premise for this setup is due to homekit's lack of fine-grained controls over who gets access to what accessories (essentially all-in or all-out).

I also failed to mention that I run 2 separate homes with 1 homebridge each having slightly different accessories configured. It currently looks like this:

Home-Admin

• Homebridge-Master
  1. Doorbird
  2. All the accessories

Home-Family

• Homebridge-Slave
  1. Doorbird
  2. Accessories that family members can access (about 70%)

Therefore the solution that you proposed with 3 instances still won't allow the same doorbird to live on both the homes/homebridges. That would mean you can't have a setting of 2 homes where you have

1. Master (100%)
2. Shared (70%)

but rather only in this way

1. Admin Only (30%)
2. Shared (70%)

I can understand that UIDs present the challenge of uniqueness where just looking at names may not be "unique enough", though homebridge itself allows you to set a custom uid/pin. If there is really insufficient use cases to justify giving the user a choice to specify their own UID then I will stick to running both 0.1.1 and >0.2.1 on my instances.

Thank you

[hjdhjd]

Good luck on this one...you're definitely trying to move uphill on this one, against some core design decisions in HomeKit. Over time, I expect Apple will add some additional access controls to HomeKit, but in the meantime...best of luck to you. Closing this one out.

[chrislimk]

Thanks alot @hjdhjd!