Thanks for the clarification. Java isn’t my choice, it’s just what openHAB happens to be written in 
.
You know far more about this than anyone else on this thread. What would you say needs to be done to correct the subscription bug once and for all?
Other annoyances are livable for a while, but that one is really a problem in my opinion.
openHAB is open source. The Java Paho library is open source. openHAB depends on the Java Paho library.
Why is no one mentioning or considering throwing some support towards the Java Paho library? Isn’t this how it’s supposed to work? The users of open source software should contribute to supporting that software in some way? Many of us complain about people taking without giving back. Are we not doing the same to the Java Paho library in this case?
I believe I saw similiar but couldn’t describe it at the time. As I was just getting setup on 2.x binding i just restarted and moved on vs troubleshooting further. My system is fairly static in regards to config once setup.
Well you’re the first to identify the problem. The homie support in Athom’s Homey came out about a year ago but when tested didn’t work at all well with OH2.4. The reason offered was that 2.5M1 would be needed. Then 2.5M1 was better but still had some issues and it was mentioned some fixes missed M1 so 2.5M2 became the target to test against. I don’t use OH very much but obviously I wanted the Homey and Hubitat homie implementations to work so was awaiting 2.5M2 …
Unfortunately there’s no other viable controller to test against. Well - except the Athom Homey & Hubitat Elevation implementations both of which will, and do implement homie discovery.
Would love to… but that’s way beyond me.
K
Believe me, if I knew any Java, I’d be on it! As it is, I think I’m more useful to the community in areas where I know what the heck I’m doing. I spent today cleaning up and making a publically releasable version of both my Base library and HomieV3 library for ESP8266 and ESP32. I’m about to create a thread about it right now. Tomorrow I’ll also release the full source code for my bedroom MCU. Then I’ll probably take a break from openHAB and do some “real work” for a while :).
It also helps a lot to get the implementations done for espeasy and other esp libraries out there. They all support the homeassistant standard though, which might be good enough for openHAB. The feedback I got so far is that those solutions are not prepared to publish multiple mqtt topics for one sensor or actor, which would be required for Homie.
David, can you point me to the issues where subscriptions bugs are explained (or at least steps to reproduce). Maybe we can fix them in Paho or fork Paho and fix them there. I tried to find an alternative to Paho but it seems the only one is HiveMQ but that is not an OSGi bundle, so we would need to add wrapping (again).
Argh… Clicked the wrong button and my long answer is gone. Sigh.
tldr; Forking is a bad idea. Fixing also. Takes ages on paho’s side.
HiveMQ is awesome. Good async API support.
We need to adapt anyway. paho mqttv5 branch has a different API. Let’s go with the better library. no osgi wrapping necessary if static compiling the transport. should be fine because all addons are using the transport and not paho directly afaik.
Cheers, David
@J-N-K, if you and @David_Graeff could work together to bring an stable MQTT binding it would be awesome, MQTT is a key transport protocol for home automation and openHAB deserves to fully support it 