Fork of the excellent esp8266-react - https://github.com/rjwats/esp8266-react
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

604 lines
24 KiB

6 years ago
6 years ago
6 years ago
6 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
6 years ago
5 years ago
6 years ago
6 years ago
6 years ago
6 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
  1. # ESP8266 React
  2. [![Build Status](https://travis-ci.org/rjwats/esp8266-react.svg?branch=master)](https://travis-ci.org/rjwats/esp8266-react)
  3. A simple, secure and extensible framework for IoT projects built on ESP8266/ESP32 platforms with responsive React front-end.
  4. Designed to work with the PlatformIO IDE with [limited setup](#getting-started). Please read below for setup, build and upload instructions.
  5. ![Screenshots](/media/screenshots.png?raw=true "Screenshots")
  6. ## Features
  7. Provides many of the features required for IoT projects:
  8. * Configurable WiFi - Network scanner and WiFi configuration screen
  9. * Configurable Access Point - Can be continuous or automatically enabled when WiFi connection fails
  10. * Network Time - Synchronization with NTP
  11. * MQTT - Connection to an MQTT broker for automation and monitoring
  12. * Remote Firmware Updates - Enable secured OTA updates
  13. * Security - Protected RESTful endpoints and a secured user interface
  14. The back end is provided by a set of RESTful endpoints and the responsive React based front end is built using [Material-UI](https://material-ui.com/).
  15. The front end has the prerequisite manifest file and icon, so it can be added to the home screen of a mobile device if required.
  16. ## Getting Started
  17. ### Prerequisites
  18. You will need the following before you can get started.
  19. * [PlatformIO](https://platformio.org/) - IDE for development
  20. * [Node.js](https://nodejs.org) - For building the interface with npm
  21. ### Building and uploading the firmware
  22. Pull the project and open it in PlatformIO. PlatformIO should download the ESP8266 platform and the project library dependencies automatically.
  23. The project structure is as follows:
  24. Resource | Description
  25. -------------------------------- | ----------------------------------------------------------------------
  26. [data/](data) | The file system image directory
  27. [interface/](interface) | React based front end
  28. [lib/framework/](lib/framework) | C++ back end for the ESP8266/ESP32 device
  29. [src/](src) | The main.cpp and demo project to get you started
  30. [scripts/](scripts) | Scripts that build the React interface as part of the platformio build
  31. [platformio.ini](platformio.ini) | PlatformIO project configuration file
  32. ### Building the firmware
  33. Once the platform and libraries are downloaded the back end should successfully build within PlatformIO.
  34. The firmware may be built by pressing the "Build" button:
  35. ![build](/media/build.png?raw=true "build")
  36. Alternatively type the run command:
  37. ```bash
  38. platformio run
  39. ```
  40. #### Uploading the firmware
  41. The project is configured to upload over a serial connection by default. You can change this to use OTA updates by uncommenting the relevant lines in ['platformio.ini'](platformio.ini).
  42. The firmware may be uploaded to the device by pressing the "Upload" button:
  43. ![uploadfw](/media/uploadfw.png?raw=true "uploadfw")
  44. Alternatively run the 'upload' target:
  45. ```bash
  46. platformio run -t upload
  47. ```
  48. ### Building & uploading the interface
  49. The interface has been configured with create-react-app and react-app-rewired so the build can customized for the target device. The large artefacts are gzipped and source maps and service worker are excluded from the production build. This reduces the production build to around ~150k, which easily fits on the device.
  50. The interface will be automatically built by PlatformIO before it builds the firmware. The project can be configured to serve the interface from either PROGMEM or SPIFFS as your project requires. The default configuration is to serve the content from PROGMEM, serving from SPIFFS requires an additional upload step which is documented below.
  51. #### Serving the interface from PROGMEM
  52. By default, the project is configured to serve the interface from PROGMEM. This can be disabled by removing the -D PROGMEM_WWW build flag in ['platformio.ini'](platformio.ini) and re-building the firmware. If this your desired approach you must manually [upload the file system image](#uploading-the-file-system-image) to the device.
  53. The interface will consume ~150k of program space which can be problematic if you already have a large binary artefact or if you have added large dependencies to the interface. The ESP32 binaries are fairly large in there simplest form so the addition of the interface resources requires us to use special partitioning for the ESP32.
  54. When building using the "node32s" profile, the project uses the custom [min_spiffs.csv](https://github.com/espressif/arduino-esp32/blob/master/tools/partitions/min_spiffs.csv) partitioning mode. You may want to disable this if you are manually uploading the file system image:
  55. ```yaml
  56. [env:node32s]
  57. board_build.partitions = min_spiffs.csv
  58. platform = espressif32
  59. board = node32s
  60. ```
  61. #### Uploading the file system image
  62. If service content from SPIFFS, disable the PROGMEM_WWW build flag and build the project. The compiled interface will be copied to [data/](data) by the build process and may now be uploaded to the device by pressing the "Upload File System image" button:
  63. ![uploadfs](/media/uploadfs.png?raw=true "uploadfs")
  64. Alternatively run the 'uploadfs' target:
  65. ```bash
  66. platformio run -t uploadfs
  67. ```
  68. ### Running the interface locally
  69. You can run a development server locally to allow you preview changes to the front end without the need to upload a file system image to the device after each change.
  70. Change to the ['interface'](interface) directory with your bash shell (or Git Bash) and use the standard commands you would with any react app built with create-react-app:
  71. ```bash
  72. cd interface
  73. ```
  74. Install the npm dependencies, if required and start the development server:
  75. ```bash
  76. npm install
  77. npm start
  78. ```
  79. > **Tip**: You can (optionally) speed up the build by commenting out the call to build_interface.py under "extra scripts" during local development. This will prevent the npm process from building the production release every time the firmware is compiled significantly decreasing the build time.
  80. #### Changing the endpoint root
  81. The interface has a development environment which is enabled when running the development server using `npm start`. The environment file can be found in ['interface/.env.development'](interface/.env.development) and contains the HTTP root URL and the WebSocket root URL:
  82. ```properties
  83. REACT_APP_HTTP_ROOT=http://192.168.0.99
  84. REACT_APP_WEB_SOCKET_ROOT=ws://192.168.0.99
  85. ```
  86. The `REACT_APP_HTTP_ROOT` and `REACT_APP_WEB_SOCKET_ROOT` properties can be modified to point a ESP device running the back end firmware.
  87. > **Tip**: You must restart the development server for changes to the environment file to come into effect.
  88. #### Enabling CORS
  89. You can enable CORS on the back end by uncommenting the -D ENABLE_CORS build flag in ['platformio.ini'](platformio.ini) then re-building and uploading the firmware to the device. The default settings assume you will be accessing the development server on the default port on [http://localhost:3000](http://localhost:3000) this can also be changed if required:
  90. ```properties
  91. -D ENABLE_CORS
  92. -D CORS_ORIGIN=\"http://localhost:3000\"
  93. ```
  94. ## Factory settings
  95. The firmware has built-in factory settings which act as default values for the various configurable services where settings are not saved on the file system. These settings can be overridden using the build flags defined in [factory_settings.ini](factory_settings.ini).
  96. Customize the settings as you see fit, for example you might configure your home WiFi network as the factory default:
  97. ```ini
  98. -D FACTORY_WIFI_SSID=\"My Awesome WiFi Network\"
  99. -D FACTORY_WIFI_PASSWORD=\"secret\"
  100. -D FACTORY_WIFI_HOSTNAME=\"awesome_light_controller\"
  101. ```
  102. ### Default access point settings
  103. By default, the factory settings configure the device to bring up an access point on start up which can be used to configure the device:
  104. * SSID: ESP8266-React
  105. * Password: esp-react
  106. ### Security settings and user credentials
  107. By default, the factory settings configure two user accounts with the following credentials:
  108. Username | Password
  109. -------- | --------
  110. admin | admin
  111. guest | guest
  112. It is recommended that you change the user credentials from their defaults better protect your device. You can do this in the user interface, or by modifying [factory_settings.ini](factory_settings.ini) as mentioned above.
  113. ### Customizing the factory time zone setting
  114. Changing factory time zone setting is a common requirement. This requires a little effort because the time zone name and POSIX format are stored as separate values for the moment. The time zone names and POSIX formats are contained in the UI code in [TZ.ts](interface/src/ntp/TZ.ts). Take the appropriate pair of values from there, for example, for Los Angeles you would use:
  115. ```ini
  116. -D FACTORY_NTP_TIME_ZONE_LABEL=\"America/Los_Angeles\"
  117. -D FACTORY_NTP_TIME_ZONE_FORMAT=\"PST8PDT,M3.2.0,M11.1.0\"
  118. ```
  119. ### Device ID factory defaults
  120. If not overridden with a build flag, the firmware will use the device ID to generate factory defaults for settings such as the JWT secret and MQTT client ID.
  121. > **Tip**: Random values are generally better defaults for these settings, so it is recommended you leave these flags undefined.
  122. ## Building for different devices
  123. This project supports ESP8266 and ESP32 platforms. To support OTA programming, enough free space to upload the new sketch and file system image will be required. It is recommended that a board with at least 2mb of flash is used.
  124. The pre-configured environments are "esp12e" and "node32s". These are common ESP8266/ESP32 variants with 4mb of flash:
  125. ![ESP12E](/media/esp12e.jpg?raw=true "ESP12E") ![ESP32](/media/esp32.jpg?raw=true "ESP32")
  126. The settings file ['platformio.ini'](platformio.ini) configures the supported environments. Modify these, or add new environments for the devides you need to support. The default environments are as follows:
  127. ```yaml
  128. [env:esp12e]
  129. platform = espressif8266
  130. board = esp12e
  131. board_build.f_cpu = 160000000L
  132. [env:node32s]
  133. platform = espressif32
  134. board = node32s
  135. ```
  136. If you want to build for a different device, all you need to do is re-configure ['platformio.ini'](platformio.ini) and select an alternative environment by modifying the default_envs variable. Building for the common esp32 "node32s" board for example:
  137. ```yaml
  138. [platformio]
  139. ;default_envs = esp12e
  140. default_envs = node32s
  141. ```
  142. ## Customizing and theming
  143. The framework, and MaterialUI allows for a reasonable degree of customization with little effort.
  144. ### Theming the app
  145. The app can be easily themed by editing the [MaterialUI theme](https://material-ui.com/customization/theming/). Edit the theme in ['interface/src/CustomMuiTheme.tsx'](interface/src/CustomMuiTheme.tsx) as you desire. For example, here is a dark theme:
  146. ```js
  147. const theme = createMuiTheme({
  148. palette: {
  149. type:"dark",
  150. primary: {
  151. main: '#222',
  152. },
  153. secondary: {
  154. main: '#666',
  155. },
  156. info: {
  157. main: blueGrey[900]
  158. },
  159. warning: {
  160. main: orange[500]
  161. },
  162. error: {
  163. main: red[500]
  164. },
  165. success: {
  166. main: green[500]
  167. }
  168. }
  169. });
  170. ```
  171. ![Dark Theme](/media/dark.png?raw=true "Dark Theme")
  172. ### Changing the app icon
  173. You can replace the app icon is located at ['interface/public/app/icon.png'](interface/public/app/icon.png) with one of your preference. A 256 x 256 PNG is recommended for best compatibility.
  174. ### Changing the app name
  175. The app name displayed on the login page and on the menu bar can be modified by editing the REACT_APP_NAME property in ['interface/.env'](interface/.env)
  176. ```properties
  177. REACT_APP_NAME=Funky IoT Project
  178. ```
  179. There is also a manifest file which contains the app name to use when adding the app to a mobile device, so you may wish to also edit ['interface/public/app/manifest.json'](interface/public/app/manifest.json):
  180. ```json
  181. {
  182. "name":"Funky IoT Project",
  183. "icons":[
  184. {
  185. "src":"/app/icon.png",
  186. "sizes":"48x48 72x72 96x96 128x128 256x256"
  187. }
  188. ],
  189. "start_url":"/",
  190. "display":"fullscreen",
  191. "orientation":"any"
  192. }
  193. ```
  194. ## Back end
  195. The back end is a set of REST endpoints hosted by a [ESPAsyncWebServer](https://github.com/me-no-dev/ESPAsyncWebServer) instance. The ['lib/framework'](lib/framework) directory contains the majority of the back end code. The framework contains of a number of useful utility classes which you can use when extending it. The project also comes with a demo project to give you some help getting started.
  196. The framework's source is split up by feature, for example [WiFiScanner.h](lib/framework/WiFiScanner.h) implements the end points for scanning for available networks where as [WiFiSettingsService.h](lib/framework/WiFiSettingsService.h) handles configuring the WiFi settings and managing the WiFi connection.
  197. ### Initializing the framework
  198. The ['src/main.cpp'](src/main.cpp) file constructs the webserver and initializes the framework. You can add endpoints to the server here to support your IoT project. The main loop is also accessable so you can run your own code easily.
  199. The following code creates the web server and esp8266React framework:
  200. ```cpp
  201. AsyncWebServer server(80);
  202. ESP8266React esp8266React(&server, &SPIFFS);
  203. ```
  204. Now in the `setup()` function the initialization is performed:
  205. ```cpp
  206. void setup() {
  207. // start serial and filesystem
  208. Serial.begin(SERIAL_BAUD_RATE);
  209. // start the file system (must be done before starting the framework)
  210. #ifdef ESP32
  211. SPIFFS.begin(true);
  212. #elif defined(ESP8266)
  213. SPIFFS.begin();
  214. #endif
  215. // start the framework and demo project
  216. esp8266React.begin();
  217. // start the server
  218. server.begin();
  219. }
  220. ```
  221. Finally the loop calls the framework's loop function to service the frameworks features.
  222. ```cpp
  223. void loop() {
  224. // run the framework's loop function
  225. esp8266React.loop();
  226. }
  227. ```
  228. ### Developing with the framework
  229. The framework promotes a modular design and exposes features you may re-use to speed up the development of your project. Where possible it is recommended that you use the features the frameworks supplies. These are documented in this section and a comprehensive example is provided by the demo project.
  230. The following diagram visualises how the framework's modular components fit together, each feature is described in detail below.
  231. ![framework diagram](/media/framework.png?raw=true "framework diagram")
  232. #### Stateful service
  233. The [StatefulService.h](lib/framework/StatefulService.h) class is a responsible for managing state and interfacing with code which wants to change or respond to changes in that state. You can define a data class to hold some state, then build a StatefulService class to manage its state:
  234. ```cpp
  235. class LightState {
  236. public:
  237. bool on = false;
  238. uint8_t brightness = 255;
  239. };
  240. class LightStateService : public StatefulService<LightState> {
  241. };
  242. ```
  243. You may listen for changes to state by registering an update handler callback. It is possible to remove an update handler later if required.
  244. ```cpp
  245. // register an update handler
  246. update_handler_id_t myUpdateHandler = lightStateService.addUpdateHandler(
  247. [&](String originId) {
  248. Serial.println("The light's state has been updated");
  249. }
  250. );
  251. // remove the update handler
  252. lightStateService.removeUpdateHandler(myUpdateHandler);
  253. ```
  254. An "originId" is passed to the update handler which may be used to identify the origin of the update. The default origin values the framework provides are:
  255. Origin | Description
  256. --------------------- | -----------
  257. http | An update sent over REST (HttpEndpoint)
  258. mqtt | An update sent over MQTT (MqttPubSub)
  259. websocket:{clientId} | An update sent over WebSocket (WebSocketRxTx)
  260. StatefulService exposes a read function which you may use to safely read the state. This function takes care of protecting against parallel access to the state in multi-core enviornments such as the ESP32.
  261. ```cpp
  262. lightStateService.read([&](LightState& state) {
  263. digitalWrite(LED_PIN, state.on ? HIGH : LOW); // apply the state update to the LED_PIN
  264. });
  265. ```
  266. StatefulService also exposes an update function which allows the caller to update the state with a callback. This approach automatically calls the registered update handlers when complete. The example below turns on the lights using the arbitrary origin "timer":
  267. ```cpp
  268. lightStateService.update([&](LightState& state) {
  269. state.on = true; // turn on the lights!
  270. }, "timer");
  271. ```
  272. #### Serialization
  273. When transmitting state over HTTP, WebSockets, or MQTT it must to be marshalled into a serializable form (JSON). The framework uses ArduinoJson for serialization and the functions defined in [JsonSerializer.h](lib/framework/JsonSerializer.h) and [JsonDeserializer.h](lib/framework/JsonDeserializer.h) facilitate this.
  274. The static functions below can be used to facilitate the serialization/deserialization of the light state:
  275. ```cpp
  276. class LightState {
  277. public:
  278. bool on = false;
  279. uint8_t brightness = 255;
  280. static void serialize(LightState& state, JsonObject& root) {
  281. root["on"] = state.on;
  282. root["brightness"] = state.brightness;
  283. }
  284. static void deserialize(JsonObject& root, LightState& state) {
  285. state.on = root["on"] | false;
  286. state.brightness = root["brightness"] | 255;
  287. }
  288. };
  289. ```
  290. For convenience, the StatefulService class provides overloads of its `update` and `read` functions which utilize these functions.
  291. Copy the state to a JsonObject using a serializer:
  292. ```cpp
  293. JsonObject jsonObject = jsonDocument.to<JsonObject>();
  294. lightStateService->read(jsonObject, serializer);
  295. ```
  296. Update the state from a JsonObject using a deserializer:
  297. ```cpp
  298. JsonObject jsonObject = jsonDocument.as<JsonObject>();
  299. lightStateService->update(jsonObject, deserializer, "timer");
  300. ```
  301. #### Endpoints
  302. The framework provides an [HttpEndpoint.h](lib/framework/HttpEndpoint.h) class which may be used to register GET and POST handlers to read and update the state over HTTP. You may construct an HttpEndpoint as a part of the StatefulService or separately if you prefer.
  303. The code below demonstrates how to extend the LightStateService class to provide an unsecured endpoint:
  304. ```cpp
  305. class LightStateService : public StatefulService<LightState> {
  306. public:
  307. LightStateService(AsyncWebServer* server) :
  308. _httpEndpoint(LightState::serialize, LightState::deserialize, this, server, "/rest/lightState") {
  309. }
  310. private:
  311. HttpEndpoint<LightState> _httpEndpoint;
  312. };
  313. ```
  314. Endpoint security is provided by authentication predicates which are [documented below](#security-features). The SecurityManager and authentication predicate may be provided if a secure endpoint is required. The demo project shows how endpoints can be secured.
  315. #### Persistence
  316. [FSPersistence.h](lib/framework/FSPersistence.h) allows you to save state to the filesystem. FSPersistence automatically writes changes to the file system when state is updated. This feature can be disabled by calling `disableUpdateHandler()` if manual control of persistence is required.
  317. The code below demonstrates how to extend the LightStateService class to provide persistence:
  318. ```cpp
  319. class LightStateService : public StatefulService<LightState> {
  320. public:
  321. LightStateService(FS* fs) :
  322. _fsPersistence(LightState::serialize, LightState::deserialize, this, fs, "/config/lightState.json") {
  323. }
  324. private:
  325. FSPersistence<LightState> _fsPersistence;
  326. };
  327. ```
  328. #### WebSockets
  329. [WebSocketTxRx.h](lib/framework/WebSocketTxRx.h) allows you to read and update state over a WebSocket connection. WebSocketTxRx automatically pushes changes to all connected clients when state is updated.
  330. The code below demonstrates how to extend the LightStateService class to provide an unsecured WebSocket:
  331. ```cpp
  332. class LightStateService : public StatefulService<LightState> {
  333. public:
  334. LightStateService(AsyncWebServer* server) :
  335. _webSocket(LightState::serialize, LightState::deserialize, this, server, "/ws/lightState"), {
  336. }
  337. private:
  338. WebSocketTxRx<LightState> _webSocket;
  339. };
  340. ```
  341. WebSocket security is provided by authentication predicates which are [documented below](#security-features). The SecurityManager and authentication predicate may be provided if a secure WebSocket is required. The demo project shows how WebSockets can be secured.
  342. #### MQTT
  343. The framework includes an MQTT client which can be configured via the UI. MQTT requirements will differ from project to project so the framework exposes the client for you to use as you see fit. The framework does however provide a utility to interface StatefulService to a pair of pub/sub (state/set) topics. This utility can be used to synchronize state with software such as Home Assistant.
  344. [MqttPubSub.h](lib/framework/MqttPubSub.h) allows you to publish and subscribe to synchronize state over a pair of MQTT topics. MqttPubSub automatically pushes changes to the "pub" topic and reads updates from the "sub" topic.
  345. The code below demonstrates how to extend the LightStateService class to interface with MQTT:
  346. ```cpp
  347. class LightStateService : public StatefulService<LightState> {
  348. public:
  349. LightStateService(AsyncMqttClient* mqttClient) :
  350. _mqttPubSub(LightState::serialize,
  351. LightState::deserialize,
  352. this,
  353. mqttClient,
  354. "homeassistant/light/my_light/set",
  355. "homeassistant/light/my_light/state") {
  356. }
  357. private:
  358. MqttPubSub<LightState> _mqttPubSub;
  359. };
  360. ```
  361. You can re-configure the pub/sub topics at runtime as required:
  362. ```cpp
  363. _mqttPubSub.configureBroker("homeassistant/light/desk_lamp/set", "homeassistant/light/desk_lamp/state");
  364. ```
  365. The demo project allows the user to modify the MQTT topics via the UI so they can be changed without re-flashing the firmware.
  366. ### Security features
  367. The framework has security features to prevent unauthorized use of the device. This is driven by [SecurityManager.h](lib/framework/SecurityManager.h).
  368. On successful authentication, the /rest/signIn endpoint issues a [JSON Web Token (JWT)](https://jwt.io/) which is then sent using Bearer Authentication. The framework come with built-in predicates for verifying a users access privileges. The built in AuthenticationPredicates can be found in [SecurityManager.h](lib/framework/SecurityManager.h) and are as follows:
  369. Predicate | Description
  370. -------------------- | -----------
  371. NONE_REQUIRED | No authentication is required.
  372. IS_AUTHENTICATED | Any authenticated principal is permitted.
  373. IS_ADMIN | The authenticated principal must be an admin.
  374. You can use the security manager to wrap any request handler function with an authentication predicate:
  375. ```cpp
  376. server->on("/rest/someService", HTTP_GET,
  377. _securityManager->wrapRequest(std::bind(&SomeService::someService, this, std::placeholders::_1), AuthenticationPredicates::IS_AUTHENTICATED)
  378. );
  379. ```
  380. ### Accessing settings and services
  381. The framework supplies access to various features via getter functions:
  382. SettingsService | Description
  383. ---------------------------- | ----------------------------------------------
  384. getSecurityManager() | The security manager - detailed above
  385. getSecuritySettingsService() | Configures the users and other security settings
  386. getWiFiSettingsService() | Configures and manages the WiFi network connection
  387. getAPSettingsService() | Configures and manages the Access Point
  388. getNTPSettingsService() | Configures and manages the network time
  389. getOTASettingsService() | Configures and manages the Over-The-Air update feature
  390. getMqttSettingsService() | Configures and manages the MQTT connection
  391. getMqttClient() | Provides direct access to the MQTT client instance
  392. The core features use the [StatefulService.h](lib/framework/StatefulService.h) class and can therefore you can change settings or observe changes to settings through the read/update API.
  393. Inspect the current WiFi settings:
  394. ```cpp
  395. esp8266React.getWiFiSettingsService()->read([&](WiFiSettings& wifiSettings) {
  396. Serial.print("The ssid is:");
  397. Serial.println(wifiSettings.ssid);
  398. });
  399. ```
  400. Configure the WiFi SSID and password manually:
  401. ```cpp
  402. esp8266React.getWiFiSettingsService()->update([&](WiFiSettings& wifiSettings) {
  403. wifiSettings.ssid = "MyNetworkSSID";
  404. wifiSettings.password = "MySuperSecretPassword";
  405. }, "myapp");
  406. ```
  407. Observe changes to the WiFiSettings:
  408. ```cpp
  409. esp8266React.getWiFiSettingsService()->addUpdateHandler(
  410. [&](String originId) {
  411. Serial.println("The WiFi Settings were updated!");
  412. }
  413. );
  414. ```
  415. ## Libraries Used
  416. * [React](https://reactjs.org/)
  417. * [Material-UI](https://material-ui.com/)
  418. * [notistack](https://github.com/iamhosseindhv/notistack)
  419. * [ArduinoJson](https://github.com/bblanchon/ArduinoJson)
  420. * [ESPAsyncWebServer](https://github.com/me-no-dev/ESPAsyncWebServer)
  421. * [AsyncMqttClient](https://github.com/marvinroger/async-mqtt-client)