In the OH1 implementation there was a generic binding for CUL only and one binding for MAX! which uses the CUL.
In the OH3 implementation I created a bridge, which provides just the CUL features and a child bridge for the MAX! bridge features which is used by the MAX! CUL things.
Currently it’s all in one new binding but I’m thinking about making a own binding just for the CUL brige which can be reused by other bindings like in OH1.
Is it posible to reference a <supported-bridge-type-refs> from other binding modules? The id looks like a lokal id only?
Yes that is possible. There are some other examples. For example the bluetooth and modbus binding have a generic bridge. The structure is that there are several projects that all form 1 feature. The structure here would be something like org.binding.cul and org.binding.cul.max.
However I looked at the code and notices in the xml you had a cul bridges and a max bridge. Where the max bridge had the cul bridges as parents. This is not allowed. A bridge can not have a parent. In it looked like the max bridge was a bridge itself and the other cul parents didn’t seem to bridges itself. So this looked more like a case where one part is a transport project (cul) and the max is an actual binding. So if the max bridge requires max specific settings this structure looks more logical.
Thank you for the fast answer. The bluetooth bindings are a good example and I think I can refactor it to a similar structure with org.binding.cul and org.binding.cul.max. This was really helpful.
Is there any architecture reason why a bridge should not depend on another bridge? Technically it’s working fine, As a bridge is also just a thing.
It allows to split technical between the bridge as a serial device which is initialized for MAX! and the the bridge which handles the MAX! protocol like parsing the messages, ACK and find the right thing to deliver messages. I thought this was a good idea.
