New Option "-X" for multiple instances

[seydx]

A new option has been added (-X) that allows only certain plugins to be loaded to avoid huge memory usage

Example (/etc/default/homebridge-instance)

# Defaults / Configuration options for homebridge
# The following settings tells homebridge where to find the config.json file and where to persist the data (i.e. pairing and others)
HOMEBRIDGE_OPTS=-U /var/homebridge-instance -X homebridge-alexa

# If you uncomment the following line, homebridge will log more 
# You can display this via systemd's journalctl: journalctl -f -u homebridge
# DEBUG=*

(i.e. this will only load homebridge-alexa)

Adding the plugin name after -X allows only to load the given plugin, you can also list several plugins (you just have to separate it with a comma, like -X homebridge-alexa,homebridge-hue etc.)

Another advantage is that your homebridge instances will load noticeably faster, feels three times faster than without "-X" AND in my case I have 30% less memory usage than without "-X"

The plugins are loaded "globally", so it will be always possible with "-g" to continue installing or updating plugins

The -X option just insert the added plugin name(s) to the already existing paths, so it works on every system

[m4d-maNu]

Great, pls add this option in HB.

[Nastras]

Yeahhh,

thank you very much, that you've made this great feature so fast. Please add this Option to Homebridge!

[maikburd]

I completely agree! Please add this Feature to Homebridge!

[Heiliger85]

Great idea. I hope it will come in next version of Homebridge.

[theo-69]

Really Great!

[det-box]

Hello,
I think the Ide is great especially for multible instances.

Please take it to the HB

Thank you

[Kohle81]

Great idea, please add this to the homebridge! 👍

[theo-69]

is there a way to install it already?

[theo-69]

@nfarina a merge would be great, waiting for this feature to to problems with one plugin.

[KhaosT]

Instead of an argument passed in on launch, can we switch to put this as an array of paths in config.json? That way this setting can be there more permanent and avoids comma separated list which a lot of people can mess up.

[seydx]

@KhaosT

Is the method with passing paths into config.json not "too late" for homebridge?
The config.json is only loaded after all plugins of homebridge have been loaded or am I wrong?

An argument passed in on launch prevent homebridge to load any other plugins which is listed after -X so we don't need to wait for config.json to load

[theo-69]

@KhaosT I think if someone can handle several instances he can handle -X ;-)

[DSchumacher2104]

This sounds really great! Please add it to Homebridge 👍

[Typ1er]

is a good idea 👍

[cubilon]

really useful!

[Nastras]

@KhaosT Can you tell us what your next plan is for this pull request? Will he be taken over?
Or should @sydeX rebuild it for the config.json? What about his guess that the config.json loads too late?

Many Thanks!

Greeting Nastra

[NSCHI]

like this idea, need it in homebridge.

[Razeeer]

I would also be very happy about this feature in the official Homebridge. Please take it.

[theo-69]

@KhaosT so why still no pull

[KhaosT]

I still think this should live in config file instead of a launch parameter. Regarding the order of operation, I mean we can change that if necessary. I’ll try to write something later today and see how it goes.

[seydx]

that sounds good, but as i said, to get the advantages i listed above, homebridge should check first which plugins we only want to load before loading all installed plugins

[ebaauw]

I would prefer a config.json solution as well, over a command-line option. This would make for simpler system management, as all plugins would still be installed in one place, and only the configuration needs to be changed between instances.

Rather than introducing a new key, would it be possible to use the existing platform and accessory keys? Homebridge would derive the plugin directory from config.json, rather than through registerPlatform() or registerAccessory(). I’m not sure I oversee the full consequences of this, but at least:

• In config.json, one would specify the plugin suffix rather than the plugin name, e.g. ”platform”: “xxx” for plugin homebridge-xxx;
• The name parameter to registerPlatform() and registerAccessory() would become obsolete;
• cachedAccessories would need to hold the platform directory suffix rather than the platform name.

[cubilon]

I agree with @ebaauw. a config.json solution would be a better choice.

[theo-69]

Even with -x solution the plugins are still installed in the same place. Its just a edition to the already existing way to load plugins. For now I think it would be the best solution. Maybe for later it should be on the to do list.

[r32er]

Great idea! i hope it will be added to the homebridge!

[theo-69]

Its great lot of people waiting for this, but nothings is happening. However a Logo is getting merged ;-)

[Nastras]

That is really a shame. I thought about the last answer from @KhaosT

  I'll try to write something later today and see how it goes.

The now speed in the topic comes but unfortunately it does not seem to be the case.

Maybe we have to ask the boss .-)
@nfarina @KhaosT
What is the current state of affairs on the topic?