Skip to content
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

Enable forwarding entire console output to MQTT [MQTLog?] #6498

Closed
jziolkowski opened this issue Sep 27, 2019 · 25 comments
Labels

Comments

@jziolkowski
Copy link
Contributor

@jziolkowski jziolkowski commented Sep 27, 2019

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.

  • first of all, by default (unless specified otherwise during compilation), the feature is disabled. Those who don't need it won't even know it's there.
  • one option is to have the console respond on a completely different, hardcoded prefix, ex. cons/, so MQTT clients, home automation software etc can simply ignore the messages
  • another option, as an alternative to the above, reply topic different than the usual RESULT, ex. CONSOLE, which also can be ignored from parsing by other apps.

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.

@Jason2866

This comment has been minimized.

Copy link
Contributor

@Jason2866 Jason2866 commented Sep 27, 2019

@arendst what resources would be free if webserver is not used?

@shantur

This comment has been minimized.

Copy link
Contributor

@shantur shantur commented Sep 27, 2019

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.

@Jason2866

This comment has been minimized.

Copy link
Contributor

@Jason2866 Jason2866 commented Sep 27, 2019

@shantur +1 dislike Websockets ;-)

@jziolkowski

This comment has been minimized.

Copy link
Contributor Author

@jziolkowski jziolkowski commented Sep 27, 2019

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.

@arendst

This comment has been minimized.

Copy link
Owner

@arendst arendst commented Sep 27, 2019

Without the webserver you'll lose Wemo/Hue emulation too.

Just a compile without define USE_WEBSERVER gives a rough idea of the impact.

@jziolkowski

This comment has been minimized.

Copy link
Contributor Author

@jziolkowski jziolkowski commented Sep 27, 2019

You can't have everything, huh? :)

I assume there is no way to have a "lightweight" webserver for emulations?

@jziolkowski

This comment has been minimized.

Copy link
Contributor Author

@jziolkowski jziolkowski commented Sep 27, 2019

However, what about the core of the issue? Sending log data throught MQTT?

@arendst

This comment has been minimized.

Copy link
Owner

@arendst arendst commented Sep 27, 2019

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.

@jziolkowski

This comment has been minimized.

Copy link
Contributor Author

@jziolkowski jziolkowski commented Sep 27, 2019

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.

image

@arendst

This comment has been minimized.

Copy link
Owner

@arendst arendst commented Sep 27, 2019

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...

@arendst

This comment has been minimized.

Copy link
Owner

@arendst arendst commented Sep 27, 2019

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

@arendst

This comment has been minimized.

Copy link
Owner

@arendst arendst commented Sep 27, 2019

A matter of adding MqttLog to SeriaLog, Syslog and WebLog...

@shantur

This comment has been minimized.

Copy link
Contributor

@shantur shantur commented Sep 27, 2019

I would prefer stat/sonoff1/console

@arendst

This comment has been minimized.

Copy link
Owner

@arendst arendst commented Sep 27, 2019

But it's not really a console as it will only pipe logging information.

@jziolkowski

This comment has been minimized.

Copy link
Contributor Author

@jziolkowski jziolkowski commented Sep 27, 2019

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

@arendst

This comment has been minimized.

Copy link
Owner

@arendst arendst commented Sep 27, 2019

I'll make a POC

@jziolkowski

This comment has been minimized.

Copy link
Contributor Author

@jziolkowski jziolkowski commented Sep 27, 2019

So if I understand correctly, on this topic would be only the log data, not the command outputs etc?

@arendst

This comment has been minimized.

Copy link
Owner

@arendst arendst commented Sep 27, 2019

Correct. The command outputs were always send as MQTT and will continue to do so.

arendst added a commit that referenced this issue Sep 27, 2019
Add initial support for MQTT logging using command MqttLog <loglevel> (#6498)
@jziolkowski

This comment has been minimized.

Copy link
Contributor Author

@jziolkowski jziolkowski commented Sep 27, 2019

That was quick :) Slow day? ;)

@ascillato2

This comment has been minimized.

Copy link
Collaborator

@ascillato2 ascillato2 commented Oct 2, 2019

Closing this issue as the feature has been added. Thanks :)

@ascillato2 ascillato2 closed this Oct 2, 2019
@jziolkowski

This comment has been minimized.

Copy link
Contributor Author

@jziolkowski jziolkowski commented Oct 2, 2019

No, this is not added :) Theo only added some boilerplate code and moved on to bigger topics. But the feature is not there.

@ascillato2 ascillato2 reopened this Oct 2, 2019
@ascillato2 ascillato2 removed the fixed label Oct 2, 2019
@arendst

This comment has been minimized.

Copy link
Owner

@arendst arendst commented Oct 2, 2019

This is all you will get.

@jziolkowski

This comment has been minimized.

Copy link
Contributor Author

@jziolkowski jziolkowski commented Oct 2, 2019

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.

image

@jziolkowski jziolkowski closed this Oct 2, 2019
@jziolkowski

This comment has been minimized.

Copy link
Contributor Author

@jziolkowski jziolkowski commented Oct 3, 2019

One thing is missing: MQTTLog in STATUS3

@jziolkowski jziolkowski reopened this Oct 3, 2019
arendst added a commit that referenced this issue Oct 4, 2019
Add MqttLog to my_user_config.h and status 3 (#6498)
@jziolkowski

This comment has been minimized.

Copy link
Contributor Author

@jziolkowski jziolkowski commented Oct 4, 2019

Thanks a lot!

@jziolkowski jziolkowski closed this Oct 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.