stjohnjohnson / smartthings-mqtt-bridge

Bridge between SmartThings and MQTT
https://hub.docker.com/r/stjohnjohnson/smartthings-mqtt-bridge/
MIT License
363 stars 241 forks source link

Any way to produce less log? #126

Open tanus10 opened 6 years ago

tanus10 commented 6 years ago

Since these are, in many case, running on a SD card + Raspberry pi, once everything works, it is desirable to have less or even no log at all to preserve SD card life.

Is there any way or a future plan to reduce amount of log it produces?

stjohnjohnson commented 6 years ago

Hmm. Good question. It's all in winston. It should be possible to tweak that. I typically just have it all on logrotate.d. You could cheat and make the files a symlink to /dev/null.

stjohnjohnson commented 6 years ago

https://www.npmjs.com/package/winston#using-logging-levels would be how to set the log level per transport.

tanus10 commented 6 years ago

I was actually thinking about some configurable options in config.ylm, but I guess symlink would do the job.

stjohnjohnson commented 6 years ago

Oh yeah, totally. It's best done via a setting in the yml, but until I or someone gives a PR for it, you can cheat by symlinking :)

airdrummingfool commented 6 years ago

@tanus10 I'm looking into making a PR for this. Would the ability to set the log level for the file transport ( which writes events.log, access.log, and error.log) be enough? You could set it to error, which would prevent all of the normal log messages from being written to disk (errors would still get written, but that seems like a good thing to me).

nphil commented 5 years ago

@airdrummingfool any progress on this PR? My log files are getting pretty huge and the constant writing to disk is quite annoying and unnecessary.

airdrummingfool commented 5 years ago

@nphil thanks for the nudge... I'd completely forgotten about this. I managed to find the code I was working with in my git stash - I tested it and it seems to work, but take a look and let me know if this is useful. It's not necessarily PR quality yet but I've thrown it up anyways for discussion (see #173).