Piso WiFi After a Power Outage: Recovery Checklist

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. General recovery workflow; exact boot order and backup features depend on the installed equipment.

Step-by-step checklist

1. Check electrical safety, UPS/surge protection and stable power before repeated restarts.
2. Bring the ISP modem/ONT online and confirm upstream service.
3. Boot the controller and inspect storage/database and network-interface status.
4. Bring switches/APs online and confirm clients receive the intended gateway/DNS.
5. Test one free/admin diagnostic session, then one low-value paid transaction.
6. Reconcile coin/digital-payment records around the outage and make a fresh backup after recovery.

What not to assume

Repeated hard power cycling can worsen storage/database problems. If the controller reports filesystem or database errors, preserve logs/backups before attempting destructive recovery. 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.

Restore service in dependency order

Start with stable power, then the ISP modem/ONT, controller/storage, network switch, access points, and payment hardware. Wait for each layer to become healthy before judging the next. A captive portal can sometimes load locally while the WAN is still down, so do not take a working portal as proof that customers should begin paying.

Storage and databases deserve extra care after abrupt power loss

Many vending controllers run from SD cards or other flash storage. Repeated hard power interruptions can corrupt filesystems or databases. If the dashboard reports storage/database errors, preserve logs and the latest backup before repeated restarts or reflashing. AdoPiSoft provides backup/restore options for database, portal, and system settings that are especially valuable before storage replacement.

Run a complete transaction after recovery

Once WAN and Wi-Fi are healthy, verify one customer join, portal redirect, low-value coin/voucher/digital payment, session start, and expiry/pause behavior. Reconcile any transactions that occurred around the outage before clearing logs or sales records.

Power recovery order for multi-device sites

Bring up the ISP modem/ONT first and wait for service, then the Piso controller/storage, managed switch, wired backhaul, access points, and payment peripherals. If all devices share one power source, a UPS can keep short outages from producing repeated hard shutdowns, but size it for the actual load and battery condition. Outdoor equipment should also have appropriate surge/lightning protection for the installation environment.

What to inspect if the problem returns after every outage

Look for weak power supplies, failing SD/flash storage, filesystem/database errors, APs that boot into the wrong mode, DHCP services that start unexpectedly, lost clock/time-zone state, or upstream equipment that changes subnet after reset. Fix the recurring dependency rather than teaching staff to factory-reset the controller after every brownout. Keep a recent off-device backup and a written boot/recovery checklist near the operator station.

Frequently asked questions

Where this advice stops being universal

The principles in Piso WiFi After a Power Outage: Recovery Checklist 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.

Useful next steps