Migration of maxcul OH1 binding to OH3

Development Add-ons
#1

I’m currently working on the migration of MAX! CUL Binding from OH1 to OH3.

The most things are already working on my feature branch GitHub - johgoe/openhab2 at feature/maxcul

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?

#2

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.

#3

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.

#4

The split into two module org.binding.cul and org.binding.cul.max was succesful and I updated my branch.