Any developers care to chime in? This just gave me a fibaro-style chill. These are major bugs in the MQTT binding, and MQTT + Homie is a major technology for the target audience of an open home automation system such as openHAB. I didn’t come here looking for a controller for my MQTT devices – it’s the other way around. After jumping on the openHAB bandwagon I’ve spent weeks getting proficient at MQTT and Homie (even writing my own device implementation) because it seemed like a good fit for openHAB. I had no idea when I started that the implementation had so many issues. Hearing that it there will be a major release without any of these bugs fixed is disappointing.
1 Like
When griping about “major bugs” it would be as well to point to the github issues for each one, to forestall further panic. We’ve sorted one today which is about expectations only.
The biggest one so far is this one:
#5786
This one is real bad because it breaks an otherwise functioning system. It even causes homie items to break generic items.
I believe I’ve done all that I can with regards to describing, isolating and reproducing this bug. At this point all that’s left is to actually fix it. And, I was just made aware that there may be no one to do that.
Hey, I don’t know how I became the Homie advocate. I saw it in openHAB (and in the forum), it seemed to fit the bill, so I learned to use it. I had no idea it would be such a headache.
Isn’t this what the REFRESH command is supposed to be for, at least in part?
Hm. I think the refresh command is making the core re-requesting all channel values.
openHAB does only support commands on channels not on Things. And that’s what is required for the mentioned actions.
Regarding MQTT. The thing is that the underlying library (paho mqtt) is full of bugs and only maintained by one guy that only occasionally works on it and currently focuses on mqtt5. And its an eclipse project 
paho would need to be replaced by that other mqtt library (forgotten the name but linked in one of the issues). That’s unfortunately a Core contribution, which I’m clearly not doing at the moment.
paho has several subscription bugs with the async API that I’m using. Most of the java people out there seem to use the synchronous API which apparently works (most of the time). I don’t see a point in working around in the mqtt binding when the actual bugs are further down in the stack.
Cheers, David
1 Like
REFRESH is an Item based command, with an expectation that a binding would interpret it as a prompt to review/update the Item state. Essentially, trigger a read poll on the channel. Data stuff.
Refreshing Things would be about updating thing properties - for example, to force an update from a zwave or homie device that changes its properties (conceivably as a result of binding changes). Use case - zwave 2.4 broke existing things that needed to be deleted and readded to recover. Configuration stuff.
EDIT - I suppose a good example would be some kind of HTTP service, weather etc.
REFRESH could be used to fetch current temperature to our Item.
Thing refresh might be used to update our password or certificate.
1 Like
OK, I think I understand. Thanks for the clarification.
1 Like
@leif I’m very committed in my own HA system architecture to MQTT and it’s panning out well. What MQTT needs though is a discovery protocol and topic definitions for standard capabilities and I am finding homie lacking, the Home Assistant MQTT discovery protocol is quite basic but works reasonably well.
In my quest to promote and include support for MQTT in several controllers I have released code that implements both protocols , with a view to supporting HA with their protocol and OpenHAB with homie. Like you I feel the latter has been more burden than reward.
Awaiting 2.5 was always being advocated as the ‘already fixed’ solution to the 2.4 homie problems To hear that OH 2.5 M2 will still have known issues at so many levels in both homie and MQTT is very discouraging. I am unfortunately not of a capability level to contribute towards fixing it . I wish I hadn’t spent so much time on the homie projects I’ve worked on. What a shame.
I’ve been undecided between HA and OH, the current impasse and disinterest that I sense from the preceding posts has made my decision a little easier I think as resolving the issue seems a distant prospect and I need MQTT to work dependably.
K
1 Like
@xAPPO, I agree, I have made a large investment in MQTT/Homie which now feels like a dead end. If the problems lie in the PAHO library which HA and Python use then the problem is greater than just OH.
2 Likes
I feel exactly the same way… well, except for HA. The rudimentary Z-Wave support in HA was a non-starter for me as you know.
If the underlying subscription bugs are actually in the paho client (that’s the MQTT client code which the MQTT binding is written on top of) then chances are the openHAB HomeAssistant MQTT Component support is going to have the same exact issues.
Exactly! I was led to believe this as well.
I don’t think this is okay. I believe MQTT and Homie fits right into the spirit of openHAB and that’s why I and others adopted it when we came across it. I don’t think it’s right for it to be abandoned at this juncture. With all the invested time it seems like fixing the glaring issues would take only a fraction of the total time spent so far, and make it workable for the future. If not, what is the alternative DIY-friendly technology being promoted for use with openHAB?
Worrying…
Eclipse messed up the names. Please be careful when you say “Paho library”. The C/C++ paho mqtt library is in really good shape and supports mqtt5 for ages. The python library as well.
It is just the java library that is lacking.
But considering that java had its peak 2012 and Google turned away from it (Go was developed to replace Java within the Google company and Kotlin appeared later on to run on the JVM fork that runs on Android devices) I do not see much progress on Java anyway.Homie is not abandoned. It is a json-free discovery protocol of entities on an mqtt broker. It does not specify HA types though, which makes the mapping more like heuristic than deterministic.
1 Like
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.
1 Like
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
1 Like
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).
2 Likes