Tasmota, Theo Arends' replacement firmware for the Sonoff Basic and many other WiFi switches, logs error and information messages to the serial port and to the console on its web server by default. It can also log messages to a syslog compatible server where they will be stored and can then be reviewed. While this would be specially valuable with error messages, it is not the default behaviour. As will be shown, it is a simple matter to change the configuration in Tasmota.

The second part of logging messages from Tasmota or any other application is to have a reachable syslog server running. As my home automation server is a Raspberry Pi running Debian, it makes sense to use its default syslog daemon rsyslog.

Table of Contents

1. Enabling UDP in rsyslog
2. Enabling Error Logs in Tasmota
3. More About rsyslog

Enabling UDP in rsyslog

Theo Arends' Tasmota firmware uses the traditional User Datagram Protocol (UDP on port 514) when logging over the network. Accordingly, the rsyslog configuration file needs to be modified to enable reception of UDP messages. This is done by removing the comment symbol, #, in front of the UDP reception lines. I used the nano editor to change the file.

If the configuration file looks completely different then you may be using an older configuration file. The original version of this post, written in the days of Debian Jessie, may be helpful.

Then the daemon needs to be restarted so that the modified configuration file is used.

Just for the fun of it, I listed the last 10 entries in the daemon log file.

This confirms that the daemon was restarted and it should now receive UDP messages over the network. This is easily verified if logger is installed on a Linux machine on the local network.

List the content of the syslog log file to verify that the message was received by the Raspberry Pi.

It's even more fun if the --follow (or -f) command line option is specified.

In that case, tail does not exit and instead it displays new log messages as they come in. To close tail, use the CtrlC combination.

If Windows is being used, then the Adiscon logger could be used in a similar way. First the command prompt has to be invoked (cmd) in order to use the command line utility.

Note the different command line switches and that the zeronconf URL rapsberrypi.local could not be resolved in a vanilla install of Windows 10 running in an Oracle Virtual Box. Nevertheless, the test worked. There may be GUI applications that perform the same task in Windows, I have not had time nor the inclination to search beyond the first utility that I found. Besides, Adiscon has close ties to the rsyslog project (the majority shareholder and president of the company is Rainer Gerhards who is the creator of the software), so its utility could be considered "official".

Enabling Error Logs in Tasmota

The web interface of a device running Theo Arends' Tasmota replacement firmware can be used to enable logging of messages to syslog. As usual, the interface is reached with a web browser by entering the device IP address or its zeronconf URL <hostname>.local if mDNS is enabled in the firmware.

1. In the main page, click on the Configuration button (left panel on the figure above).
2. In the configuration page, click on the Configure Logging button (middle panel above).
3. In the Logging parameters page (right panel) enter the IP address of the syslog host or its name if it can be resolved.
4. Check that the Syslog port matches the port chosen in the rsyslog configuration file. I did not change the default port which is 514.
5. Enter the syslog priority level for messages. I suggest setting it to 1 Error to avoid flooding the journal system with messages from the device.
6. Finally don't forget to press on the Save button.

While setting the Syslog level to 1 Error makes sense, it would be difficult to test that everything is working, so temporarily set the level to 2 Info. Then click on the Save button. To test, just toggle the device on and off. This can be done in the initial page, Main menu, or by pressing the button on the device itself or by using the home automation software. To make sure it all works, look at the user log on the server.

The information should also appear in another log file: /var/log/syslog.

If all is working go back to Configure Logging and set the the Syslog level to 1 Error. Do not forget to also click on the Save button.

More About rsyslog

It was surprising how little information could be found about rsyslog on the the Raspberry Pi. It seemed that many chose to replace it with syslog-ng. Since this was my first foray into the world of syslog, I decided to get acquainted with the default daemon before replacing it. After all, the persons looking after Debian must have a good reason for their choice. You can read rsyslog author's own take on the subject posted in July 2007: [W]hy does the world need another syslogd? (aka rsyslog vs. syslog-ng).

The version of rsyslog installed in the latest (August 8, 2020) release of Raspberry Pi OS (32-bit) Lite is 8.1901.

This January 22, 2019 release of rsyslog is not the newest. Version v8.2010.0 was made available only five days ago. However 8.1901 is the most recent version in the Raspbian repository and it is sufficiently up to date.

Some were worried about memory usage in rsyslog. The project Wiki, which is no longer available, did say that the daemon is a multi-threaded application with each thread potentially taking up 8MB of memory for its stack. The huge limit on the per thread stack size remains in effect in the current version of rsyslog in Raspbian / Raspberry Pi OS.

I just ignored the problem over the last two and a half years, without negative consequences as far as I can tell. I tried following Jesse Johnson's instruction on limiting the thread stack size as described in his article entitled Reducing memory usage of rsyslog but failed. Apparently, the /etc/default/rsyslog file which exists is ignored by the systemd service manager. I think the proposed fix was for Linux systems using the init service manager.

In March of 2019, Reimer Prochnow, who is much more knowledgeable than myself, send an e-mail giving instruction on the correct way to set the stack limit. First, create a service override configuration file with the desired maximum stack size.

Then reload the service configuration files and restart the service.

Finally, check that the lower limit is enforced.

Success! Hopefully, setting a limit on the stack size will not be detrimental; time will tell.

In a recent post, Rainer Gerhards enjoins us to [a]void overly-large in memory queues. Unfortunately, this is over my head. As before I will just ignore this, hoping that the default settings work .

Some are uneasy about log files saved to SD cards because of the limited number of write cycles that can be performed on these memory devices. There seems to be a divergence of opinion between those that calculate the theoretical impact of all those additions to the logs, which is apparently negligible, and those that insist they have lost SD cards because of too many writes. Since the latter could very well be an example of a post hoc ergo propter hoc argument, I have decided to not worry about SD card wear. Besides, I am lazy and doing nothing suits me fine.