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
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
Table of Contents
Theo Arends' Sonoff 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
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.
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".
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
is enabled in the firmware.
- In the main page, click on the button (left panel on the figure above).
- In the configuration page, click on the button (middle panel above).
- In the
Logging parameterspage (right panel) enter the IP address of the
syslog hostor its name if it can be resolved.
- Check that the Syslog port matches the port chosen in the
rsyslogconfiguration file. I did not change the default port which is 514.
- Enter the
syslogpriority level for messages. I suggest setting it to
1 Errorto avoid flooding the journal system with messages from the device.
- Finally don't forget to press on the button.
While setting the
Syslog level to
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 button. To test, just toggle the device
on and off. This can be done in the initial page, , 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:
If all is working go back to
Syslog level to
Do not forget to also click on the button.
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.
Naturally, I wanted to get the proper documentation for the daemon
installed on Raspbian Buster Lite. From the
syslog message sent by the service itself when it was restarted,
the software version is 8.1901.0 (released January 22, 2019) which is not too
far behind version 8.1908.0, the current stable version. I must admit that I
am somewhat perplexed by the following.
Version 8.24.0 of rsyslog was release about 2,5 years ago in January 2017.
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 Buster.
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,
/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 this year, 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.