For operators: Back up before software upgrades, major rate/network changes and hardware migration; record the software version/device identity so you know what a backup belongs to.
Start with the correct platform and role
Piso WiFi is a category of prepaid/captive-portal deployments, not one standardized router firmware. A vending/controller platform, the upstream ISP router, and separate Wi-Fi access points can all have different addresses and credentials. The customer portal and the operator admin page are also different security roles. AdoPiSoft explicitly documents backup/restore permissions; exact file compatibility is version/platform dependent.
Step-by-step checklist
- Record device ID, software version, LAN/WAN design and current rate plan.
- Use the platform’s supported backup/export function.
- Store a copy away from the machine and protect sensitive credentials/data.
- After an upgrade/change, test a fresh user transaction before declaring success.
- Restore only a backup compatible with the correct platform/version/hardware, then verify WAN, portal, rates and sessions.
What not to assume
A backup can contain sensitive network or business data. Do not publish it or store it in an open web directory. Likewise, 10.0.0.1 is only a private IPv4 address. Its presence does not identify the software by itself, and changing the address does not change how the vending/session system works.
Customer-side checks
- Stay connected to the Piso WiFi SSID and turn off a VPN temporarily if the portal will not open.
- Do not type operator credentials into a public search result.
- If a portal fails only on one phone, test browser captive-portal state, Private DNS, MAC randomization and date/time before blaming the machine.
- Keep payment/voucher proof until the session is confirmed.
- For pause/resume or voucher issues, use the same device when the platform ties sessions to a device identity.
Operator-side checks
Troubleshoot in layers. Confirm stable power, then WAN internet, controller WAN/LAN interfaces, DHCP/DNS, access-point reachability, captive-portal service, payment input, and finally the user/session database. If every client fails, focus on shared infrastructure. If one client fails, compare that client with a working one before rebooting or resetting the system.
Security and reliability
- Change initial/factory administrator credentials after setup.
- Keep customer traffic separated from the management LAN where the platform supports it.
- Use official software updates and make backups before upgrading.
- Protect the controller, coin acceptor and power hardware from moisture, heat and unstable power.
- Use a proper access point for coverage and capacity rather than assuming the controller board’s radio can serve a busy area.
- Never expose the admin dashboard directly to the public internet through an unrestricted port forward.
Network architecture matters more than the portal IP
A healthy installation normally has a clear upstream/downstream design: ISP modem or ONT, then the device responsible for routing/session control, then switches/access points serving customers. Avoid accidental double DHCP, overlapping subnets and a consumer Wi-Fi router running NAT behind the vending controller unless the design intentionally calls for another routed boundary. Label WAN and LAN cables so a maintenance visit does not silently reverse them.
Payment and session integrity
When money or vouchers are involved, troubleshoot payment confirmation separately from internet access. Keep transaction/session logs long enough for legitimate support and reconciliation, but do not collect secrets that the payment provider does not require. For digital wallets, the operator should never request a customer PIN or one-time password. Test duplicate payments, failed callbacks, controller restarts and recovery after power loss before advertising a new payment option.
Maintenance checklist
- Keep the controller/router and access-point software on supported releases from the official vendor.
- Back up configuration before updates and store a copy away from the machine.
- Check power supply, ventilation, storage health and cable condition.
- Review peak-hour WAN utilization, loaded latency and access-point client counts.
- Audit admin accounts after staff/vendor changes and remove access that is no longer needed.
- Test the customer journey—from joining Wi-Fi through payment, portal access, session expiry and reconnect—after every major change.
Check the exact platform before using credentials or reset steps
Piso WiFi systems are not one standardized firmware. Match the machine name, installed version, controller type and local network before applying a login, password-recovery or reset instruction. If the device label or installed platform shows a different address or workflow, use the information for that exact machine rather than forcing a value from another platform.
Know what your backup actually contains
AdoPiSoft currently separates backup options for the database, captive portal, and system settings. Database backups can include Wi-Fi users, customers, sessions, vouchers, e-load data, and sales inventory. Captive-portal backups can include theme/settings/assets. System settings can include accounts, rates, coinslots, bandwidth, schedules, network interfaces, and plugin data. Choose the scope deliberately rather than assuming every backup is a full machine image.
Back up before the risky events
Create a fresh off-device backup before software upgrade/downgrade, SD-card replacement, reflashing, major network changes, rate redesign, or restoring older settings. Record the running software version with the backup. A configuration created on a newer version may not be safe to restore blindly onto an older image.
Test restore as a procedure, not during an emergency
Document where the file is stored, who can access it, which components it contains, and the order required to restore service. After a restore, test WAN/LAN addressing, portal assets, admin accounts, rates, one payment, one voucher/session, access points, and customer internet. A file that was never tested is not yet a proven recovery plan.
Know what the backup actually contains
AdoPiSoft currently separates backup scopes such as database, captive-portal assets, and system settings; its backup data can include users, sessions, vouchers, sales, rates, coin-slot/bandwidth/network configuration, and admin accounts depending on the selected scope. Label backups with machine identity, platform/software version, date, and purpose so an operator does not restore the right file to the wrong machine or overwrite newer business data.
Practice restore before an emergency
A backup that has never been tested is only a hope. After creating a known-good backup, verify it is readable, store an off-device copy, and document the supported restore sequence. During a real recovery, restore only onto a compatible platform/version according to vendor guidance, then verify machine identity/license, WAN/LAN, rates, payment inputs, portal assets, admin accounts, and one complete customer transaction before reopening service.
Frequently asked questions
When should I create a backup?
Create one after a known-good commissioning state and before software updates, major rate/network/payment changes, storage replacement, or migration. Keep dated copies rather than overwriting the only working backup.
Can I restore a backup to any Piso WiFi machine?
Do not assume compatibility. Match platform, software version, machine identity/licensing, and hardware as required by the vendor. Restoring the wrong data can overwrite newer sales/configuration or create licensing/network problems.
Where should backups be stored?
Keep at least one copy away from the controller and protect it as sensitive business/network data. Label it with machine identity, version, date, and scope so it can be selected confidently during an outage.
What must be tested after restore?
Verify activation/license, WAN/LAN, DHCP/DNS, AP connectivity, portal assets, rates/vouchers, payment inputs, admin accounts, session rules, and one complete low-value customer transaction.
Where this advice stops being universal
The principles in How to Back Up and Restore Piso WiFi Settings Safely apply broadly, but interface names and supported features do not. A mesh system managed by an app, an ISP gateway with provider firmware, a prosumer firewall, and an ordinary retail router can expose the same underlying function in very different ways. Use the concept to understand the job, then use the exact device documentation to perform it.
Do not import settings from a different topology
Values copied from another household can create overlaps, break WAN authentication, expose services, or disable access to the management interface. Copy the reasoning, not the configuration.