Repository navigation
Releases: aronreid/ups-to-esp32
Release list
v0.16
Meet My UPS Pal
Your UPS finally has a name. My UPS Pal is a small board that plugs into a
UPS's USB port and puts it on your network, so Home Assistant, a NAS or
anything that speaks NUT can watch it with no computer in between. It used
to be called the UPS to ESP32 Module. The web page, the NUT banner and the
metrics now say My UPS Pal. The network name (ups-esp32-XXXX) and the way
updates work are unchanged, so nothing you have set up needs touching.
My UPS Pal is getting a home at https://myupspal.com (https://myupspal.ca
goes there too). It is still being built, so for now this repository has
the firmware, the docs and the source. Questions and licence requests:
hello@myupspal.com.
Introducing Rev B
Rev B is the next My UPS Pal board, and the one going into production. It
has more processing power and memory than Rev A, which is what lets it run
features Rev A has no room for. The first is Tailscale: your board joins
your own private network, so you can reach it from anywhere with no port
forwarding and no VPN to set up. Rev B also keeps a long history and an
outage log, and serves its page over HTTPS.
From v0.16 both boards run the same firmware version, so an update means
the same thing on either. Rev A keeps working and keeps getting updates.
What changed
- A new look for the web page, on both boards. Each UPS is a little battery
with a face that shows how it is doing, with its status in plain words, a
menu that splits the page into sections, and larger buttons for a phone. - Fixes a board restarting itself whenever Wi-Fi dropped, once it had been up
for fifteen minutes. It now restarts only after fifteen minutes offline. - Fixes a board that could stop reading its UPS until someone restarted it
by hand. It now restarts itself if the USB side stops answering. - Fixes boards not being able to see a new release.
- An update no longer power-cycles the UPS's USB link.
- A deep battery test is refused unless the battery reads 100 %.
- More free memory on both boards. Rev A gains about 40 KB.
- NUT serves up to three clients at once on Rev A and six on Rev B.
- Rev B only: Tailscale (enter an auth key on its Tailscale card; it stays
off until you do), long history, an outage log, and HTTPS with STARTTLS. - Built with ESP-IDF 5.5.5.
Updating a board that is running: open its web page, go to
Firmware, and press Check for updates. The board installs the file
for its own target into the spare slot and runs it after a restart.
If the new image does not come back, the bootloader reverts to the
previous one by itself.
First flash, over USB: use the -full image. It holds the
bootloader, partition table, OTA selector and application, and goes
to offset 0:
esptool.py --chip esp32s3 write_flash 0x0 ups-adaptor-reva-full.bin
The plain .bin files are the application only, at offset 0x20000.
They are what the board downloads when it updates itself.
ups-adaptor-reva* is Rev A, ups-adaptor-reva-oled* is Rev A with
the OLED fitted, ups-adaptor-revb* is Rev B. Every image names its
board, and a board refuses anything that is not its own.
SHA256SUMS.txt covers every binary.
v0.16-rc5
Meet My UPS Pal
Your UPS finally has a name. My UPS Pal is a small board that plugs into a
UPS's USB port and puts it on your network, so Home Assistant, a NAS or
anything that speaks NUT can watch it with no computer in between. It used
to be called the UPS to ESP32 Module. The web page, the NUT banner and the
metrics now say My UPS Pal. The network name (ups-esp32-XXXX) and the way
updates work are unchanged, so nothing you have set up needs touching.
My UPS Pal is getting a home at https://myupspal.com (https://myupspal.ca
goes there too). It is still being built, so for now this repository has
the firmware, the docs and the source. Questions and licence requests:
hello@myupspal.com.
Introducing Rev B
Rev B is the next My UPS Pal board, and the one going into production. It
has more processing power and memory than Rev A, which is what lets it run
features Rev A has no room for. The first is Tailscale: your board joins
your own private network, so you can reach it from anywhere with no port
forwarding and no VPN to set up. Rev B also keeps a long history and an
outage log, and serves its page over HTTPS.
From v0.16 both boards run the same firmware version, so an update means
the same thing on either. Rev A keeps working and keeps getting updates.
What changed
- A new look for the web page, on both boards. Each UPS is a little battery
with a face that shows how it is doing, with its status in plain words, a
menu that splits the page into sections, and larger buttons for a phone. - Fixes a board restarting itself whenever Wi-Fi dropped, once it had been up
for fifteen minutes. It now restarts only after fifteen minutes offline. - Fixes a board that could stop reading its UPS until someone restarted it
by hand. It now restarts itself if the USB side stops answering. - Fixes boards not being able to see a new release.
- An update no longer power-cycles the UPS's USB link.
- A deep battery test is refused unless the battery reads 100 %.
- More free memory on both boards. Rev A gains about 40 KB.
- NUT serves up to three clients at once on Rev A and six on Rev B.
- Rev B only: Tailscale (enter an auth key on its Tailscale card; it stays
off until you do), long history, an outage log, and HTTPS with STARTTLS. - Built with ESP-IDF 5.5.5.
Updating a board that is running: open its web page, go to
Firmware, and press Check for updates. The board installs the file
for its own target into the spare slot and runs it after a restart.
If the new image does not come back, the bootloader reverts to the
previous one by itself.
First flash, over USB: use the -full image. It holds the
bootloader, partition table, OTA selector and application, and goes
to offset 0:
esptool.py --chip esp32s3 write_flash 0x0 ups-adaptor-reva-full.bin
The plain .bin files are the application only, at offset 0x20000.
They are what the board downloads when it updates itself.
ups-adaptor-reva* is Rev A, ups-adaptor-reva-oled* is Rev A with
the OLED fitted, ups-adaptor-revb* is Rev B. Every image names its
board, and a board refuses anything that is not its own.
SHA256SUMS.txt covers every binary.
v0.16-rc4
Meet My UPS Pal
Your UPS finally has a name. My UPS Pal is a small board that plugs into a
UPS's USB port and puts it on your network, so Home Assistant, a NAS or
anything that speaks NUT can watch it with no computer in between. It used
to be called the UPS to ESP32 Module. The web page, the NUT banner and the
metrics now say My UPS Pal. The network name (ups-esp32-XXXX) and the way
updates work are unchanged, so nothing you have set up needs touching.
My UPS Pal is getting a home at https://myupspal.com (https://myupspal.ca
goes there too). It is still being built, so for now this repository has
the firmware, the docs and the source. Questions and licence requests:
hello@myupspal.com.
Introducing Rev B
Rev B is the next My UPS Pal board, and the one going into production. It
has more processing power and memory than Rev A, which is what lets it run
features Rev A has no room for. The first is Tailscale: your board joins
your own private network, so you can reach it from anywhere with no port
forwarding and no VPN to set up. Rev B also keeps a long history and an
outage log, and serves its page over HTTPS.
From v0.16 both boards run the same firmware version, so an update means
the same thing on either. Rev A keeps working and keeps getting updates.
What changed
- A new look for the web page, on both boards. Each UPS is a little battery
with a face that shows how it is doing, with its status in plain words, a
menu that splits the page into sections, and larger buttons for a phone. - Fixes a board restarting itself whenever Wi-Fi dropped, once it had been up
for fifteen minutes. It now restarts only after fifteen minutes offline. - Fixes a board that could stop reading its UPS until someone restarted it
by hand. It now restarts itself if the USB side stops answering. - Fixes boards not being able to see a new release.
- An update no longer power-cycles the UPS's USB link.
- A deep battery test is refused unless the battery reads 100 %.
- More free memory on both boards. Rev A gains about 40 KB.
- NUT serves up to three clients at once on Rev A and six on Rev B.
- Rev B only: Tailscale (enter an auth key on its Tailscale card; it stays
off until you do), long history, an outage log, and HTTPS with STARTTLS. - Built with ESP-IDF 5.5.5.
Updating a board that is running: open its web page, go to
Firmware, and press Check for updates. The board installs the file
for its own target into the spare slot and runs it after a restart.
If the new image does not come back, the bootloader reverts to the
previous one by itself.
First flash, over USB: use the -full image. It holds the
bootloader, partition table, OTA selector and application, and goes
to offset 0:
esptool.py --chip esp32s3 write_flash 0x0 ups-adaptor-reva-full.bin
The plain .bin files are the application only, at offset 0x20000.
They are what the board downloads when it updates itself.
ups-adaptor-reva* is Rev A, ups-adaptor-reva-oled* is Rev A with
the OLED fitted, ups-adaptor-revb* is Rev B. Every image names its
board, and a board refuses anything that is not its own.
SHA256SUMS.txt covers every binary.
v0.15.1
What changed
- Updates no longer crash with some UPSes attached. A board on v0.14.4 with a CyberPower EC850LCD rebooted every time it began downloading v0.15 (a panic in the USB host driver), so it said it was updating and never did, and its crash count rose by one each try. The board now pauses all USB traffic to the UPS for the length of an update and resumes it after; the UPS's readings hold their last values meanwhile, about half a minute.
- A board on v0.14.4 or v0.15 still runs the old update code, so its update to this release can crash the same way. For that one update, press the page's button that power-cycles the UPS's USB link, then start the update straight away. Unplugging the UPS's USB cable from the board does the same. Updates after this one need neither.
Firmware for the UPS to ESP32 Module.
Updating a board already running: open its web UI, go to
Firmware, and press Check for updates. The board installs the asset
for its own target, writes it to the spare slot, and runs it after a
restart. If the new image does not come back, the bootloader reverts
to the previous one by itself.
First flash, over USB: use the -full image. It contains the
bootloader, partition table, OTA selector and the application, and
goes to offset 0 with nothing to get wrong:
esptool.py --chip esp32s3 write_flash 0x0 ups-adaptor-reva-full.bin
(ups-adaptor-reva-oled-full.bin on a Rev A board with the OLED
display fitted; read "OLED module compatibility" in the hardware
docs before wiring one.)
A board fresh from the fab has none of those things, so the plain
application binary is not enough on its own.
The plain .bin files are the application only, at offset
0x20000. They are what the OTA client downloads, and what to use
if you are replacing the application on a board that is already
running.
ups-adaptor-reva* is for the Rev A board, ups-adaptor-reva-oled*
for a Rev A board with the OLED display fitted. Every image
declares its board in its app descriptor, and a device refuses
anything that is not its own.
SHA256SUMS.txt covers every binary here.
v0.15.1-rc2
What changed
- Updates no longer crash with some UPSes attached. A board on v0.14.4 with a CyberPower EC850LCD rebooted every time it began downloading v0.15 (a panic in the USB host driver), so it said it was updating and never did, and its crash count rose by one each try. The board now pauses all USB traffic to the UPS for the length of an update and resumes it after; the UPS's readings hold their last values meanwhile.
- A board on v0.14.4 or v0.15 still runs the old update code, so its update to this release can crash the same way. For that one update, press the page's button that power-cycles the UPS's USB link, then start the update straight away. Unplugging the UPS's USB cable from the board does the same.
- Same source as v0.15.1-rc1, whose build was refused for the format of its notes and never published.
Firmware for the UPS to ESP32 Module.
Updating a board already running: open its web UI, go to
Firmware, and press Check for updates. The board installs the asset
for its own target, writes it to the spare slot, and runs it after a
restart. If the new image does not come back, the bootloader reverts
to the previous one by itself.
First flash, over USB: use the -full image. It contains the
bootloader, partition table, OTA selector and the application, and
goes to offset 0 with nothing to get wrong:
esptool.py --chip esp32s3 write_flash 0x0 ups-adaptor-reva-full.bin
(ups-adaptor-reva-oled-full.bin on a Rev A board with the OLED
display fitted; read "OLED module compatibility" in the hardware
docs before wiring one.)
A board fresh from the fab has none of those things, so the plain
application binary is not enough on its own.
The plain .bin files are the application only, at offset
0x20000. They are what the OTA client downloads, and what to use
if you are replacing the application on a board that is already
running.
ups-adaptor-reva* is for the Rev A board, ups-adaptor-reva-oled*
for a Rev A board with the OLED display fitted. Every image
declares its board in its app descriptor, and a device refuses
anything that is not its own.
SHA256SUMS.txt covers every binary here.
v0.15
What changed
- APC Smart-UPS units that keep their voltages out of the normal USB data, such as the Smart-UPS C 1500, now report input and output voltage, load, watts, current, frequency and battery details, read through APC's Modbus channel as NUT's apc_modbus does. Turn Modbus on in the UPS's menu first (Configuration, Modbus, Enable). Not yet tried on a real unit.
- /api/modbus downloads what the board and a Smart-UPS said over Modbus. "Send my UPS info" includes it for such a UPS, and the page says it carries readings.
- PeaNUT now shows the board's UPS instead of "Device Unreachable": the board answers GET TYPE, LIST ENUM and LIST RANGE.
- NUT reports "data stale" once the UPS stops answering, instead of its last status, so a power cut is not hidden behind an old "on mains".
- A UPS that fails its first detection is tried again instead of staying "not detected" until replugged.
- UPSes with large report descriptors (some Eaton and Legrand) are detected, as are ones shorter than they claim. A short reply no longer reads as zeros.
- Older Tripp Lite UPSes (09ae:0001) should now be detected. Not yet tried on a real unit.
- If the board cannot join its saved Wi-Fi for half an hour, it opens its setup network for five minutes so you can fix it, then tries again. A dropped reconnect is retried at once.
- NUT clients that vanish are noticed in about two minutes, not two hours. Commands split across packets are read whole, upsmon as primary no longer logs an alert, and quotes in names are escaped.
- A self-test sent while a Smart-UPS is slow on Modbus goes through at once instead of timing out and then running anyway.
- A fleet check-in answered with an interval of zero no longer counts as failed.
- The status page can no longer crash the board with long error messages, and a service that fails to start no longer restarts the board.
Firmware for the UPS to ESP32 Module.
Updating a board already running: open its web UI, go to
Firmware, and press Check for updates. The board installs the asset
for its own target, writes it to the spare slot, and runs it after a
restart. If the new image does not come back, the bootloader reverts
to the previous one by itself.
First flash, over USB: use the -full image. It contains the
bootloader, partition table, OTA selector and the application, and
goes to offset 0 with nothing to get wrong:
esptool.py --chip esp32s3 write_flash 0x0 ups-adaptor-reva-full.bin
(ups-adaptor-reva-oled-full.bin on a Rev A board with the OLED
display fitted; read "OLED module compatibility" in the hardware
docs before wiring one.)
A board fresh from the fab has none of those things, so the plain
application binary is not enough on its own.
The plain .bin files are the application only, at offset
0x20000. They are what the OTA client downloads, and what to use
if you are replacing the application on a board that is already
running.
ups-adaptor-reva* is for the Rev A board, ups-adaptor-reva-oled*
for a Rev A board with the OLED display fitted. Every image
declares its board in its app descriptor, and a device refuses
anything that is not its own.
SHA256SUMS.txt covers every binary here.
v0.15-rc4
What changed
- PeaNUT now shows the board's UPS. It asks the type of every variable (GET TYPE), which the board did not answer, and PeaNUT then listed the whole UPS as "Device Unreachable". LIST ENUM and LIST RANGE are answered too.
- Everything in v0.15-rc3 is included: APC Smart-UPS voltages over Modbus, the /api/modbus capture, and the fixes from failure testing.
- Checked against Home Assistant's NUT integration: all 21 variables it shows for a Back-UPS RS 1000G match what the board serves.
Firmware for the UPS to ESP32 Module.
Updating a board already running: open its web UI, go to
Firmware, and press Check for updates. The board installs the asset
for its own target, writes it to the spare slot, and runs it after a
restart. If the new image does not come back, the bootloader reverts
to the previous one by itself.
First flash, over USB: use the -full image. It contains the
bootloader, partition table, OTA selector and the application, and
goes to offset 0 with nothing to get wrong:
esptool.py --chip esp32s3 write_flash 0x0 ups-adaptor-reva-full.bin
(ups-adaptor-reva-oled-full.bin on a Rev A board with the OLED
display fitted; read "OLED module compatibility" in the hardware
docs before wiring one.)
A board fresh from the fab has none of those things, so the plain
application binary is not enough on its own.
The plain .bin files are the application only, at offset
0x20000. They are what the OTA client downloads, and what to use
if you are replacing the application on a board that is already
running.
ups-adaptor-reva* is for the Rev A board, ups-adaptor-reva-oled*
for a Rev A board with the OLED display fitted. Every image
declares its board in its app descriptor, and a device refuses
anything that is not its own.
SHA256SUMS.txt covers every binary here.
v0.15-rc3
What changed
- A self-test or other command sent while the board is waiting on a slow or silent Smart-UPS Modbus reply now goes through at once. Before, it could time out on the page and then run anyway.
- A check-in the fleet server answers with an interval of zero no longer counts as a failed one. Before, the board backed off and "Send my UPS info" said it could not reach the server.
- New tests: corrupt and random UPS data under memory-error checkers, a UPS that stops answering, and a fleet server that is down, refusing or misbehaving, over simulated days.
- Everything in v0.15-rc2 (APC Smart-UPS voltages over Modbus, the /api/modbus capture) is included. Still not tried on a real Smart-UPS with Modbus.
Firmware for the UPS to ESP32 Module.
Updating a board already running: open its web UI, go to
Firmware, and press Check for updates. The board installs the asset
for its own target, writes it to the spare slot, and runs it after a
restart. If the new image does not come back, the bootloader reverts
to the previous one by itself.
First flash, over USB: use the -full image. It contains the
bootloader, partition table, OTA selector and the application, and
goes to offset 0 with nothing to get wrong:
esptool.py --chip esp32s3 write_flash 0x0 ups-adaptor-reva-full.bin
(ups-adaptor-reva-oled-full.bin on a Rev A board with the OLED
display fitted; read "OLED module compatibility" in the hardware
docs before wiring one.)
A board fresh from the fab has none of those things, so the plain
application binary is not enough on its own.
The plain .bin files are the application only, at offset
0x20000. They are what the OTA client downloads, and what to use
if you are replacing the application on a board that is already
running.
ups-adaptor-reva* is for the Rev A board, ups-adaptor-reva-oled*
for a Rev A board with the OLED display fitted. Every image
declares its board in its app descriptor, and a device refuses
anything that is not its own.
SHA256SUMS.txt covers every binary here.
v0.15-rc2
What changed
- APC Smart-UPS units that keep their voltages out of the normal USB data, such as the Smart-UPS C 1500, now report input and output voltage, load, watts, output current and frequency, battery voltage and temperature. The board reads them through APC's Modbus channel on the same USB cable, as NUT's apc_modbus driver does.
- Modbus has to be turned on in the UPS's front-panel menu first (Configuration, Modbus, Enable). Until it answers, the board asks again every five minutes; everything else works as before.
- New download at /api/modbus: what the board and the UPS said to each other over Modbus. "Send my UPS info to the developer" now sends it too for such a UPS, and the page says it includes the UPS's readings.
- Also in this build: a UPS that fails its first detection is tried again, NUT reports "data stale" once the UPS stops answering instead of its last status, and larger report descriptors are accepted.
- Not yet tried on a real Smart-UPS with Modbus. Other UPSes take the same path as before.
Firmware for the UPS to ESP32 Module.
Updating a board already running: open its web UI, go to
Firmware, and press Check for updates. The board installs the asset
for its own target, writes it to the spare slot, and runs it after a
restart. If the new image does not come back, the bootloader reverts
to the previous one by itself.
First flash, over USB: use the -full image. It contains the
bootloader, partition table, OTA selector and the application, and
goes to offset 0 with nothing to get wrong:
esptool.py --chip esp32s3 write_flash 0x0 ups-adaptor-reva-full.bin
(ups-adaptor-reva-oled-full.bin on a Rev A board with the OLED
display fitted; read "OLED module compatibility" in the hardware
docs before wiring one.)
A board fresh from the fab has none of those things, so the plain
application binary is not enough on its own.
The plain .bin files are the application only, at offset
0x20000. They are what the OTA client downloads, and what to use
if you are replacing the application on a board that is already
running.
ups-adaptor-reva* is for the Rev A board, ups-adaptor-reva-oled*
for a Rev A board with the OLED display fitted. Every image
declares its board in its app descriptor, and a device refuses
anything that is not its own.
SHA256SUMS.txt covers every binary here.
v0.14.4
What changed
- The board now also listens for the reports a UPS sends the moment something changes, as NUT does, so a switch to battery shows up straight away.
- Liebert UPSes get ups.status from NUT's own logic: on mains, on battery, charging, low battery, replace battery and shutdown imminent.
- docs/tested-ups.md now lists UPSes in three groups by evidence: tested on hardware, checked against their real descriptor (56 models from the NUT issue tracker), and not supported (serial over USB).
Firmware for the UPS to ESP32 Module.
Updating a board already running: open its web UI, go to
Firmware, and press Check for updates. The board installs the asset
for its own target, writes it to the spare slot, and runs it after a
restart. If the new image does not come back, the bootloader reverts
to the previous one by itself.
First flash, over USB: use the -full image. It contains the
bootloader, partition table, OTA selector and the application, and
goes to offset 0 with nothing to get wrong:
esptool.py --chip esp32s3 write_flash 0x0 ups-adaptor-reva-full.bin
(ups-adaptor-reva-oled-full.bin on a Rev A board with the OLED
display fitted; read "OLED module compatibility" in the hardware
docs before wiring one.)
A board fresh from the fab has none of those things, so the plain
application binary is not enough on its own.
The plain .bin files are the application only, at offset
0x20000. They are what the OTA client downloads, and what to use
if you are replacing the application on a board that is already
running.
ups-adaptor-reva* is for the Rev A board, ups-adaptor-reva-oled*
for a Rev A board with the OLED display fitted. Every image
declares its board in its app descriptor, and a device refuses
anything that is not its own.
SHA256SUMS.txt covers every binary here.