The program pointed its boot-time update check at a personal GitHub repo
(husbananjum/m5core-s3-UIMETRIX-Z87) that now answers 404 for both
version.txt and main.py, so every box on that build has been failing its
check on every boot - harmlessly, but no release could ever reach them. It
also had the broker at 192.168.87.11, while the boxes on the floor (and the
UiMetrix server) are on 192.168.2.174.
Updates now come from this repo on the company Gitea, through its anonymous
raw-file URLs. For that the program is committed as main.py - the name the
device downloads and runs - instead of "M5-Stack Code for Uimetrix.txt", and
version.txt is added. The old broker stays as a commented line, the way the
earlier networks are kept.
- A push to main that also bumps version.txt IS a release now; every box that
follows Gitea installs it at its next boot. Leave version.txt alone until
main.py is ready for the floor.
- No box follows Gitea yet: the ones with OTA code still point at the dead
GitHub URL, and the ones on the floor run a build without OTA at all. Each
needs one USB copy of this main.py; after that they update by themselves.
- version.txt starts at 2.0. Nobody knows the highest number ever published
on GitHub, and a box's NVS may hold a number it never actually ran; if any
box shows a higher V... on its screen, bump version.txt above it.
- A box freshly copied over USB still has its old NVS version (or the default
1.0), so on its first boot it downloads the identical main.py once and
resets. Expected, not a loop.
- The repo stores LF; the CRLF seen in a Windows checkout is core.autocrlf.
Gitea serves the stored LF bytes, which is what the device compiles.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
m.faisal
0d7c5781b0