TasmoAdmin: a web control panel for Tasmota flashed devices

One panel for the devices that Tasmota put on your network

TasmoAdmin is an administrative platform for devices flashed with Tasmota, the open source firmware for ESP8266 and ESP32 based switches, plugs and sensors. The project was previously called SonWEB, and the older name still appears in the package layout.

The problem it addresses is that Tasmota devices expose an HTTP API per device, with a handful of endpoints each, and a house full of them has no single place to look. TasmoAdmin keeps an inventory of devices and gives you a web UI over the lot.

The feature list is practical rather than aspirational. There is login protection, a multi update process where you select devices to update and an automatic mode that downloads the latest firmware bin from the Tasmota OTA site, device information and sensor data display, configuration of devices from the web UI, and batch actions on the device list for sending commands, creating backups, restarting devices and deleting them. Startpage visibility controls let you hide selected devices from the startpage without removing them from the inventory.

Two details deserve attention. Device passwords are encrypted at rest, which is unusual for a hobbyist tool, and the multi update process is the feature that turns a collection of switches into something you can maintain.

The interface is a responsive Bootstrap 5 interface with SCSS based assets and minified builds. The primary language is PHP and the badge asks for PHP 8.2 or newer, with the project licensed under GPL-3.0.

Docker is the route the readme recommends

TasmoAdmin can run standalone, as a container, or as a Home Assistant addon, and the readme is direct about the preference: the Docker path is the recommended way to get up and running. Images are published on GitHub packages.

The image is a Linux Alpine based image with Nginx and PHP 8.5 installed, and it supports amd64 for things like Synology DSM, arm for a Raspberry Pi 3 and arm64 for a Pine64. Setup instructions live in a separate wiki guide, which is worth knowing because the readme points at the wiki rather than repeating the steps.

The compose file in the repository shows how the pieces are wired for a local run.

services:
  web:
    build:
      context: .
      dockerfile: .docker/Dockerfile.alpine-tmpl
    ports:
      - "8000:80"
    environment:
      - TASMO_DATADIR=/data/tasmoadmin/
      - TASMO_DEBUG=1
    volumes:
      - ./tasmoadmin:/var/www/tasmoadmin
      - ./.storage:/data/tasmoadmin
      - web_tmp:/var/www/tasmoadmin/tmp

That is the whole deployment surface. Note the two volumes: the application tree is mounted for development, and the data directory is mounted separately so the device inventory survives a rebuild. The temporary directory gets its own named volume so sessions and cache files do not leak into the data directory.

The other supported platforms are Apache2 and Nginx for a plain web server install, the Home Assistant addon, an unRaid plugin, and IOCage on FreeBSD, each contributed by a named maintainer. For anyone who wants the panel embedded in an existing dashboard rather than on its own domain, the Home Assistant addon is the shortest path.

Environment variables decide where the data lives

Seven environment variables cover the configuration that would otherwise require editing files. `TASMO_DATADIR` is the data directory and needs a trailing slash, defaulting to `./tasmoadmin/data/`. `TASMO_TMPDIR` is the directory for sessions and temporary cache files, also with a trailing slash, defaulting to `./tasmoadmin/tmp/`. `TASMO_BASEURL` customises the base URL for the application, which matters when the panel sits under a sub path rather than at the root of a domain.

`TASMO_DEBUG` set to `true` displays PHP errors and is disabled by default. `NO_AUTH` set to `true` bypasses the built-in login when authentication is handled externally, which is the setting to use behind an authenticating proxy rather than exposing the panel on a network with no login in front of it.

Two of them are about security and deserve careful reading. `TASMO_DEVICE_PASSWORD_KEY` is a base64 encoded 32 byte secret used for device password encryption at rest, and `TASMO_ALLOW_CROSS_SITE_IFRAME` set to `true` allows the panel to be embedded in another HTTPS site such as Home Assistant or Organizr, while HTTP requests stay restricted.

One inconsistency to note. The badge in the readme advertises PHP 8.2 or newer, while the Docker image description says Nginx and PHP 8.5 are installed. Both statements can be true at once, but if you run the panel on your own web server, 8.2 is the version the badge asks for.

Only the password column is encrypted, and the key rules are strict

The device password handling is the most precisely specified part of the documentation. TasmoAdmin encrypts only the `password` column in `devices.csv`. Usernames, column order and in memory `Device` objects remain unchanged, which is a deliberate scoping decision: the change is narrow enough to reason about.

The key is resolved in a fixed order. If `_DATADIR_/.device-password.key` exists, that file is used. Otherwise, if `TASMO_DEVICE_PASSWORD_KEY` is set, that value is used. Otherwise TasmoAdmin lazily generates a 32 byte key, persists it to `.device-password.key` and uses it. If both sources exist, they must match exactly, or TasmoAdmin fails closed.

