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
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: [WIP] Homie v3.0.0 by bodiroga · Pull Request #47 · jalmeroth/homie-python · GitHub). 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 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? 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
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) 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
Anyway, whatever you decide, thank you very much for your work David
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.
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!
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 openhab.org.
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.
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.
We need a working solution first.
If libraries are not updated, openHAB won’t be able to talk to no devices and that is an undesired situation.
