There certainly are risks when you are writing files, but I don't see making a general rule of this. In the case of the flogger node, the issue starts with the use of msg.filename, which is shared with the core file nodes and perhaps others. As suggested above, the risk of error could be reduced by instead using msg.logfile (or better yet, msg.flogger.logfile) for this property. Also, the node configuration allows the user to define a Log Dir , which can help isolate any damage to that directory. I have used a strategy for overriding defaults that greatly reduces the chance of errors. I name properties that can be overridden as msg.nodename.property, so that for flogger the overrides object might be
msg.flogger = {
logfile: "mylog.log",
loglevel: "INFO"
};
The chance of a message accidentally carrying something like this into a flogger node is very small, but the node could still have defaults configured to deal with the case where the message doesn't provide valid parameters.
All perfectly good workarounds. As is the suggestion to use a typedinput which I would argue is slightly more user friendly? (Certainly reduces the need to add change nodes before nodes & therefore simplifies things to some degree)
As @dceejay and I started originally, it is ultimately the DEVs choice...
...we just provide the information, make our requests and hope we provide a good argument with reasoned advice. 
Anyhow, I don't think anyone disagrees that in its prior form (msg.filename overriding the explicit form property) was not the best idea for a couple of reasons.
Btw, that is something I'm going to bear in mind for future. Good Nugget of info.
1 Like
Thank you for the input - it almost got heated a little bit 
Here are my decisions:
- I made the status text date on the node consistent with the local/UTC setting on the node (drmibell)
- I added a Z designator to the UTC logtime because it makes good sense to know what for the ones reading an unknown logfile (drmibell)
- Changed back to original behaveour of allowing overriding the filename. To avoid name collisions like Steve talked about, I decided that from now on it should be overridden with msg.logfile. The risk of a name collision with this name is very small. I like drmibell's nested object solution, but I think it's a little too much for the average Joe - my feeling is that it overcomplicates the usage just to protect from extremely rare edge cases.
I know this goes a little against normal node behavior, but I really feel that it makes sense in this case. It also makes it consistent with the error-level override functionality which I like (drmibell). I feel it's OK because it is well documented in the info section of the node.
Like dceejay says: At the end of the day it is up the author... 
Version 1.1.7 has been committed.
5 Likes
I have just added log rotation to flogger. Now you can specify how big your logfiles can get before they get rotated. Old logfiles can be gzip compressed if you wish.
I also did a lot of refactoring of the code, but that shouldn't affect the functionality. It was getting a little to big and bulky to easily read.
Version 1.2.1 is now committed
3 Likes
Flogger is close to my idea of a perfect logger. Thanks for the contribution!
The only thing I'm wishing it had that I haven't found yet is millisecond granularity.
But how am I to shut the log off??? Short of deleting the node I couldn't get it to stop logging. I thought for sure unwiring it's input would do it but no.
1 Like
If you don't send a msg, it shouldn't log anything. Are you certain you deployed changes? Are there other flogger instances still operating?
Try searching for flogger in node red (CTRL+f) see if there is more than one
Yes. I'll do it again just to be sure. Hang on...
Something strange is going on. I had it hooked up to a MQTT "read all" node which I'm also testing and the 2nd time I had trouble getting it to start logging. So I restarted NR and still iffy. I copied the flogger node to a live flow and it works as expected, both starting and stopping by disconnecting it's input wires (and Deploy of course).
So I'll retract my original comments... except
Sorry to bother you.
When i use moustache Response payload {{payload}} i get in file [moustache] Response payload [object Object]. What is correct way to render object?
Thanks
Awesome node. Much much appreciated!
I know its been sometime . Have been using flogger node for a while. Excellent node.
Is it possible to add following 2 functionalities to the node .
- If msg.LOG_LEVEL is set - then print only those messages which are node.LOG_LEVEL = msg.LOG_LEVEL - aim being we can go for run time decision how much to print in log. Only for trouble shooting i may need huge logs.
- Can the name of the node printing the message be printed as part of the log message . This will make it very easy to trace each line to the node which printed the message.
I can do both changes and share the JS. Unfortunately I do not know how to create a node.
If I understand what you're looking for, just copy the existing code and modify it if you just want it for your own purposes. I've done the same with the Gate node because I wanted it to have both open and closed outputs.
If you want to contribute back to the community you can either make a Pull Request in Github or change the name (Flogger2?) and publish it as a new node.
We would always recommend trying to contribute back to the existing node rather than fork and publish a clone.
@SandeepA As this particular node isn't one the core project maintains, you may want to raise an issue in its GitHub repository for its author to see.
1 Like
Thanks Nick. Will do. Will raise it to the author.
