ESP32 Telegram Bot

By the end of this project, you will:

• Use an existing chat app as your device's user interface: no page to design, nothing to install on the phone.
• Understand why polling an outside service reaches your board on networks where hosting a web server never would.
• Parse a text command and dispatch to the right action.
• Send a message the other way, unprompted, when a sensor event happens: a push notification from your own hardware.
• Meet HTTPS on a microcontroller, and see what a root certificate is for.
• Compare three control models: local web server (Projects 5 to 9), cloud dashboard (Project 11), and chat (this one).

Telegram runs a bot API over HTTPS. The ESP32 asks Telegram "any new messages?" once a second and acts on them, and it can also send you a message when something happens (motion).

Because it is just outbound HTTPS, this reaches your phone even on networks where a self-hosted web server would not.

1. In Telegram, chat with @BotFather and send /newbot.
2. Pick a name and a username ending in bot. Copy the HTTP API token.
3. Optional: open @userinfobot to get your numeric chat id for motion alerts.

Install: UniversalTelegramBot (Brian Lough), ArduinoJson (v6+), DHT sensor library, Adafruit Unified Sensor.

Edit the marked block: WIFI_SSID, WIFI_PASS, BOT_TOKEN, and optionally CHAT_ID. Upload, open Serial Monitor at 115200, then send /start to your bot in Telegram.

==============================================
 Project 12: ESP32 Telegram Bot
==============================================
Connecting to Wi-Fi: MyNetwork
....
Wi-Fi connected!
Bot ready. Open Telegram and send /start to your bot.

More moving parts than anything before it, but each one is something you have already met.

Step 1: A secure client, and a bot that rides on it

#include <WiFiClientSecure.h>
#include <UniversalTelegramBot.h>
#include <ArduinoJson.h>

WiFiClientSecure secured_client;
UniversalTelegramBot bot(BOT_TOKEN, secured_client);

Two objects, stacked. WiFiClientSecure is a TCP connection with TLS on top: the https:// part. UniversalTelegramBot sits above it and knows Telegram's API, turning sendMessage() into the right HTTPS request. ArduinoJson is underneath both, decoding the replies, which is why the library needs it even though your code never mentions it.

Step 2: Trusting Telegram, in setup()

secured_client.setCACert(TELEGRAM_CERTIFICATE_ROOT);

HTTPS is only useful if the client can tell the real server from an impostor, and that check works by trusting a root certificate. Your laptop ships with hundreds. An ESP32 ships with none, so the library bundles the one Telegram's certificate chains up to and this line installs it. Skip it and every request fails to connect, even with a perfect token.

Step 3: handleNewMessages() reads the text and dispatches

for (int i = 0; i < numNewMessages; i++) {
  String chat_id = bot.messages[i].chat_id;
  String text    = bot.messages[i].text;
  String from    = bot.messages[i].from_name;

  if (text == "/light_on") {
    digitalWrite(LED_PIN, HIGH);
    bot.sendMessage(chat_id, "Light is ON", "");
  }
  ...
  else {
    bot.sendMessage(chat_id, "Unknown command. Send /help.", "");
  }
}

Several messages can be waiting, so the function takes a count and loops. Each message carries who sent it (from_name), what they typed (text), and which conversation it came from (chat_id). Replying to chat_id rather than a fixed id is what lets one bot serve several people at once.

The chain of if/else if is a command dispatcher, the same job the URL parsing did in Project 5. The final else matters: a bot that ignores what it does not understand feels broken, while one that says "send /help" teaches its own interface.

/status reads the sensor at the moment you ask, with the same isnan() guard as Project 9, and builds the reply with String(t, 1) so 24.63 prints as 24.6.

Step 4: loop() pushes on motion, then polls for commands

bool motion = digitalRead(PIR_PIN);
if (motion && !lastMotion && String(CHAT_ID).length() > 0) {
  bot.sendMessage(CHAT_ID, "Motion detected!", "");
  Serial.println("[PIR] motion -> alert sent");
}
lastMotion = motion;

if (millis() - lastBotCheck > BOT_CHECK_INTERVAL) {
  int numNewMessages = bot.getUpdates(bot.last_message_received + 1);
  while (numNewMessages) {
    handleNewMessages(numNewMessages);
    numNewMessages = bot.getUpdates(bot.last_message_received + 1);
  }
  lastBotCheck = millis();
}

motion && !lastMotion is Project 4's edge detection, doing real work here: without it, standing in front of the sensor would send a message every few milliseconds until Telegram rate-limited the bot.

The second half is polling. getUpdates(last_message_received + 1) asks "anything newer than the last one I saw?", and the + 1 is what stops the board replying to the same message forever. The inner while drains the queue, since a burst may not arrive in one response.

Note who does the asking: the ESP32 always opens the connection outwards, which is exactly why this works behind a router that would never let an incoming request through.

Key concepts: what each line really does

You have built a device with a user interface you did not have to design, reachable from any network in the world. The key takeaways:

• The best UI is often one people already have. No app to install, no page to style, no instructions beyond /help.
• Outbound polling beats inbound hosting. Your board opens the connection, so home routers, campus Wi-Fi, and mobile networks all work. A web server reaches only the local network.
• The + 1 is the whole trick. Asking for updates newer than the last one handled is how a polling client avoids replaying its own history.
• Both directions matter. Replies are pull, motion alerts are push, and a device that can interrupt you is qualitatively more useful than one you have to check.
• Edge detection is not optional once a message costs something.
• HTTPS needs someone to trust. A microcontroller has no certificate store, so you install the root certificate yourself.
• Compare the three models you have now built: a local page (fast, private, same network only), a cloud dashboard (history and charts, needs an account), and a chat bot (instant, personal, no history).

• Add a command that returns more sensors: light from an LDR, the current motion state.
• Combine this with the Ubidots dashboard from Project 11: dashboard for history, Telegram for quick checks and alerts. Both patterns feed the capstone.