search

homieiot / homie-esp8266

💡 ESP8266 framework for Homie, a lightweight MQTT convention for the IoT
http://homieiot.github.io/homie-esp8266
MIT License
1.36k stars 308 forks source link

Logging to MQTT #534

Closed mosseb closed 6 years ago

mosseb commented 6 years ago

Hi.

I'm nearly ready to put my homie powered module in the attic. When it's there, I want it to be monitored from my desktop pc, obviously. Updating firmware with OTA MQTT is perfectly fine and works OK. Homie is outputting a lot of usefull logs on the serial, but when it's up there, I will not have access to it anymore. If there a possibility to redirect logging to MQTT to have a full access to it, wherever the module is ? According to doc, I don't think this is not something that exists, or plan to exist today.

We could have a topic homie/deviceid/$log/active, when true it would log on serial + mqtt Then a second topic homie/deviceid/$log/console where we output each line one by one.

I'm not really sure if it is easily feasible, but I suppose it would not be that hard ? Are you interested in such a possibility ?

Thanks for your feedback.

euphi commented 6 years ago

FYI: I did some logging mechanism here https://github.com/euphi/HomieLoggerNode .

However, this does not log Homie internals (yet).

mosseb commented 6 years ago

I think this could be something relatively easy and usefull to add to Homie itself. Any plan for that @marvinroger, @timpur, @ThomDietrich ?

ThomDietrich commented 6 years ago

https://github.com/homieiot/convention/issues/77#issuecomment-385789150

Why do we need log topics? Why do we need them as fixed part of the convention? If correctly configured, your device offers the right set of nodes and properties to publish all relevant data that you'd otherwise dump to a log. A well implemented node doesn't need a log.

For debugging purposes a regular node/property can be used.

mosseb commented 6 years ago

I really don't agree that we "don't need log if a node is well implemented". By definition, we have bug in software. Logs are a good way to obtain info about what happens. If you say we don't need log over mqtt (which is the exclusive way of communicating with the device), then explain me why we need log when in serial :) This is non sense to me. I think discussion should not be whether we need log or not, but what is the better way to access those logs with MQTT, absolutely including homie internal logs. Nevertheless, thanks for pointing me to homieiot/convention#77 where I can see this is already in great debate. May I close this topic or is this still a pending subject for marvinroger/homie-esp8266 ? Thank you.

ThomDietrich commented 6 years ago

Providing an infrastructure for logs in the homie convention does not make sense, because it is supposed to support the communication of application specific information and commands and more importantly the means for auto-discovery of those by a controller.

That said, I agree that a way for debugging is useful during development and testing. As I said, you can simply define a node/property for the purpose and publish as much verbosity as you like there. I have a working project just like it: https://github.com/ThomDietrich/SenseoWifi/blob/master/src/SenseoWifi.cpp#L172

Yes, feel free to close this issue and join https://github.com/homieiot/convention/issues/77 instead 😉

mosseb commented 6 years ago

I don't quite understand why this is not related to homie convention. I don't feel like my custom logs are sufficient. I'd wish all homie logging are pushed to the same channel. I don't understand why one would not like to have mqtt disconnections, resets, wifi statistics.. as they are anyway produced to be put on the serial port. Concerning my custom logs, I agree about the kind of implementation you're proposing. Thank you.

ThomDietrich commented 6 years ago

Because the convention concerns itself with application oriented data and actions and the auto-discovery of these. 😃 It does not disallow or discourage the implementation of a debugging channel. It's simply out of the main scope. That said, now that you are also speaking about disconnects or wifi stats, please see https://github.com/homieiot/convention/issues/102 (and probably others. Join)

ThomDietrich commented 6 years ago

Addition: What I said regards the convention. I can't speak for the "homie-esp8266" framework. @timpur

mosseb commented 6 years ago

I would like to have @marvinroger opinion concerning homie-esp8266. Actually, it might be a little bit more difficult than just push a MQTT message as long as a serial message : if wifi or mqtt is down, how would you log it ? For it to work as expected, it has to memorize logs when mqtt is not reachable. Not sure this is actually relevant after all. I'm not MQTT specialist but what I understand is the messages are lost unless something else scrutates for it (not true only for the last one if retain flag is set).

marvinroger commented 6 years ago

@mosseb what you're asking is already doable thanks to events. You can then use, as said above, a logging node.

mosseb commented 6 years ago

OK so everything is here to do it, got it. Thanks for the advice and all comments of every people.

timpur commented 6 years ago

@mosseb , not sure if this interests you https://github.com/euphi/HomieLoggerNode

mosseb commented 6 years ago

Yes this is interesting. Concerning issues when MQTT or Wifi is erratic, I dont' think there is any intelligent thing to do at module side. We should log this by historizing the alive flag, in a home automation system software for example. This answers my question fully, thanks for sharing :)