diff --git a/zk/ESP_32.md b/zk/ESP_32.md
new file mode 100644
index 0000000..f17a521
--- /dev/null
+++ b/zk/ESP_32.md
@@ -0,0 +1,24 @@
+---
+tags:
+  - micro-controllers
+---
+
+# ESP32 microcontroller
+
+- Manufactured by Expressif Systems
+
+- An example of a [system on a chip](./System_on_a_chip.md)
+
+- 520 KB RAM
+
+- Flash memory (non-volatile, equivalent to harddrive) of 4-16MB
+
+- WiFi and [bluetooth](./Bluetooth.md) connectivity.
+
+- Programmable using ESP-IDF SDK (C or C++) or MicroPython (but less efficient
+  and you are adding the weight of an interpreter to the flash memory)
+
+For using the ESP32 in different project, you typically use _devboards_, these
+are PCBs with ESP32 and different modules attached. The Heltec V3 (for
+[lora](/zk/LoRa_radio.md) radio communication) is an example of a devboard.
+Different devboards exist for different purposes like sensors etc.
diff --git a/zk/mqtt.md b/zk/mqtt.md
new file mode 100644
index 0000000..128aebf
--- /dev/null
+++ b/zk/mqtt.md
@@ -0,0 +1,41 @@
+---
+tags:
+  - micro-controllers
+---
+
+# MQTT
+
+_Message Queuing Telemetry Transport_
+
+Messaging protocol that runs on top of TCP/IP like HTTP. Particularly well
+suited for IoT devices.
+
+Has publisher/subscriber architecture. Devices publish data to a broker which
+manages topics. Other devices subscribe to those topics. Broker would typically
+run on a server as the central messaging hub.
+
+MQTT handles connection drops gracefully - if an ESP32 temporarily loses Wi-Fi,
+it can queue messages and send them when reconnected. The protocol uses minimal
+bandwidth (just a few bytes of overhead vs HTTP's much larger headers), which
+means lower power consumption on your ESP32s. MQTT also maintains persistent
+connections rather than creating new ones for each data point, reducing network
+overhead and latency.
+
+The main Linux client for setting up an MQTT is `mosquitto`.
+
+There are different **Quality of Service** levels you can use to manage how
+messages are sent and what to do in event of failure:
+
+- _fire and forget_
+- _acknowledged delivery_
+- _acknowledged only once delivery_
+- _retained message_ (broker remembers last message)
+- _last will and testament_ (automatica notification if device disconnects
+  unexpectedly)
+
+## Example use case
+
+As an example, my usecase would be to have several ESP32 micro-controllers in
+different rooms publish humidity data to a small computer that acts as broker.
+This computer will also subcribe to the topics belonging to each room e.g
+`bathroom_sensor`, `bedroom_sensor` and store this data in a database.