Piso WiFi Software Update: Versions, Backups, and Rollback
Up: Piso WiFi Platforms | Same category: LPB Guide | AdoPiSoft Guide
Answer first: Never update a live machine during a busy period, never update without a backup, and never update all machines at once. Update one machine first during a quiet period, test it as a customer, and only then update the rest.
Software updates for Piso WiFi platforms are maintenance work, not a one click upgrade that can be ignored. This post is the update, backup, and rollback guide across platforms. The Platforms Compared pillar gives the platform comparison. The LPB guide, AdoPiSoft guide, PisoFi guide, and JuanFi guide give platform depth. This post does not repeat those guides. It explains how to check a version, how to back up before an update, how to update step by step, how to test after an update, and how to roll back if an update breaks a setting. Platform guides link to this post for update steps, instead of repeating update steps in each platform guide.
The rule for updates is simple: never update a live machine during a busy period, never update without a backup, and never update all machines at once. An update that changes a rate, a pause setting, or a portal button will affect every customer on that machine, so it should be tested first, on one machine, during a quiet period.
Before You Update: Version, Backup, and Notes
Check the current version and what the update changes
Before you update, note: platform name, current version, machine type, licence type if applicable, and the date you checked. Then check the update notes for the new version, from the official platform site or the supplier, for: what changed, what was fixed, what was added, and whether any setting, rate, pause rule, or portal layout changed. If update notes are vague, ask the supplier for a written summary before you update, because a vague update can hide a setting change that you will only discover when customers complain.
For newer systems such as Ruijie and SmartFi, JLink, 1Click, and WiFi5Soft, update notes are especially important, because firmware updates for those systems have changed portal behaviour in operator reports, including auto pause behaviour and coin counter display. Do not assume a firmware update for a newer system is only a security fix. Check the notes for portal, pause, and payment changes as well.
Back up settings, rates, and records
A backup for Piso WiFi is not only a file. It is a complete record that lets you rebuild the machine if the update fails. Before you update, record and save, in a safe place not on the machine itself:
- Rates: time for each coin amount, data rates if used, promo rates, and expiry dates for promos.
- WiFi name and WiFi password, admin login details in a safe place (not written on the machine), and any co-admin accounts and permissions.
- Pause settings: whether pause is enabled, maximum pause duration or count, pause validity, and coin versus voucher behaviour.
- Portal settings: coin mode, voucher mode, portal buttons visible, and any custom site name or tagline.
- Voucher and WiPass settings in general terms: voucher types in use, and any active voucher batches that customers may still hold, without sharing voucher codes publicly.
- Sales records: daily and monthly totals you need, and any downloadable sales report for the current period.
- Script and configuration notes for JuanFi builds, and any MikroTik configuration export your setup provides.
- Licence details: tier, validity period, and receipt, so you can prove the licence if support is needed after the update.
For commercial platforms, use the platform backup or export feature if one is provided, in addition to the written notes above. A platform backup usually restores settings for that same platform only, and it does not usually import into a different platform. For JuanFi, the script and configuration notes are the backup, because there is no single commercial backup file for all builds. Test the backup by checking that the notes are complete enough to rebuild the machine, not only by assuming a file was created.
Choose a quiet time and a test machine
Update during a quiet period, when few customers are using the machine, and when you have time to test afterwards. If you run several machines, update one machine first, test it for a period that includes a busy period, and only then update the rest. Updating all machines at once leaves you with no working machine to compare against if the new version fails, and it leaves all customers affected at the same time.
Tell customers in advance if a machine will be offline for an update, with a sign stating the expected downtime. A short planned downtime with a sign causes fewer complaints than an unexpected outage during a busy period.
Update Steps by Platform, in General Terms
Exact update steps differ by platform and version, so this section gives the general sequence that applies to all platforms, with platform specific notes where they matter. Follow the official platform update instructions for your version, in addition to this sequence, and do not skip the backup and test steps.
General update sequence
- Back up settings, rates, and records, as listed above, and confirm the backup is saved outside the machine.
- Check the update notes for setting, rate, pause, and portal changes, and note any change you need to test after the update.
- Check licence and version compatibility: whether the update is included in your licence tier, whether it applies to your board or hardware type, and whether it requires a specific version as a starting point.
- Apply the update during a quiet period, on one machine first, and do not interrupt power during the update.
- After the update, check the version number shown in the admin panel, to confirm the update actually applied.
- Test as a customer with a small payment: join the network, open the portal, pay by each payment mode you offer, check the rate and timer, test pause if offered, test voucher or WiPass if offered, and check desktop or charging if offered.
- Check admin settings after the update: rates, pause, portal buttons, WiFi name, and bandwidth limits, against your backup notes. An update can reset a setting to a default, even if the update notes do not highlight it.
- Monitor the machine for the next busy period, and keep the backup and the previous version notes available until you are confident the update is stable.
LPB update notes
For LPB, check licence tier and validity before updating, because an update may be included only for certain tiers or validity periods. After updating, test remote management, e-payment options where enabled, and pause in both coin and voucher modes, because those are the areas most likely to affect customers. If remote management shows a different machine status after the update, check the machine on site as a customer, rather than assuming the dashboard is correct.
AdoPiSoft update notes
For AdoPiSoft, check board compatibility and version type before updating, because licence terms differ by version and by ARM versus x64 hardware. After updating, test pause count behaviour, time and data rates, and coin acceptor behaviour at busy pace, because those are the areas most likely to change with a version update. If you use the Community Edition for learning, test the update on a test board first, before applying it to a commercial machine.
PisoFi update notes
For PisoFi, check version before updating, because some features, including some e-load features, may not be available on older versions, and an update may add or change those features. After updating, test WiPass generation and redemption, desktop timers if used, charging if used, sub vendo links if used, and sales report filters, because those are the areas most likely to be affected by a version change. Confirm licence type and key in the admin panel after the update, using the validation button in the device section, if your version provides it.
JuanFi update notes
For JuanFi, an update may mean a script change, a MikroTik firmware change, or both, depending on the build. Treat each change as a separate update: back up the script and configuration notes, apply one change at a time, and test after each change. Do not apply a script change and a firmware change at the same time to a live machine, because if something breaks, you will not know which change caused it. Test pause, portal, voucher, and rate behaviour after each change, on your own build, because a script that works for another build may not match yours.
If the Update Breaks Something: Rollback
Rollback means returning the machine to the previous working version and settings, after an update fails or changes a setting in a way you cannot accept. Rollback is not always possible in the same way for every platform, so the backup step before updating is what makes rollback possible.
Decide quickly whether to roll back or to fix forward
If a core function is broken after an update, such as coin payment not crediting, portal not opening, or rates showing wrong amounts, roll back first and investigate later, rather than trying to fix a live machine during a busy period. If only a minor setting changed, such as a portal button label or a default rate for a promo you do not use, fix forward by restoring that setting from your backup notes, and monitor the machine. The decision rule is: core function broken, roll back; minor setting changed, restore that setting and monitor.
Rollback steps in general terms
- Stop new customer payments on that machine if possible, with a sign explaining the machine is under maintenance, to avoid new sessions being created on a broken version.
- Restore the previous version using the platform rollback method for your version, or reinstall the previous version if the platform provides that path, following official instructions for your platform.
- Restore settings from your backup notes: rates, WiFi name, pause settings, portal settings, and bandwidth limits, and check each one against the backup.
- Test as a customer with a small payment, in each payment mode you offer, and test pause, voucher, desktop, and charging if offered, before reopening.
- Note the failed update: platform, previous version, new version, date, what broke, and what rollback step fixed it. That note helps you decide whether to retry the update later, and it helps support diagnose the problem if you contact the supplier.
When rollback is not possible, or not enough
In some cases, a platform update cannot be rolled back by a simple button, or a rollback restores the version but not all settings. In that case, rebuild the machine from your backup notes: reinstall the previous version if possible, re-enter rates, WiFi name, pause, and portal settings from notes, and test every function as a customer before reopening. If you cannot rebuild from notes, contact your supplier with platform, versions, backup details, and the exact failure, rather than trying random settings on a live machine. For JuanFi, rebuilding from script and configuration notes is the expected path, so complete notes are more important than for a commercial platform with a one click backup.
Firmware Tracker: A Simple Monthly Log
A firmware tracker is a simple log that prevents the most common update mistake: not knowing what version a machine is on, or what changed in the last update. Keep one tracker for all machines, with one row per machine per update, and update it monthly or after every update, whichever comes first.
Tracker format
| Field | What to record |
|---|---|
| Date | Date of update, or date of check if no update was applied |
| Machine | Location and machine identifier, so you know which machine the row refers to |
| Platform | LPB, AdoPiSoft, PisoFi, JuanFi, Ruijie and SmartFi, JLink, or other, with board or hardware type if relevant |
| Previous version | Version before the update, from the admin panel |
| New version | Version after the update, from the admin panel, or same version if no update was applied |
| What changed | Summary from official update notes, plus any setting, rate, pause, or portal change you noticed during testing |
| Tested | Yes or no, with payment modes tested, pause tested if offered, and any failure noted |
| Verified | Whether the update was verified on your machine, not only on a marketing page, with tester initials or name if you run a team |
| Rollback note | Whether rollback was needed, and what step fixed the problem, if applicable |
A tracker that is updated monthly is more useful than a tracker that is filled in once and forgotten. Review the tracker before buying a new machine, before renewing a licence, and before applying a major update, because it shows which versions have been stable for your locations and which versions caused problems.
Monthly firmware tracker: blank log format, to fill only from official sources
The Firmware Update Tracker is merged into this post, not given a separate post, because a separate tracker post would repeat this post’s tracker format, backup steps, and rollback steps, without a distinct answer. What follows is the monthly log format to use, with blank entries only. No version, date, or change is pre filled in this guide, because versions and changes must come from your own admin panel and from official update notes for your exact platform and hardware, not from a forum post, a marketplace listing, or an old guide.
How to run the monthly tracker
- Once a month, and after every update, whichever comes first, check each machine’s admin panel for its current version, and check the official update notes for that platform, if official notes are published for your version.
- Record one row per machine per check, even if no update was applied, so a blank month is visible as a checked month, not as a forgotten month.
- Record only what you verified on your machine or in official notes. If a change is reported only in a forum post or a social media update, mark it as unverified in the Verified column, and do not treat it as a confirmed change until you have checked it on your machine or in official notes.
- Review the tracker before buying a new machine, before renewing a licence, and before applying a major update, because it shows which versions have been stable for your locations and which versions caused problems.
Blank monthly log table
Copy this table for each month, and fill one row per machine per check. Leave a field blank if you do not know it, rather than guessing it, and mark the row as unchecked until you have verified it.
| Date of check | Machine and location | Platform | Previous version, from admin panel | New version, from admin panel, or same version if no update applied | Change, from official update notes only | Tested: payment, pause, voucher, coin, as applicable | Verified: on your machine, or official notes only, or unverified report |
|---|---|---|---|---|---|---|---|
What not to record in the tracker
Do not record a version, a date, or a change from an unofficial source as if it were verified, do not copy a version number from another operator’s machine, and do not record a marketing claim as a change. If official notes are not published for your platform or version, record that fact in the Change column, with the date you checked, rather than filling the column with a forum summary. A tracker with honest blanks is more useful than a tracker filled with unverified claims, because a future update decision based on a false version history can break payment, pause, or voucher behaviour for real customers.
Frequently Asked Questions About Piso WiFi Software Updates
Should I update my Piso WiFi machine as soon as a new version is released?
No, not during a busy period and not without a backup and a test plan. Wait for a quiet period, check update notes, back up settings and records, update one machine first, test it as a customer, and only then update the rest. An early update without testing can break a core function for all customers at once.
What should I back up before a Piso WiFi update?
Back up rates, WiFi name, pause settings, portal settings, bandwidth limits, voucher and WiPass settings in general terms, sales records, licence details, and script and configuration notes for JuanFi builds. Save the backup outside the machine, and check that the notes are complete enough to rebuild the machine, not only that a file was created.
Can I roll back a Piso WiFi update if it breaks my machine?
In many cases, yes, by restoring the previous version and settings from your backup, following the platform rollback method for your version. Rollback is not guaranteed for every platform and version, which is why the backup step before updating is essential. If rollback is not possible, rebuild from backup notes and test every function before reopening.
Why did my rates or pause settings change after an update?
An update can reset a setting to a default, change a portal layout, or change a pause rule, even if the update notes do not highlight it. After every update, check rates, pause, portal buttons, WiFi name, and bandwidth limits against your backup notes, and restore any setting that changed, before reopening to customers.
How often should I check for Piso WiFi updates?
Check monthly, as part of a regular maintenance routine, rather than checking only when something breaks. A monthly check lets you plan updates during quiet periods, keep a firmware tracker current, and avoid a situation where a machine falls many versions behind and an update becomes a major rebuild instead of a small step.
Do I need to update all my machines to the same version?
It is usually simpler to keep machines on the same version, because support, troubleshooting, and customer behaviour are consistent across locations. If you must keep different versions for different hardware or licence tiers, note the version per machine in your firmware tracker, and test each version separately, because a setting that works on one version may not work on another.
After an Update, Test Pause, Voucher, and Coin Behaviour
Older firmware builds have been reported to freeze a timer counter when a session is unpaused, so a pause test belongs in every post update check, not only in a first setup check. After an update, test a small coin payment, a voucher payment if offered, a pause and a resume, and a resume after a short disconnect, each on the same device. If a timer freezes or a session disappears, roll back using the backup noted above, and report the version and the exact test to the supplier. Operator discussions also mention names such as FoxPisoWiFi, SmartFi, and Mikhmon. Treat those only as names to verify from their own suppliers, with no full feature list claimed here.
What to Read Next
If you want platform depth, go to the LPB Piso WiFi Guide, the AdoPiSoft Guide, the PisoFi Guide, or the JuanFi Guide. If you want the wider comparison, go to the Platforms Compared pillar. If you need admin safety and recovery, go to the Admin Login guide. If you need troubleshooting for a problem after an update, go to the Troubleshooting guide. If you need pause rules in full, go to the Pause Time pillar.