ESP32 IoT presentation @ dev.bg

Mission possible:
DIY smart home
hub/controller
Martin Harizanov
Sofia, February 5th 2019

Agenda
● Agenda
● About me
● Goals
● Mission possible: DIY smart home
hub/controller
● Q/A

About
Martin Harizanov
Supervisor, Systems Engineering
Visteon

What problem does this project solve?
Gateway ActuatorsSensors
Cloud
Phone app
Control hub
● Home automation control without
internet connection
● Shared controls access
● Cost reduction by having control hubs
and ‘dumb’ sensors/actuators

Requirements
● Control hub that integrates with the existing home automation
● Works regardless of the internet connectivity
● Visual and acoustic feedback
● Easy to use
● Reliable
● Low cost

Analysis steps
Customer Requirements
System Architecture
System Requirements HW
architecture
SW
architecture
Software Design
Requirements
Software functional
requirements
Mechanical
Hardware
Requirements
Mechanical
Requirements

Non-Functional requirements
Architecture Hardware Software Mechanics Design/UX
Localization, easy initial
setup, wireless
Color TFT with touch,
dimming, ambient light
sensing; buttons
Precise touch
detection/calibration
Option to hang on wall,
magnetic attachment,
compact size
Graphical HMI with
touch, buttons;
Antialiased fonts;
Usability
Ease with which the user is able to learn, operate, prepare inputs and interpret outputs through
interaction with the system
Multi-language
Localization
(TZ, units)SmartConfig
AP web config
WiFi config GUI Touch
calibration GUI
Touch
calibration in
flash
GUI library
Configurable
“skins”

Watchdog, OTA
recovery, safe mode,
degraded operation
mode, crash recovery,
task
isolation/prioritization
Thermal, EMI
consideration
Power management Durable moving parts
Reliability
Extent to which the system consistently performs the specified functions without failure

TLS, RF encryption,
mutual authentication,
provisioning, access
PIN
Encryption chip Authentication on APIs,
DDoS rate limiter,
encrypted vFS, NVS
Reflashing port not
available without
product disassembly
Security
Extent to which the system is safeguarded against deliberate and intrusive faults from internal and
external sources

Connections manager,
operational state
manager , fallback to
backup connection.
Revert to factory app
HW RTC to ensure time
availability regardless
of network availability,
RF control as
alternative to WiFi
Degraded (fail safe)
mode
Availability
Degree to which users can depend on the system to be up and able to function during normal operating
times

Piezo buzzer for
acoustic feedback.
RGB LED for visual
feedback
Buttons easily
pressable
Large contrast icons,
color selection,
acoustic feedback,
visual feedback from
distance, lighting
sensing and brightness
adjustment
Accessibility
Extent to which the system can be used by people with the widest range of capabilities

..and more requirements
Non-functional
● Integrity
● Safety
● Environmental
● Flexibility
● Scalability
● Maintainability
● Performance
● Storage
● Regulatory
● .. and more
Functional
● Time & Date
● Temperature, Humidity, ambient light
● Configuration
● Connectivity management
● Diagnostics
● Security functions
● Power management
● Input devices
.. and more functional requirements
● Acoustic feedback
● Multi-language
● RF comms
● OTA
● Charts
● Thermostat
● HMI
● API

What is HMI?
Sensory stimuli
Visual/acoustic/
vibration etc
Controls
Responses (motor,
acoustic)
Machine
State
Human
Information
processing and
decision making
Human MachineInterface

System functions diagram
OTA
GUI
security
env. sensing
power
diagnostics
clock/date
communication
protocols
communications
operating state data storage
visual feedback
audio
display
in-dev
illumination
Internal data
localization
application logic

System function allocation diagram

SWCs design
SW time & date
manager
Enabled, TZ, DST, TimeFormat
rtc_datetime
ntp_datetime
api_datetime
● Signals include STATE e.g. VALID, ERR,
TMO, SNA
● SWC has cycle time, this particular runs every
1000ms
set_TZ
set_DST
set_TimeFormat
timestamp
hour
minute
second
day
DOW
month
year
DST
TZ
timeFormat
ampmFlag

Layered Architecture
IO Peripherals Memories CoresWiFi basebandBT Baseband
FreeRTOS
Drivers Bootloader
Middleware
Application
Communication Protocol StacksGUISW
HW

Fact break
78,337 lines of code as of todayThis project has

