Thank you, i can read, no need to repeat 
Already done and updated.
1 Like
Good to hear about this binding. I would like to test your binding on OH3.
Could you provide a jar for it?
Thanks 
@hilbrand I managed to conquer everything except one problem.
[ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.2.7:verify (karaf-feature-verification) on project org.openhab.binding.irobot: Feature resolution failed for [openhab-binding-irobot/3.0.0.SNAPSHOT]
[ERROR] Message: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-binding-irobot; type=karaf.feature; version=3.0.0.SNAPSHOT; filter:="(&(osgi.identity=openhab-binding-irobot)(type=karaf.feature)(version>=3.0.0.SNAPSHOT))" [caused by: Unable to resolve openhab-binding-irobot/3.0.0.SNAPSHOT: missing requirement [openhab-binding-irobot/3.0.0.SNAPSHOT] osgi.identity; osgi.identity=org.openhab.binding.irobot; type=osgi.bundle; version="[3.0.0.202010110837,3.0.0.202010110837]"; resolution:=mandatory [caused by: Unable to resolve org.openhab.binding.irobot/3.0.0.202010110837: missing requirement [org.openhab.binding.irobot/3.0.0.202010110837] osgi.wiring.package; filter:="(&(osgi.wiring.package=com.hivemq.client.mqtt)(version>=1.1.0)(!(version>=2.0.0)))"]]
Could you help me with this? My binding uses hivemq client directly, bypassing OHās wrapper (comments in the code explain why). I am assuming that itās somehow available from within OpenHab core (it seems to be the case). Iāve checked what org.openhab.core.io.transport.mqtt does about this. It does not list the hivemq in pom.xml; nether it even contains features.xml. How is my binding different and whatās missing ?
For your reference the full build log is here: https://travis-ci.com/github/openhab/openhab-addons/builds/189287580
@hilbrand I was able to fix that error too by adding a āfeature dependencyā to feature.xml in the same way as i found it listed in one of core subdirs. Now everything seems to build, but the job fails with:
The job exceeded the maximum time limit for jobs, and has been terminated.
Here i definitely need your (or some other competent personās) help.
By the way is that ? Why do we have several parallel mechanisms for handling dependencies? Sometimes pom.xml is used and sometimes feature.xml. And the latter seems to be completely undocumented.
The pom is for compile time dependencies and the feature.xml is for runtime dependencies and related to the use of OSGI. There is some documentation here: Build System | openHAB Both pom and feature are generic concepts so there is more documentation in general.
So you need both, but at compile time more depencies are available from openhab core poms as that has little impact. While at runtime loading libraries has effect on memory so that is more closely controlled and thus you need to add it to the feature.xml. itās intended to use as few as possible additional libraries. Because each library adds to the memory footprint. So for example we have standardized on gson for Json parsing. So it will be suggested to use that library during review.
Regarding mqtt. You mention the provided wrapper doesnāt work for you. But what would be needed to change in the wrapper to make it work? It would be better to fix the wrapper than to hack a custom implementation, because the wrapper hides the internals and thus if those internals would change your binding would break and requires additional work.
The comment in my code describes the problem: Roomba chokes on UNSUBSCRIBE command. We could add a method to MQTTConnectionBroker, something like disableUnsubscribe(boolean disable) to switch on that behavior. Do you want me to make a patch? It seems not difficult, i could do it.
I remember you mentioned it earlier. I checked it out and it looks like it isnāt good for dealing with indeterminate content. I mean - GSON works by introducing Java classes with structure identical to the JSON to be (de)coded and then (de)serializing them from/to JSON. But what it fields can be missing? Or if i do not need all fields, but only specific ones ?
I see some other bindings use org.json too. Is this a strict requirement ?
I did a quick look at your code and Iād suggest you look at https://www.openhab.org/docs/developer/guidelines.html. It doesnāt look like any of your classes are using null annotations. Also you shouldnāt be catching Exception. Iād also do as suggested by @hilbrand for both json and mqtt.
@ranielsen Thank you, iāve done it today and updated the pull request.
To tell the truth, if youāre interested, this is IMHO one of the most controversal requirements. Because it automatically turns all the fields @NonNull, but you normally have a field called āconfigā, which is initially null but filled in in initialize() by design. Iāve looked at some other binding sources, they simply ignore it, and Eclipse issues tons of (false) warnings on them. I think it does not do any good, it is simply annoying and teaches the developer to fight those warnings instead of doing something useful.
Or maybe i am a bad Java programmer. Well, my brains are badly spoiled with C and other machine-oriented stuff
Iāve read through gson docs again, it seems to also have low-level stream parser API, that should be appropriate. Iāll try to use it a bit later when i have more time.
As to MQTT wrapper, iāve asked whether i should make a patch for the core but got no reply so far.
Creating a patch seems like a good idea. I donāt know enough specifics on what the best solution is, so creating a pr seems like a good starting point.
1 Like
@hilbrand I have rewritten the binding for GSON (and learned to use it). The only bad part about it is documentation. Pull Request https://github.com/openhab/openhab-addons/pull/8723 updated
True! For such a popular package, the GSON documentationā¦ well, letās be nice and say it could use some improvement.