simplest-thing.js non detected during scan

[Utopiah]

No error while I start it using node simplest-thing.js and when I verify using curl.

Yet, when I try to add the device, it doesn't get detected. If I manually add it though, it works.

While checking the logs of the gateway I notice this error 2020-11-05 08:12:03.765 INFO : thing-url-adapter: Failed to connect to http://gateway (2).local:8888: FetchError: request to http://gateway/%20(2).local:8888 failed, reason: connect ECONNREFUSED 127.0.1.1:80 which happened every time simplest-thing.js was started and during the scan.

I assume the error comes from the hostname gateway (2).local being wrong. I do have gateway and gateway.local in /etc/hosts/ but I have never seen "gateway (2)" or added that manually anyway.

[mrstegeman]

This can happen when you’re running multiple mDNS servers on the same host. If you add your device by IP address, or use localhost, it should work fine.

[Utopiah]

Yes, as I said when I manually add it it works but ideally I'd like them to be autodetected. Beside the property/action discovery the broadcasting capabilities of Things is interesting.

When you mentioned "multiple mDNS servers on the same host" how can I know if that's the case? Does the Gateway and some adapters or bridge do that and conflict with each other? Would it help to host the Thing on another device than the Gateway?

[mrstegeman]

The gateway runs an mDNS server as well, which would then conflict with the web thing. That's why you end up with the (2) hostname. If you put the web thing on another device, things should work better.

[Utopiah]

I followed the same process and tried on my desktop which, from all I can remember, has no Thing running and get the same problem but with a different hostname namely 2020-11-05 21:32:21.114 INFO : thing-url-adapter: Failed to connect to http://fabien-CORSAIR-ONE-i160 (2).local:8888: FetchError: request to http://fabien-corsair-one-i160/%20(2).local:8888 failed, reason: getaddrinfo ENOTFOUND fabien-corsair-one-i160 fabien-corsair-one-i160:80

[mrstegeman]

Is avahi running on your desktop?

[Utopiah]

Indeed I have avahi-daemon (and on the RPi with the gateway, just checked)

[mrstegeman]

So, again, that's the conflicting mDNS service. If you stop that daemon and try again, do you get the expected result?

[Utopiah]

Yes! Now that worked right away. So... I'm not sure what to proceed from there since I imagine the audience for this example is people who are not yet familiar with Thing. If there is no way to detect it the mDNS conflict from the client itself maybe a warning in the documentation could help prevent this unexpected behavior for newcomers.

[mrstegeman]

There are other mDNS libraries we could theoretically use for Node that just plug into avahi. I chose our current one specifically because it was cross-platform and pure JS, but that has obviously led to other issues. Thoughts?

[Utopiah]

Indeed I was precisely wondering how reliably could the Thing detect avahi and rely on it instead. It seems to be present and enabled by default in the most common distribution for newcomers, namely Raspbian and Ubuntu.

[mrstegeman]

We actually do this in the gateway... kind of. If we see that avahi is running, we just move on, otherwise we start up our own mDNS server. In the case of this library, the preferred thing would be to switch libraries at runtime, but that obviously leads to an additional platform-dependent dependency.

[mrstegeman]

Actually, scratch that. We stopped doing that a while ago. We just rely on the system service at this point.