Partitions
● Flash layout
○ NVS for factory and user apps
○ Factory + user apps
○ VFS (SPIFFS, FAT etc)
App NVS
Factory NVS
Factory App
User App 1
User App 2
VFS
Bootloader

User Application
Operational states
Fail safe
Init
Normal
Configuration
OTA
Power-save
Degraded
mode
Factory
app

Power management strategies
● Dynamic Frequency Shifting
● Modem light sleep
● Variable WiFi transmission power
● Screen dimming
● GUI refresh rate reducing
● Peripheral sleep mode, whenever possible
● Overall: interrupt driven functionality vs polling
As a result: power consumption is ~60mA while
maintaining WiFi connection and being fully operational

OTA strategies
● OTA over web portal
● OTA over HTTPs
● OTA over MQTTs
● Compressed image OTA
● OTA rollback
○ Image verification
○ Tracking restarts due to crash
● Queued OTA
● OTA resume

DMA SPI and double buffering to speed up GUI rendering
DMA SPI VB2
VB1 VB2 VB1
DMA SPI VB1 DMA SPI VB2
VB
2
DMA SPI VB1
VB1
30ms 30ms
SPI HW
CPU
30ms

Integrated Development Framework choice
● ESP-IDF using FreeRTOS
● Eclipse
● Github private repository

Fact break
7 months to developThis project took

Physical architecture
UController
TFT
ILI9341
Buttons
RF comms
RFM69
RGB LED
WS2812b
Temperature/
Humidity
HTU21D
Light sensor
LDR
FTDI
programming
interface
RTC
DS1338
Piezo Buzzer
WiFiBLE
1 PWM
1 RMT
SPI1 + CS + D/C
+ RST
1 UART
1 I2C
1 ADC
1 SPI2 + CS
2 GPIO+2 GPIO with ADC and
IRQ
Touch
4-wire resistive
4 GPIO
HW encryption
module
ATSHA204
Flash
Screen
dimming
1 PWM
● GPIO 10 total (2 for touch + 3 for
TFT CS, D/C and RST + 4 buttons +1
for RF CS)
● PWM 2 total (1 for piezo, 1 for screen
dimming)
● RMT 1 total (1 for LED)
● SPI 2 SPI interfaces or 5 pins (1 for
TFT CLK, MOSI only and 1 for RF
CLS, MOSI, MISO)
● I2C 1 total or 2 pins
● ADC 3 total (1 for LDR and 2 for
touch screen)
● UART - 1 total or 2 pins (RX/TX)
~23 GPIO pins needed

SoC choice
● ESP32 is dual core containing a Protocol CPU (known
as CPU 0 or PRO_CPU) and an Application CPU
(known as CPU 1 or APP_CPU). The two cores are
identical in practice and share the same memory. This
allows the two cores to run tasks interchangeably
between them.

Final version … after six PCB revisions

Mechanics - 3D PCB model for enclosure design

Mechanics - 3D printable enclosure

HMI Use cases
Setup
WiFi
Calibrate
Touch
Dimming
setup
About
Time/date
settings
Units
setup
Language
select
OTA
Thermost
at
Provisioni
ng
Reset to
Factory
View
charts
Thermost
at
schedule
Sound
setup
Clock
Pairing

Menu structure
Settings
WiFi
Manual
Smartconfig
Web portal
Display
Brightness
Screensaver
Wifi
On/Off
Calibration
*Manual
*Auto
Localization
Language
Time & date
Units
Sound
About
FW update
LED
Charts
Thermost
at
Clock
Schedule
More
settings
RF Pairing
Reset

Menu design
Main menu
Item Item Item
Item Item Settings
Sub-menu
Back Item Item
Item ItemItem

Menu design
App
Back Next
Thermostat
Back
21.5*C
Manual
Boost
18.2*C
Off
Schedule

Menu design
WiFi settings
Back Next
List of networks
Select network
WiFi settings
Back Next
**********
Enter password
QWERTY keyboard

Challenges
● Driver conversion to FreeRTOS
● Temperature skew
● Enclosure design
● DMA, double video buffers
● Overall R&D process, as this is my first project using ESP32

Future plans
● Larger 3.5” TFT
● LoRa support
● No buttons, thin frame
● More powerful ESP32 package
with PSRAM support
● Improved firmware functions

ESP32 IoT presentation @ dev.bg

Recommended

More Related Content

What's hot (20)

Similar to ESP32 IoT presentation @ dev.bg (20)

Recently uploaded (20)

ESP32 IoT presentation @ dev.bg

Editor's Notes