A shower you open with your phone, in a shipping container

Our part in it

This was a combined software and hardware product, delivered to the client as one system by a team of partners: power supply, 4G connectivity, the main control board, the waterproofed enclosure and the in-cabin display, alongside the server, the WeChat client and the admin console. imady's principal was part of that team, leading project coordination on the development side and building the front-end static content. What follows is the team's work, described as such.

What we built, and why that shape

The hard part of an unattended machine is not taking the money — it is knowing, without anyone watching, what state each door is actually in. The system was therefore designed around an explicit state machine for every pod, in which the door lock and the water solenoid are never both open, and the pod only returns to 'free' once a magnetic sensor has confirmed the door closed behind the departing user.

• A WeChat official account is the entire user interface: scan the code on the pod, be identified by WeChat Auth, and the lock and valve open. No app, no account of ours to create — the same reasoning that suits a passer-by using a facility once.
• Four states, not two: idle, open, in use, leaving. The half-closed 'leaving' state exists because the user must be able to get out after the valve has shut, and the pod must not be offered to the next person until the door is confirmed closed.
• Billing is settled after the fact rather than prepaid: the session is timed (the first minute free), a payment record is generated on exit, and an unpaid record blocks the offender's next scan until it is cleared — which is also why blacklisting and arrears queries sit in the entry flow rather than in an afterthought of an admin screen.
• A hardware API separates business logic from the physical layer, so the server reasons about pods and sessions while the devices deal in locks, valves, lights and timers.
• An admin console covers what an operator actually needs at 2am: pod status and remote open/close, user and blacklist administration, arrears, and the full usage record.
• The failure questions were written down before the build — what if there is no mobile signal, what if the door will not open, what if payment fails, what if the entry and exit states disagree — because on unattended hardware these are the normal cases, not the edge cases.
• Nothing off the shelf fitted a wet, unattended, outdoor box, so the hardware was designed for the job: power supply, main control board, waterproofing and the in-cabin display were all custom, with the control logic answerable to the same state machine the server reasons about.
• Connectivity was ordinary 4G LTE from China Telecom — by then a mature, well-covered network. The interesting question was never the radio but what the pod should do when it drops, which is why the local control board holds the door state rather than deferring to the server for it.