That last rule is the one to internalise. It means an operator cannot quietly rotate one key while the other stays stale, because the application refuses to start rather than silently decrypting with the wrong key or losing the passwords.

On disk, an encrypted password cell is stored as `enc:v1:<base64(iv||tag||ciphertext)>`, a versioned prefix followed by the initialisation vector, the authentication tag and the ciphertext. On the first read after an upgrade, legacy plaintext cells are migrated in place to the encrypted format, so an existing `devices.csv` is upgraded automatically without operator action.

One destructive path exists. Running `clean=devices` removes both `devices.csv` and `.device-password.key` for file backed installs, which deletes the inventory and the key together. There is no separate backup step described for that command.

CSRF, cookies and iframes come with a verification checklist

Session handling is documented at the level of individual request attributes. Authenticated state changes require a POST request carrying the session CSRF token. The session cookie uses `SameSite=Lax` by default, so an iframe deployment keeps working when the parent page and TasmoAdmin are on the same site.

Embedding in another HTTPS site, such as Home Assistant or Organizr, requires `TASMO_ALLOW_CROSS_SITE_IFRAME=true`. That setting switches to `SameSite=None; Secure`, but only for HTTPS requests, since HTTP stays at `SameSite=Lax`. The readme also notes that browsers which block third party cookies may still require a user exception, which is a browser policy rather than something the application can fix.

The readme ends that section with a deployment check, and it is the most unusual instruction in the documentation: verify an authenticated device command and the self update form in both day and night mode, then confirm that a cross-site POST and a legacy state-changing GET URL leave the installation unchanged.

That is a concrete acceptance test for the security model rather than a reassurance, and it is worth running before you point the panel at a real fleet. The self update feature is disabled for Docker installs, so in a container deployment the update path is the image, not the panel.

Autoscan finds devices two ways, network range and MQTT broker

The discovery story is what makes TasmoAdmin more than a static list, and it covers two mechanisms.

Classic autoscan scans a network range for Tasmota devices. The second route goes through an MQTT broker. The broker connection is configured in `Settings -> MQTT discovery`, and the MQTT tab in autoscan lets you subscribe to one or more discovery topics such as `tele/+/LWT`, match existing devices by MQTT topic and refresh their status, and add newly discovered devices from broker responses.

The topic matching is the part that needs thought. You can store a device specific MQTT topic in the device edit form, and the readme recommends it because it makes matching more reliable in installations with custom topic layouts. In other words, the broker scan works out of the box for standard topic layouts and needs per-device help when your MQTT setup is not standard.

The rest of the interface handles the daily work. There is night mode with `Enable`, `Disable` and `Auto` settings, optional touch friendly toggle confirmations with a global default in settings and a per-device override, support for multiple sensors, and batch actions from the list view for sending commands, creating backups, restarting devices and deleting them.

The self update function for TasmoAdmin itself exists for web server installs and is switched off for Docker installs, where the update path is pulling a new image.

Where TasmoAdmin is the wrong tool

The scope boundary is firmware. TasmoAdmin administers devices flashed with Tasmota. If your home contains devices that talk to a vendor cloud, or run a different firmware entirely, there is nothing here for them, and you would be running two administration systems instead of one.

The second limitation is the release line. The published releases are all v5.1.0 beta builds, with v5.1.0-beta.1 dated 2026-06-12, beta.2 on 2026-06-22 and beta.3 on 2026-08-26. The last push to the default branch was on 2026-10-12, so work continues between releases, but the newest artefact is a beta. For a tool that sends firmware to devices and stores your credentials, a beta tag is a reasonable thing to weigh.

The third is the destructive surface. The multi update process can push new firmware to selected devices, an automatic mode pulls the latest bin from the Tasmota OTA site, and `clean=devices` deletes the inventory file along with the encryption key. Backups exist as a device list batch action, but the readme does not describe an automated backup schedule or a documented restore procedure for a wiped data directory, so a file level backup of `TASMO_DATADIR` is the safety net.

The fourth is documentation depth. The readme's development section is cut off mid sentence, and the setup instructions live in a wiki and in the Home Assistant addon repository rather than in the repository itself. Upgrading has its own `UPGRADE.md` file and a `CHANGELOG.md` at the root, which is where you should look before moving between versions.

Editorial conclusion

TasmoAdmin suits a home lab that already runs Tasmota on ESP8266 or ESP32 devices and wants one place to configure them, update firmware and keep credentials encrypted at rest, and it is the wrong tool for a fleet that mixes vendor apps or non Tasmota firmware. Before adopting it, decide whether the container image or the Home Assistant addon suits your setup, confirm that `TASMO_DEVICE_PASSWORD_KEY` and the `.device-password.key` file do not disagree, since TasmoAdmin fails closed when both exist and differ, and read UPGRADE.md and CHANGELOG.md before the first upgrade given that the published releases are all v5.1.0 beta builds.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. TasmoAdmin/TasmoAdmin on GitHub