v2.9 β no more freezes, and a single generation 2 file for both variants
The most common reason a Pylon-Monitor became unreachable until it was unplugged and plugged back in is fixed.
- The device now recovers on its own from a stuck web server. A single slow or interrupted connection to the dashboard could previously hang it indefinitely; it now notices within about two minutes and restarts itself — no more power-cycling it by hand.
- One generation 2 file now covers both hardware variants. The with-screen and without-screen (Lite) versions used to need two different downloads; the device now detects which one it is at boot, so a single generation 2 file works for both.
- Fixed a rare bug that could reopen the WiFi setup screen on its own, mistaking two settings-triggered restarts in quick succession for a double press of the reset button.
- New troubleshooting option if your screen stays blank white after an update: Settings → Screen Display now lets you try alternate panel variants without opening the case.
- Pushover push alerts are no longer offered on generation 1 hardware. The secure connection they need takes more memory than this board reliably has free, so they rarely worked there. The charge/temperature threshold fields stay on both generations: they still colour the on-screen gauge and feed the JSON API.
If your device is on v2.8, please update as soon as you can — it has the freeze issue above, and is no longer offered for download below. See the full changelog.
How to update
Update in 4 steps
- Download the latest
.binbelow (registered owners only β see next section). - On Windows: right-click the downloaded
.bin, choose Properties, and if you see a Security line saying the file came from another computer, tick Unblock and click OK. Windows marks downloaded files and the upload fails silently otherwise. - Open your Pylon-Monitor dashboard β Update firmware.
- Choose the file and click Install firmware.
- The device reboots into the new version in under 30 seconds — WiFi, MQTT, hostname and login settings are all preserved.
To keep the .bin from circulating outside the people who actually bought the device, the last step of every download asks for the email address you used at checkout. If it matches an order, the file starts immediately. If it doesn't, we queue a manual review β you'll have the file within 24 hours.
Releases
-
Pylon-Monitor v2.9 LatestFixes the most common cause of a Pylon-Monitor becoming unreachable: a single slow or interrupted connection to the dashboard could hang the on-device web server indefinitely, requiring a power cycle to recover. The device now notices and restarts itself within about two minutes. Also fixes a rare bug where two settings-triggered restarts in quick succession (for example changing the screen panel type twice) could be mistaken for a double press of the reset button and reopen the WiFi setup screen. The generation 2 firmware is now a single file for both the with-screen and without-screen (Lite) hardware — the device detects which one it is at boot instead of you having to pick. New: if your screen stays blank white after updating, Settings → Screen Display lets you try alternate panel variants without opening the case. Generation 1 hardware no longer offers Pushover push alerts — the secure connection they need takes more memory than this board reliably has free, so it rarely worked there; the charge/temperature threshold fields remain and still drive the on-screen gauge colour and the JSON API. The device also now checks the address embedded in an uploaded file before writing anything, so installing the wrong generation’s .bin by mistake is refused outright instead of risking a device that no longer boots. Two files, one per hardware generation β they are not interchangeable. Not sure which one you have? Take generation 1: it is what every unit shipped before 5 September 2026 uses. Units ordered from 5 September 2026 are generation 2. If you pick the wrong one, nothing breaks: the device checks the file before writing anything, tells you it is not for this board, and keeps running the version it already has. From v2.8 onwards your device also shows its generation on its own Update firmware page. Already got it running? Open
http://pylon-monitor.local/api.jsonin a browser (or your device's own address) β the"hw"field says it directly, for example"hw":"gen2". -
Pylon-Monitor v2.8 Superseded β no longer distributedNo longer offered for download. v2.8 has a reliability issue where a single slow or interrupted connection to the dashboard could hang the device indefinitely, requiring a power cycle to recover — fixed in v2.9 above, which keeps everything v2.8 added (high-voltage Pylontech pack support, hardware generation shown in the JSON). If your device is still on v2.8, please update to v2.9.
-
Pylon-Monitor v2.7Fixes the public JSON URL, which was broken on every pack with more than one battery: the document was assembled in memory with a fixed allowance of 260 bytes per battery while one really takes 363, so the end was silently cut off and the server refused it. It is now written straight into the connection in 1 KB pieces, so memory use no longer depends on pack size. Nothing is published before your batteries have been read, so the public address can no longer stay stuck on an empty snapshot. Home Assistant: each battery now publishes its model, BMS version and serial number as attributes of its own sensors. And saving any setting no longer disconnects MQTT — the connection is only remade when the MQTT settings themselves change. Superseded by v2.8.
-
Pylon-Monitor v2.6Everything v2.5 brought, plus what checking v2.5 on real hardware turned up. Your MQTT settings now take effect immediately instead of waiting for a restart you were never told to perform. Pushover alerts can no longer restart the device — the memory check now runs before the secure connection is created rather than after, which is what made v2.5’s guard powerless; if memory is short the alert is skipped and says why, instead of telling you to check keys that were fine. A drop in the number of batteries now needs two readings giving the same figure. Battery polling is adjustable from 5 to 300 seconds, as an owner had asked. And the event log now reports the memory that was really free before a restart, instead of a constant figure measured after it. Superseded by v2.7.
-
Pylon-Monitor v2.5Merged the two board firmwares into a single source, and verified the WiFi password before saving it. Also fixed, from four owners’ reports: the per-battery Home Assistant sensors, the charge-cycle count jumping after start-up, a pack briefly reporting fewer batteries than it has, and a dashboard that faded out silently when it lost contact. Superseded by v2.6, which corrects two v2.5 fixes that did not actually take effect.
-
Pylon-Monitor v2.4Reliability release for installations with several batteries. Devices with roughly four batteries or more could restart endlessly: memory use grew with the number of batteries until it ran out. Fixed, and memory use no longer depends on pack size. Also fixed: voltage and charge level were wrong on large packs (a single incompletely-read battery dragged the average down — 45.50 V shown on a pack really at 50.55 V), state of health now shows what the battery actually reports instead of an estimate, cells of the fifth battery and beyond are shown, the dashboard fills in much faster, and the CSV history export — broken on every installation — works again. The device also queries the batteries less often for slow-changing values. New on the dashboard: a “Your batteries” table showing, for each battery, its model, BMS firmware version, serial number, capacity, remaining charge, cells being balanced and status — data your batteries already reported but that was only visible on the raw diagnostics page. v2.4 adds two fixes reported by an owner running five batteries: batteries no longer disappear from the dashboard while the cells are being read, and the “stat” section of the raw diagnostics page — permanently empty until now — is filled again. Superseded by v2.5.
-
Pylon-Monitor v2.3Reliability release for installations with several batteries: no more endless restarts, correct voltage and charge level on large packs, real state of health, cells of the fifth battery and beyond, a faster dashboard, a working CSV export and the new “Your batteries” table. Superseded by v2.4, which adds two fixes: batteries no longer disappear from the dashboard while the cells are read, and the “stat” section of the raw diagnostics page is no longer empty.
-
Pylon-Monitor v2.2Quieter by default: the status light keeps its usual blinking for the first 5 minutes after power-on, then switches itself off while everything is fine — one short blink every 10 seconds only if the battery stops answering. Three modes to pick from, including the previous always-on behaviour. The device also sets its own clock from the internet now, with a time zone setting: local time on the dashboard, real dates in the event log, a timestamp column in the CSV export, and history graphs dated by the device. Plus an optional clock on the device's screen, and a night mode that switches screen and light off between two hours you choose.
-
Pylon-Monitor v2.1Major update. Reliability: the battery console reader now locates each value by name instead of a fixed position (a real BMS firmware difference was silently producing wrong readings under the old method), the combined charge level is correctly weighted for mixed-model packs, and the Raw data page no longer blanks out after a normal serial hiccup. Reset button: triple-pressing it could get stuck in a repeating reboot loop instead of completing β fixed for good, with a new "Forgot password?" section on the sign-in page. Setup screens: rebuilt with clearer instructions, a fixed display bug (part of the screen was invisible on the physical panel), the Screen Display footer/preview no longer cut off, and a first-time device no longer wastes 25 seconds trying to reconnect to a network that was never set up.
-
Pylon-Monitor v2.0Own captive portal (wildcard DNS + mDNS), self-healing TFT, multi-battery support (up to 16 units, per-cell voltage detail for the first ~4), Screen Display customization, Event log & Raw data diagnostics, Network test page, 24h history with CSV export, configurable SOC/temperature alarms with Pushover, 10 MQTT auto-discovered sensors, real session cookies for the optional login.
-
Pylon-Monitor v1.1 Superseded β no longer distributedAdded the JSON API, the browser-based OTA update page, the factory reset button and an improved TFT layout with a giant SOC readout.
-
Pylon-Monitor v1.0 Superseded β no longer distributedInitial public release. Captive portal WiFi setup, web dashboard, TFT screen.
Whatβs new since v2.4
- Your MQTT settings only took effect at the next restart. The broker address was read once, at start-up, and only if one had already been saved. Typing it into Settings and saving therefore triggered nothing at all — no connection attempt, no line in the event log — until you restarted the device yourself, which nothing prompted you to do. Measured on a device: not a single packet was sent to the broker for over two minutes after saving, then an immediate connection after a plain restart. The address is now applied on save, with an immediate retry and a fresh Home Assistant announcement.
- Pushover notifications could restart the device. The real cause is in the underlying library: creating the secure connection allocates 6.2 KB for BearSSL’s working stack and, if that allocation fails, halts the device instead of returning an error — which is why one owner saw a reboot the moment he saved his keys. The memory check now runs before that object is created rather than after it, which is what makes the reboot impossible. The threshold also matches what is really needed: 24 KB was more than this board ever has free in normal operation (about 5.7 KB), so the check refused every send and the log repeated “Pushover skipped: only 3144 B free, TLS needs 24000”. The buffers kept for the raw diagnostics page are now released before the attempt, the threshold reflects what is really needed, and a skipped alert states the actual reason instead of telling you to check an app token and user key that were correct.
- The battery polling interval is now adjustable in Settings, from 5 to 300 seconds, with 10 as the default and the previous behaviour. An owner running ten batteries asked for exactly this on 4 September and was told it was possible; the setting had not followed.
- A reduction in the number of batteries now requires two readings that give the same figure. Two consecutive short readings are not enough on their own: a truncated reply is cut at a variable point, so a six-to-two followed by a six-to-four would otherwise accept four, which is just as wrong.
- The memory figure shown in the boot history was measured after the restart, not before it. It was recorded during start-up, so it was a nearly constant value of about 24 KB that told you nothing about the session that had just ended — while reading, right next to a restart reason, exactly as though it did. It is now the amount that was really free within 30 seconds of the end of the previous session, under a label that cannot be misread, and “unknown” when there is nothing to report.
- Home Assistant: the sensors published for each individual battery never appeared on a multi-battery pack. The device announces its sensors to your broker when it connects, which happens a few seconds after start-up — before the first reading round has established how many batteries are present. The block that publishes the per-battery sensors is conditional on there being more than one, so it was skipped, and would only be published again on the next reconnection to the broker. The announcement is now repeated as soon as the number of batteries changes, including the very first time it becomes known.
- Home Assistant: the pack’s charge-cycle count could jump from one value to another shortly after start-up, which looked like two batteries writing into the same entity. They were not. When a battery does not answer the slower commands, the device falls back on the first battery’s figures rather than showing zeros — but it was doing so on the very first round, before the other batteries had had their few retries. The pack average therefore equalled battery 1 for a moment, then jumped to the true average. The fallback now waits until the retries are exhausted.
- A pack could briefly report fewer batteries than it has. When the reply from the batteries is cut short mid-table, the lines already read are perfectly valid and only the count is short — nothing distinguishes it from a genuinely smaller pack. A six-battery installation could therefore announce two for one cycle, typically just after the console cable was reconnected. A reduction in the number of batteries now requires two consecutive readings that agree; a battery genuinely removed is simply taken into account about ten seconds later.
- The dashboard went dark without explanation. Whenever a refresh failed to reach the device, the page faded to 45 % opacity and stopped updating — nothing else. Owners quite reasonably described it as the screen going dark and the data disappearing, and there was no way to tell that the page had simply lost contact. The dimming stays, because it is a useful signal, but a message now explains what happened and that the page keeps retrying every ten seconds.
- The WiFi password is now verified before being saved. Previously the device wrote it to memory, rebooted, failed to connect, and reopened its setup network 25 seconds later without saying why — leaving you in front of the same empty form. On a device already installed, a single typo made it disappear from your network and only the physical button could recover it. The device now tries the network while still reachable: a wrong password brings the form back with just the password to retype and nothing is saved, a network out of range says exactly that, and a success shows the address obtained plus a clickable link, then opens the dashboard on its own as soon as it can reach it.
- The setup network chooses a clearer radio channel. It always started on channel 1, by far the most used; it now measures the neighbouring networks at start-up and picks the least crowded of channels 1, 6 and 11.
- The MQTT status on the dashboard is now capitalised like the battery-link status shown just below it.