You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please consider implementing backup and restore support using files to allow for migration back and forth from and to Zigbee2MQTT.
Such a feature would enable developers and testers to temporary migrate between the different solution to test what is working and what is not in the other solution.
The text was updated successfully, but these errors were encountered:
Hi, the idea behind zigbee-matter-bridge is to create a software that map real zigbee device onto matter device (where possibile).
So no configuration is needed is the first step of the project. I think configuration will be mandatory to manage custom cluster configuration related to vendor implementation.
Surely I have to allow Zigbee2MQTT backup and restore to manage device group and device-to-device binding and scenes (testing and dev purpose).
To give you more details, I'm now grouping cluster exposed by zigbee endpoint into a bridged device.
I'm following matter.js implementation, so for now only device types in packages/matter.js/src/device/DeviceTypes.ts are used in algorithm that perform grouping.
For example if zigbee device simpledesc response contains 0x0006 and 0x0008 clusters, device mapped would be DIMMABLE_LIGHT
The enumeration of devices is deterministic so application do not need to persist any information other that koenkk zigbee library database and matter.js own storage.
Your every suggestion is as precious as gold to me, in this stage of project.
Consider that for now, it's only a eight hours artifact.
But I think that when Amazon Alexa, Google Home App will support the latest matter specification, the software can replace any vendor hub, because it allows vocal assistant to work offline: more privacy, more reliability, less cost for device vendor because of cloudless mode.
Very interested in Z2M interoperability as well. Would it be a good idea to contact Koenkk to see if you two can work together? There is an ongoing discussion in his repository Koenkk/zigbee2mqtt#7443
Please consider implementing backup and restore support using files to allow for migration back and forth from and to Zigbee2MQTT.
Such a feature would enable developers and testers to temporary migrate between the different solution to test what is working and what is not in the other solution.
The text was updated successfully, but these errors were encountered: