I am about to develop a binding for Meross devices and was able to translate an existing python library to Java using the open-source mqtt client from Hive.
Now I am realizing that this might conflict with the already existing/included Paho client.
Would it be a deal breaker to use Hive’s client lib?
Thanks for advise and sorry that I haven’t researched enough beforehand…
well, my understanding is that Meross has a mix of a rest-api and a mqtt broker. And I need to call the rest api first in order to get user/pw and some other stuff needed for the mqtt connection. I am far from being an expert in this field, maybe I could have used the existing mqtt binding from my binding in order to achieve the same result?
I’m not a developer so my comments are probably not all that worth while. However I had the same question as hmerk.
Based on what you describe it sounds like it might be more appropriate as an extension of the MQTT 2 binding than as a separate binding. The binding currently has support for Homie and Home Assistant which both do automatic discovery of MQTT topics and creates appropriate Things for you. This “feels” like it could be a third type supported by the MQTT binding.
Is this a one time thing or does it need to be frequently? If it’s a one time thing, it seems reasonable and not at all unusual to require those steps be performed manually and used to configure the Things needed.
I do not know if it is possible for bindings to use each other like this in OH 2, but I do know that some stuff that is commonly used, like connections to serial devices, have been pulled out into their own bundles. Perhaps MQTT should be done so as well?
Ok, so if I understand this correctly, I should rather extend the existing mqtt2 binding using the mqtt client available and add a thing(s) provider following the Homie/HA example…
Correct? Sounds doable to me.
If you need to be more to the metal, you can use the openHAB mqtt transport bundle directly (there is a slim paho wrapper class MqttBrokerConnection to be used with a simple nice async API).
it doesn’t. not at all actually. I would have to rebuild all the mqtt logic and that was a quite painful and long lasting experience.
I was under the impression developing a new binding is easier. I am not familiar with Eclipse, never worked with it, and I couldn’t set up the addons project in Intellij. My hope was to either copy some simple binding or follow the presumably easy dev documentation. My plan now is to look at the zigbee/zwave bindings and maybe use that approach. Seems a lot easier…
If you import existing addons from within the “bundles/” directory that will work in Intellij.
You probably have read about the current build system migration away from the former very eclipse specific setup.
Starting an openHAB instance does not work though. But that doesn’t work in Eclipse either at the moment, not so well / painless at least. We haven’t figured out a guide for development yet.
maven does this for you. You import the addons2 project as maven project into Intellij and the IDE should run maven for you.
I didn’t even know that this goal is a thing. You usually do mvn install which does all required steps. I’m not a maven master as well, I’m using gradle usually, but the above command can be found on the internet everywhere
I would consider myself an advanced Maven user. Thanks for the advice.
The mvn compile goal is part of the lifecycle and executed way before install. It checks deps and compiles the source code (surprise!).
Anyhow. The dependencies defined in the addons project cannot be found in a public mvn repo (check). That is why I assumed one needs to checkout the core project and build it once locally. That would install the artifacts in the local mvn repo which then can be found by all sorts of clients (like your IDE or even Gradle(!))
I see. Check the reactor pom of openhab2-addons. All repositories are defined there. But you are right that you probably need to execute maven from the root directory once, before you can use it in subdirectories.
And: We don’t use maven.org (maven central) but bintray