Below is a fading blink program I created for a Wemos Lolin32 Lite clone but it may be modified for other ESP32 boards by changing the LED_PIN value.

The CYCLE_TIME value sets the duration of a complete fade cycle in seconds.

The STEPS_PER_CYCLE value is set at a multiple of 50 to prevent beating with UK mains lighting. If your locality uses 60Hz mains frequency you might wish to make this a multiple of 60 (perhaps 480).

The cos function was chosen because the Wemos Lolin32 Lite has active-low LED drive. For boards with active-high LED drive an inverted cos function could be used instead.

import machine, math, time

LED_PIN = 22
CYCLE_TIME = 4

STEPS_PER_CYCLE = 400
STEPS_INTERVAL = CYCLE_TIME / STEPS_PER_CYCLE

pwm_led = machine.PWM(machine.Pin(LED_PIN), int(1 / STEPS_INTERVAL))

def set_fade(step):
    pwm_led.duty(int(511.5 * math.cos(2 * math.pi * step / STEPS_PER_CYCLE) + 512))
    time.sleep(STEPS_INTERVAL)

while True:
    for i in range(STEPS_PER_CYCLE):
        set_fade(i)

UPDATE: Remove the named parameter from PWM function call for newer versions of MicroPython.

In this post we will install Thonny for MicroPython development with ESP32 devices on an Ubuntu-derived distribution.

Step 1: Required repository packages

A number of python3-related packages are required to be installed from the Linux Mint repositories. This can be done as follows:

sudo apt install python3-dev python3-tk python3-venv

Step 2: Create virtual environment

python3 -m venv thonny
cd thonny
source bin/activate

Step 3: Populate the virtual environment

python -m pip install -U wheel setuptools pip
python -m pip install -U Cython esptool thonny
deactivate

NOTE: The installs must be split as shown to prevent ordering changes breaking things.

Running Thonny from the virtual environment

cd
python3 -m venv thonny
source thonny/bin/activate
thonny
deactivate

Thonny's configuration is located in ~/thonny/.thonny where configuration.ini may be found for changing advanced settings.

My OpenDMARC package recently broke following an update. Investigating what had happened, it appears that version 1.4.0 has introduced a new feature i.e. support for ARC.

This has required a few changes both in packaging and runtime environment. I am using archlinuxARM and their packaging of OpenDMARC is taken directly from upstream Archlinux. Unfortunately, the packagers missed the requirement that OpenDMARC-1.4.0 needs perl-json.

The added support for ARC also requires additions to the Report Database schema in the form of some new tables and extra fields on existing ones. The History file format has also changed and requires some manual intervention.

In summary, after an update of OpenDMARC to 1.4.0 you need to do the following:

• For Archlinux package opendmarc-1.4.0-1, also install perl-json
• Update your Report Database with e.g. schema.mysql (recreating the database is the easiest method)
• Truncate your existing history file before the next scheduled report import time

I have raised a bug report against Archlinux for opendmarc-1.4.0-1 missing the perl-json dependency so later versions of this package should fix this.

No, I'm not talking about a new human member of the family. Today marks the first week of life for our ARM-based Home Server and, so far, things are going very well. What's been achieved during this short period?

The Postfix and Dovecot mailserver has been verified as working. OpenDKIM and OpenDMARC checks and report generation are working fine. ClamAV has been scanning incoming and outgoing email and caught a few incoming virus-infected ones. Needless to say, SMTP and IMAP services are both experiencing brute-force password cracking attacks at moderate levels.

Lighttpd has been provisioned with Let's Encrypt certificates for the small number of virtual-hosted domains it serves. HTTP to HTTPS request promotion has been implemented and this blog is being served on the primary domain. Certificate updates are handled by acme.sh and its deployment mechanism distributes them to the containers providing the hosted services.

Prosody is serving, at the moment, one multi-user chatroom (MUC) with less than a dozen participants. The configuration has been updated to add server-to-server two-way communication over a single connection (mod_bidi) and stream management (mod_smacks) for message retrieval following a disconnect and subsequent reconnect from either a client or server connection. Audio and video calling hasn't yet been tested but should be functional.

General infrastructure management is operating well with DHCP, DNS, NTP, firewall and routing functions operating correctly. Memory usage is good with 600MB-800MB of the 2GB RAM being available as spare under normal operating conditions. Networking performance is good, achieving a 160Mbps download speed with 5G WiFi for our 200Mbps cable Internet connection.

When learning a programming language a Hello World! program is obligatory. I figured the same is warranted for a new server blog!