Matterbridge exports from:
"matterbridge"
- Matterbridge and all Matterbridge related classes.
- All relevant matter-node.js or matter.js clusters, classes and functions.
"matterbridge/matter"
- All relevant matter.js new api only exports (in beta).
"matterbridge/cluster"
- All clusters not present in matter.js or modified.
"matterbridge/utils"
- All general utils and colorUtils functions.
"matterbridge/logger"
- AnsiLogger class.
"matterbridge/storage"
- NodeStorageManager and NodeStorage classes.
A plugin must never install or import from @matter
or @project-chip
directly (neither as a dependency, devDependency, nor peerDependency), as this leads to a second instance of matter.js
, causing instability and unpredictable errors such as "The only instance is Endpoint".
Additionally, when Matterbridge updates the matter.js
version, it should be consistent across all plugins.
A plugin must never install Matterbridge (neither as a dependency, devDependency, nor peerDependency).
Matterbridge must be linked to the plugin in development only.
"scripts": {
'''
"dev:link": "npm link matterbridge",
'''
}
I added some error messages when a plugin has wrong imports or configurations and the plugin will be disabled to prevent instability and crashes.
I'm working with matter.js team to define the strategy for the migration of Matterbridge to the new API.
- First phase: crete MatterbridgeEdge class: completed 90%
- Second phase: create MatterbridgeEndpoint and MatterbridgeBehaviors classes: completed 90%
- Third phase: modifiy all plugins to support both normal and edge mode of Matterbridge: completed 80%
- Fourth phase: remove all old api code from Matterbridge and all plugins...
The easiest way is to clone:
-
https://github.com/Luligu/matterbridge-example-accessory-platform if you want to create an Accessory Platform Plugin.
-
https://github.com/Luligu/matterbridge-example-dynamic-platform if you want to create a Dynamic Platform Plugin.
Then change the name (keep matterbridge- at the beginning of the name), version, description and author in the package.json.
Add your plugin logic in platform.ts.
To install i.e. https://github.com/Luligu/matterbridge-example-accessory-platform
On windows:
cd $HOME\Matterbridge
On linux:
cd ~/Matterbridge
then clone the plugin
git clone https://github.com/Luligu/matterbridge-example-accessory-platform
cd matterbridge-example-accessory-platform
npm install
npm run build
then add the plugin to Matterbridge
matterbridge -add .\
The plugin name.
The plugin platform type.
The plugin config (loaded before the platform constructor is called and saved after onShutdown() is called). Here you can store your plugin configuration (see matterbridge-zigbee2mqtt for example)
The method onStart() is where you have to create your MatterbridgeDevice and add all needed clusters and command handlers.
The MatterbridgeDevice class has the create cluster methods already done and all command handlers needed (see plugin examples).
The method is called when Matterbridge load the plugin.
The method onConfigure() is where you can configure or initialize your device.
The method is called when the platform is commissioned.
The method onShutdown() is where you have to eventually cleanup some resources.
The method is called when Matterbridge is shutting down.
After you created your device, add it to the platform.
You can unregister one or more device.
You can unregister all devices you added.
It can be useful to call this method from onShutdown() if you don't want to keep all the devices during development.
Work in progress...
Thank you for your interest in contributing to my project!
I warmly welcome contributions to this project! Whether it's reporting bugs, proposing new features, updating documentation, or writing code, your help is greatly appreciated.
- Fork this repository to your own GitHub account and clone it to your local device.
- Make the necessary changes and test them out
- Commit your changes and push to your forked repository
- Create a new pull request against the dev from my repository and I'll be glad to check it out
- Be sure to follow the existing code style
- Add unit tests for any new or changed functionality if possible
- In your pull request, do describe what your changes do and how they work