[mqtt][homie] Delete '$name' subscription in discovery service

[bodiroga]

Context:

Although we thought that #7723 would solve #7252, the truth is that after the release of openHAB 2.5.6, new users started complaining that their Homie devices were not behaving correctly ($name message does not arrive). Taking into account that there are some problems with subscriptions and retained messages (in some circumstances the binding does not receive all the messages it should), it has been decided to remove the subscription to the "homie/xxx/$name" topic in the Homie300Discovery class. The only problem with this solution is that the name of the thing will be the same as the device id of Homie, but I think that this small loss of functionality will compensate for the advantage of fixing the bug. Also, the transport.io.mqtt library is already being improved to fix its bugs (openhab/openhab-core@cc3f140, thanks @jochen314), although these changes are only valid for openHAB Core 3, so I think that, until openHAB3 is released, it is better to opt for this workaround.

Also, in the PR a new timeout has been added in the HomieThingHandler, which represents the maximum time the device can take to be completely processed. This timeout does have a high value (5000 milliseconds), although the other two timeouts still have values below 500 milliseconds. This improvement ends up defining the changes introduced in #7760, since the previous code could fail in devices with many nodes and properties.

What do you think @jochen314, @cpmeister, @J-N-K?

Thanks!

Closes #7252

[TravisBuddy]

Travis tests have failed

Hey @bodiroga,
please read the following log in order to understand the failure reason. There might also be some helpful tips along the way.
It will be awesome if you fix what is wrong and commit the changes.

[bodiroga]

Hi everyone!

I don't understand why is Travis failing 😞 Do you know what is this error about?

[FATAL] Non-resolvable parent POM for org.openhab.addons.itests:org.openhab.binding.mqtt.homie.tests:2.5.2-SNAPSHOT: Failure to find org.openhab.addons.itests:org.openhab.addons.reactor.itests:pom:2.5.2-SNAPSHOT in https://oss.sonatype.org/content/repositories/snapshots/ was cached in the local repository, resolution will not be reattempted until the update interval of sonatype-snapshots has elapsed or updates are forced and 'parent.relativePath' points at wrong local POM @ line 6, column 11

I would be awesome if we could merge this fix for openHAB 2.5.7 and have a stable Homie discovery process 😉

Thanks!

[Hilbrand]

Just a small comment. Let's go for 2.5.8!

[Hilbrand]

Nice to put them in constants. Can you add the unit on these constants:

Suggested change

	public static final int HOMIE_DEVICE_TIMEOUT = 5000;
	public static final int HOMIE_SUBSCRIBE_TIMEOUT = 500;
	public static final int HOMIE_ATTRIBUTE_TIMEOUT = 200;
	public static final int HOMIE_DEVICE_TIMEOUT_MS = 5000;
	public static final int HOMIE_SUBSCRIBE_TIMEOUT_MS = 500;
	public static final int HOMIE_ATTRIBUTE_TIMEOUT_MS = 200;

[bodiroga]

Sure @Hilbrand, done in the last commit! 👍

[Hilbrand]

Did you intentionally increase the timeout to 15 seconds or was it a mixup with some testing you did?

[bodiroga]

Ups, I pushed the changes before writing my "longer" message, sorry. Yes, I have increased the timeout on purpose, because for really complex devices 5 seconds is not enough. That is also the timeout value that was set before #7760, so nothing unexpected. I really hope that this PR can "fix" the Homie bug that we've been suffering from for so long, and I'm really sorry for all my trial and errors, I thought that it would be easier to solve, but it seems that it wasn't true 😞

[bodiroga]

Hi @Hilbrand!

Thank you for your suggestion, I have already changed the names 😉 And I have also increased the device_timeout value, because devices with many many many nodes and properties (50-100) can take more than 10 seconds to be processed. Anyway, this value doesn't impact the discovery time of fast devices, but it is there for those unusual cases.

Many thanks for taking care of this PR!

[TravisBuddy]

Travis tests were successful

Hey @bodiroga,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[Hilbrand]

LGTM

[TGit-Tech]

Yes; I'm still getting this problem in OH3.

2023-02-07 17:22:53.827 [WARN ] [.mqtt.homie.internal.homie300.Device] - Could not subscribe

java.util.concurrent.CompletionException: java.lang.Exception: Did not receive mandatory topic value: homie/tode/rctode/$name

It seems to be intermittent. Sometimes it works; most of the time it doesn't.
Running.
openHAB 3.4.1
Release Build

After hours of playing around. Getting it to semi-work required.

1. Adding a 50ms delay after each homie publish.
2. Adding the device (via inbox) first; then restarting the device.
3. Sending all homie publishes 3x.

Finally; Channels started to show up - this just isn't right.