From the browser (Admin, Update)
The simplest way for routine updates: sign in as a superadmin, open Admin then
Update, choose the new beez-minibms.zip, and click Upload and check. The
platform verifies the package and shows its version against the running one. Click
Apply update and it does the rest by itself: it stops the services, replaces the code
(your data, tenants and settings are untouched), and restarts. The page reconnects and
reloads when the new version is live. If anything stalls, the full trace is in
update-debug.log in the install folder, and the manual updater below always
works as a fallback.
How it works: applying launches the same update.ps1 used by
the manual updater, run unattended through a one-shot Windows scheduled task (as SYSTEM),
so it has the rights to restart the services without a prompt and keeps running while the
server itself is stopped and restarted. Service-mode installs are the intended target.
The one action (manual)
Download the new beez-minibms.zip (leaving it in Downloads is fine),
double click update.bat in the installation folder, approve the one UAC
prompt, confirm the package it found, press Enter. Everything else is automatic, and
your data survives by construction.
The updater itself is update.ps1, a PowerShell program;
update.bat is only its launcher. It looks for the package in this order:
a path passed as the first argument, then beez-minibms.zip in the
installation folder, then the newest beez*minibms*.zip in the
installation folder and in your Downloads. The tolerant pattern is deliberate
(2026.08.8-32): browsers rename a second download to
beez-minibms (1).zip and some transfer pipelines strip punctuation
entirely, producing beezminibms.zip, and a package that arrived
under such a name used to be invisible to the updater. The filename never
decides what the package is; the content check (the wrapped
beez-minibms folder with app\main.py and
VERSION.txt) remains the gate, and the updater shows what it
picked and waits for your confirmation before touching anything.
Right clicking update.ps1 and choosing "Run with PowerShell" works too.
Getting the new updater into an old installation
Updater fixes travel inside the package, so an installation whose own updater is
broken can never heal itself by running it. The way out takes one minute: download
update.ps1 and update.bat as standalone files, place them in
the installation folder replacing the old ones, then run update.bat
normally. From that point every run leaves a full trace in
update-debug.log and the window always waits for Enter before closing,
even when something fails.
What it does, step by step
| Step | Action |
|---|---|
| Elevation | Requests administrator rights once. Needed to see and stop background (session 0) instances and services; without it Windows hides their paths. |
| 1. Stop processes | Finds every process whose executable path or command line references beez-minibms (the server, its BACnet bridge children, stray instances from old folders) and stops them, listing each PID. |
| 2. Stop services | Finds Windows services whose binary path references
beez-minibms (beez-minibms, beez-mqtt), remembers them, and
stops them. |
| Safety gate | If port 8000 is still held now, the occupant is not the miniBMS: the updater shows the process and its path and aborts before changing any file. It never stops foreign software. Scheduled tasks referencing beez-minibms are reported with the command to review them, never modified. |
| 3. Unpack and verify | Extracts the zip to a staging folder and checks it is a genuine beez-minibms package. |
| 4. Replace code | Mirrors the code directories and root scripts
(.bat, .py, .txt, .md) onto the
installation. data\, tenants\ and config.json
are never touched. |
| 5. Dependencies and broker | Updates Python packages in the venv and starts the Mosquitto service if it is installed but stopped. |
| 6. Restart | The platform comes back the way it was running: stopped
services are started again; if there were none, a console window opens with
run.bat. Schema migrations run automatically on this first start. |
Finish with one hard reload in the browser (Ctrl+F5) so the new interface loads.
Knowing it worked
Four independent confirmations, use any one. The updater's administrator window ends
with an unmistakable UPDATE SUCCESSFUL: old to new banner (the first,
non-administrator window only hands over and closes by design). Every run appends a line
to update.log in the installation folder: timestamp, versions, package.
The web console header shows the installed version at all times, and
/api/version returns it for scripts. And if an update fails, nothing
breaks: the platform keeps running the previous code and you rerun
update.bat after fixing the printed cause.
Troubleshooting
The updater window closed and you saw nothing
With the PowerShell updater this cannot happen anymore: the final "Press Enter to
close this window" runs in a finally block, which executes even when the script fails,
so the window always waits. If you are seeing a vanishing window you are still on the
old batch updater; follow "Getting the new updater into an old installation" above.
Every run writes a full trace to update-debug.log next to the script
(both windows, every step, every robocopy and pip output, every abort reason); open it
and the last lines say exactly how far the run got. The one-line outcome stays in
update.log.
Port 8000 is held by another application
The updater already stopped everything miniBMS related, so the shown process is something else. Close it (the path printed tells you what it is) and run the update again. Nothing was changed.
WinError 10048 when starting manually
Two instances are fighting for the port, typically a console start while the
beez-minibms service is running. run.bat shows the occupant
and offers to stop it; a service instance needs an administrator terminal
(taskkill /PID <pid> /T /F) or simply update.bat. Decide
on one run mode per the overview.
Copy failed for a directory
A file is locked, usually an editor or a process that survived. Close it and rerun; aborted updates leave the installation working.
VPN interface bounced, or "Proxy error" in the console
The BACnet bridges bind the VPN interface's IP, so a VPN restart takes them down
while the platform itself (localhost and 0.0.0.0) keeps running. Restore the VPN
adapter first (check ipconfig), then restart the affected bridges in the
Admin tab; if the VPN handed out a new IP, update the bridge's local IP in the bridges
card before restarting. A message mentioning "Proxy error" or "did not come from the
miniBMS" means your browser's path to the server is broken, not the platform: open the
console on the server itself (http://localhost:8000) until the VPN route is back. A
bridge that refuses to restart may have a wedged child holding its UDP port:
netstat -ano | findstr :47809, then
taskkill /PID <pid> /T /F, then restart it.
Dependency installation failed
A proxy or VPN blocking pypi.org is the usual cause. Fix connectivity and rerun
update.bat, or run.bat which retries the install when the venv
is incomplete.
Manual fallback
Stop the platform, extract the zip over the installation folder (data, tenants and config.json are not in the zip, so they survive a merge), start again. The updater exists so you never have to remember that; prefer it.