List of binding-maintainers?

I think I have seen a discussion on this topic before, but I could not find it…

Is there some kind of list of maintainers for the different bindings? I presume that there is a setup with one person being sort of appointed maintainer for a specific binding, or is this not correct?

The reason I ask is that I am considering trying to implement a binding that is based on MQTT transport, and I would like to discuss this with the maintainer of the MQTT binding. I think that maybe these kind of - potentially detailed - questions and answers may be better handled outside the forum.

Unfortunately, we do not have such a list in place. A good starting point could be to have a look into the binding code on GitHub.
The author tag for mqttitude binding says that it was originally developed by Ben Jones. So you could ping Ben and ask him if he is still maintaining the binding.

To add to @hmerk’s suggestion, The MQTTitude (now known as OwnTracks) binding uses and it should be a good model for using the underlying services. It uses Eclipse Paho, but keeping your usage at the transport.mqtt level should be sufficient for most needs. See also the end of the MQTT binding documentation.

Upps, yes, this was not the correct answer,as the question is not related to MQttitude (Owntracks).
Mqtt binding was introdueced by Davy Vanherbergen.

1 Like

Thanks to both of you for quick answers! I already had a quick look at the MQTTitude binding since I had a feeling that this could serve as a “role model” for how to build a binding based on (services from) another binding.

One thing I am not sure about, though:

MQTT and MQTTitude are both legacy bindings. If I decide to make an attempt at my first binding, however, I would obviously write this as a 2.x binding. Do you think that it would still work out to build such a binding based on services from a legacy binding?

Regarding the “list of binding-maintainers”:

I think it would be very valuable to have such a list, but I guess one would first have some kind of process to ask people to “step up to the plate” and agree to be the maintainer?

Best case, the original binding developer is the maintainer. Thats how I handle my developments. I just made exceptions with feature requests for 1.x bindings, I don’t do them, as I layed my focus on openHAB 2.0.

That is not the correct usage of the word “legacy” in the context of openHAB bindings. I’m afraid bad information has been circulated that has led to this misunderstanding. They are both 1.x bindings, but they have not been obsoleted by 2.x bindings, which would make them “legacy.” Please see the descriptions at the top of this page.

The MQTT service is distinct from any other services that depend on it, and does not use 1.x openHAB API afaik. So it is present and usable in OH2 and so should fit your needs.

1 Like

My bad! Your definition makes total sense, :slight_smile:

Good to hear that I should be able to build on the work done in the MQTT binding. Now I will try to find some time to dig a bit deeper into this. Thanks!

1 Like

Here is a attempt for mqtt binding for OH2 that has discovery build in. Main challenge is that OH2 has the channel types which needs to be dealt with