I would like to discuss my assumptions before making a general device to HomeKit converter, or specifically Zigbee/MQTT to Homebridge-MQTT.
The Redmatic-HomeKit Zigbee node (alternative to homekit-bridged) has awesome no-config automatic creation and control of homekit accessories (lights and sensors) from zigbee-herdsman (node-red-contrib-zigbee instead of external zigbee2mqtt (same core)), but my hope is to elegantly (and much simpler and more errorprone) make my own converter from zigbee-herdsman or MQTT to Homebridge-MQTT, because of the latter's stability and dynamic nature.
This in turn made me think of adopting the homie-convention for MQTT to standardise all info and states in MQTT and node-red, before attempting to automatically convert to Homebridge-MQTT. But this may be overkill because of my simple plan which follows.
My early sketch idea is to inspect the "clusters" of the zigbee devices (at intervals and when a new one shows up) and set up a general rule set for different sets of clusters. Eg. if it has onOff, Level, and Color clusters it's probably a bulb or lightstrip, and a HomeKit light tile could be automatically created through Homebridge-MQTT. Depending on availability status reachability could be set in HomeKit automatically too.
If the device is too special it won't touch it and it would have to added to HomeKit and controlled by hand in node-red, which may be preferable for other things than lights and sensors anyway.
When it comes to running control and synchronization the hardest part is the color modes I think.
I'm not really a hardcore coder so I was thinking of implementing it as a subflow if I cant manage it all in a function node.
What do you think ?
EDIT: Should I be able to also put up a UI for this node/subflow the user could edit a device’s HomeKit configuration (or block/remove accessory) by Homebridge-MQTT’s dynamic nature without any restarts. A big change would be a remove and add behind the scenes.