For Piso WiFi operators and staff: A short daily check catches failures before they become lost sales: confirm WAN health, controller/storage status, captive portal, one transaction path, access-point availability, backups and physical/payment hardware.
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. Operational checklist applicable to most deployments; exact dashboards differ.
Step-by-step checklist
- Check WAN status, latency and whether the public internet is actually reachable.
- Review controller storage/database health, time/date and recent critical logs.
- Join as a customer and verify portal redirection and one test session.
- Check access points, switch links and unusual client/load spikes.
- Test coin/bill/digital-payment paths appropriate to the machine.
- Confirm the latest backup exists off-device and record any configuration change made that day.
What not to assume
Do not use a factory reset as routine maintenance. Repeated unexplained failures should be diagnosed from logs, power quality, storage health and network evidence. 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.
Five minutes of checks can prevent a day of lost sales
Confirm WAN internet, controller time/date, disk/storage health, recent critical logs, access-point status, and the customer portal before peak hours. Then perform one real client join and start a test session. A dashboard that loads for the operator does not prove the customer path is working.
Review payment and sales anomalies
Compare expected cash/coin/digital-payment activity with sales inventory and investigate sudden gaps or duplicates. AdoPiSoft sales inventory can be filtered by time period, sales type, payment portal, customer/device and other fields. Do not routinely clear records before they have served their reconciliation purpose.
Keep a simple change log
Record firmware/software updates, rate edits, network changes, access-point replacement, payment-hardware repairs, and staff-account changes. When a problem appears later, knowing what changed—and when—is often more useful than another reboot.
Daily, weekly, and monthly tasks
Daily: check WAN, portal, one customer login/session, payment input, critical logs, storage alerts, and AP status. Weekly: review peak utilization/latency, failed payments/vouchers, admin login anomalies, backups, and physical cleanliness/ventilation. Monthly: verify a backup restore plan, update inventory/change records, review staff permissions, inspect UPS/surge equipment, and compare ISP capacity with real peak demand.
Define escalation thresholds
Write down when staff should stop experimenting and escalate: repeated storage errors, unexplained license/activation state, WAN/optical faults owned by the ISP, overheating, burnt power components, database corruption, or payment discrepancies that cannot be reconciled. A checklist is useful only when it tells the operator both what to do and when not to make a risky change.
Frequently asked questions
What is the minimum daily customer-path test?
Join from a normal customer device, obtain the expected network settings, open the portal, start a low-value/test session, confirm internet/DNS, and verify the operator record. An admin dashboard alone is not enough.
What should be reviewed in logs every day?
Look for critical storage/database/network errors, repeated failed admin access, payment/session anomalies, WAN instability, and AP/controller restarts. Establish a normal baseline so unusual events stand out.
How often should backups be checked?
Create them on a sensible schedule and after major changes, but also verify that the files are readable, labelled, stored off-device, and compatible with the documented restore process. A forgotten backup folder is not a recovery plan.
What issues should a staff operator escalate instead of fixing alone?
Escalate licensing/activation anomalies, database/storage corruption, ISP/optical faults, electrical/overheating damage, unreconciled payment loss, and any change requiring credentials or recovery information outside that staff member’s role.
How to validate the explanation on your own network
For Piso WiFi Operator Daily Checklist, look for an observable before/after signal: route table, lease, DNS answer, gateway reachability, radio association, WAN status, application behavior, or latency under load. A setting is understood when you can predict which observation it should change and which observations it should leave alone.
Keep recovery access available
When a change can affect Wi-Fi, LAN addressing, routing, or admin access, keep an Ethernet path or documented recovery method available before pressing Save.