HNK SafeRoute
Know your route before you go
Choose where you are to get your brief.
Next hours
| Time | Weather | Temp | Rain | Gusts |
|---|---|---|---|---|
| Loading... | ||||
Your AI brief
Press the button: the assistant reads the conditions and tells you what to do, in a few sentences.
Warn me while I walk
Shares your location while this page is open and warns you (sound, vibration, notification) when you enter a zone with a problem: a train at the crossing, an emergency, fire, gas or flooding.
Weather: Open-Meteo (free, no account). Street data: the HNK street node, live. Your position is used only in your browser and for the map you choose to join.
The street node
Device screen
A live copy of the 0.96" OLED screen on the crossing pole. People waiting see the robot colour, WALK or CARS GO, a train or emergency warning, and the road conditions.
People crossing
Environment
Priority crossing (RFID)
People who need more time (elderly, disabled, school patrol) tap a registered fob on the reader at the pole and get a longer WALK. Any other card works like the walk button.
Live map
Where people are around the crossing, live. A person inside the crossing zone while the robots show blue (cars go), or on the railway while a train is coming, is logged as an infraction. Free map (OpenStreetMap), no API key. Locations are shared only when a person presses "Share my location".
Zones
People now 0
Infractions 0
Controls
Gates move from here only through the hardware tests below, which run in maintenance mode and are refused while a train is on the crossing. A remote command can never lift a barrier onto a train.
Data export (CSV)
Every reading from the crossing (every 5 s) is recorded in this browser while the page is open, and the last 3,000 are kept after a refresh. Download them as CSV files for Excel, Google Sheets or the report.
Event log
Ask the crossing
AI assistant (Gemini 3.8 Flash). It sees the live crossing data with every question.
RoboFace Live
Meet SafeRoute
The crossing's robot companion. It sees you through your camera, hears your questions and answers out loud, using the live data from the crossing.
Allow the camera and microphone when the browser asks. Works best in Chrome or Edge.
Sees what you show it
Every question goes with a camera frame: show it the breadboard, a sensor or the crossing and ask what it sees.
Voice conversation
Speak naturally. SafeRoute listens, thinks, answers with its own voice and listens again. Tap the face to interrupt.
Knows the crossing
It reads the live state: robots, train, gates, tunnel guard, temperature, gas and wait times.
Has a personality
It blinks, looks around, smiles, winks and thinks visibly while it works out an answer.
Your camera is off
Email alerts
- Fire or gas emergency at the crossing
- Flooded path or ice risk on the road
- Train on the crossing for more than 60 s
- Device offline for more than 60 s
Each alert type sends at most once every 10 minutes. Alerts go out from this page, so keep it open on one laptop during the demo. Preview data never sends email.
Hardware test
Robots (both lanes)
Lights
Buzzer
Railway gate
Car barrier
Whole crossing
Each test lasts 3 seconds (the up-and-down tests and the train drill 6 s). Gates moved by a test go back to automatic after 30 seconds. Device reply: --
Boot self-test
| Part | Result | Detail |
|---|---|---|
| Reset the ESP32, or press "Run self-test again" in maintenance mode. | ||
Inputs: check each one on the real device
| Part | Reading now | How to check it | Result |
|---|---|---|---|
| DHT temperature | -- | Breathe on it or hold it, temperature and humidity rise | -- |
| MQ-5 gas | -- | Unlit lighter gas near it, the value jumps | -- |
| Soil moisture | -- | Dip the probe in water, it rises | -- |
| LDR light | -- | Cover it with your hand, it drops | -- |
| Train sensor (IR) | -- | Pass a hand 1 cm in front of the IR sensor: train detected | -- |
| RFID reader (PN532) | -- | Tap the blue fob or any card on the reader | -- |
| PIR tunnel guard | -- | Walk in front of it (wait 45 s after power-up) | -- |
| Button 1 pedestrian | -- | Press it on the device | -- |
| Button 2 railway gate | -- | Press it on the device | -- |
| Button 3 car barrier | -- | Press it on the device | -- |
| Button 4 street lamp | -- | Press it on the device | -- |
| WiFi signal | -- | Better than -75 dBm is solid | -- |
| City mainframe link | -- | Needs CITY_HOST in config.h | -- |
Pinout
ESP32 DevKit V1, 30 pins, seen from the top with the USB port at the bottom. Every pin we use and what is connected to it.
WROOM
Power
Pin connections
ESP32 Dev Board 30-pin (CP2102), labels as printed on the board. Buttons use the internal pull-up: one leg to the pin, the opposite leg to GND. Every LED has its own resistor.
| Pin | Part | Wiring | Extra part |
|---|---|---|---|
| Traffic robots (left and right lane share pins) | |||
| D25 | RED, both robots | D25 → 220Ω → LED → GND, twice | 2 × 220Ω |
| D26 | ORANGE, both robots | D26 → 220Ω → LED → GND, twice | 2 × 220Ω |
| D33 | BLUE, both robots | D33 → 100Ω → LED → GND, twice | 2 × 100Ω |
| Push buttons | |||
| D13 | Button 1, pedestrian | D13 ↔ button ↔ GND | none |
| D18 | Button 2, railway gate | D18 ↔ button ↔ GND | none |
| D19 | Button 3, car barrier (hold 3 s = emergency) | D19 ↔ button ↔ GND | none |
| D21 | Button 4, street lamp (hold 3 s = maintenance) | D21 ↔ button ↔ GND | none |
| Train sensor and gates | |||
| VN | IR train sensor (TCRT5000 module, 3 pins) | OUT → VN, VCC → 3V3, GND → GND; train = OUT goes LOW (range about 1 cm, blue knob) | none |
| RX2 | Servo, car barrier | orange → RX2, red → breadboard 5V rail, brown → GND | none |
| TX2 | Servo, railway gate | orange → TX2, red → breadboard 5V rail, brown → GND | none |
| Environment | |||
| D4 | DHT temperature + humidity (3-pin module) | S → D4, + (middle) → 3V3, − → GND | none (pull-up on the module) |
| D34 | MQ-5 gas | AO → 10kΩ → D34 → 10kΩ → GND, VCC → breadboard 5V rail | 2 × 10kΩ |
| D35 | Soil moisture | AO → D35, VCC → 3V3, GND → GND | none |
| D32 | LDR light sensor | 3V3 → LDR → D32 → 10kΩ → GND | 10kΩ |
| D22 | Street lamp LED | D22 → 220Ω → LED → GND | 220Ω |
| D23 | Buzzer module, 3 pins (− , middle, S) | S → D23, middle (+) → 5V rail (louder) or 3V3, − → GND | none |
| OLED screen (0.96" SSD1306, 7-pin SPI) | |||
| D14 | OLED SCL (clock) | SCL → D14 | none |
| D15 | OLED SDA (data) | SDA → D15 | none |
| D5 | OLED DC | DC → D5; RES → EN; CS → GND; VCC → 3V3; GND → GND | none |
| VP | PIR tunnel guard (HC-SR501) | OUT → VP, VCC → 5V rail, GND → GND | none |
| D2 | Status LED | onboard, nothing to wire | none |
| RFID reader (Elechouse PN532 V3, UART / HSU mode) | |||
| D27 | RFID TXD (hole marked SDA) | SDA/TXD → D27, the ESP32 receives (was the ultrasonic TRIG, free with the IR sensor) | none |
| D12 | RFID RXD (hole marked SCL) | SCL/RXD → D12, the ESP32 sends; VCC → 3V3, GND → GND; BOTH DIP switches OFF (HSU). D12 is safe because this board's flash voltage eFuse is set to 3.3 V | none |
| Power | |||
| 3V3 | 3.3V rail | DHT11, soil moisture, LDR, buzzer, OLED, IR sensor, RFID reader | |
| 5V rail | Breadboard power supply, jumper on 5V | 9V battery clip → its barrel jack; 5V rail → both servos, MQ-5 VCC, PIR VCC | supply module |
| USB | ESP32 power | laptop USB powers the ESP32; do NOT also link VIN to the 5V rail | |
| GND | Common ground | ESP32 GND → breadboard GND rail: the only wire between the two supplies | |
| VIN | Run without the laptop | unplug USB first, then VIN → breadboard 5V rail | |
| Reserved / free | |||
| D14 | Used by the OLED (was for ultrasonic 2, car) | VP is now used by the PIR | |
Device console
Live log from the ESP32 (the same lines it prints on the Serial Monitor), plus what this website does. Everything is also written to the browser console (F12).
Serial Monitor commands (115200 baud, type a letter then Enter)
Gallery
Photos from the hackathon, concept art made with AI (labelled), and the design drawings. Tap any picture to see it full size.
Terms and privacy
Last updated 4 October 2026. By using this website you agree to these terms. If you do not agree, please do not use it.
1. What this is
HNK SafeRoute is a prototype by HNK IoT Solutions (Pty) Ltd, Cape Town. It began as the HNK SafeRoute at Octoco Hack the City 2026 in Stellenbosch. This website shows a working demonstration street node, public weather data and sample data. It is not yet a commercial service, and it is not run or endorsed by any municipality or by Octoco.
2. Not a safety system
Never rely on this website, the device or the AI assistant to decide when it is safe to cross a road or a railway. Always follow the real traffic signals, railway signs and barriers, and look and listen for trains and cars. Readings can be late, missing or wrong.
3. Your location
The live map shows your position only after you press "Share my location", and only while this page is open. Your browser asks for permission first. Other visitors see a dot and a short random name, never your real name. Stop at any time by closing the page or turning off location in your browser.
4. What data is used
- The crossing uses no cameras and stores no names. It counts presses, wait times, trains and sensor readings.
- RFID cards are stored only as a card number on the device, to give a longer walk time. No personal details are linked to them.
- Readings, events and settings you choose (theme, alerts) are kept in your own browser so you can export them as CSV. Clear them at any time with "Clear stored data" or by clearing your browser data.
- Live data travels through HiveMQ Cloud (a message service) to reach this page. Weather comes from Open-Meteo, using the position you choose; it is not stored.
5. AI assistant and RoboFace Live
Questions, photos, camera pictures and the live device readings you send to the AI assistant are sent to Google Gemini to produce an answer, under Google's terms. Do not send photos of other people without their permission, or anything private. Answers can be wrong and are advice only.
6. Email alerts
If alerts are switched on, alert messages about the street node (for example fire, gas or a train blocking the crossing) are sent by Formspree to HNK IoT Solutions. They contain device readings, not visitor data.
7. Your rights (POPIA)
We follow the Protection of Personal Information Act: we collect as little as possible, only for the purpose above, and only with your consent. You may ask what we hold about you, or ask us to delete it, using the contact below.
8. Fair use
The controls and hardware tests are for demonstrations by the team and the judges. Do not send commands to disrupt the device, try to break into the services, or overload them. We may block access that misuses the system.
9. Ownership
The SafeRoute design, code, drawings and brand belong to HNK IoT Solutions (Pty) Ltd. The first prototype was built at Octoco Hack the City 2026 with Nathan, Emmanuel and Joshua. Pictures marked "Concept illustration (AI)" were made with AI tools. Map data © OpenStreetMap contributors. Please ask before reusing our material.
10. No warranty
The website and device are provided "as is" for demonstration, without any warranty. As far as the law allows, HNK IoT Solutions is not liable for any loss or harm from using them.
11. Changes and contact
We may update these terms; the date above shows the latest version. Questions or requests: email henock@hnkiot.com or visit hnkiot.com.
About HNK SafeRoute
Know your route before you go. SafeRoute joins smart street nodes, live weather and an AI assistant, so you do not have to check five apps before you leave home. While you walk, it warns you when you enter a zone with a problem.
Built by Henock Mukonkole, founder of HNK IoT Solutions (Pty) Ltd, Cape Town · henock@hnkiot.com
Before you go
Open SafeRoute in the morning: heat, cold, wind gusts, rain, UV and storms for where you are, plus fire, gas, flooding and trains from the street nodes on your way. The AI turns it into a short spoken brief.
While you walk
Share your location and SafeRoute watches the zones around its street nodes. Walk into a crossing while a train is coming, or near a gas or fire alarm, and your phone warns you with a sound, a vibration and a notification.
The street node
One ESP32 runs traffic robots, a railway gate and a car barrier, an IR train sensor, a PIR tunnel guard, an RFID priority crossing (a longer walk for people who need it), temperature and humidity, gas and smoke, flood and light sensors, an OLED screen and a street lamp. It tests itself after every reset.
The platform
Live dashboard and map, an AI assistant with voice, photos and a talking video call, email alerts and CSV export, all over MQTT (HiveMQ Cloud) on Cloudflare. No cameras and no names: privacy by design (POPIA).
Where it started
SafeRoute began as the HNK SafeRoute at Octoco Hack the City 2026 in Stellenbosch (challenge: Getting Around, moving people across the divide), built with Nathan, Emmanuel and Joshua.
What comes next
- Live traffic on your route
- More street nodes: crossings, tunnels, flood spots
- Camera hazard detection (ESP32-CAM)
- Train speed and arrival warning from two track sensors
- Solar power and LoRaWAN for sites without WiFi
What the crossing does
- Two robots (left and right lane) run red, red + orange, blue, orange in sync.
- A pedestrian button cuts the cars' blue short, and the wait is measured.
- An IR sensor at the track sees the train: bell, red robots, railway gate and car barrier down.
- A registered RFID fob gives people who need more time a longer WALK.
- Road temperature (ice, heat, fire), gas and smoke, and flooding are watched all the time.
- The street light turns on by itself at night.
Three modes
- Normal: the robot cycle with the walk chirp.
- Maintenance: flashing orange; hardware tests allowed.
- Emergency: flashing red and a siren, barrier down, railway gate open so people can leave, street light on.
Hardware
ESP32 (30-pin), 6 LEDs on 3 pins, 2 SG90 servos, IR train sensor, PN532 RFID reader, DHT11, MQ-5, soil moisture probe, LDR, buzzer, 4 push buttons, and a breadboard power supply for the 5 V parts. After every reset the device tests each part for 5 s.
Software and data
Firmware in Arduino C++ on two cores: control on one, WiFi and MQTT on the other. Every 30 s it sends uptime, average wait, road temperature and gas level to the Octoco city mainframe, with an HTTP fallback. Its status is retained, with a last will so the city knows when it goes offline. This website gets the full state over HiveMQ Cloud, with an AI assistant and email alerts.
Why it matters
Every press of the button becomes a data point: where people wait, for how long, and at what time of day. That is the evidence the corridor planners need to place crossings, change timings and make the case for funding.
Cloud broker
| Broker | eeb1e83a06da4b44b7a340bc19cd1e75.s1.eu.hivemq.cloud (HiveMQ Cloud) |
|---|---|
| Device port | 8883 MQTT over TLS |
| Website port | 8884 MQTT over secure WebSocket, path /mqtt |
| State topic | ion4/crossing/state, full JSON every 5 s |
| Command topic | ion4/crossing/cmd, for example {"cmd":"mode","val":"maintenance"}, {"cmd":"test","val":"train_drill"}, {"cmd":"self_test","val":"run"} |
| People topic | ion4/crossing/people, phone positions from the Live map: {"id","name","lat","lng","acc"} |
| Log topic | ion4/crossing/log, one line of text per device event (the Device console page) |
| City mainframe | hack/qsoju/crossing-01/telemetry every 30 s and hack/qsoju/crossing-01/status (retained), on the Octoco broker |