eKiosk IKN

The problem

IKN's smart city program puts information kiosks in public places across Nusantara. Each one runs an app that shows government content: maps, announcements and transport schedules. With no central control, changing what a kiosk shows meant touching that device. That doesn't scale as more kiosks go up. Operators also couldn't tell whether a kiosk was running, had crashed, or was showing old content.

IKN also runs a bus rapid transit fleet. An earlier in-house service tracked bus positions in memory only. It kept no history, and it couldn't tell riders or operators when the next bus would arrive. Two teams needed tools: content staff managing kiosk playlists, and transport staff watching the fleet.

What I built

Kiosks report in, and the server works out their state

Every kiosk checks in every five minutes with what it's playing, where it is, and how much storage and memory it has left. From that check-in, the server works out whether the kiosk is operational, stale, disconnected or in maintenance. Each playlist carries a fingerprint that changes when its content changes. A kiosk reports the fingerprint it last loaded, so the server knows at once whether that device is behind. Operators build playlists by dragging media into order, and changes reach the kiosks on their own.

Arrival times learned from the buses' own history

A background service reads every bus's GPS position about every five seconds and places it on its route. For arrival times, I didn't assume a fixed speed. Each night, a job studies past trips and learns how long each stretch between stops usually takes, by hour and by weekday or weekend. The estimate starts from where the bus is on the road, then adds those learned times stop by stop. Where history is thin, it falls back to the timetable, then distance, then stop count, so it always gives an answer.

The system grades its own predictions

I wanted to know whether the arrival times were any good, so the system checks itself. It samples its own predictions, then records the error the moment the bus reaches that stop. A report shows the average error and the share of arrivals within one, two or three minutes, broken down by hour and by stop. Staff can see exactly where the estimates are weakest.

Buses that change route are caught without flip-flopping

Buses sometimes get reassigned or leave their scheduled route. A separate check compares each bus's recent path with every route and suggests a correction when one route is clearly the best match. My first version switched a bus after a few readings near another route. At stops shared by overlapping routes, buses flipped back and forth. Now a switch only happens after the bus visits a stop unique to the new route, or at least 80% of that route's stops. Every correction is logged.

Two apps, one sign-in

What began as one dashboard with a fleet tab is now two separate apps, eKiosk CMS and Fleet Management, with a shared launcher and a switcher between them. Operators sign in once through IKN's single sign-on, and Fleet Management is limited to staff. Kiosks don't use that sign-in at all. They register with an ID assigned at first boot, since a kiosk has no person to log in as.

Result

Both apps run in production for IKN, across 24 pages. Content staff manage kiosk playlists and see device health, with trend charts and an email alert when a kiosk goes silent. Transport staff get a live bus map, a route and stop editor, fleet schedules, a journey planner with points of interest, and reports on headways, travel times and arrival accuracy. The daily fleet report used to time out under load, so I rewrote it as a single database query. The work ran from March to July 2026. The system tracks vehicles only; it has no passenger or fare data.