Roadmap: MQTT binding

Hello community,

this is the roadmap for the MQTT binding for the next months.


  • Improve HomeAssistant MQTT compatibility :heavy_check_mark:
    • and make it 100% compatible to Tasmota HA MQTT
    • implement all missing HA components
  • Migrate all MQTT bundles to the new buildsystem :heavy_check_mark:
  • Move HA and Homie parts into separate bundles :heavy_check_mark:


  • Release Homie 4
  • Fix all outstanding GenericMQTT and Homie bugs and write new tests to cover those cases
    • Fixed rollershutter :heavy_check_mark:
    • Fixed Dimmer/PercentageType :heavy_check_mark:
    • others
  • Readme: Move all .thing/.item file specific parts into an own file (need to be discussed with the website team for adapting the generator) :heavy_check_mark:

Cheers, David


Hi @David_Graeff!

It’s great to see that you will be working again on the MQTT binding, fantastic!

But there are a couple of things that scares me a bit :frowning_face:

  • Release Homie 4

Are you just talking about the convention (I don’t think so, because you wouldn’t write it here) or changing the binding to only follow the 4th version of the convention? As far as I know, the most known implementation of the convention is Homie-ESP8266 and we haven’t released yet a stable version of the library that is compatible with Homie 3.0.1. The python library that allows one to write Homie clients hasn’t been updated (my PR is still pending: I know that in an ideal situation the development of the convention should go faster, but the reality is that we have lots of troubles syncing the controller (openHAB) and clients (libraries) development.

And to make things worst, the current version of the binding has many (small) bugs that make the Homie-openHAB combo unusable :cry: We need a working solution first.

Could you please consider fixing first the Homie 3 convention bugs (2019-03 in your roadmap) and wait a little bit until moving the binding to Homie 4? :angel: If libraries are not updated, openHAB won’t be able to talk to no devices and that is an undesired situation.

Many thanks, as always, for your commitment to openHAB David :+1:

Best regards,


1 Like

I’m talking about the specification. Homie 4 has arrays removed, which is beneficial for the openHAB controller, because I have never implemented them :smiley:

Yeah, sure, @David_Graeff, I know it! :wink:

But what worries me is that currently anyone that tries to use Homie with openHAB gets a bad impression of the implementation, because things don’t work well (even in the snapshot version) :cry: And I fear that jumping to Homie 4 before giving a stable Homie 3 implementation will create the same scenario. No stable libraries and the binding quickly adopting the latest convention -> errors, troubles and bad integration.

Yes, I’m aware that Homie 4 simplifies the convention and remove unnecessary code (less required attributes, no more stats, extension nodes…), so changes should be very backward compatible, but they don’t bring any benefit feature wise or from the final users perspective. But will the binding’s Homie 4 implementation fully support a Homie 3 device? What devices are we going to integrate in openHAB if libraries are not updated? Sadly it will take months until client libraries reach the stable 4.0 version. For example, have a look here, where people is still deciding about the future of Homie-ESP8266 (the most famous implementation).

That’s why I propose to move the “Homie bugs” statement to the 2019-03, give it more importance and “release” a stable Homie 3 implementation of the binding (fully working and tested, I can help with that). From my perspective, that should be the top 1 MQTT binding priority (from Homie’s viewpoint, of course). It’s your free time, for sure, but I also know that you are a fucking programming master and that you are able to fix the 3-4 pending issues very fast :wink:

Anyway, whatever you decide, thank you very much for your work David :+1:


1 Like

The controller already accepts Homie 3 and 4 devices and will continue to do so. But I also get bug reports about the missing array support which I will never implement. And I would like to write to the readme that the controller is Homie 4 compliant and Homie 3 tolerating.

I don’t have time for MQTT this month. The HomeAssistant part is coming from another contributor that I’m only reviewing.

I know about the situation. The homie website is pointing to both branches of that project.

The binding was stable actually, but a few contributors have changed things that were apparently not good enough documented and my test suite didn’t catch those problems. I will improve that as soon as I’m reworking the bindings structure.

Hi again @David_Graeff!

I don’t have time for MQTT this month. The HomeAssistant part is coming from another contributor that I’m only reviewing.

Ok, I will try to fix the most important issues (mainly the error that makes the Homie device unusable after an openHAB reboot) and me can talk later about the Homie 4 implementation! :wink:

David, do you have a link to the draft 4.0 spec?

You can change the specification version on the homie spec page. Just select develop.

Borrows this thread instead of clutter the forum with a new one.
I have a topic concerning the Embedded MQTT broker.

A) Where in the filesystem could I find the serverkeystore.keystore file referred in the source code?
I can’t find any place where this keystore is created? Was looking into JAVA_PATH/jre/lib/security/ where the java environment is storing the cacerts but didn’t found anything.

B) My embedded broker shows:
2019-04-02 11:07:40.703 [WARN ] [r.internal.EmbeddedBrokerServiceImpl] - Embedded broker offline
when using the “secure option” and I wonder if that relates to a non existent keystore.

secure mode was broken until two weeks ago. You need a snapshot version if you want it to work.
snapshots especially all mqtt parts are not stable atm though.

The keystore file is embedded into the bundle. You find this information on the addon page of

Maybe I’ve missed it, but is it planned to have something like the MQTT event bus in the new binding?

1 Like

Yes you missed that :wink:

It’s part of the mqtt addon examples on how to archive something similar via rules.

Unfortunately they are not rendered at the moment. Have a look at instead.

1 Like

What a pity, I just began to like and implement Arrays…

It seems exceptions from MqttMessageSubscriber#processMessage not handled somehow and just ignored. It would be good to catch them all in modules and report with corresponding loggers, but unhandled should also be processed in transport.mqtt.

1 Like


Is there something planned to add auto discovery of tasmota tasmota/discovery topic ?
SetOption19 1 is deprecated now, only tasmota discovery is included in new images.


1 Like

Note tasmota 12.0.2 has it disabled.

It took me a bit to figure this out.

Manually adding new ones via the UI is not straightforward, but I only have two right now so using the UI should not be too much.