Just getting back to this again. @bakman2 this information has helped isolate the issue.
The problem stems from convention versus strict adherance to RF3164. This disparity is not uncommon, particularly for older RFCs. From section 4.1.3:
The MSG part will fill the remainder of the syslog packet [after the timestamp]. This will usually contain some additional information of the process that generated the message, and then the text of the message.
The MSG part has two fields known as the TAG field and the CONTENT field. The value in the TAG field will be the name of the program or process that generated the message. The CONTENT contains the details of the message.
Your syslog message above is missing the TAG field.
But its not a clear-cut case. Section 5.3 and 5.4 of the RFC expand on the TAG field further, with vague comments such as:
It has also been considered to be a good practice to include some information about the process on the device that generated the message - if that concept exists. This is usually the process name and process id (often known as the "pid") for robust operating systems. The process name is commonly displayed in the TAG field. Quite often, additional information is included at the beginning of the CONTENT field. The format of "TAG[pid]:" - without the quote marks - is common. The left square bracket is used to terminate the TAG field in this case and is then the first character in the CONTENT field. If the process id is immaterial, it may be left off.
From line 110, in the simple-syslog-server library used by this node, it assumes a tag field is provided and formatted according to the convention shown in the RFC.
@bakman2, just wondering how you generated the test syslog messages from your NAS? Did you craft them yourself, or did you simply click a button through the software to have it send one?
If the former, then you may be in luck in that your router does generate syslog messages conventionally.
If not, then the code for
node-red-contrib-syslog-input that parses the syslog messages will need to be rewritten to comply more strictly to the RFC. Unfortunately, I don't have the capacity to undertake that sort of work at this time, but I will gratefully accept Github PRs if someone is able to prepare one.