PyScada: a Django-based SCADA server with an HTML5 front end

A SCADA server that is a Django application

PyScada is described in the README as an open source SCADA system with an HTML5 HMI, built using the Django framework, and the project description calls it a Python and Django based Open Source SCADA System. The Django framing is the first thing to understand, because it explains both the shape of the codebase and the shape of the deployment. There is no separate control runtime to install and no Windows service to register. The server is a web application, the HMI is a web page, and the data model is an application database with the process values in it. The README claims very low hardware requirements for the server, which is a reasonable consequence of that design for a small installation. The homepage is pyscada.rtfd.io, the source repository is separate from the documentation, and the licence is the GNU Affero General Public License v3, which is the copyleft variant and matters if you plan to modify and serve it over a network.

The core and HMI layer, and the plugins that hang off it

The dependency list in the README names the base layer explicitly as core and HMI, with python>=3.8, django==4.2, numpy>=1.6.0, pillow and python-daemon. The project structure image in the repository shows how the pieces relate. The protocol and device support is not in the core at all. Each protocol lives in its own repository: Modbus with pyModbus covering TCP/IP, RTU, ASCII and Binary, Phant, VISA with pyVISA, 1-Wire, BACnet/IP with BACpypes and BAC0, MeterBus with pyMeterBus, SMBus with smbus2, GPIO with RPi.GPIO for the Raspberry Pi, SystemStat, OPC-UA with opcua-asyncio, SML with pySML, file read/write, Serial, and WebService. Alongside those sit a generic dummy device, the PT104 temperature data logger device, a Scripting plugin, and an EMS system tool for event management, data export and mail notification. The consequence for a user is that installing PyScada gives you the framework, and every protocol you actually use is a second install.

What the README says works, and how narrowly

The README has a section titled What is Working, and its entries are more informative than a feature list because each one carries a qualifier. Modbus TCP/RTU/BIN is listed plainly. Visa is qualified as working at least for the devices in the visa/devices folder. Systemstat and scripting are listed without qualification, and OneWire is qualified to only DS18B20. Phant and event are marked as having no known issues, and smbus is qualified the same way as VISA, at least for the devices in the smbus/devices folder. GPIO is qualified as at least for the Raspberry Pi. Webservice is noted as json and xml parsing, export and hmi are marked as having no known issues. Read those qualifiers as the project's own definition of the supported set, and note the pattern: the qualification is always a folder of specific device configurations, not a protocol as such. A protocol being listed does not mean your model of instrument is in the list.

The missing list is the most useful part of the README

There is a matching section titled What is not Working/Missing, and it names four things. Documentation is the first. SysV init daemon handling is the second, which is a concrete operational detail on older Linux distributions. BACnet is the third, with the reason given as due to the lack of hardware to test. OPC-UA and MeterBus are the fourth and fifth, both with need more tests as the reason. The protocol list in the feature section marks BACnet and MeterBus as in development as well, so the two statements agree. This is unusual candour for a project README, and it is the section to read first. A SCADA system that quietly claims support for a building protocol and fails to poll a device is a bad outcome, and here at least the boundary is written down. The missing documentation entry also tells you that the detailed installation instructions live on the Read the Docs site rather than in the repository, which is where you should go before planning a deployment.

Two install paths in the repository, and the packaging metadata

The README itself says detailed installation instructions can be found at pyscada.rtfd.io and does not give a command, so there is nothing to copy here. What the repository does contain is a set of install scripts at the top level, install.sh, install_docker.sh and install_venv.sh, along with a docker/ directory, so the shape of the deployment is a Python virtual environment or a container, and the scripts are the entry points for each. The packaging metadata gives the current version of the dependency stack, and it is newer than the README's dependency list, which still says django==4.2 while the project metadata asks for django>=5.2,<5.3 and requires-python >= 3.10 rather than 3.8. The rest of the runtime dependencies are h5py for the HDF5-based storage, pillow, python-daemon for process supervision, pytz, python-dateutil, asgiref, monthdelta, six, concurrent-log-handler with a comment noting rotating logs for multiprocess, and scipy. The comment in that list is a small but telling detail, since a multiprocess deployment with rotating logs is a specific operational requirement rather than a default.

The HMI is a web page, which cuts both ways

The HTML5 HMI is the reason to pick this project and the reason to be careful with it. On the good side, a browser-based HMI means no separate runtime client to install on a panel PC, a display you can reach over HTTP, and a front end that the repository classifies under JavaScript as a primary language, with an eslint.config.mjs at the top level and a black and isort configuration in the project metadata, where isort is set to the black profile with pyscada as the known first party package. On the other side, an HMI served over HTTP is a control interface reachable from a browser, and a SCADA system by definition has the authority to move actuators. The README does not document the authentication model, the authorisation scheme or the deployment hardening for the HMI, and the missing-documentation entry covers that silence. The System tools component with the EMS plugin for event management, data export and mail notification suggests the operational side is taken seriously, but the security posture has to be established by the installer.

Where a general SCADA package is the wrong answer

Three cases point elsewhere. The first is a site with BACnet or MeterBus equipment, since the README marks BACnet as untested for lack of hardware and MeterBus as needing more tests, and the feature list marks both in development. No amount of configuration gets you a working integration there. The second is a site that needs a proven human machine interface and a support contract, because an open source project with a beta development status and a documentation entry in the not-working list is a different proposition from a commercial SCADA vendor who will answer the phone when a pump stops at 3am. The third is a team that wants a server with a documented security model out of the box.

The alternative worth weighing is a commercial SCADA platform with a vendor-supported driver library, and the difference in approach is where the money goes. PyScada gives you a Django web application, a plugin ecosystem you assemble yourself, and hardware requirements the README describes as very low, in exchange for owning the process supervision, the plugin versions and the HMI security. A commercial platform gives you a driver catalogue and a support contract, in exchange for a licence and a much larger hardware and database footprint. The judgement depends on how many devices you have and how much of your time is worth spending on a device configuration file.

Editorial conclusion

PyScada fits a lab, a building or a small plant where the hardware is Modbus, VISA or 1-Wire, the operator wants a browser-based HMI, and the team is willing to assemble the system from separate plugin repositories and run the process supervision themselves. It does not fit a site with BACnet or MeterBus equipment, since the README marks both as in development and BACnet untested for lack of hardware, and it does not fit a team that needs vendor support. Before you commit, read the What is not Working list in the README rather than the feature list, and check whether your specific device has a configuration under the matching plugin's devices folder, because the working notes qualify most protocols with exactly that caveat.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. pyscada/PyScada on GitHub
4. README
5. Releases