While d eveloping TDM, I've been trying to find out if entire device management could be done _without_ using WebUI; the simple answer is no, because of console. While a lot of data can be requested via MQTT, some debugging information is available only there. Hence my suggestion, to add the possibility to forward console to MQTT.
Why? Because for a tool that's not meant to be used as a main interface to Tasmota, webserver takes up a reasonably amount of resources.
As it will naturally increase MQTT chatter a lot, I have a few thoughts how to avoid it.
This is just a concept, as I'm not proficient enough (or at all?) in C++ to even attempt making a draft or a PR, but @shantur said that this should be easy to implement.
@arendst what resources would be free if webserver is not used?
Another option (which @jziolkowski won't like it) can be Websockets. That could give Tasmota another way to communicate to. In my opinion, one good thing about using Websocket for configuration management is that Websockets can be used without any MQTT broker setup.
@shantur +1 dislike Websockets ;-)
Indeed, there are plenty alternatives. But at the same time, Tasmota which is meant to be used primarily via MQTT, doesn't present all the (vital) data via this transport.
Without the webserver you'll lose Wemo/Hue emulation too.
Just a compile without define USE_WEBSERVER gives a rough idea of the impact.
You can't have everything, huh? :)
I assume there is no way to have a "lightweight" webserver for emulations?
However, what about the core of the issue? Sending log data throught MQTT?
Log data must be possible is most likely the only info currently not send through MQTT.
What MQTT tool are you planning to use to handle these messages? I use Mqtt-Spy and it's not up to it.
My application, TDM: https://github.com/jziolkowski/tdm
Under heavy development now.
It's not just a MQTT client; it's a MQTT client that understands Tasmota and its functions.

How about piping/publishing the console output to a topic called console.
So if a normal topic would be stat/sonoff1/power it would send to stat/sonoff1/console.
Or worse cons/sonoff1 which breaks with previous syntax...
Well it's actually logging output that will be piped/published. All other messages or send to mqtt anyway.
So stat/sonoff1/log makes more sense
A matter of adding MqttLog to SeriaLog, Syslog and WebLog...
I would prefer stat/sonoff1/console
But it's not really a console as it will only pipe logging information.
My thoughts exactly. MQTTLog with log levels like other commands.
Console sounds better, but indeed it is log output, so stat/sonoff/log makes more sense
I'll make a POC
So if I understand correctly, on this topic would be only the log data, not the command outputs etc?
Correct. The command outputs were always send as MQTT and will continue to do so.
That was quick :) Slow day? ;)
Closing this issue as the feature has been added. Thanks :)
No, this is not added :) Theo only added some boilerplate code and moved on to bigger topics. But the feature is not there.
This is all you will get.
Oh damn, I tested this earlier and it wasn't working. My bad, sorry Theo.
It seems it works out of the box :) Fantastic, thank you.

One thing is missing: MQTTLog in STATUS3
Thanks a lot!