-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mDNS discovery could be more useful #6020
Comments
disabling mDNS was due to excessive resource usage in newer frameworks. Please prove me wrong, I’d love to continue using mDNS... |
Hi By disabling mDNS by default, a lot of issues and complaints from users had been solved. As you have probably read in the issue linked, some users have their routers or other softwares misconfigured and not allowing mDNS or spamming it. Besides we don't have more issues and complaints due to mDNS problems, and as very few users make use of mDNS, I don't think it is going to be enabled by default again. Anyway, mDNS can be enabled just activating it in my_user_config.h if you want to make it enabled by default. Also, if you enable it using the Tasmota console, that config will remain on all the following updates. |
I would love that Tasmota have a feature to be autodetected by home automation softwares like using mDNS but it has to be something more lightweight for the tiny esp8266. As example, Tasmoadmin uses ip ping scan for detecting Tasmota devices |
I see, well, any other autodiscovery mechanism would work too for me. If there are reasons why mDNS can't be used properly on ESP chips (I lack knowledge of insides of Tasmota) then so be it. But I'd love to be able to provide our users a way to just add those device by discovering them without having to lookup the ip in the router and/or find SetOption commands in the Wiki before that. I just installed TasmoAdmin to see what it does... Haven't read through its code, but it seems to do more than just ping-scanning... It also requires username & password before the scan, which breaks as soon as 2 devices have a different user setting. Not saying that it won't work at all, but again seems a very hacky way to ping scan everything on the network and try to log in to see if it actually works. Do you think UPnP might be an option instead? |
The key design goal of Tasmota is the use of mqtt. Every other function is a nice to have feature. |
uPnP as being used by current emulation support bears a heavy load on the device. I suggest you try to dump your uPnP traffic initiated by chromecast, sonos, alexa , router(s) and others. All have to be analysed by Tasmota before taken action. For me it's a no-go implementing even more uPnP listeners. I personaly do not use emulation for the reason stated above. |
ok, well then... Sad to hear that there is no interest in making tasmota work for non-tech-geeks. I'll go and write a howto on dealing with IP addresses then... In any case, thanks for tasmota! |
I work in the tech industry, and would still love to have mDNS support. More documentation, education, and guidance, around how to use it properly would be helpful for non-tech users. |
Have you look for this feature in other issues and in the wiki?
Yes. This has recently been disabled by default, IMHO likely because not being implemented completely in the first place and hence not being used by many.
Is your feature request related to a problem? Please describe.
mDNS discovery has recently been turned off by default. There is SetOption 55 to enable/disable it. In a previous discussion the common opinion seems to have been that this feature should be disabled by default. See issue #4793
I am looking at this from a smart home system developer point of view. To be precise, this came up while updating nymea's tasmota plugin (https://nymea.io). As an older Sonoff Touch T1 here announced itself via mDNS I just wanted to add support for auto-detecting available Tasmota devices in the network, just to discover that updating to the latest tasmota firmware this feature would not work any more. Having to manually SetOption55 1 kinda defeats its purpose, given this feature is particularly useful when someone doesn't know the IP. Also, mDNS is supposed to help people who lack understanding of what IP addresses are to still being able to configure their devices.
Describe the solution you'd like
If such a feature exists, IMHO it should be enabled by default, given that people who actually know what it is are capable to disable it, but not the other way round.
Describe alternatives you've considered
Hmm... Well, the alternative is to keep it disabled and not have IP-address-less setup available :)
Additional context
That said, I also believe the mDNS entry should be extended. This is the current entry after having it enabled manually:
= IPv4 sonoff-5482 _http._tcp local hostname = [sonoff-5482.local] address = [10.10.10.90] port = [80] txt = []
For me as a developer this is not that useful actually, given I cannot filter tasmota devices on the network by looking for
_http._tcp
only, pretty much any device announces those services as well. Well, I could probably filter for "sonoff-*" in the name but that is very bad practice, given the name might change. It would actually be very usuful if the txt record could inform about some context. For instance, if possible at all, what module it is, eg, whether it is a 2 channel or 4 channel one, what software version it has installed and such.For instance:
= IPv4 sonoff-5482 _http._tcp local hostname = [sonoff-5482.local] address = [10.10.10.90] port = [80] txt = ["devicetype=tasmota", "model=sonoff-t1", "version=6.6.0"]
That would allow users to just connect those devices to their wifi (with projects like tuya-convert this is also possible without knowing what an IP address is) and then just open their favorite smart home app on their phone and add tasmota devices just like that. In fact it could even allow nymea to automatically have them appearing in the system as nymea is already hosting an MQTT server and capable of configuring tasmota devices to talk to it without having the user knowing what MQTT is.
The text was updated successfully, but these errors were encountered: