entries on esp32 and mqtt
This commit is contained in:
parent
271d9e8470
commit
43a90613e8
2 changed files with 65 additions and 0 deletions
24
zk/ESP_32.md
Normal file
24
zk/ESP_32.md
Normal file
|
|
@ -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.
|
||||
41
zk/mqtt.md
Normal file
41
zk/mqtt.md
Normal file
|
|
@ -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.
|
||||
Loading…
Add table
Reference in a new issue