Tasmota: Feature Request: mDNS default off

Created on 3 Jan 2019  Â·  22Comments  Â·  Source: arendst/Tasmota

Have you look for this feature in other issues and in the wiki?
Yes

Is your feature request related to a problem? Please describe.
_A clear and concise description of what the problem is._
see https://github.com/arendst/Sonoff-Tasmota/issues/4789
and other strange hard to track/find issues
Describe the solution you'd like
_A clear and concise description of what you want to happen._
Disable mDNS by default. Enable via new SetOption command
Describe alternatives you've considered
_A clear and concise description of any alternative solutions or features you've considered._
Build a precompiled version without mDNS, Selfcompiling
Additional context
_Add any other context or screenshots about the feature request here._

(Please, remember to close the issue when the problem has been addressed)

enhancement

Most helpful comment

It won't be SetOption35 as it allows for values from 0-255.

It will be SetOption55.

I'll works on a solution.

All 22 comments

Interesting to note that support for mDNS takes 22.5k of code on core 2.5.0

To add insult to injury it seems a lot of people are using mDNS off-label - this is being discovered by the assumptions made by users when switching to the 2.4.2/2.5.0 cores.

Agree to have a setoption to turn it on/off and that by default it should be off.

There is already the setoption35 for a delayed start for mDNS. As now this delay is not being useful anymore due to the dynamic sleep, we could use that one as mDNS enabling. By default setoption35 is 0.

By default, mDNS support should continue to be included in the default sonoff.bin firmware, but turned off. If any user wants to enable it, with setoption35 1 can enable it and that config will survive upgrades.

What do you think?

It won't be SetOption35 as it allows for values from 0-255.

It will be SetOption55.

I'll works on a solution.

Tried to make mDNS user disablable (what's in a name) but that's a kind of catch 22 because as soon as the mDns library is compiled in by enabling define USE_DISCOVERY it initializes itself on start-up. Usage actually starts when the MDNS.begin() function is called and that can be prevented by setting SetOption55 to 0 (which is now the default).

Once SetOption55 is enabled it needs a restart to disable most of it's functions again.

Not nice but hey, who needs mDns ;-) I never used it. I have my own Linux dnsmasq running and have no need for mDns.

Cool !!! Super Fast. Thanks !!! :+1:

THX!! And again Faaaast.

All we need now is a reset 6 command which scrubs it from the binary...

What's the correct compile time option to restore the previous "on-by-default" behavior?

This change broke my setup, but as I compile my own image, I'm fine with adapting.

In the console type SetOption55 1 for enabling mDNS discovery. After you enable it in your device, this will survive OTA updates or flash updates. It will be lost only if you do a reset command or if you erase all flash.

Is there an easy way to set this in the image?

I have a lot of these, and I don't want to have to connect to the console each time I flash a new one.

You could do a url request from command line or inside a browser

http://192.168.1.2/cm?cmnd=setoption55%201

From a pi you can use wget to do this like

wget -O /dev/null http://192.168.1.2/cm?cmnd=setoption55%201

Or you flash a image make this setting and read it back with esptool.
Dont use static IP!

Or if you want a fancy output on command line to confirm you could use curl in conjusction with jq

curl http://192.168.1.2/cm?cmnd=setoption55%201 | jq '.'

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    20  100    20    0     0    350      0 --:--:-- --:--:-- --:--:--   357
{
  "SetOption55": "ON"
}

Those all need a manual step to provision a new device. That's basically
the same as having to touch one on the console.

I'll work on a change to add a define option to default it to on.

On Sat, Jan 12, 2019, 11:47 AM Andre Thomas <[email protected] wrote:

Or if you want a fancy output on command line to confirm you could use
curl in conjusction with jq

curl http://192.168.1.2/cm?cmnd=setoption51%201 | jq '.'

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 20 100 20 0 0 350 0 --:--:-- --:--:-- --:--:-- 357
{
"SetOption51": "ON"
}

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/4793#issuecomment-453775940,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG0mC4CQDFjXasyLMPX0uhChyhK1Isn0ks5vCjvtgaJpZM4Znq9k
.

With the master firmware read back (with esptool) from device with all settings you have nothing to configure on any device....

@andrethomas

If one doesn't erase the flash memory, won't settings such as SetOption51 be retained in the device flash after new firmware is uploaded? In other words, once the device is configured the very first time, subsequent firmware updates won't require setting SetOption51?

For me, I have a set of configuration steps in a text file that I cut and paste into the Console after I first flash a device with TASMOTA. There are many things which either can't be set in user_config_override.h or require slight differences from device to device (e.g., MQTT topic, Friendly Name, etc.). My configuration consists of a few Backlog concatenated commands that I paste & alter as appropriate for the device. This is a one time, unavoidable, touch. From then on, I update the firmware only.

Of course, if the device starts to "misbehave", I might wipe it and start from scratch. But most of the time, it's just upgrade firmware and go.

Am I delusional or just lucky that this works as I think it does?

Mike

@hackbar

Add

Settings.flag3.mdns_enabled = 1;

To void SettingsDefaultSet2(void) in file support.ino

That way when initial config is created it will store setoption55 as 1.

If the Option is set one time it will survive updates

If one doesn't erase the flash memory, won't settings such as SetOption51 be retained in the device flash after new firmware is uploaded? In other words, once the device is configured the very first time, subsequent firmware updates won't require setting SetOption51?

Yes, settings are retained when OTA or normal flash without erase.

I added a define to enable mDNS - set MDNS_ENABLED to 1 and it will default to on. It can still still be controlled with SetOption55.

I added a define to enable mDNS - set MDNS_ENABLED to 1 and it will default to on. It can still still be controlled with SetOption55.

Correct. Also remember since the settings are persistent after upgrading / reflashing the original state when the initial config was created will persist.

The MDNS_ENABLED directive will therefore only apply to a device which is reset to default settings or newly flashed devices which do not have settings in the spi flash.

If I issue SetOption55 1 on the console using 6.4.1.18 I get DNS: ERROR in the console every senond.
But not directly after sending the command, just after some minutes. Anybody else too?
After sending SetOption55 0 and a reboot the DNS: ERROR is gone again.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

abzman picture abzman  Â·  3Comments

smadds picture smadds  Â·  3Comments

garret picture garret  Â·  3Comments

Joeyhza picture Joeyhza  Â·  3Comments

luisfpinto picture luisfpinto  Â·  3Comments