Repository: theelims/ESP32-sveltekit
Branch: main
Commit: 81827a2af941
Files: 231
Total size: 797.0 KB
Directory structure:
gitextract_e2fr6h29/
├── .github/
│ └── workflows/
│ └── ci.yaml
├── .gitignore
├── CHANGELOG.md
├── ESP32-sveltekit.code-workspace
├── LICENSE
├── README.md
├── docs/
│ ├── buildprocess.md
│ ├── components.md
│ ├── gettingstarted.md
│ ├── index.md
│ ├── restfulapi.md
│ ├── statefulservice.md
│ ├── stores.md
│ ├── structure.md
│ └── sveltekit.md
├── factory_settings.ini
├── features.ini
├── interface/
│ ├── .eslintignore
│ ├── .eslintrc.cjs
│ ├── .gitignore
│ ├── .npmrc
│ ├── .prettierignore
│ ├── .prettierrc
│ ├── LICENSE
│ ├── package.json
│ ├── src/
│ │ ├── app.css
│ │ ├── app.d.ts
│ │ ├── app.html
│ │ ├── lib/
│ │ │ ├── DaisyUiHelper.ts
│ │ │ ├── components/
│ │ │ │ ├── BatteryIndicator.svelte
│ │ │ │ ├── Collapsible.svelte
│ │ │ │ ├── ConfirmDialog.svelte
│ │ │ │ ├── DraggableList.svelte
│ │ │ │ ├── FirmwareUpdateDialog.svelte
│ │ │ │ ├── InfoDialog.svelte
│ │ │ │ ├── InputPassword.svelte
│ │ │ │ ├── RSSIIndicator.svelte
│ │ │ │ ├── SettingsCard.svelte
│ │ │ │ ├── Spinner.svelte
│ │ │ │ ├── UpdateIndicator.svelte
│ │ │ │ └── toasts/
│ │ │ │ ├── Toast.svelte
│ │ │ │ └── notifications.ts
│ │ │ ├── stores/
│ │ │ │ ├── analytics.ts
│ │ │ │ ├── battery.ts
│ │ │ │ ├── socket.ts
│ │ │ │ ├── telemetry.ts
│ │ │ │ └── user.ts
│ │ │ └── types/
│ │ │ └── models.ts
│ │ └── routes/
│ │ ├── +error.svelte
│ │ ├── +layout.svelte
│ │ ├── +layout.ts
│ │ ├── +page.svelte
│ │ ├── connections/
│ │ │ ├── +page.ts
│ │ │ ├── mqtt/
│ │ │ │ ├── +page.svelte
│ │ │ │ ├── +page.ts
│ │ │ │ ├── MQTT.svelte
│ │ │ │ └── MQTTConfig.svelte
│ │ │ └── ntp/
│ │ │ ├── +page.svelte
│ │ │ ├── +page.ts
│ │ │ ├── NTP.svelte
│ │ │ └── timezones.ts
│ │ ├── demo/
│ │ │ ├── +page.svelte
│ │ │ ├── +page.ts
│ │ │ └── Demo.svelte
│ │ ├── ethernet/
│ │ │ ├── +page.svelte
│ │ │ ├── +page.ts
│ │ │ └── Ethernet.svelte
│ │ ├── login.svelte
│ │ ├── menu.svelte
│ │ ├── statusbar.svelte
│ │ ├── system/
│ │ │ ├── +page.ts
│ │ │ ├── coredump/
│ │ │ │ ├── +page.svelte
│ │ │ │ └── +page.ts
│ │ │ ├── metrics/
│ │ │ │ ├── +page.svelte
│ │ │ │ ├── +page.ts
│ │ │ │ ├── BatteryMetrics.svelte
│ │ │ │ └── SystemMetrics.svelte
│ │ │ ├── status/
│ │ │ │ ├── +page.svelte
│ │ │ │ ├── +page.ts
│ │ │ │ └── SystemStatus.svelte
│ │ │ └── update/
│ │ │ ├── +page.svelte
│ │ │ ├── +page.ts
│ │ │ ├── GithubFirmwareManager.svelte
│ │ │ └── UploadFirmware.svelte
│ │ ├── user/
│ │ │ ├── +page.svelte
│ │ │ ├── +page.ts
│ │ │ └── EditUser.svelte
│ │ └── wifi/
│ │ ├── +page.ts
│ │ ├── ap/
│ │ │ ├── +page.svelte
│ │ │ ├── +page.ts
│ │ │ └── Accesspoint.svelte
│ │ └── sta/
│ │ ├── +page.svelte
│ │ ├── +page.ts
│ │ ├── EditNetwork.svelte
│ │ ├── Scan.svelte
│ │ └── Wifi.svelte
│ ├── static/
│ │ └── manifest.json
│ ├── svelte.config.js
│ ├── tsconfig.json
│ ├── vite-plugin-littlefs.ts
│ └── vite.config.ts
├── lib/
│ ├── PsychicHttp/
│ │ ├── .gitignore
│ │ ├── CHANGELOG.md
│ │ ├── LICENSE
│ │ ├── README.md
│ │ ├── RELEASE.md
│ │ ├── library.json
│ │ ├── request flow.drawio
│ │ └── src/
│ │ ├── ChunkPrinter.cpp
│ │ ├── ChunkPrinter.h
│ │ ├── PsychicClient.cpp
│ │ ├── PsychicClient.h
│ │ ├── PsychicCore.h
│ │ ├── PsychicEndpoint.cpp
│ │ ├── PsychicEndpoint.h
│ │ ├── PsychicEventSource.cpp
│ │ ├── PsychicEventSource.h
│ │ ├── PsychicFileResponse.cpp
│ │ ├── PsychicFileResponse.h
│ │ ├── PsychicHandler.cpp
│ │ ├── PsychicHandler.h
│ │ ├── PsychicHttp.h
│ │ ├── PsychicHttpServer.cpp
│ │ ├── PsychicHttpServer.h
│ │ ├── PsychicHttpsServer.cpp
│ │ ├── PsychicHttpsServer.h
│ │ ├── PsychicJson.cpp
│ │ ├── PsychicJson.h
│ │ ├── PsychicRequest.cpp
│ │ ├── PsychicRequest.h
│ │ ├── PsychicResponse.cpp
│ │ ├── PsychicResponse.h
│ │ ├── PsychicStaticFileHander.cpp
│ │ ├── PsychicStaticFileHandler.h
│ │ ├── PsychicStreamResponse.cpp
│ │ ├── PsychicStreamResponse.h
│ │ ├── PsychicUploadHandler.cpp
│ │ ├── PsychicUploadHandler.h
│ │ ├── PsychicWebHandler.cpp
│ │ ├── PsychicWebHandler.h
│ │ ├── PsychicWebParameter.h
│ │ ├── PsychicWebSocket.cpp
│ │ ├── PsychicWebSocket.h
│ │ ├── TemplatePrinter.cpp
│ │ ├── TemplatePrinter.h
│ │ ├── http_status.cpp
│ │ └── http_status.h
│ └── framework/
│ ├── APSettingsService.cpp
│ ├── APSettingsService.h
│ ├── APStatus.cpp
│ ├── APStatus.h
│ ├── AnalyticsService.h
│ ├── ArduinoJsonJWT.cpp
│ ├── ArduinoJsonJWT.h
│ ├── AuthenticationService.cpp
│ ├── AuthenticationService.h
│ ├── BatteryService.cpp
│ ├── BatteryService.h
│ ├── CoreDump.cpp
│ ├── CoreDump.h
│ ├── DownloadFirmwareService.cpp
│ ├── DownloadFirmwareService.h
│ ├── ESP32SvelteKit.cpp
│ ├── ESP32SvelteKit.h
│ ├── ESPFS.h
│ ├── EthernetSettingsService.cpp
│ ├── EthernetSettingsService.h
│ ├── EthernetStatus.cpp
│ ├── EthernetStatus.h
│ ├── EventEndpoint.h
│ ├── EventSocket.cpp
│ ├── EventSocket.h
│ ├── FSPersistence.h
│ ├── FactoryResetService.cpp
│ ├── FactoryResetService.h
│ ├── Features.h
│ ├── FeaturesService.cpp
│ ├── FeaturesService.h
│ ├── FirmwareUpdateEvents.h
│ ├── HttpEndpoint.h
│ ├── IPUtils.h
│ ├── JsonUtils.h
│ ├── LICENSE
│ ├── MqttEndpoint.cpp
│ ├── MqttEndpoint.h
│ ├── MqttSettingsService.cpp
│ ├── MqttSettingsService.h
│ ├── MqttStatus.cpp
│ ├── MqttStatus.h
│ ├── NTPSettingsService.cpp
│ ├── NTPSettingsService.h
│ ├── NTPStatus.cpp
│ ├── NTPStatus.h
│ ├── NotificationService.cpp
│ ├── NotificationService.h
│ ├── RestartService.cpp
│ ├── RestartService.h
│ ├── SecurityManager.h
│ ├── SecuritySettingsService.cpp
│ ├── SecuritySettingsService.h
│ ├── SettingValue.cpp
│ ├── SettingValue.h
│ ├── SleepService.cpp
│ ├── SleepService.h
│ ├── StatefulService.cpp
│ ├── StatefulService.h
│ ├── SystemStatus.cpp
│ ├── SystemStatus.h
│ ├── UploadFirmwareService.cpp
│ ├── UploadFirmwareService.h
│ ├── WebSocketServer.h
│ ├── WiFiScanner.cpp
│ ├── WiFiScanner.h
│ ├── WiFiSettingsService.cpp
│ ├── WiFiSettingsService.h
│ ├── WiFiStatus.cpp
│ └── WiFiStatus.h
├── mkdocs.yml
├── platformio.ini
├── scripts/
│ ├── build_interface.py
│ ├── generate_cert_bundle.py
│ ├── merge_bin.py
│ ├── prebuild_utils.py
│ ├── rename_fw.py
│ └── save_elf.py
├── src/
│ ├── LightMqttSettingsService.cpp
│ ├── LightMqttSettingsService.h
│ ├── LightStateService.cpp
│ ├── LightStateService.h
│ └── main.cpp
└── ssl_certs/
└── DigiCert_Global_Root_CA.pem
================================================
FILE CONTENTS
================================================
================================================
FILE: .github/workflows/ci.yaml
================================================
name: ci
on:
push:
branches:
- master
- main
permissions:
contents: write
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-python@v4
with:
python-version: 3.x
- run: echo "cache_id=$(date --utc '+%V')" >> $GITHUB_ENV
- uses: actions/cache@v3
with:
key: mkdocs-material-${{ env.cache_id }}
path: .cache
restore-keys: |
mkdocs-material-
- run: pip install mkdocs-material
- run: mkdocs gh-deploy --force
================================================
FILE: .gitignore
================================================
.pio
.clang_complete
.gcc-flags.json
*Thumbs.db
/data/www
/interface/build
/interface/node_modules
/interface/.eslintcache
.vscode
node_modules
/releases
/src/certs
/temp
/build
/lib/framework/WWWData.h
*WWWData.h
lib/framework/WWWData.h
ssl_certs/cacert.pem
/logs
.aid
/scripts/__pycache__
.DS_Store
*.bak
================================================
FILE: CHANGELOG.md
================================================
# Changelog
All notable changes to this project will be documented in this file.
## [WIP] - Next Release
### Added
- Add originID to StateUpdateResult update [#110](https://github.com/theelims/ESP32-sveltekit/pull/110)
- Add originID to StateUpdateResult update [#110](https://github.com/theelims/ESP32-sveltekit/pull/110)
- Ethernet Support [#113](https://github.com/theelims/ESP32-sveltekit/pull/113)
### Changed
- Changed the width of the confirm dialog.
- SvelteKit bundling as single files to reduce heap consumption.
- Rework of firmware upload [#107](https://github.com/theelims/ESP32-sveltekit/pull/107)
### Fixes
- WiFi reconnection issues [#109](https://github.com/theelims/ESP32-sveltekit/issues/109)
- Blurred toast notifications [#114](https://github.com/theelims/ESP32-sveltekit/issues/114)
## [0.6.0] - 2025-11-03
> [!CAUTION]
> This update has breaking changes!
### Added
- Added `GEMINI.md` to store notes about the repository for the Gemini CLI. We are now using the Gemini CLI for development.
- Added a build script to create a merged firmware file to use with [ESP Web Tools](https://esphome.github.io/esp-web-tools/)
- Added compatibility with ESP32-C6
- Added getIP() function to WiFiSettingsService.
- Added Arduino Log Colors
- Possibility to add a loop callback to ESP32-Sveltekit to leverage its loop threat. Meant to include custom services so no separate task is needed for them.
- Change wake-up pin in SleepService during runtime. It is also possible to use the internal pull-up or pull-down resistors now.
- Get current connection status from ESP32-SvelteKit. Useful for status LED or displays.
- Battery history graph to gauge battery consumption and device life.
- Add a status topic (`online` or `offline`) to the MQTT client. It retains its message and sends `offline` as last will and testament, signalling all subscribers when it goes missing.
- FeatureService sends updates through the event system.
- WiFiSettingsService can set the WiFi station mode to offline, without deleting the list of networks.
- Expands menu on selected subitem [#77](https://github.com/theelims/ESP32-sveltekit/pull/77)
- Refactor System Status and Metrics, added PSRAM [#79](https://github.com/theelims/ESP32-sveltekit/pull/79)
- Add /rest/coreDump endpoint [#87](https://github.com/theelims/ESP32-sveltekit/pull/87) & [#94](https://github.com/theelims/ESP32-sveltekit/pull/94)
- Rate limiting for MQTT publish messages. Can be configured as factory setting or at runtime. `0` will disable the rate limiting.
- Added [discord](https://discord.gg/MTn9mVUG5n) invite to readme.md and docs.
- Created DraggableList component based on svelte-dnd-action (used in WiFi Settings) [#100](https://github.com/theelims/ESP32-sveltekit/pull/100)
- Extended Collapsible and SettingsCard components to support a dirty status [#100](https://github.com/theelims/ESP32-sveltekit/pull/100)
- Enhanced ConfirmDialog, InfoDialog and Toast components to support HTML content [#100](https://github.com/theelims/ESP32-sveltekit/pull/100)
- Added connection check to WebSocket store (socket.ts) and allow secure WebSocket connections [#100](https://github.com/theelims/ESP32-sveltekit/pull/100)
- Added a delayed reconnect function to WifiSettingsService.cpp to allow the last POST request from frontend (providing new network settings) to be properly responded to. In the previous implementation, the POST request was never responded to by the backend, as the connection was closed immediately upon receiving the request in the backend. This resulted in the user receiving no feedback about whether the settings update was successful, only a timeout that suggested something had gone wrong. [#100](https://github.com/theelims/ESP32-sveltekit/pull/100)
- Added scripts/prebuild_utils.py that allows other build scripts to be executed depending on the type of the executed task (e.g. I don't want to have the interface built or the certificate bundle created on clean tasks) [#100](https://github.com/theelims/ESP32-sveltekit/pull/100)
- Added build flag `-D TELEPLOT_TASKS` to plot task heap high water mark with teleplot. You can include this in your tasks as well:
```cpp
#ifdef TELEPLOT_TASKS
static int lastTime = 0;
if (millis() - lastTime > 1000)
{
lastTime = millis();
Serial.printf(">ESP32SveltekitTask:%i:%i\n", millis(), uxTaskGetStackHighWaterMark(NULL));
}
#endif
```
### Changed
- Lightstate example uses simpler, less explicit constructor
- MQTT library updated
- Analytics task was refactored into a loop() function which is called by the ESP32-sveltekit main task.
- Updated PsychicHttp to v1.2.1 incl. patches.
- Updated to DaisyUI 5 and Tailwind CSS 4
- Updated Svelte 5 --> see [Svelte 5 Migration Guide](https://svelte.dev/docs/svelte/v5-migration-guide)
- Changed platform to [PIO Arduino](https://github.com/pioarduino/platform-espressif32) using Arduino 3 Core. Also upgrades ESP-IDF to v5.
- ESPD_LOGx: replace first argument with TAG and define TAG as 🐼 [#85](https://github.com/theelims/ESP32-sveltekit/pull/85)
- Replace rtc_get_reset_reason(0) with esp_reset_reason() [#86](https://github.com/theelims/ESP32-sveltekit/pull/86)
- Default build_interface.py script to npm, if no lock file is found.
- Replaced `svelte-dnd-list` with `svelte-dnd-action` as `svelte-dnd-list` creates build warnings and appears to no longer be maintained, while svelte-dnd-action is under active community development. [#100](https://github.com/theelims/ESP32-sveltekit/pull/100)
- Made Spinner component more flexible (to allow other texts than "Loading..." or no text at all) [#100](https://github.com/theelims/ESP32-sveltekit/pull/100)
- Reworked WiFi Settings (Station) dialog: added edit dialog for networks, rearranged UI components, used new DraggableList component [#100](https://github.com/theelims/ESP32-sveltekit/pull/100)
### Fixed
- Ensure thread safety for client subscriptions [#58](https://github.com/theelims/ESP32-sveltekit/pull/58)
- Deferred websocket event connection to after user validation & login [#72](https://github.com/theelims/ESP32-sveltekit/pull/72)
- Wrong return type battery service
- Wrong return types in various getService functions.
- Add file.close in fileHandler handleRequest [#73](https://github.com/theelims/ESP32-sveltekit/pull/73)
- Fixed bug in WiFiSettingsService preventing discovery of networks other than the first
- Fixed mixup pull up and pull down when configuring wake up pin in SleepService.cpp
- Wifi: Multiple edits bug resolved [#79](https://github.com/theelims/ESP32-sveltekit/pull/79)
- Fixed broken link to Adafruit SSL Cert Store [#93](https://github.com/theelims/ESP32-sveltekit/issues/93)
- Fixed JSON creation in WiFiSettingsService.h [#91](https://github.com/theelims/ESP32-sveltekit/pull/91)
- Fixed preprocessor warning: usage of #ifdef with OR operator [#100](https://github.com/theelims/ESP32-sveltekit/pull/100)
- Fixed preprocessor warning: redefinition of ESP_PLATFORM [#100](https://github.com/theelims/ESP32-sveltekit/pull/100)
- Fixed deprecated usage of merge-bin and its parameters in scripts/merge_bin.py [#100](https://github.com/theelims/ESP32-sveltekit/pull/100)
- Fixed Download OTA. Issues with certificate validation might remain, but build flag `-D DOWNLOAD_OTA_SKIP_CERT_VERIFY` allows to circumvent issue by sacrificing certificate validation.
### Removed
- Removed async workers in PsychicHttp, as these were not used, but caused linker errors.
### Depreciate
- Support for ESP Arduino 2 and ESP-IDF v4 will depreciate some time in the future. Try to migrate to the current Arduino 3 / ESP-IDF v5 based branch.
### Migration Guide
#### PIO Arduino & ESP-IDF 5
The firmware is based on the community maintained fork [PIO Arduino](https://github.com/pioarduino/platform-espressif32) of Arduino 3 for ESP32. Which is based on ESP-IDF 5. Please make sure all your dependencies and application code is compatible with ESP-IDF 5.
#### Frontend
SvelteKit was updated to v2 and Svelte to v5. Please check the migration guides for [SvelteKit 2](https://svelte.dev/docs/kit/migrating-to-sveltekit-2) and the [Svelte 5 Migration Guide](https://svelte.dev/docs/svelte/v5-migration-guide) for the changes required on your frontend code.
To migrate your frontend run
```
npm install --force
npx sv migrate svelte-5
```
Also DaisyUI and Tailwind CSS have been updated to their last major versions. Run the official Tailwind upgrade tool:
```
npx @tailwindcss/upgrade
```
This will migrate some of your svelte files to the new naming convention of Tailwind. For DaisyUI follow this [guide](https://daisyui.com/docs/upgrade/#changes-from-v4). Likely you'll need to redo all forms, as the components behave differently. Forms will need the `fieldset` class. Inputs will need an additional `w-full` to have the same behavior as before. And [labels](https://daisyui.com/components/label/) have a different syntax, too.
The themes are to be found in `app.css` now. Add them back if they had been changed from the default.
### Acknowledgment
Many thanks to @runeharlyk, @ewowi, @hmbacher, and @stamp who contributed significantly to this new release.
## [0.5.0] - 2024-05-06
Changes the Event Socket System to use a clearer message structure and MessagePack. Brings breaking changes to the `EventSocket.h` API.
Updated daisyUI to v4. This has changes in the colors and switches to OKLCH. Also button groups and input groups have been depreciated in favor of join. This might require changes to custom parts of the code. Please double check all websites if the still have the desired looks.
Updates ArduinoJSON from v6 to v7 to increase the available free heap. If you make use of ArduinoJSON, changes might be required.
### Added
- Debug buildflag to switch between MessagePack and JSON for event messages.
- Show SSID of the current WiFi Station as tooltip of the RSSI icon.
### Changed
- Moved MQTT types to models.ts as well. [#49](https://github.com/theelims/ESP32-sveltekit/pull/49)
- Updated daisyUI to 4.10.2 [#48](https://github.com/theelims/ESP32-sveltekit/pull/48)
- Fixed spelling error in models.ts
- Changed ArduinoJson from v6 to v7 increasing the free heap by ~40kb
- Split NotificationService out of EventSocket into own class
- Changed API of EventSocket.h. Now uses `void emitEvent(String event, JsonObject &jsonObject, const char *originId = "", bool onlyToSameOrigin = false);`.
- Changed event socket message format to MessagePack
### Fixed
- Fixes to WiFi.svelte and models.ts to fix type errors and visibility rights.
- Fixes bug in highlighting the menu when navigating with the browser (back/forward)
- Made WiFi connection routine more robust by using BSSID. Ensures that the STA truly connects to the strongest hotspot, even if several hotspots are in reach.
### Removed
- Removed duplicate in ESP32SvelteKit.cpp [#47](https://github.com/theelims/ESP32-sveltekit/pull/47) and WiFi.svelte [#50](https://github.com/theelims/ESP32-sveltekit/pull/50)
### Acknowledgment
Many thanks to @runeharlyk who contributed significantly to the new event socket system and fixed many smaller issues with the front-end.
## [0.4.0] - 2024-04-21
This upgrade might require one minor change as `MqttPubSub.h` and its class had been renamed to `MqttEndpoint.h` and `MqttEndoint` respectively. However, it is strongly advised, that you change all existing WebSocketServer endpoints to the new event socket system.
> [!NOTE]
> The new Event Socket system is likely to change with coming updates.
### Added
- Added build flag `-D SERIAL_INFO` to platformio.ini to enable / disable all `Serial.print()` statements. On some boards with native USB those Serial prints have been reported to block and make the server unresponsive.
- Added a hook handler to StatefulService. Unlike an UPDATE a hook is called every time a state receives an updated, even if the result is UNCHANGED or ERROR.
- Added missing include for S2 in SystemStatus.cpp [#23](https://github.com/theelims/ESP32-sveltekit/issues/23)
- Added awareness of front end build script for all 3 major JS package managers. The script will auto-identify the package manager by the lock-file. [#40](https://github.com/theelims/ESP32-sveltekit/pull/40)
- Added a new event socket to bundle the websocket server and the notifications events. This saves on open sockets and allows for concurrent visitors of the internal website. The normal websocket server endpoint remains as an option, should a pure websocket connection be desired. An EventEndpoint was added to use this with Stateful Services. [#29](https://github.com/theelims/ESP32-sveltekit/issues/29) and [#43](https://github.com/theelims/ESP32-sveltekit/pull/43)
- TS Types definition in one central place for the frontend.
### Changed
- more generic board definition in platformio.ini [#20](https://github.com/theelims/ESP32-sveltekit/pull/20)
- Renamed `MqttPubSub.h` and class to `MqttEndpoint.h` and class.
- refactored MqttEndpoint.h into a single class to improve readability
- Moves appName and copyright to `layout.ts` to keep customization in one place [#31](https://github.com/theelims/ESP32-sveltekit/pull/31)
- Make event source use timeout for reconnect [#34](https://github.com/theelims/ESP32-sveltekit/pull/34)
- Make each toasts disappear after timeout [#35](https://github.com/theelims/ESP32-sveltekit/pull/35)
- Fixed version `platform = espressif32 @ 6.6.0` in platformio.ini
- Analytics data limited to 1000 data points (roughly 33 minutes).
- postcss.config.cjs as ESM module [#24](https://github.com/theelims/ESP32-sveltekit/issues/24)
### Fixed
- Fixed compile error with FLAG `-D SERVE_CONFIG_FILES`
- Fixed typo in telemetry.ts [#38](https://github.com/theelims/ESP32-sveltekit/pull/38)
- Fixed the development warning: `Loading /rest/features using 'window.fetch'. For best results, use the 'fetch' that is passed to your 'load' function:`
### Removed
- Duplicate method in FeatureService [#18](https://github.com/theelims/ESP32-sveltekit/pull/18)
- Duplicate lines in Systems Settings view.
- Removes duplicate begin [#36](https://github.com/theelims/ESP32-sveltekit/pull/36)
- Temporary disabled OTA progress update due to crash with PsychicHttp [#32](https://github.com/theelims/ESP32-sveltekit/issues/32) until a fix is found.
### Known Issues
- On ESP32-C3 the security features should be disabled in features.ini: `-D FT_SECURITY=0`. If enabled the ESP32-C3 becomes extremely sluggish with frequent connection drops.
## [0.3.0] - 2024-02-05
> [!CAUTION]
> This update has breaking changes!
This is a major change getting rid of all ESPAsyncTCP and ESPAsyncWebserver dependencies. Despite their popularity they are plagued with countless bugs, since years unmaintained, not SSL capable and simply not suitable for a production build. Although several attempts exist to fix the most pressing bugs even these libraries lead to frequent crashes. This new version replaces them with ESP-IDF based components. [PsychicHttp](https://github.com/hoeken/PsychicHttp) and [PsychicMqttClient](https://github.com/theelims/PsychicMqttClient) both wrap the ESP-IDF components in a familiar wrapper for easy porting of the code base. However, this will break existing code and will require some effort on your codebase. In return the stability is improved greatly and the RAM usage more friendly. Now e.g. running Bluetooth in parallel becomes possible.
### Added
- Added postscript to platform.io build process to copy, rename and calculate MD5 checksum of \*.bin file. These files are ready for uploading to the Github Release page.
- Added more information to SystemStatus API
- Added generateToken API for security settings
- Added Multi-WiFi capability. Add up to five WiFi configurations and connect to either strongest network (default), or by priority.
- Added InfoDialog as a simpler version of the ConfirmDialog for a simple notification modal.
- Added Adafruit certificate repository as the default choice for the X509 certificate bundle.
### Changed
- Better route protection for user page with deep link.
- Changed build_interface.py script to check for modified files in the interface sources before re-building the interface. Saves some time on the compilation process.
- Upload firmware binary allows uploading of MD5 checksum file in advance to verify downloaded firmware package.
- GithubFirmwareManager checks against PIO build_target in filename to support Github OTA for binaries build for various targets. You should rename your old release \*.bin files on the Github release pages for backward compatibility.
- Changed MQTT Client to an ESP-IDF backed one which supports SSL/TLS X509 root CA bundles and transport over WS.
- Changed the `PROGMEM_WWW` flag to `EMBED_WWW` as there is technically speaking no PROGMEM on ESP32's.
- Updated dependencies to the latest version. Except SvelteKit.
### Fixed
- Fixed reactivity of System Status page.
### Removed
- Removed support for Arduino ESP OTA.
- HttpEndpoints and Websocket Server without a securityManager are no longer possible.
### Migrate from ESPAsyncWebServer to PsychicHttp
#### Migrate `main.cpp`
Change the server and ESPSvelteKit instances to PsychicHttpServer and give the ESP32SvelteKit constructor the number of http endpoints of your project.
```
PsychicHttpServer server;
ESP32SvelteKit esp32sveltekit(&server, 120);
```
Remove `server.begin();` in `void setup()`. This is handled by ESP32SvelteKit now.
#### Migrate `platformio.ini`
Remove the following `build_flags`:
```ini
; Increase queue size of SSE and WS
-D SSE_MAX_QUEUED_MESSAGES=64
-D WS_MAX_QUEUED_MESSAGES=64
-D CONFIG_ASYNC_TCP_RUNNING_CORE=0
-D NO_GLOBAL_ARDUINOOTA
-D PROGMEM_WWW
```
Add the following `build_flags` and adjust to your app, if needed:
```ini
-D BUILD_TARGET=\"$PIOENV\"
-D APP_NAME=\"ESP32-Sveltekit\" ; Must only contain characters from [a-zA-Z0-9-_] as this is converted into a filename
-D APP_VERSION=\"0.3.0\" ; semver compatible version string
-D EMBED_WWW
```
Remove the lib dependency `esphome/AsyncTCP-esphome @ ^2.0.0` and add `https://github.com/theelims/PsychicMqttClient.git`
Consider adjusting `board_ssl_cert_source = adafruit`, so that the new MQTT client has universal SSL/TLS support with a wide range of CA root certificates.
#### Migrate `factory_settings.ini`
The new MQTT client has slightly renamed factory settings:
```ini
; MQTT settings
-D FACTORY_MQTT_ENABLED=false
-D FACTORY_MQTT_URI=\"mqtts://mqtt.eclipseprojects.io:8883\"
-D FACTORY_MQTT_USERNAME=\"\" ; supports placeholders
-D FACTORY_MQTT_PASSWORD=\"\"
-D FACTORY_MQTT_CLIENT_ID=\"#{platform}-#{unique_id}\" ; supports placeholders
-D FACTORY_MQTT_KEEP_ALIVE=120
-D FACTORY_MQTT_CLEAN_SESSION=true
```
Max Topic Length is no longer needed.
#### Custom Stateful Services
Adapt the class constructor (`(PsychicHttpServer *server, ...`) to PsychicHttpServer.
Due to the loading sequence HttpEndoint and WebsocketServer both have gotten a `begin()` function to register their http endpoints with the server. This must be called in your stateful services' own `begin()` function:
```cpp
void LightStateService::begin()
{
_httpEndpoint.begin();
_webSocketServer.begin();
_state.ledOn = DEFAULT_LED_STATE;
onConfigUpdated();
}
```
## [0.2.2] - 2023-10-08
### Added
- Status reports reset-reason & uptime.
- AnalyticsService to draw graphs about heap usage and other time dependent values
- Added ping to WebSocket Server
- Use telemetry store with RSSI messages to gauge health of connection. Automatic reconnect for SSE and WS.
- Added user supplied features to FeatureService
- Compiler flag to let it serve the config JSONs for debug purposes
- Hard fork of ESPAsyncWebserver as it is unmaintained to fix bugs and add features
### Changed
- Changed JSON format for websocket server and removed "payload" property. JSON is the same as for MQTT or HTTP now.
- Changed features.ini to default `FT_SLEEP=0`
- Updated dependencies to latest version.
## [0.2.1] - 2023-09-11
### Fixed
- Fixed the boot loop issue for Arduino 6.4.0
## [0.2.0] - 2023-08-03
### Added
- Introduced CHANGELOG.md
- Added core temperature to the system status API
- Added mDNS / Bonjour / zeroConf for better discoverability in local network
- Added recovery mode which forces AP to spin up regardless from its settings
- Added push notification service to show notification toasts on all clients
- Added SSE to update RSSI in status bar on client
- Added firmware version to System Status API
- Added sleep service to send ESP32 into deep sleep. Wake-up with button using EXT1
- Added battery service to show battery state of charge in the status bar. Uses SSE.
- Added download firmware manager to pull firmware binaries e.g. from github release pages
- modified generate_cert_bundle.py from Espressif included into the build process to automatically create SSL Root CA Bundle
### Changed
- Improved system status with more meaningful presentation of available data
- Improved layout on small screens
- Increased queue size for SSE and WS to 64 instead of 32
- ESP32-SvelteKit loop()-function is its own task now
- ArduinoOTA handle runs in own task now
- AsyncTCP tasks run on Core 0 to move all networking related stuff to Core 0 and free up Core 1 for business logic
- Compiler flag on which core ESP32-sveltekit tasks should run
- Renamed WebSocketRxTx.h to WebSocketServer.h to create a distinction between WS Client and WS Server interfaces
- Made code of LightStateExample slightly more verbose
- getServer() returning a pointer to the AsyncWebServer instance.
- Updated frontend dependencies and packages to newest version.
### Depreciated
- ArduinoOTA feature is set to depreciate. It is unstable with mDNS causing some reset loops until it finally settles.
### Removed
- `FT_PROJECT` feature flag removed.
## [0.1.0] - 2023-05-18
This is the initial release of ESP32-sveltekit. With this it is feature complete to [rjwats/esp8266-react](https://github.com/rjwats/esp8266-react), where it forked from.
### Added
- Added copyright notes
### Changed
- Renaming into ESP32-sveltekit
- Small changes to reflect the slightly different file structure of sveltekit
- Build process for sveltekit
### Removed
- Dropping support for ESP8266
================================================
FILE: ESP32-sveltekit.code-workspace
================================================
{
"folders": [
{
"path": "."
}
],
"settings": {
"files.associations": {
"*.tcc": "cpp",
"algorithm": "cpp",
"esp32-hal-misc.c": "cpp",
"esp_crt_bundle.h": "c",
"functional": "cpp",
"array": "cpp",
"atomic": "cpp",
"bitset": "cpp",
"cctype": "cpp",
"clocale": "cpp",
"cmath": "cpp",
"cstdarg": "cpp",
"cstddef": "cpp",
"cstdint": "cpp",
"cstdio": "cpp",
"cstdlib": "cpp",
"cstring": "cpp",
"ctime": "cpp",
"cwchar": "cpp",
"cwctype": "cpp",
"deque": "cpp",
"list": "cpp",
"unordered_map": "cpp",
"vector": "cpp",
"exception": "cpp",
"iterator": "cpp",
"map": "cpp",
"memory": "cpp",
"memory_resource": "cpp",
"numeric": "cpp",
"optional": "cpp",
"random": "cpp",
"regex": "cpp",
"string": "cpp",
"string_view": "cpp",
"system_error": "cpp",
"tuple": "cpp",
"type_traits": "cpp",
"utility": "cpp",
"fstream": "cpp",
"initializer_list": "cpp",
"iosfwd": "cpp",
"istream": "cpp",
"limits": "cpp",
"new": "cpp",
"ostream": "cpp",
"sstream": "cpp",
"stdexcept": "cpp",
"streambuf": "cpp",
"cinttypes": "cpp",
"typeinfo": "cpp",
"unordered_set": "cpp",
"iomanip": "cpp"
}
}
}
================================================
FILE: LICENSE
================================================
ESP32 SvelteKit is distributed with two licenses for different sections of the
code. The back end code inherits the GNU LESSER GENERAL PUBLIC LICENSE Version 3
and is therefore distributed with said license. The front end code is distributed
under the MIT License.
MIT License
Copyright (C) 2023 - 2024 theelims
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
GNU LESSER GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc.
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
This version of the GNU Lesser General Public License incorporates
the terms and conditions of version 3 of the GNU General Public
License, supplemented by the additional permissions listed below.
0. Additional Definitions.
As used herein, "this License" refers to version 3 of the GNU Lesser
General Public License, and the "GNU GPL" refers to version 3 of the GNU
General Public License.
"The Library" refers to a covered work governed by this License,
other than an Application or a Combined Work as defined below.
An "Application" is any work that makes use of an interface provided
by the Library, but which is not otherwise based on the Library.
Defining a subclass of a class defined by the Library is deemed a mode
of using an interface provided by the Library.
A "Combined Work" is a work produced by combining or linking an
Application with the Library. The particular version of the Library
with which the Combined Work was made is also called the "Linked
Version".
The "Minimal Corresponding Source" for a Combined Work means the
Corresponding Source for the Combined Work, excluding any source code
for portions of the Combined Work that, considered in isolation, are
based on the Application, and not on the Linked Version.
The "Corresponding Application Code" for a Combined Work means the
object code and/or source code for the Application, including any data
and utility programs needed for reproducing the Combined Work from the
Application, but excluding the System Libraries of the Combined Work.
1. Exception to Section 3 of the GNU GPL.
You may convey a covered work under sections 3 and 4 of this License
without being bound by section 3 of the GNU GPL.
2. Conveying Modified Versions.
If you modify a copy of the Library, and, in your modifications, a
facility refers to a function or data to be supplied by an Application
that uses the facility (other than as an argument passed when the
facility is invoked), then you may convey a copy of the modified
version:
a) under this License, provided that you make a good faith effort to
ensure that, in the event an Application does not supply the
function or data, the facility still operates, and performs
whatever part of its purpose remains meaningful, or
b) under the GNU GPL, with none of the additional permissions of
this License applicable to that copy.
3. Object Code Incorporating Material from Library Header Files.
The object code form of an Application may incorporate material from
a header file that is part of the Library. You may convey such object
code under terms of your choice, provided that, if the incorporated
material is not limited to numerical parameters, data structure
layouts and accessors, or small macros, inline functions and templates
(ten or fewer lines in length), you do both of the following:
a) Give prominent notice with each copy of the object code that the
Library is used in it and that the Library and its use are
covered by this License.
b) Accompany the object code with a copy of the GNU GPL and this license
document.
4. Combined Works.
You may convey a Combined Work under terms of your choice that,
taken together, effectively do not restrict modification of the
portions of the Library contained in the Combined Work and reverse
engineering for debugging such modifications, if you also do each of
the following:
a) Give prominent notice with each copy of the Combined Work that
the Library is used in it and that the Library and its use are
covered by this License.
b) Accompany the Combined Work with a copy of the GNU GPL and this license
document.
c) For a Combined Work that displays copyright notices during
execution, include the copyright notice for the Library among
these notices, as well as a reference directing the user to the
copies of the GNU GPL and this license document.
d) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this
License, and the Corresponding Application Code in a form
suitable for, and under terms that permit, the user to
recombine or relink the Application with a modified version of
the Linked Version to produce a modified Combined Work, in the
manner specified by section 6 of the GNU GPL for conveying
Corresponding Source.
1) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (a) uses at run time
a copy of the Library already present on the user's computer
system, and (b) will operate properly with a modified version
of the Library that is interface-compatible with the Linked
Version.
e) Provide Installation Information, but only if you would otherwise
be required to provide such information under section 6 of the
GNU GPL, and only to the extent that such information is
necessary to install and execute a modified version of the
Combined Work produced by recombining or relinking the
Application with a modified version of the Linked Version. (If
you use option 4d0, the Installation Information must accompany
the Minimal Corresponding Source and Corresponding Application
Code. If you use option 4d1, you must provide the Installation
Information in the manner specified by section 6 of the GNU GPL
for conveying Corresponding Source.)
5. Combined Libraries.
You may place library facilities that are a work based on the
Library side by side in a single library together with other library
facilities that are not Applications and are not covered by this
License, and convey such a combined library under terms of your
choice, if you do both of the following:
a) Accompany the combined library with a copy of the same work based
on the Library, uncombined with any other library facilities,
conveyed under the terms of this License.
b) Give prominent notice with the combined library that part of it
is a work based on the Library, and explaining where to find the
accompanying uncombined form of the same work.
6. Revised Versions of the GNU Lesser General Public License.
The Free Software Foundation may publish revised and/or new versions
of the GNU Lesser General Public License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the
Library as you received it specifies that a certain numbered version
of the GNU Lesser General Public License "or any later version"
applies to it, you have the option of following the terms and
conditions either of that published version or of any later version
published by the Free Software Foundation. If the Library as you
received it does not specify a version number of the GNU Lesser
General Public License, you may choose any version of the GNU Lesser
General Public License ever published by the Free Software Foundation.
If the Library as you received it specifies that a proxy can decide
whether future versions of the GNU Lesser General Public License shall
apply, that proxy's public statement of acceptance of any version is
permanent authorization for you to choose that version for the
Library.
================================================
FILE: README.md
================================================
# ESP32 SvelteKit - Create Amazing IoT Projects
A simple and extensible framework for ESP32 based IoT projects with a feature-rich, beautiful, and responsive front-end build with [Sveltekit](https://kit.svelte.dev/), [TailwindCSS](https://tailwindcss.com/) and [DaisyUI](https://daisyui.com/). This is a project template to get you started in no time backed by a powerful back end service, an amazing front end served from the ESP32 and an easy to use build chain to get everything going.
It was forked from the fabulous [rjwats/esp8266-react](https://github.com/rjwats/esp8266-react) project, from where it inherited the mighty back end services.
> **Tip**: This template repository is not meant to be used stand alone. If you're just looking for a WiFi manager there are plenty of options available. This is a starting point when you need a rich web UI.
## Features
### :butterfly: Beautiful UI powered by DaisyUI and TailwindCSS
Beautiful, responsive UI which works equally well on desktop and on mobile. Gently animated for a snappy and modern feeling without ever being obtrusive or in the way. Easy theming with DaisyUI and media-queries to respect the users wish for a light or dark theme.
### :t-rex: Low Memory Footprint and Easy Customization by Courtesy of SvelteKit
SvelteKit is ideally suited to be served from constrained devices like an ESP32. It's unique approach leads to very slim files. No bloatware like other popular JS frameworks. Not only the low memory footprint make it ideal but the developer experience is also outstanding letting you customize the front end with ease. Adapt and add functionality as you need it. The back end has you covered as well.
### :telephone: Rich Communication Interfaces
Comes with a rich set of communication interfaces to cover most standard needs of an IoT application. Like MQTT client, HTTP RESTful API, a WebSocket based Event Socket and a classic Websocket Server. All communication channels are stateful and fully synchronized. Changes propagate and are communicated to all other participants. The states can be persisted on the file system as well. For accurate time keeping time can by synchronized over NTP.
### :file_cabinet: WiFi Provisioning and Management
Naturally ESP32 SvelteKit comes with rich features to manage all your WiFi needs. From pulling up an access point for provisioning or as fall back, to fully manage your WiFi networks. Scan for available networks and connect to them. Advanced configuration options like static IP are on board as well.
### :old_key: Secured API and User Management
Manage different user of your app with two authorization levels. An administrator and a guest user. Authenticate their API calls with a JWT token. Manage the user's profile from the admin interface. Use at own risk, as it is neither secure without the ability to use TLS/SSL encryption on the ESP32 server, nor very convenient, as only an admin can change passwords.
### :airplane: OTA Upgrade Service
The framework can provide two different channels for Over-the-Air updates. Either by uploading a \*.bin file from the web interface. Or by pulling a firmware image from an update server. This is implemented with the github release page as an example. It is even possible to have different build environments at the same time and the Github OTA process pulls the correct binary.
### :building_construction: Automated Build Chain
The automated build chain takes out the pain and tears of getting all the bits and pieces play nice together. The repository contains a PlatformIO project at its heart. A SvelteKit project for the frontend code and a mkdocs project for the documentation go alongside. The PlatformIO build tools not only build the SvelteKit frontend with Vite, but also ensure that the build results are gzipped and find their way into the flash memory of the ESP32. You have two choices to serve the frontend either from the flash partition, or embedded into the firmware binary. The latter is much more friendly if your frontend code should be distributed OTA as well, leaving all configuration files intact.
### :icecream: Compatible with all ESP32 Flavours
The code runs on many variants of the ESP32 chip family. From the plain old ESP32, the ESP32-S3 and ESP32-C3. Other ESP32 variants might work, but haven't been tested. Sorry, no support for the older ESP8266. Go with one of the ESP32's instead.
## Visit the Project Site
[https://theelims.github.io/ESP32-sveltekit/](https://theelims.github.io/ESP32-sveltekit/)
## Join our [Discord](https://discord.gg/MTn9mVUG5n)
## Libraries Used
- [SvelteKit](https://kit.svelte.dev/)
- [Tailwind CSS](https://tailwindcss.com/)
- [DaisyUI](https://daisyui.com/)
- [tabler ICONS](https://tabler-icons.io/)
- [unplugin-icons](https://github.com/antfu/unplugin-icons)
- [svelte-modals](https://svelte-modals.mattjennings.io/)
- [svelte-dnd-action](https://github.com/isaacHagoel/svelte-dnd-action)
- [ArduinoJson](https://github.com/bblanchon/ArduinoJson)
- [PsychicHttp](https://github.com/hoeken/PsychicHttp)
- [PsychicMqttClient](https://github.com/theelims/PsychicMqttClient)
## Licensing
ESP32 SvelteKit is distributed with two licenses for different sections of the code. The back end code inherits the GNU LESSER GENERAL PUBLIC LICENSE Version 3 and is therefore distributed with said license. The front end code is distributed under the MIT License. See the [LICENSE](LICENSE) for a full text of both licenses.
================================================
FILE: docs/buildprocess.md
================================================
# Build Process
The build process is controlled by [platformio.ini](https://github.com/theelims/ESP32-sveltekit/platformio.ini) and automates the build of the front end website with Vite as well as the binary compilation for the ESP32 firmware. Whenever PlatformIO is building a new binary it will call the python script [build_interface.py](https://github.com/theelims/ESP32-sveltekit/scripts/build_interface.py) to action. It will check the frontend files for changes. If necessary it will start the Vite build and gzip the resulting files either to the `data/` directory or embed them into a header file. In case the WWW files go into a LITTLEFS partition a file system image for the flash is created for the default build environment and upload to the ESP32.
## Changing the JS package manager
This project uses NPM as the default package manager. However, many users might have different preferences and like to use YARN or PNPM instead. Just switch the interface to one of the other package managers. The build script identify the package manager by the presence of its lock-file and start the vite build process accordingly.
## Serving from Flash or Embedding into the Binary
The front end website can be served either from the LITTLEFS partition of the flash, or embedded into the firmware binary (default). Later has the advantage that only one binary needs to be distributed easing the OTA process. Further more this is desirable if you like to preserve the settings stored in the LITTLEFS partition, or have other files there that need to survive a firmware update. To serve from the LITTLEFS partition instead please comment the following build flag out:
```ini
build_flags =
...
-D EMBED_WWW
```
### Partitioning
If you choose to embed the frontend it becomes part of the firmware binary (default). As many ESP32 modules only come with 4MB built-in flash this results in the binary being too large for the reserved flash. Therefor a partition scheme with a larger section for the executable code is selected. However, this limits the LITTLEFS partition to 200kb. There are a great number of [default partition tables](https://github.com/espressif/arduino-esp32/tree/master/tools/partitions) for Arduino-ESP32 to choose from. If you have 8MB or 16MB flash this would be your first choice. If you don't need OTA you can choose a partition scheme without OTA.
Should you want to deploy the frontend from the flash's LITTLEFS partition on a 4MB chip you need to comment out the following two lines. Otherwise the 200kb will not be large enough to host the front end code.
```ini
board_build.partitions = min_spiffs.csv
```
## Selecting Features
Many of the framework's built in features may be enabled or disabled as required at compile time. This can help save sketch space and memory if your project does not require the full suite of features. The access point and WiFi management features are "core features" and are always enabled. Feature selection may be controlled with the build flags defined in [features.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/features.ini).
Customize the settings as you see fit. A value of 0 will disable the specified feature:
```ini
-D FT_SECURITY=1
-D FT_MQTT=1
-D FT_NTP=1
-D FT_UPLOAD_FIRMWARE=1
-D FT_DOWNLOAD_FIRMWARE=1
-D FT_SLEEP=1
-D FT_BATTERY=1
-D FT_ETHERNET=1
```
| Flag | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| FT_SECURITY | Controls whether the [security features](statefulservice.md#security-features) are enabled. Disabling this means you won't need to authenticate to access the device and all authentication predicates will be bypassed. |
| FT_MQTT | Controls whether the MQTT features are enabled. Disable this if your project does not require MQTT support. |
| FT_NTP | Controls whether network time protocol synchronization features are enabled. Disable this if your project does not require accurate time. |
| FT_UPLOAD_FIRMWARE | Controls whether the manual upload firmware feature is enabled. Disable this if you won't be manually uploading firmware. |
| FT_DOWNLOAD_FIRMWARE | Controls whether the firmware download feature is enabled. Disable this if you won't firmware pulled from a server. |
| FT_SLEEP | Controls whether the deep sleep feature is enabled. Disable this if your device is not battery operated or you don't need to place it in deep sleep to save energy. |
| FT_BATTERY | Controls whether the battery state of charge shall be reported to the clients. Disable this if your device is not battery operated. |
| FT_ETHERNET | Controls whether an ethernet interface will be used. Disable this if your device has no ethernet interface connected. |
In addition custom features might be added or removed at runtime. See [Custom Features](statefulservice.md#custom-features) on how to use this in your application.
## Factory Settings
The framework 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](https://github.com/theelims/ESP32-sveltekit/blob/main/factory_settings.ini). All strings entered here must be escaped, especially special characters.
Customize the settings as you see fit, for example you might configure your home WiFi network as the factory default:
```ini
-D FACTORY_WIFI_SSID=\"My\ Awesome\ WiFi\ Network\"
-D FACTORY_WIFI_PASSWORD=\"secret\"
-D FACTORY_WIFI_HOSTNAME=\"awesome_light_controller\"
```
### Default access point settings
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:
- SSID: ESP32-Sveltekit
- Password: esp-sveltekit
### Security settings and user credentials
By default, the factory settings configure two user accounts with the following credentials:
| Username | Password |
| -------- | -------- |
| admin | admin |
| guest | guest |
It is recommended that you change the user credentials from their defaults to better protect your device. You can do this in the user interface, or by modifying [factory_settings.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/factory_settings.ini) as mentioned above.
### Customizing the factory time zone setting
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 [timezones.ts](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/routes/connections/timezones.ts). Take the appropriate pair of values from there, for example, for Los Angeles you would use:
```ini
-D FACTORY_NTP_TIME_ZONE_LABEL=\"America/Los_Angeles\"
-D FACTORY_NTP_TIME_ZONE_FORMAT=\"PST8PDT,M3.2.0,M11.1.0\"
```
### Placeholder substitution
Various settings support placeholder substitution, indicated by comments in [factory_settings.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/factory_settings.ini). This can be particularly useful where settings need to be unique, such as the Access Point SSID or MQTT client id. The following placeholders are supported:
| Placeholder | Substituted value |
| ------------ | --------------------------------------------------------------------- |
| #{platform} | The microcontroller platform, e.g. "esp32" or "esp32c3" |
| #{unique_id} | A unique identifier derived from the MAC address, e.g. "0b0a859d6816" |
| #{random} | A random number encoded as a hex string, e.g. "55722f94" |
## Other Build Flags
### Cross-Origin Resource Sharing
If you need to enable Cross-Origin Resource Sharing (CORS) on the ESP32 server just uncomment the following build flags:
```ini
build_flags =
...
; Uncomment to configure Cross-Origin Resource Sharing
-D ENABLE_CORS
-D CORS_ORIGIN=\"*\"
```
This will add the `Access-Control-Allow-Origin` and `Access-Control-Allow-Credentials` headers to any request made.
### ESP32 `CORE_DEBUG_LEVEL`
The ESP32 Arduino Core and many other libraries use the ESP Logging tools. To enable these debug and error messages from deep inside your libraries uncomment the following build flag.
```ini
build_flags =
...
-D CORE_DEBUG_LEVEL=5
```
It accepts values from 5 (Verbose) to 1 (Errors) for different information depths to be logged on the serial terminal. If commented out there won't be debug messages from the core libraries. For a production build you should comment this out.
### Serve Config Files
By enabling this build flag the ESP32 will serve all config files stored on the LittleFS flash partition under `http:\\[IP]\config\[filename].json`. This can be helpful to troubleshoot problems. However, it is strongly advised to disable this for production builds.
```ini
build_flags =
...
-D SERVE_CONFIG_FILES
```
### Serial Info
In some circumstances it might be beneficial to not print any information on the serial consol (Serial1 or USB CDC). By commenting out the following build flag ESP32-Sveltekit will not print any information on the serial console.
```ini
build_flags =
...
-D SERIAL_INFO
```
## SSL Root Certificate Store
Some features like firmware download or the MQTT client require a SSL connection. For that the SSL Root CA certificate must be known to the ESP32. The build system contains a python script derived from Espressif ESP-IDF building a certificate store containing one or more certificates. In order to create the store you must uncomment the three lines below in `platformio.ini`.
```ini
extra_scripts =
pre:scripts/generate_cert_bundle.py
board_build.embed_files = src/certs/x509_crt_bundle.bin
board_ssl_cert_source = adafruit
```
The script will download a public certificate store from Mozilla (`board_ssl_cert_source = mozilla`) or a repository curated by Adafruit (`board_ssl_cert_source = adafruit`) or (`board_ssl_cert_source = adafruit-full`), builds a binary containing all certs and embeds this into the firmware. This will add ~65kb to the firmware image. Should you only need a few known certificates you can place their `*.pem` or `*.der` files in the [ssl_certs](https://github.com/theelims/ESP32-sveltekit/blob/main/ssl_certs) folder and change `board_ssl_cert_source = folder`. Then only these certificates will be included in the store. This is especially useful, if you only need to connect to know servers and need to shave some kb off the firmware image:
!!! info
To enable SSL the feature `FT_NTP=1` must be enabled as well.
!!! bug
At the moment there is a bug with the certificate bundle when using the firmware download e.g. from Github. By using the build flag `-D DOWNLOAD_OTA_SKIP_CERT_VERIFY` you may skip certificate validation to keep OTA working. Only OTA seems affected, not MQTT. Keep in mind, that this voids the main security feature of SSL and allows man-in-the-middle attacks.
## Vite and LittleFS 32 Character Limit
The static files for the website are build using vite. By default vite adds a unique hash value to all filenames for improved caching performance. However, LittleFS on the ESP32 is limited to filenames with 32 characters. This restricts the number of characters available for the user to name svelte files. To give a little bit more headroom a vite-plugin removes all hash values, as they offer no benefit on an ESP32. However, have the 32 character limit in mind when naming files. Excessively long names may still cause some issues when building the LittleFS binary.
## Merged Firmware File for Web Flasher
The PIO build system calls a script `merge_bin.py` to create a merged firmware binary ready to be used with [ESP Web Tools](https://esphome.github.io/esp-web-tools/). The file is located under the PIO build folder. Typically `build/merged/{APP_NAME}_{$PIOENV}_{APP_VERSION}.bin`.
================================================
FILE: docs/components.md
================================================
# Components
The project includes a number of components to create the user interface. Even though DaisyUI has a huge set of components, it is often beneficial to recreate them as a Svelte component. This offers a much better integration into the Svelte way of doing things, is less troublesome with animations and results in a overall better user experience.
## Collapsible
A collapsible container to hide / show content by clicking on the arrow button.
```ts
import Collapsible from "$lib/components/Collapsible.svelte";
```
It exports a closed / open state with `export open` which you can use to determine the mounting behavior of the component.
### Slots
The component has two slots. A named slot `title` for the collapsible title and the main slot for the content that can be hidden or shown.
```
Title
...
```
The `class` attribute may be used as normal to style the container. By default there is no special styling like background or shadows to accentuate the container element.
### Events
The collapsible component dispatches two events. `on:closed` when the collapsible is closed and `on:opened` when it is opened. You can bind to them as to any other event.
## InputPassword
This is an input field specifically for passwords. It comes with an "eye"-button on the right border to toggle the visibility of the password. It natively blends into the style from DaisyUI.
```ts
import InputPassword from "$lib/components/InputPassword.svelte";
```
You may use it like any other form element:
```
```
## RSSIIndicator
This shows the popular WiFi strength indicator icon with differently highlighted circles depending on the received signal strength (RSSI) of the WiFi signal. In addition it can display the signal strength in raw "dBm" as an indicator badge.
```ts
import RssiIndicator from "$lib/components/RSSIIndicator.svelte";
```
Just use and style as you please. It doesn't have any slots or events.
```
```
Two exports control the behavior of the component. `rssi_dbm` accepts a negative number of the raw RSSI in dBm and is used to determine how many circles of reception should be shown. An optional boolean `showDBm` (defaults to `false`) shows the indicator badge with the dBm value.
## Settings Card
A Settings Card is in many ways similar to a [collapsible](#collapsible). However, it is styled and is the main element of many settings menus. It also accepts an icon in a dedicate slot and unlike collapsible has no events.
```ts
import SettingsCard from "$lib/components/SettingsCard.svelte";
```
### Slots
Three slots are available. Besides the main slot for the content there is a named slot for the `title` and s second one for the `icon`.
```
Title
...
```
The component exports two properties to determine its behavior. `collapsible` is a boolean describing wether the component should behave like a collapsible in the first place. `open` is a boolean as well and if set true shows the full content of the body on mount.
## Spinner
A small component showing an animated spinner which can be used while waiting for data.
```ts
import Spinner from "$lib/components/Spinner.svelte";
```
No slots, no events, no properties. Just use `` whenever something is loading.
## Toast Notifications
Toast notifications are implemented as a writable store and are easy to use from any script section. They are an easy way to feedback to the user. To use them just import the notifications store
```ts
import { notifications } from "$lib/components/toasts/notifications";
```
and call one of the 4 toast methods:
| Method | Description |
| -------------------------------------------------- | --------------------------------------------------- |
| `notification.error(msg:string, timeout:number)` | :octicons-x-circle-16: Shows an error message |
| `notification.warning(msg:string, timeout:number)` | :octicons-alert-16: Shows a warning message |
| `notification.info(msg:string, timeout:number)` | :octicons-info-16: Shows an info message |
| `notification.success(msg:string, timeout:number)` | :octicons-check-circle-16: Shows as success message |
Each method takes an `msg`-string as an argument, which will be shown as the message body. It accepts HTML to enrich your toasts, if you should desire to do so. The `timeout` argument specifies how many milliseconds the toast notification shall be shown to the user.
## Github Update Dialog
This is a modal showing the update progress, possible error messages and makes a full page refresh 5 seconds after the OTA was successful.
## Update Indicator
The update indicator is a small widget shown in the upper right corner of the status bar. It indicates the availability of a newer firmware release then the current one. Upon pressing the icon it will automatically update the firmware to the latest release. By default this works through the Github Latest Release API. This must be customized should you use a different update server. Have a look at the [source file](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/lib/components/GithubUpdateDialog.svelte) to see what portions to update.
## Info Dialog
Shows a modal on the UI which must be deliberately dismissed. It features a `title` and a `message` property. The dismiss button can be customized via the `dismiss` property with a label and an icon. `onDismiss` call back must close the modal and can be used to do something when closing the info dialog.
```ts
import InfoDialog from "$lib/components/InfoDialog.svelte";
modals.open(InfoDialog, {
title: 'You have a new Info',
message:
'Something really important happened that justifies showing you a modal which must be clicked away.',
dismiss: { label: 'OK', icon: Check },
onDismiss: () => modals.close();
});
```
This modal is based on [svelte-modals](https://svelte-modals.mattjennings.io/) where you can find further information.
## Confirm Dialog
Shows a confirm modal on the UI which must be confirmed to proceed, or can be canceled. It features a `title` and a `message` property. The `confirm` and `cancel` buttons can be customized via the `labels` property with a label and an icon. `onConfirm` call back must close the modal and can be used to trigger further actions.
```ts
import ConfirmDialog from "$lib/components/ConfirmDialog.svelte";
modals.open(ConfirmDialog, {
title: "Confirm what you are doing",
message: "Are you sure you want to proceed? This could break stuff!",
labels: {
cancel: { label: "Abort", icon: Cancel },
confirm: { label: "Confirm", icon: Check },
},
onConfirm: () => modals.close(),
});
```
This modal is based on [svelte-modals](https://svelte-modals.mattjennings.io/) where you can find further information.
================================================
FILE: docs/gettingstarted.md
================================================
# Getting Started
## Prerequisites
This project has quite a complicated build chain to prepare the frontend code for the ESP32. You will need to install some tools to make this all work, starting with a powerful code editor.
### Softwares to Install
Please install the following software, if you haven't already:
- [VSCode](https://code.visualstudio.com/) - IDE for development
- [Node.js](https://nodejs.org) - For building the interface with npm
### VSCode Plugins and Setups
Please install the following mandatory VSCode Plugins:
- [PlatformIO](https://platformio.org/) - Embedded development platform
- [Prettier](https://prettier.io/) - Automated code formatter
- Svelte for VS Code - Makes working with Svelte much easier
- Svelte Intellisense - Another Svelte tool
- Tailwind CSS Intellisense - Makes working with Tailwind CSS much easier
- [Prettier plugin for Tailwind CSS](https://github.com/tailwindlabs/prettier-plugin-tailwindcss) - Automatically sorts the Tailwind classes into their recommended order
Lastly, if you want to make use of Materials for MkDocs as your documentation engine, install [Material for MkDocs](https://squidfunk.github.io/mkdocs-material/) by typing the following into the VSCode terminal:
```bash
pip install mkdocs-material
```
!!! tip
You might need to run this as administrator, if you getting an error message.
### Project Structure
| Resource | Description |
| -------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| [.github/](https://github.com/theelims/ESP32-sveltekit/blob/main/.github) | Github CI pipeline to deploy MkDocs to gh-pages |
| [docs/](https://github.com/theelims/ESP32-sveltekit/blob/main/docs) | MkDocs documentation files |
| [interface/](https://github.com/theelims/ESP32-sveltekit/blob/main/interface) | SvelteKit based front end |
| [lib/framework/](https://github.com/theelims/ESP32-sveltekit/blob/main/lib/framework) | C++ back end for the ESP32 device |
| [src/](https://github.com/theelims/ESP32-sveltekit/blob/main/src) | The main.cpp and demo project to get you started |
| [scripts/](https://github.com/theelims/ESP32-sveltekit/tree/main/scripts) | Scripts that build the interface as part of the platformio build |
| [platformio.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/platformio.ini) | PlatformIO project configuration file |
| [mkdocs.yaml](https://github.com/theelims/ESP32-sveltekit/blob/main/mkdocs.yaml) | MkDocs project configuration file |
## Setting up PlatformIO
### Setup Build Target
!!! danger "Do not use the PlatformIO UI for editing platformio.ini"
It is tempting to use the PlatformIO user interface to add dependencies or parameters to platformio.ini. However, doing so will remove all "irrelevant" information like comments from the file. Please edit the file directly in the editor.
[platformio.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/platformio.ini) is the central file controlling the whole build process. It comes pre-configure with a few boards which have different ESP32 chips. It needs to be adapted to the board you want to program.
```ini
[platformio]
...
default_envs = esp32-s3-devkitc-1
...
[env:adafruit_feather_esp32_v2]
board = adafruit_feather_esp32_v2
board_build.mcu = esp32
[env:lolin_c3_mini]
board = lolin_c3_mini
board_build.mcu = esp32c3
[env:esp32-s3-devkitc-1]
board = esp32-s3-devkitc-1
board_build.mcu = esp32s3
```
If your board is not listed in the platformio.ini you may look in the [official board list](https://docs.platformio.org/en/latest/boards/index.html#espressif-32) for supported boards and add their information accordingly. Either delete the obsolete `[env:...]` sections, or change your board as `default_envs = ...`.
!!! info "Default setup is for an ESP32-S3-DevKitC/M board"
The projects platformio.ini defaults for an ESP32-S3-DevKitC/M board by Espressif connected to the UART USB port. If you use an other board and the projects shows an undesired behavior it is likely that some parts do not match with pin definitions.
### Build & Upload Process
After you've changed [platformio.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/platformio.ini) to suit your board you can upload the sample code to your board. This will download all ESP32 libraries and execute `node install` to install all node packages as well. Select your board's environment under the PlatformIO tab and hit `Upload and Monitor`.

The first build process will take a while. After a couple of minutes you can see the ESP32 outputting information on the terminal. Some of the python scripts might need to install additional packages. In that case the first build process will fail. Just run it a second time.
!!! tip "Use several terminals in parallel"
VSCode allows you to have more then one terminal running at the same time. You can dedicate one terminal to the serial monitor, while having the development server running in an other terminal.
## Setting up SvelteKit
### Setup Proxy for Development
To ease the frontend development you can deploy the back end code on an ESP32 board and pass the websocket and REST API calls through the development server's proxy.
The [vite.config.ts](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/vite.config.ts) file defines the location of the services which the development server will proxy. This is defined by the "target" property, which will need to be changed to the the IP address or hostname of the device running the firmware. Change this for both, "http://" and "ws://".
```ts
proxy: {
// Proxying REST: http://localhost:5173/rest/bar -> http://192.168.1.83/rest/bar
'/rest': {
target: 'http://192.168.1.83',
changeOrigin: true,
},
// Proxying websockets ws://localhost:5173/ws -> ws://192.168.1.83/ws
'/ws': {
target: 'ws://192.168.1.83',
changeOrigin: true,
ws: true,
},
},
```
!!! tip
You must restart the development server for changes of the proxy location to come into effect.
### Development Server
The interface comes with Vite as a development server. It allows hot module reloading reflecting code changes to the front end instantly in your browser. Open a new terminal session and execute the following commands:
```bash
cd interface
npm run dev
```
Follow the link to access the front end in your browser.
## Setup Material for mkdocs
Material for MkDocs allows you to create great technical documentation pages just from markup. If you don't want to use it just delete the `.github` and `docs` folder, as well as `mkdocs.yaml`.
Otherwise initiate the github CI pipeline by committing and pushing to your repository once. This triggers the automatic build. After a few minutes a new branch `gh-pages` containing the static website with your documentation should appear. To deploy it go to your github repository go under settings and complete the following steps.

### Development Server
MkDocs comes with a build-in development server which supports hot reload as well. Open a new terminal session in VSCode and type
```
mkdocs serve
```
================================================
FILE: docs/index.md
================================================
---
hide:
- navigation
- toc
---
# ESP32 SvelteKit - Create Amazing IoT Projects
A simple and extensible framework for ESP32 based IoT projects with a feature-rich, beautiful, and responsive front-end build with [Sveltekit](https://kit.svelte.dev/), [TailwindCSS](https://tailwindcss.com/) and [DaisyUI](https://daisyui.com/). This is a project template to get you started in no time backed by a powerful back end service, an amazing front end served from the ESP32 and an easy to use build chain to get everything going.
It was forked from the fabulous [rjwats/esp8266-react](https://github.com/rjwats/esp8266-react) project, from where it inherited the mighty back end services.
!!! info
This template repository is not meant to be used stand alone. If you're just looking for a WiFi manager there are plenty of options available. This is a starting point when you need a rich web UI.
## Features
### :butterfly: Beautiful UI powered by DaisyUI and TailwindCSS
Beautiful, responsive UI which works equally well on desktop and on mobile. Gently animated for a snappy and modern feeling without ever being obtrusive or in the way. Easy theming with DaisyUI and media-queries to respect the users wish for a light or dark theme.
### :simple-svelte: Low Memory Footprint and Easy Customization by Courtesy of SvelteKit
SvelteKit is ideally suited to be served from constrained devices like an ESP32. It's unique approach leads to very slim files. No bloatware like other popular JS frameworks. Not only the low memory footprint make it ideal but the developer experience is also outstanding letting you customize the front end with ease. Adapt and add functionality as you need it. The back end has you covered as well.
### :telephone: Rich Communication Interfaces
Comes with a rich set of communication interfaces to cover most standard needs of an IoT application. Like MQTT client, HTTP RESTful API, a WebSocket based Event Socket and a classic Websocket Server. All communication channels are stateful and fully synchronized. Changes propagate and are communicated to all other participants. The states can be persisted on the file system as well. For accurate time keeping time can by synchronized over NTP.
### :file_cabinet: WiFi Provisioning and Management
Naturally ESP32 SvelteKit comes with rich features to manage all your WiFi needs. From pulling up an access point for provisioning or as fall back, to fully manage your WiFi networks. Scan for available networks and connect to them. Advanced configuration options like static IP are on board as well.
### :people_with_bunny_ears_partying: Secured API and User Management
Manage different user of your app with two authorization levels. An administrator and a guest user. Authenticate their API calls with a JWT token. Manage the user's profile from the admin interface. Use at own risk, as it is neither secure without the ability to use TLS/SSL encryption on the ESP32 server, nor very convenient, as only an admin can change passwords.
### :airplane: OTA Upgrade Service
The framework can provide two different channels for Over-the-Air updates. Either by uploading a \*.bin file from the web interface. Or by pulling a firmware image from an update server. This is implemented with the github release page as an example. It is even possible to have different build environments at the same time and the Github OTA process pulls the correct binary.
### :construction_site: Automated Build Chain
The automated build chain takes out the pain and tears of getting all the bits and pieces play nice together. The repository contains a PlatformIO project at its heart. A SvelteKit project for the frontend code and a mkdocs project for the documentation go alongside. The PlatformIO build tools not only build the SvelteKit frontend with Vite, but also ensure that the build results are gzipped and find their way into the flash memory of the ESP32. You have two choices to serve the frontend either from the flash partition, or embedded into the firmware binary. The latter is much more friendly if your frontend code should be distributed OTA as well, leaving all configuration files intact.
### :fontawesome-solid-microchip: Compatible with all ESP32 Flavours
The code runs on all variants of the ESP32 chip family. From the plain old ESP32, the ESP32-S3 and ESP32-C3. Other ESP32 variants might work, but haven't been tested. Sorry, no support for the older ESP8266. Go with one of the ESP32's instead.
[Let's get started!](gettingstarted.md)
## License
ESP32 SvelteKit is distributed with two licenses for different sections of the code. The back end code inherits the GNU LESSER GENERAL PUBLIC LICENSE Version 3 and is therefore distributed with said license. The front end code is distributed under the MIT License. See the [LICENSE](https://github.com/theelims/ESP32-sveltekit/blob/main/LICENSE) for a full text of both licenses.
================================================
FILE: docs/restfulapi.md
================================================
# RESTful API
The back end exposes a number of API endpoints which are referenced in the table below.
| Method | Request URL | Authentication | POST JSON Body | Info |
| ------ | --------------------------------------- | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| GET | /rest/features | `NONE_REQUIRED` | none | Tells the client which features of the UI should be use |
| GET | /rest/mqttStatus | `IS_AUTHENTICATED` | none | Current MQTT connection status |
| GET | /rest/mqttSettings | `IS_ADMIN` | none | Currently used MQTT settings |
| POST | /rest/mqttSettings | `IS_ADMIN` | `{"enabled":false,"uri":"mqtt://192.168.1.12:1883","username":"","password":"","client_id":"esp32-f412fa4495f8","keep_alive":120,"clean_session":true,"message_interval_ms":0}` | Update MQTT settings with new parameters |
| GET | /rest/ntpStatus | `IS_AUTHENTICATED` | none | Current NTP connection status |
| GET | /rest/ntpSettings | `IS_ADMIN` | none | Current NTP settings |
| POST | /rest/ntpSettings | `IS_ADMIN` | `{"enabled": true,"server": "time.google.com","tz_label": "Europe/London","tz_format": "GMT0BST,M3.5.0/1,M10.5.0"}` | Update the NTP settings |
| GET | /rest/apStatus | `IS_AUTHENTICATED` | none | Current AP status and client information |
| GET | /rest/apSettings | `IS_ADMIN` | none | Current AP settings |
| POST | /rest/apSettings | `IS_ADMIN` | `{"provision_mode": 1,"ssid": "ESP32-SvelteKit-e89f6d20372c","password": "esp-sveltekit","channel": 1,"ssid_hidden": false,"max_clients": 4,"local_ip": "192.168.4.1","gateway_ip": "192.168.4.1","subnet_mask": "255.255.255.0"}` | Update AP settings |
| GET | /rest/wifiStatus | `IS_AUTHENTICATED` | none | Current status of the wifi client connection |
| GET | /rest/scanNetworks | `IS_ADMIN` | none | Async Scan for Networks in Range |
| GET | /rest/listNetworks | `IS_ADMIN` | none | List networks in range after successful scanning. Otherwise triggers scanning. |
| GET | /rest/wifiSettings | `IS_ADMIN` | none | Current WiFi settings |
| POST | /rest/wifiSettings | `IS_ADMIN` | `{"hostname":"esp32-f412fa4495f8","connection_mode":1,"wifi_networks":[{"ssid":"YourSSID","password":"YourPassword","static_ip_config":false}]}` | Update WiFi settings and credentials |
| GET | /rest/systemStatus | `IS_AUTHENTICATED` | none | Get system information about the ESP. |
| POST | /rest/restart | `IS_ADMIN` | none | Restart the ESP32 |
| POST | /rest/factoryReset | `IS_ADMIN` | none | Reset the ESP32 and all settings to their default values |
| POST | /rest/uploadFirmware | `IS_ADMIN` | none | File upload of firmware.bin |
| POST | /rest/signIn | `NONE_REQUIRED` | `{"password": "admin","username": "admin"}` | Signs a user in and returns access token |
| GET | /rest/securitySettings | `IS_ADMIN` | none | retrieves all user information and roles |
| POST | /rest/securitySettings | `IS_ADMIN` | `{"jwt_secret": "734cb5bb-5597b722", "users": [{"username": "admin", "password": "admin", "admin": true}, {"username": "guest", "password": "guest", "admin": false, }]}` | retrieves all user information and roles |
| GET | /rest/verifyAuthorization | `NONE_REQUIRED` | none | Verifies the content of the auth bearer token |
| GET | /rest/generateToken?username={username} | `IS_ADMIN` | `{"token": "734cb5bb-5597b722"}` | Generates a new JWT token for the user from username |
| POST | /rest/sleep | `IS_AUTHENTICATED` | none | Puts the device in deep sleep mode |
| POST | /rest/downloadUpdate | `IS_ADMIN` | `{"download_url": "https://github.com/theelims/ESP32-sveltekit/releases/download/v0.1.0/firmware_esp32s3.bin"}` | Download link for OTA. This requires a valid SSL certificate and will follow redirects. |
| GET | /rest/coreDump | `IS_AUTHENTICATED` | Text | Core dump of the last crash. |
================================================
FILE: docs/statefulservice.md
================================================
# Developing with the Framework
The back end is a set of REST endpoints hosted by a [PsychicHttp](https://github.com/hoeken/PsychicHttp) instance. The ['lib/framework'](https://github.com/theelims/ESP32-sveltekit/blob/main/lib/framework) directory contains the majority of the back end code. The framework contains 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.
The framework's source is split up by feature, for example [WiFiScanner.h](https://github.com/theelims/ESP32-sveltekit/blob/main/lib/framework/WiFiScanner.h) implements the end points for scanning for available networks where as [WiFiSettingsService.h](https://github.com/theelims/ESP32-sveltekit/blob/main/lib/framework/WiFiSettingsService.h) handles configuring the WiFi settings and managing the WiFi connection.
## Initializing the framework
The ['src/main.cpp'](https://github.com/theelims/ESP32-sveltekit/blob/main/src/main.cpp) file constructs the web server and initializes the framework. You can add endpoints to the server here to support your IoT project. The main loop is also accessible so you can run your own code easily.
The following code creates the web server and esp32sveltekit framework:
```cpp
PsychicHttpServer server;
ESP32SvelteKit esp32sveltekit(&server, 120);
```
ESP32SvelteKit is instantiated with a reference to the server and a number of HTTP endpoints. The underlying ESP-IDF HTTP Server statically allocates memory for each endpoint and needs to know how many there are. Best is to inspect your WWWData.h file for the number of Endpoints from SvelteKit (currently 60), the framework itself has 37 endpoints, and Lighstate Demo has 7 endpoints. Each `_server.on()` counts as an endpoint. Don't forget to add a couple of spare, just in case. Each HttpEndpoint adds 2 endpoints, if CORS is enabled it adds an other endpoint for the CORS preflight request.
Now in the `setup()` function the initialization is performed:
```cpp
void setup() {
// start serial and filesystem
Serial.begin(SERIAL_BAUD_RATE);
// start the framework and demo project
esp32sveltekit.begin();
}
```
`server.begin()` is called by ESP32-SvelteKit, as the start-up sequence is crucial.
## Stateful Service
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.
The following diagram visualizes how the framework's modular components fit together, each feature is described in detail below.

The [StatefulService.h](https://github.com/theelims/ESP32-sveltekit/blob/main/lib/framework/StatefulService.h) class is responsible for managing state. It has an API which allows other code to update or respond to updates in the state it manages. You can define a data class to hold state, then build a StatefulService class to manage it. After that you may attach HTTP endpoints, WebSockets or MQTT topics to the StatefulService instance to provide commonly required features.
Here is a simple example of a state class and a StatefulService to manage it:
```cpp
class LightState {
public:
bool on = false;
uint8_t brightness = 255;
};
class LightStateService : public StatefulService {
};
```
### Update Handler
You may listen for changes to state by registering an update handler callback. It is possible to remove an update handler later if required.
```cpp
// register an update handler
update_handler_id_t myUpdateHandler = lightStateService.addUpdateHandler(
[&](const String& originId) {
Serial.print("The light's state has been updated by: ");
Serial.println(originId);
}
);
// remove the update handler
lightStateService.removeUpdateHandler(myUpdateHandler);
```
An "originId" is passed to the update handler which may be used to identify the origin of an update. The default origin values the framework provides are:
| Origin | Description |
| -------------------------- | ----------------------------------------------- |
| http | An update sent over REST (HttpEndpoint) |
| mqtt | An update sent over MQTT (MqttEndpoint) |
| websocketserver:{clientId} | An update sent over WebSocket (WebSocketServer) |
### Hook Handler
Sometimes if can be desired to hook into every update of an state, even if the StateUpdateResult is `StateUpdateResult::UNCHANGED` and the update handler isn't called. In such cases you can use the hook handler. Similarly it can be removed later.
```cpp
// register an update handler
hook_handler_id_t myHookHandler = lightStateService.addHookHandler(
[&](const String& originId, StateUpdateResult &result) {
Serial.printf("The light's state has been updated by: %s with result %d\n", originId, result);
}
);
// remove the update handler
lightStateService.removeHookHandler(myHookHandler);
```
### Read & Update State
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 environments such as the ESP32.
```cpp
lightStateService.read([&](LightState& state) {
digitalWrite(LED_PIN, state.on ? HIGH : LOW); // apply the state update to the LED_PIN
});
```
StatefulService also exposes an update function which allows the caller to update the state with a callback. This function automatically calls the registered update handlers if the state has been changed. The example below changes the state of the light (turns it on) using the arbitrary origin "timer" and returns the "CHANGED" state update result, indicating that a change was made:
```cpp
lightStateService.update([&](LightState& state) {
if (state.on) {
return StateUpdateResult::UNCHANGED; // lights were already on, return UNCHANGED
}
state.on = true; // turn on the lights
return StateUpdateResult::CHANGED; // notify StatefulService by returning CHANGED
}, "timer");
```
There are three possible return values for an update function which are as follows:
| Origin | Description |
| ---------------------------- | ------------------------------------------------------------------------ |
| StateUpdateResult::CHANGED | The update changed the state, propagation should take place if required |
| StateUpdateResult::UNCHANGED | The state was unchanged, propagation should not take place |
| StateUpdateResult::ERROR | There was an error updating the state, propagation should not take place |
### JSON Serialization
When reading or updating state from an external source (HTTP, WebSockets, or MQTT for example) the state must be marshalled into a serializable form (JSON). SettingsService provides two callback patterns which facilitate this internally:
| Callback | Signature | Purpose |
| ---------------- | ------------------------------------------------------- | --------------------------------------------------------------------------------- |
| JsonStateReader | void read(T& settings, JsonObject& root) | Reading the state object into a JsonObject |
| JsonStateUpdater | StateUpdateResult update(JsonObject& root, T& settings) | Updating the state from a JsonObject, returning the appropriate StateUpdateResult |
The static functions below can be used to facilitate the serialization/deserialization of the light state:
```cpp
class LightState {
public:
bool on = false;
uint8_t brightness = 255;
static void read(LightState& state, JsonObject& root) {
root["on"] = state.on;
root["brightness"] = state.brightness;
}
static StateUpdateResult update(JsonObject& root, LightState& state) {
state.on = root["on"] | false;
state.brightness = root["brightness"] | 255;
return StateUpdateResult::CHANGED;
}
};
```
For convenience, the StatefulService class provides overloads of its `update` and `read` functions which utilize these functions.
Read the state to a JsonObject using a serializer:
```cpp
JsonObject jsonObject = jsonDocument.to();
lightStateService->read(jsonObject, LightState::read);
```
Update the state from a JsonObject using a deserializer:
```cpp
JsonObject jsonObject = jsonDocument.as();
lightStateService->update(jsonObject, LightState::update, "timer");
```
### HTTP RESTful Endpoint
The framework provides an [HttpEndpoint.h](https://github.com/theelims/ESP32-sveltekit/blob/main/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.
The code below demonstrates how to extend the LightStateService class to provide an endpoint:
```cpp
class LightStateService : public StatefulService {
public:
LightStateService(PsychicHttpServer* server, ESP32SvelteKit *sveltekit) :
_httpEndpoint(LightState::read, LightState::update, this, server, "/rest/lightState", sveltekit->getSecurityManager(),AuthenticationPredicates::IS_AUTHENTICATED) {
}
void begin(); {
_httpEndpoint.begin();
}
private:
HttpEndpoint _httpEndpoint;
};
```
Endpoint security is provided by authentication predicates which are [documented below](#security-features). The SecurityManager and authentication predicate must be provided, even if no secure endpoint is required. The placeholder project shows how endpoints can be secured.
To register the HTTP endpoints with the web server the function `_httpEndpoint.begin()` must be called in the custom StatefulService Class' own `void begin()` function.
### File System Persistence
[FSPersistence.h](https://github.com/theelims/ESP32-sveltekit/blob/main/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.
The code below demonstrates how to extend the LightStateService class to provide persistence:
```cpp
class LightStateService : public StatefulService {
public:
LightStateService(ESP32SvelteKit *sveltekit) :
_fsPersistence(LightState::read, LightState::update, this, sveltekit->getFS(), "/config/lightState.json") {
}
private:
FSPersistence _fsPersistence;
};
```
### Event Socket Endpoint
[EventEndpoint.h](https://github.com/theelims/ESP32-sveltekit/blob/main/lib/framework/EventEndpoint.h) wraps the [Event Socket](#event-socket) into an endpoint compatible with a stateful service. The client may subscribe and unsubscribe to this event to receive updates or push updates to the ESP32. The current state is synchronized upon subscription.
The code below demonstrates how to extend the LightStateService class to provide an WebSocket:
```cpp
class LightStateService : public StatefulService {
public:
LightStateService(ESP32SvelteKit *sveltekit) :
_eventEndpoint(LightState::read, LightState::update, this, sveltekit->getSocket(), "led") {}
void begin()
{
_eventEndpoint.begin();
}
private:
EventEndpoint _eventEndpoint;
};
```
To register the event endpoint with the event socket the function `_eventEndpoint.begin()` must be called in the custom StatefulService Class' own `void begin()` function.
Since all events run through one websocket connection it is not possible to use the [securityManager](#security-features) to limit access to individual events. The security defaults to `AuthenticationPredicates::IS_AUTHENTICATED`.
### WebSocket Server
[WebSocketServer.h](https://github.com/theelims/ESP32-sveltekit/blob/main/lib/framework/WebSocketServer.h) allows you to read and update state over a WebSocket connection. WebSocketServer automatically pushes changes to all connected clients when state is updated.
The code below demonstrates how to extend the LightStateService class to provide an WebSocket:
```cpp
class LightStateService : public StatefulService {
public:
LightStateService(PsychicHttpServer* server, ESP32SvelteKit *sveltekit) :
_webSocket(LightState::read, LightState::update, this, server, "/ws/lightState", sveltekit->getSecurityManager(), AuthenticationPredicates::IS_AUTHENTICATED), {
}
void begin() {
_webSocketServer.begin();
}
private:
WebSocketServer _webSocketServer;
};
```
WebSocket security is provided by authentication predicates which are [documented below](#security-features). The SecurityManager and authentication predicate must be provided, even if no secure endpoint is required. The placeholder project shows how endpoints can be secured.
To register the WS endpoint with the web server the function `_webSocketServer.begin()` must be called in the custom StatefulService Class' own `void begin()` function.
### MQTT Client
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.
[MqttEndpoint.h](https://github.com/theelims/ESP32-sveltekit/blob/main/lib/framework/MqttEndpoint.h) allows you to publish and subscribe to synchronize state over a pair of MQTT topics. MqttEndpoint automatically pushes changes to the "pub" topic and reads updates from the "sub" topic.
The code below demonstrates how to extend the LightStateService class to interface with MQTT:
```cpp
class LightStateService : public StatefulService {
public:
LightStateService(ESP32SvelteKit *sveltekit) :
_mqttEndpoint(LightState::read,
LightState::update,
this,
sveltekit->getMqttClient(),
"homeassistant/light/my_light/set",
"homeassistant/light/my_light/state") {
}
private:
MqttEndpoint _mqttEndpoint;
};
```
You can re-configure the pub/sub topics at runtime as required:
```cpp
_mqttEndpoint.configureBroker("homeassistant/light/desk_lamp/set", "homeassistant/light/desk_lamp/state");
```
The demo project allows the user to modify the MQTT topics via the UI so they can be changed without re-flashing the firmware.
## Event Socket
Beside RESTful HTTP Endpoints the Event Socket System provides a convenient communication path between the client and the ESP32. It uses a single WebSocket connection to synchronize state and to push realtime data to the client. The client needs to subscribe to the topics he is interested. Only clients who have an active subscription will receive data. Every authenticated client may make use of this system as the security settings are set to `AuthenticationPredicates::IS_AUTHENTICATED`.
### Message Format
The event messages exchanged between the ESP32 and its clients consists of an "event" head and the "data" payload. For the LightState example a message looks like this in JSON representation:
```JSON
{
"event": "led",
"data": {
"led_on": true
}
}
```
To save on bandwidth the event message is encoded as binary [MessagePack](https://msgpack.org/) instead of a JSON.
To subscribe the client has to send the following message (as MessagePack):
```JSON
{
"event": "subscribe",
"data": "analytics"
}
```
### Emit an Event
The Event Socket provides an `emitEvent()` function to push data to all subscribed clients. This is used by various esp32sveltekit classes to push real time data to the client. First an event must be registered with the Event Socket by calling `_socket.registerEvent("CustomEvent");`. Only then clients may subscribe to this custom event and you're entitled to emit event data:
```cpp
void emitEvent(String event, JsonObject &jsonObject, const char *originId = "", bool onlyToSameOrigin = false);
```
The latter function allowing a selection of the recipient. If `onlyToSameOrigin = false` the payload is distributed to all subscribed clients, except the `originId`. If `onlyToSameOrigin = true` only the client with `originId` will receive the payload. This is used by the [EventEndpoint](#event-socket-endpoint) to sync the initial state when a new client subscribes.
### Receive an Event
A callback or lambda function can be registered to receive an ArduinoJSON object and the originId of the client sending the data:
```cpp
_socket.onEvent("CostumEvent",[&](JsonObject &root, int originId)
{
bool ledState = root["led_on"];
});
```
### Get Notified on Subscriptions
Similarly a callback or lambda function may be registered to get notified when a client subscribes to an event:
```cpp
_socket.onSubscribe("CostumEvent",[&](const String &originId)
{
Serial.println("New Client subscribed: " + originId);
});
```
The boolean parameter provided will always be `true`.
### Push Notifications to All Clients
It is possibly to send push notifications to all clients by using the Event Socket. These will be displayed as toasts an the client side. Either directly call
```cpp
esp32sveltekit.getNotificationService()->pushNotification("Pushed a message!", PUSHINFO);
```
or keep a local pointer to the `EventSocket` instance. It is possible to send `PUSHINFO`, `PUSHWARNING`, `PUSHERROR` and `PUSHSUCCESS` events to all clients.
## Security features
The framework has security features to prevent unauthorized use of the device. This is driven by [SecurityManager.h](https://github.com/theelims/ESP32-sveltekit/blob/main/lib/framework/SecurityManager.h).
On successful authentication, the /rest/signIn endpoint issues a [JSON Web Token (JWT)](https://jwt.io/) which is then sent using Bearer Authentication. For this add an `Authorization`-Header to the request with the Content `Bearer {JWT-Secret}`. The framework come with built-in predicates for verifying a users access privileges. The built in AuthenticationPredicates can be found in [SecurityManager.h](https://github.com/theelims/ESP32-sveltekit/blob/main/lib/framework/SecurityManager.h) and are as follows:
| Predicate | Description |
| ---------------- | --------------------------------------------- |
| NONE_REQUIRED | No authentication is required. |
| IS_AUTHENTICATED | Any authenticated principal is permitted. |
| IS_ADMIN | The authenticated principal must be an admin. |
You can use the security manager to wrap any request handler function with an authentication predicate:
```cpp
server->on("/rest/someService", HTTP_GET,
_securityManager->wrapRequest(std::bind(&SomeService::someService, this, std::placeholders::_1), AuthenticationPredicates::IS_AUTHENTICATED)
);
```
In case of a websocket connection the JWT token is supplied as a search parameter in the URL when establishing the connection:
```
/ws/lightState?access_token={JWT Token}
```
## Placeholder substitution
Various settings support placeholder substitution, indicated by comments in [factory_settings.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/factory_settings.ini). This can be particularly useful where settings need to be unique, such as the Access Point SSID or MQTT client id. Strings must be properly escaped in the ini-file. The following placeholders are supported:
| Placeholder | Substituted value |
| ------------ | --------------------------------------------------------------------- |
| #{platform} | The microcontroller platform, e.g. "esp32" or "esp32c3" |
| #{unique_id} | A unique identifier derived from the MAC address, e.g. "0b0a859d6816" |
| #{random} | A random number encoded as a hex string, e.g. "55722f94" |
You may use SettingValue::format in your own code if you require the use of these placeholders. This is demonstrated in the demo project:
```cpp
static StateUpdateResult update(JsonObject& root, LightMqttSettings& settings) {
settings.mqttPath = root["mqtt_path"] | SettingValue::format("homeassistant/light/#{unique_id}");
settings.name = root["name"] | SettingValue::format("light-#{unique_id}");
settings.uniqueId = root["unique_id"] | SettingValue::format("light-#{unique_id}");
return StateUpdateResult::CHANGED;
}
```
## Accessing settings and services
The framework supplies access to various features via getter functions:
| SettingsService | Description |
| ---------------------------- | -------------------------------------------------- |
| getFS() | The filesystem used by the framework |
| getSecurityManager() | The security manager - detailed above |
| getSecuritySettingsService() | Configures the users and other security settings |
| getWiFiSettingsService() | Configures and manages the WiFi network connection |
| getAPSettingsService() | Configures and manages the Access Point |
| getNTPSettingsService() | Configures and manages the network time |
| getMqttSettingsService() | Configures and manages the MQTT connection |
| getMqttClient() | Provides direct access to the MQTT client instance |
| getNotificationEvents() | Lets you send push notifications to all clients |
| getSleepService() | Send the ESP32 into deep sleep |
| getBatteryService() | Update battery information on the client |
The core features use the [StatefulService.h](https://github.com/theelims/ESP32-sveltekit/blob/main/lib/framework/StatefulService.h) class and therefore you can change settings or observe changes to settings through the read/update API.
Inspect the current WiFi settings:
```cpp
esp32sveltekit.getWiFiSettingsService()->read([&](WiFiSettings& wifiSettings) {
Serial.print("The ssid is:");
Serial.println(wifiSettings.ssid);
});
```
Configure the WiFi SSID and password manually:
```cpp
esp32sveltekit.getWiFiSettingsService()->update([&](WiFiSettings& wifiSettings) {
wifiSettings.ssid = "MyNetworkSSID";
wifiSettings.password = "MySuperSecretPassword";
return StateUpdateResult::CHANGED;
}, "myapp");
```
Observe changes to the WiFiSettings:
```cpp
esp32sveltekit.getWiFiSettingsService()->addUpdateHandler(
[&](const String& originId) {
Serial.println("The WiFi Settings were updated!");
}
);
```
## Other functions provided
### MDNS Instance Name
ESP32 SvelteKit uses mDNS / Bonjour to advertise its services into the local network. You can set the mDNS instance name property by calling
```cpp
esp32sveltekit.setMDNSAppName("ESP32 SvelteKit Demo App");
```
making the entry a little bit more verbose. This must be called before `esp32sveltekit.begin();`. If you want to advertise further services just include `#include ` and use `MDNS.addService()` regularly.
### Use ESP32-SvelteKit loop() Function
Under some circumstances custom services might want to do something periodically. One solution would be to use a dedicated task or RTOS timer for this. Or you can leverage the ESP32-SvelteKit loop-function and have it executed as a callback every 20ms.
```cpp
esp32sveltekit.addLoopFunction(callback)
```
### Factory Reset
A factory reset can not only be evoked from the API, but also by calling
```cpp
esp32sveltekit.factoryReset();
```
from your code. This will erase the complete settings folder, wiping out all settings. This can be a last fall back mode if somebody has forgotten his credentials.
### Recovery Mode
There is also a recovery mode present which will force the creation of an access point. By calling
```cpp
esp32sveltekit.recoveryMode();
```
will force a start of the AP regardless of the AP settings. It will not change the the AP settings. To exit the recovery mode restart the device or change the AP settings in the UI.
### Power Down with Deep Sleep
This API service can place the ESP32 in the lowest power deep sleep mode consuming only a few µA. It uses the EXT1 wakeup source, so the ESP32 can be woken up with a button or from a peripherals interrupt. Consult the [ESP-IDF Api Reference](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/sleep_modes.html#_CPPv428esp_sleep_enable_ext1_wakeup8uint64_t28esp_sleep_ext1_wakeup_mode_t) which GPIOs can be used for this. The RTC will also be powered down, so an external pull-up or pull-down resistor is required. It is not possible to persist variable state through the deep sleep. To optimize the deep sleep power consumption it is advisable to use the callback function to put pins with external pull-up's or pull-down's in a special isolated state to prevent current leakage. Please consult the [ESP-IDF Api Reference](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/sleep_modes.html#configuring-ios-deep-sleep-only) for this.
The settings wakeup pin definition and the signal polarity need to be defined in [factory_settings.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/factory_settings.ini):
```ini
; Deep Sleep Configuration
-D WAKEUP_PIN_NUMBER=38 ; pin number to wake up the ESP
-D WAKEUP_SIGNAL=0 ; 1 for wakeup on HIGH, 0 for wakeup on LOW
```
In addition it is possible to change this as well at runtime by calling:
```cpp
esp32sveltekit.getSleepService()->setWakeUpPin(int pin, bool level, pinTermination termination = pinTermination::FLOATING);
```
With this function it is also possible to configure the internal pull-up or pull-down resistor for this RTC pin. Albeit this might increase the deep sleep current slightly.
A callback function can be attached and triggers when the ESP32 is requested to go into deep sleep. This allows you to safely deal with the power down event. Like persisting software state by writing to the flash, tiding up or notify a remote server about the immanent disappearance.
```cpp
esp32sveltekit.getSleepService()->attachOnSleepCallback();
```
Also the code can initiate the power down deep sleep sequence by calling:
```cpp
esp32sveltekit.getSleepService()->sleepNow();
```
### Battery State of Charge
A small helper class let's you update the battery icon in the status bar. This is useful if you have a battery operated IoT device. It must be enabled in [features.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/features.ini). It uses the [Event Socket](#event-socket) and exposes two functions that can be used to update the clients.
```cpp
esp32sveltekit.getBatteryService()->updateSOC(float stateOfCharge); // update state of charge in percent (0 - 100%)
esp32sveltekit.getBatteryService()->setCharging(boolean isCharging); // notify the client that the device is charging
```
### ESP32-SvelteKit Connection Status
Especially for a cases like a colored status LED it can be useful to have a quick indication of the connection status. By calling:
```cpp
ConnectionStatus status = esp32sveltekit.getConnectionStatus();
```
the current connection status can be accessed. The following stats are available:
| Status | Description |
| ------------- | ------------------------------------------------------------------------------- |
| OFFLINE | Device is completely offline |
| AP | Access Point is available, but no client is connected |
| AP_CONNECTED | Access Point is used and at least 1 client is connected |
| STA | Device connected to a WiFi Station |
| STA_CONNECTED | Device connected to a WiFi Station and at least 1 client is connected |
| STA_MQTT | Device connected to a WiFi Station and the device is connected to a MQTT server |
### Custom Features
You may use the compile time feature service also to enable or disable custom features at runtime and thus control the frontend. A custom feature can only be added during initializing the ESP32 and ESP32-SvelteKit. The frontend queries the features only when first loading the page. Thus the frontend must be refreshed for the changes to become effective.
```cpp
esp32sveltekit.getFeatureService()->addFeature("custom_feature", true); // or false to disable it
```
## OTA Firmware Updates
ESP32-SvelteKit offers two different ways to roll out firmware updates to field devices. If the frontend should be updated as well it is necessary to embed it into the firmware binary by activating `-D EMBED_WWW`.
### Firmware Upload
Enabling `FT_UPLOAD_FIRMWARE=1` in [features.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/features.ini) creates a REST endpoint that one can post a firmware binary to. The frontend has a file drop zone to upload a new firmware binary from the browser.
### Firmware Download from Update Server
By enabling `FT_DOWNLOAD_FIRMWARE=1` in [features.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/features.ini) one can POST a link to a firmware binary which is downloaded for the OTA process. This feature requires SSL and is thus dependent on `FT_NTP=1`. The Frontend contains an implementation which uses GitHub's Releases section as the update server. By specifying a firmware version in [platformio.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/platformio.ini) one can make use of semantic versioning to determine the correct firmware:
```ini
-D BUILD_TARGET="$PIOENV"
-D APP_NAME=\"ESP32-Sveltekit\" ; Must only contain characters from [a-zA-Z0-9-_] as this is converted into a filename
-D APP_VERSION=\"0.3.0\" ; semver compatible version string
```
A build script copies the firmware binary files for all build environment to `build/firmware`. It renames them into `{APP_NAME}_{$PIOENV}_{APP_VERSION}.bin`. It also creates a MD5 checksum file for verification during the OTA process. These files can be used as attachment on the GitHub release pages.
!!! info
This feature could be unstable on single-core members of the ESP32 family.
#### Custom Update Server
If Github is not desired as the update server this can be easily modified to any other custom server. The REST API will accept any valid HTTPS-Link. However, SSL is mandatory and may require a different Root CA Certificate then Github to validate correctly.
Follow the instructions here how to change the [SSL CA Certificate](buildprocess.md#ssl-root-certificate-for-download-ota).
If you use a custom update server you must also adapt the [frontend](structure.md#custom-update-server) code to suit your needs.
================================================
FILE: docs/stores.md
================================================
# Stores
## User
The user store holds the current users credentials, if the security features are enabled. Just import it as you would use with any svelte store:
```ts
import { user } from "$lib/stores/user";
```
You can subscribe to it like to any other store with `$user` and it has the following properties:
| Property | Type | Description |
| -------------------- | --------- | ------------------------------------------------- |
| `$user.bearer_token` | `String` | The JWT token to authorize a user at the back end |
| `$user.username` | `String` | Username of the current user |
| `$user.admin` | `Boolean` | `true` if the current user has admin privileges |
In addition to the properties it provides two methods for initializing the user credentials and to invalidate them. `user.init()` takes a valid JWT toke as an argument and extracts the user privileges and username from it. `user.invalidate()` invalidates the user credentials and redirects to the login pages
!!! warning "User credentials are stored in the browsers local storage"
The user credentials including the JWT token are stored in the browsers local storage. Any javascript executed on the browser can access this making it extremely vulnerable to XSS attacks. Also the HTTP connection between ESP32 and front end is not encrypted making it possible for everyone to read the JWT token in the same network. Fixing these severe security issues is on the todo list for upcoming releases.
## Event Socket
The [Event Socket System](statefulservice.md#event-socket) is conveniently provided as a Svelte store. Import the store, subscribe to the data interested with `socket.on`. To unsubscribe simply call `socket.off`. Data can be sent to the ESP32 by calling `socket.sendEvent`
```ts
import { socket } from "$lib/stores/socket";
let lightState: LightState = { led_on: false };
onMount(() => {
socket.on("led", (data) => {
lightState = data;
});
});
onDestroy(() => socket.off("led"));
socket.sendEvent("led", lightState);
```
Subscribing to an invalid event will only create a warning in the ESP_LOG on the serial console of the ESP32.
## Telemetry
The telemetry store can be used to update telemetry data like RSSI via the [Event Socket](statefulservice.md#event-socket) system.
```ts
import { telemetry } from "$lib/stores/telemetry";
```
It exposes the following properties you can subscribe to:
| Property | Type | Description |
| ---------------------------------- | --------- | ------------------------------------------- |
| `$telemetry.rssi.rssi` | `Number` | The RSSI signal strength of the WiFi in dBm |
| `$telemetry.rssi.ssid` | `String` | Name of the connected WiFi station |
| `$telemetry.rssi.connected` | `Boolean` | Connection status of the WiFi |
| `$telemetry.battery.soc` | `Number` | Battery state of charge |
| `$telemetry.battery.charging` | `Boolean` | Is battery connected to charger |
| `$telemetry.download_ota.status` | `String` | Status of OTA |
| `$telemetry.download_ota.progress` | `Number` | Progress of OTA |
| `$telemetry.download_ota.error` | `String` | Error Message of OTA |
| `$telemetry.ethernet.connected` | `Boolean` | Connection status of the ethernet interface |
## Analytics
The analytics store holds a log of heap and other debug information via the [Event Socket](statefulservice.md#event-socket) system.
```ts
import { analytics } from "$lib/stores/analytics";
```
It exposes an array of the following properties you can subscribe to:
| Property | Type | Description |
| --------------------------- | -------- | ---------------------------------------------- |
| `$analytics.uptime` | `Number` | Uptime of the chip in seconds since last reset |
| `$analytics.free_heap` | `Number` | Current free heap |
| `$analytics.min_free_heap` | `Number` | Minimum free heap that has been |
| `$analytics.max_alloc_heap` | `Number` | Biggest continues free chunk of heap |
| `$analytics.fs_used` | `Number` | Bytes used on the file system |
| `$analytics.fs_total` | `Number` | Total bytes of the file system |
| `$analytics.core_temp` | `Number` | Core temperature (on some chips) |
By default there is one data point every 2 seconds. It holds 1000 data points worth roughly 33 Minutes of data.
================================================
FILE: docs/structure.md
================================================
# Customizing the Front End
The actual code for the front end is located under [interface/src/](https://github.com/theelims/ESP32-sveltekit/tree/main/interface/src) and divided into the "routes" folder and a "lib" folder for assets, stores and components.
| Resource | Description |
| ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| [routes/](https://github.com/theelims/ESP32-sveltekit/tree/main/interface/src/routes/) | Root of the routing system |
| [routes/connections/](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/routes/connections) | Setting and status pages for MQTT, NTP, etc. |
| [routes/demo/](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/routes/demo/) | The lightstate demo |
| [routes/system/](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/routes/system/) | Status page for ESP32 and OTA settings |
| [routes/user/](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/routes/user/) | Edit and add users and change passwords |
| [routes/wifi/](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/routes/wifi/) | Status and settings for WiFi station and AP |
| [lib/](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/lib/) | Library folder for stores, components and assets |
| [lib/assets/](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/lib/assets/) | Assets like pictures |
| [lib/components/](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/lib/components/) | Reusable components like modals, password input or collapsible |
| [lib/stores](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/lib/stores/) | Svelte stores for common access to data |
## Features
The back end provides a JSON which features of the back end are enabled by the [feature selection](buildprocess.md#selecting-features). It is fetched with the page load and made available in the `pages`-store and can be accessed on any site with `page.data.features`. It is used to hide any disabled setting element.
## Delete `demo/` Project
The light state demo project is included by default to demonstrate the use of the backend and front end. It demonstrates the use of the MQTT-API, websocket API and REST API to switch on the build in LED of the board. [routes/connections/mqtt/MQTTConfig.svelte](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/routes/connections/mqtt/MQTTConfig.svelte) is also part of the 'demo/' Project. You can reuse this to set your own MQTT topics, or delete it. Do not forget to adjust `+page.svelte` as well. Use it as an example how to create your own custom API and access it from the front end. It can be deleted safely after it has been [removed from the menu](#adapt-the-menu) as well.
## Create your root `+page.svelte`
The root page of the front end is located under [routes/+page.svelte](https://github.com/theelims/ESP32-sveltekit/tree/main/interface/src/routes/+page.svelte). This should be the central place of your app and can be accessed at any time by pressing the logo and app name in the side menu. Just override it to suit your needs.
## Customize the Main Menu
The main menu is located in [routes/menu.svelte](https://github.com/theelims/ESP32-sveltekit/tree/main/interface/src/routes/menu.svelte) as a svelte component and defines the main menu including a menu footer.
### Menu Footer
The main menu comes with a small footer to add your copyright notice plus links to github and your discord server where users can find help. The `active`-flag is used to disable an element in the UI. Most of these global parameters are set in the [routes/+layout.ts](https://github.com/theelims/ESP32-sveltekit/tree/main/interface/src/routes/+layout.ts).
```ts
const discord = { href: ".", active: false };
```
### Menu Structure
The menu consists of an array of menu items. These are defined as follows:
```ts
{
title: 'Demo App',
icon: Control,
href: '/demo',
feature: page.data.features.project,
},
```
- Where `title` refers to the page title. It must be identical to `page.data.title` as defined in the `+page.ts` in any of your routes. If they do not match the corresponding menu item is not highlighted on first page load or a page refresh. A minimum `+page.ts` looks like this:
```ts
import type { PageLoad } from "./$types";
export const load = (async ({ fetch }) => {
return {
title: "Demo App",
};
}) satisfies PageLoad;
```
- `icon` must be an icon component giving the menu items icon.
- `href` is the link to the route the menu item refers to.
- `feature` takes a bool and should be set to `true`. It is used by the [feature selector](#features) to hide a menu entry of it is not present on the back end.
## Advanced Customizations
On the root level there are two more files which you can customize to your needs.
### Login Page
`login.svelte` is a component showing the login screen, when the security features are enabled. By default it shows the app's logo and the login prompt. Change it as you need it.
### Status Bar
`statusbar.svelte` contains the top menu bar which you can customize to show state information about your app and IoT device. By default it shows the active menu title and the hamburger icon on small screens.
## Github Firmware Update
If the feature `FT_DOWNLOAD_FIRMWARE` is enabled, ESP32 SvelteKit pulls the Github Release section through the Github API for firmware updates once per hour. Also the firmware update menu shows all available firmware releases allowing the user to up- and downgrade has they please. If you're using the Github releases section you must first tell the frontend your correct path to your github repository as described [here](sveltekit.md#changing-the-app-name).
Also you must make use of couple build flags in [platformio.ini](https://github.com/theelims/ESP32-sveltekit/blob/main/platformio.ini):
```ini
-D BUILD_TARGET=\"$PIOENV\"
-D APP_NAME=\"ESP32-Sveltekit\" ; Must only contain characters from [a-zA-Z0-9-_] as this is converted into a filename
-D APP_VERSION=\"0.3.0\" ; semver compatible version string
```
Out of these flags the [rename_fw.py](https://github.com/theelims/ESP32-sveltekit/blob/main/scripts/rename_fw.py) script will copy and rename the firmware binary to `/build/firmware/{APP_NAME}_{$PIOENV}_{APP_VERSION}.bin`. In addition it will also create a corresponding MD5 checksum file. These files are ready to be uploaded to the Github release page without any further changes. The frontend searches for the firmware binary which matches the build environment and uses this as the update link. This allows you to serve different build targets (e.g. different boards) from the same release page.
### Custom Update Server
The frontend and backend code can be easily adjusted to suit a custom update server. For the backend the changes are described [here](statefulservice.md#custom-update-server). On the frontend only two files must be adapted and changed to switch to a custom update server: [/lib/components/UpdateIndicator.svelte](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/lib/components/UpdateIndicator.svelte) and [/routes/system/update/GithubFirmwareManager.svelte](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/routes/system/update/GithubFirmwareManager.svelte).
!!! info
The update server must provide the firmware download through SSL encryption.
================================================
FILE: docs/sveltekit.md
================================================
# Getting Started with SvelteKit
SvelteKits unique approach makes it perfect suitable for constraint server. It builds very small files shipping only the minimum required amount of java script. This keeps the memory footprint low so that rich applications can be build with just the 4MB flash of many ESP32 chips.
However, since SvelteKit is designed with server-side rendering first, there are some catches and pitfalls one must avoid. Especially as nearly all tutorials found on SvelteKit heavily make use of the combined front and back end features.
## Limitations of `adapter-static`
To build a website that can be served from an ESP32 `adapter-static` is used. This means no server functions can be used. The front end is build as a Single-Page Application (SPA) instead. However, SvelteKit will pre-render sites at build time, even if SSR and pre-rendering are disabled. This leads to some restrictions that must be taken into consideration:
- You can't use any server-side logic like `+page.server.ts`, `+layout.server.ts` or `+server.ts` files in your project.
- The load function in `+page.ts` gets executed on the server and the client. If you try to access browser resources in the load function this will fail. Use a more traditional way like fetching the data in the `+page.svelte` with the `onMount(() => {})` callback.
## Customizing and Theming
### Changing the App Name
[+layout.ts](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/routes/%2Blayout.ts) bundles a few globally customizable properties like github repository, app name and copyright notice:
```js
export const load = (async () => {
const result = await fetch('/rest/features');
const item = await result.json();
return {
features: item,
title: 'ESP32-SvelteKit',
github: 'theelims/ESP32-sveltekit',
copyright: '2024 theelims',
appName: 'ESP32 SvelteKit'
};
}) satisfies LayoutLoad;
```
In [menu.svelte](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/routes/menu.svelte) there is additionally the possibility to add a discord invite, which is disabled by default.
```js
const discord = { href: ".", active: false };
```
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/static/manifest.json](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/static/manifest.json):
```json
{
"name": "ESP32 SvelteKit",
"icons": [
{
"src": "/favicon.png",
"sizes": "48x48 72x72 96x96 128x128 256x256"
}
],
"start_url": "/",
"display": "fullscreen",
"orientation": "any"
}
```
### Changing the App Icon and Favicon
You can replace the apps favicon which is located at [interface/static/favicon.png](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/static/favicon.png) with one of your preference. A 256 x 256 PNG is recommended for best compatibility.
Also the Svelte Logo can be replaced with your own. It is located under [interface/src/lib/assets/logo.png](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/lib/assets/logo.png).
### Daisy UI Themes
The overall theme of the front end is defined by [DaisyUI](https://daisyui.com/docs/themes/) and can be easily changed according to their documentation. Either by selecting one of the standard themes of DaisyUI, or creating your own. By default the `corporate` and `business` for dark are defined in [app.css](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/app.css):
```js
@plugin "daisyui" {
themes: corporate --default, business --prefersdark;
}
```
#### Opinionated use of Shadows
The front end makes some use of colored shadows with the `shadow-primary` and `shadow-secondary` DaisyUI classes. Just use the search and replace function to change this to a more neutral look, if you find the color too much.
#### Color Scheme Helper
Some JS modules do not accept DaisyUI/TailwindCSS color class names. A small helper function can be imported and used to convert any CSS variable name for a DaisyUI color into OKCHL. That way modules like e.g. Charts.js can be styled in the current color scheme in a responsive manner.
```js
import { daisyColor } from "$lib/DaisyUiHelper";
borderColor: daisyColor('--color-primary'),
backgroundColor: daisyColor('--color-primary', 50),
```
## TS Types Definition
All types used throughout the front end are exported from [models.ts](https://github.com/theelims/ESP32-sveltekit/blob/main/interface/src/lib/types/models.ts). It is a convenient location to add your custom types once you expand the front end.
================================================
FILE: factory_settings.ini
================================================
; The indicated settings support placeholder substitution as follows:
;
; #{platform} - The microcontroller platform, e.g. "esp32" or "esp32c3"
; #{unique_id} - A unique identifier derived from the MAC address, e.g. "0b0a859d6816"
; #{random} - A random number encoded as a hex string, e.g. "55722f94"
[factory_settings]
build_flags =
; WiFi settings
-D FACTORY_WIFI_SSID=\"\"
-D FACTORY_WIFI_PASSWORD=\"\"
-D FACTORY_WIFI_HOSTNAME=\"#{platform}-#{unique_id}\" ; supports placeholders
-D FACTORY_WIFI_RSSI_THRESHOLD=-80 ; dBm, -80 is a good value for most applications
; Access point settings
-D FACTORY_AP_PROVISION_MODE=AP_MODE_DISCONNECTED
-D FACTORY_AP_SSID=\"ESP32-SvelteKit-#{unique_id}\" ; 1-64 characters, supports placeholders
-D FACTORY_AP_PASSWORD=\"esp-sveltekit\" ; 8-64 characters
-D FACTORY_AP_CHANNEL=1
-D FACTORY_AP_SSID_HIDDEN=false
-D FACTORY_AP_MAX_CLIENTS=4
-D FACTORY_AP_LOCAL_IP=\"192.168.4.1\"
-D FACTORY_AP_GATEWAY_IP=\"192.168.4.1\"
-D FACTORY_AP_SUBNET_MASK=\"255.255.255.0\"
; User credentials for admin and guest user
-D FACTORY_ADMIN_USERNAME=\"admin\"
-D FACTORY_ADMIN_PASSWORD=\"admin\"
-D FACTORY_GUEST_USERNAME=\"guest\"
-D FACTORY_GUEST_PASSWORD=\"guest\"
; NTP settings
-D FACTORY_NTP_ENABLED=true
-D FACTORY_NTP_TIME_ZONE_LABEL=\"Europe/Berlin\"
-D FACTORY_NTP_TIME_ZONE_FORMAT=\"GMT0BST,M3.5.0/1,M10.5.0\"
-D FACTORY_NTP_SERVER=\"time.google.com\"
; MQTT settings
-D FACTORY_MQTT_ENABLED=false
-D FACTORY_MQTT_URI=\"mqtts://broker.hivemq.com:8883\"
-D FACTORY_MQTT_USERNAME=\"\" ; supports placeholders
-D FACTORY_MQTT_PASSWORD=\"\"
-D FACTORY_MQTT_CLIENT_ID=\"#{platform}-#{unique_id}\" ; supports placeholders
-D FACTORY_MQTT_KEEP_ALIVE=120
-D FACTORY_MQTT_CLEAN_SESSION=true
-D FACTORY_MQTT_STATUS_TOPIC=\"esp32sveltekit/#{unique_id}/status\" ; supports placeholders
-D FACTORY_MQTT_MIN_MESSAGE_INTERVAL_MS=0
; JWT Secret
-D FACTORY_JWT_SECRET=\"#{random}-#{random}\" ; supports placeholders
; Deep Sleep Configuration
-D WAKEUP_PIN_NUMBER=0 ; pin number to wake up the ESP
-D WAKEUP_SIGNAL=0 ; 1 for wakeup on HIGH, 0 for wakeup on LOW
================================================
FILE: features.ini
================================================
[features]
build_flags =
-D FT_SECURITY=1
-D FT_MQTT=1
-D FT_NTP=1
-D FT_UPLOAD_FIRMWARE=1
-D FT_DOWNLOAD_FIRMWARE=1 ; requires FT_NTP=1
-D FT_SLEEP=1
-D FT_BATTERY=0
-D FT_ANALYTICS=1
-D FT_COREDUMP=1
; -D FT_ETHERNET=1 ; ethernet feature should be enabled in the board config as not every board supports ethernet
================================================
FILE: interface/.eslintignore
================================================
.DS_Store
node_modules
/build
/.svelte-kit
/package
.env
.env.*
!.env.example
# Ignore files for PNPM, NPM and YARN
pnpm-lock.yaml
package-lock.json
yarn.lock
================================================
FILE: interface/.eslintrc.cjs
================================================
module.exports = {
root: true,
parser: '@typescript-eslint/parser',
extends: ['eslint:recommended', 'plugin:@typescript-eslint/recommended', 'prettier'],
plugins: ['svelte3', '@typescript-eslint'],
ignorePatterns: ['*.cjs'],
overrides: [{ files: ['*.svelte'], processor: 'svelte3/svelte3' }],
settings: {
'svelte3/typescript': () => require('typescript')
},
parserOptions: {
sourceType: 'module',
ecmaVersion: 2020
},
env: {
browser: true,
es2017: true,
node: true
}
};
================================================
FILE: interface/.gitignore
================================================
.DS_Store
node_modules
/build
/.svelte-kit
/package
.env
.env.*
!.env.example
vite.config.js.timestamp-*
vite.config.ts.timestamp-*
================================================
FILE: interface/.npmrc
================================================
engine-strict=true
================================================
FILE: interface/.prettierignore
================================================
.DS_Store
node_modules
/build
/.svelte-kit
/package
.env
.env.*
!.env.example
# Ignore files for PNPM, NPM and YARN
pnpm-lock.yaml
package-lock.json
yarn.lock
================================================
FILE: interface/.prettierrc
================================================
{
"useTabs": true,
"singleQuote": true,
"trailingComma": "none",
"printWidth": 100,
"plugins": ["prettier-plugin-svelte"],
"pluginSearchDirs": ["."],
"overrides": [{ "files": "*.svelte", "options": { "parser": "svelte" } }]
}
================================================
FILE: interface/LICENSE
================================================
ESP32-SvelteKit is distributed with two licenses for different sections of the
code. The back end code inherits the GNU LESSER GENERAL PUBLIC LICENSE Version 3
and is therefore distributed said license. The front end code is distributed
under the MIT License.
MIT License
Copyright (C) 2023 - 2024 theelims
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
================================================
FILE: interface/package.json
================================================
{
"name": "ESP32-Sveltekit Template",
"version": "0.2.0",
"private": true,
"scripts": {
"dev": "vite dev --host",
"build": "vite build",
"preview": "vite preview",
"check": "svelte-kit sync && svelte-check --tsconfig ./tsconfig.json",
"check:watch": "svelte-kit sync && svelte-check --tsconfig ./tsconfig.json --watch",
"lint": "prettier --plugin-search-dir . --check . && eslint .",
"format": "prettier --plugin-search-dir . --write ."
},
"devDependencies": {
"@iconify-json/tabler": "^1.2.19",
"@sveltejs/adapter-static": "^3.0.8",
"@sveltejs/kit": "^2.22.3",
"@sveltejs/vite-plugin-svelte": "^4.0.4",
"@tailwindcss/vite": "^4.1.11",
"@types/msgpack-lite": "^0.1.11",
"@typescript-eslint/eslint-plugin": "^8.36.0",
"@typescript-eslint/parser": "^8.36.0",
"daisyui": "^5.0.46",
"eslint": "^9.30.1",
"eslint-config-prettier": "^10.1.5",
"eslint-plugin-svelte": "^3.10.1",
"prettier": "^3.6.2",
"prettier-plugin-svelte": "^3.4.0",
"prettier-plugin-tailwindcss": "^0.6.14",
"svelte": "^5.35.5",
"svelte-check": "^4.2.2",
"svelte-focus-trap": "^1.2.0",
"tailwindcss": "^4.1.11",
"terser": "^5.44.0",
"tslib": "^2.8.1",
"typescript": "^5.8.3",
"unplugin-icons": "^22.1.0",
"vite": "^5.4.19"
},
"type": "module",
"dependencies": {
"chart.js": "^4.5.0",
"chartjs-adapter-luxon": "^1.3.1",
"compare-versions": "^6.1.1",
"jwt-decode": "^4.0.0",
"luxon": "^3.7.1",
"msgpack-lite": "^0.1.26",
"svelte-dnd-action": "^0.9.65",
"svelte-modals": "^2.0.1"
}
}
================================================
FILE: interface/src/app.css
================================================
@import "tailwindcss";
@plugin "daisyui" {
themes: corporate --default, business --prefersdark;
}
/*
The default border color has changed to `currentcolor` in Tailwind CSS v4,
so we've added these compatibility styles to make sure everything still
looks the same as it did with Tailwind CSS v3.
If we ever want to remove these styles, we need to add an explicit border
color utility to any element that depends on these defaults.
*/
@layer base {
*,
::after,
::before,
::backdrop,
::file-selector-button {
border-color: var(--color-gray-200, currentcolor);
}
}
================================================
FILE: interface/src/app.d.ts
================================================
// See https://kit.svelte.dev/docs/types#app
// for information about these interfaces
///
///
declare global {
namespace App {
// interface Error {}
// interface Locals {}
// interface PageData {}
// interface Platform {}
}
}
export {};
================================================
FILE: interface/src/app.html
================================================
%sveltekit.head%
%sveltekit.body%
================================================
FILE: interface/src/lib/DaisyUiHelper.ts
================================================
export function daisyColor(name: string, opacity: number = 100) {
const color = getComputedStyle(document.documentElement).getPropertyValue(name);
// console.debug(`daisyColor: name=${name}, color=${color}, opacity=${opacity}`);
// console.debug(`${color}`);
// add transparency to the color if opacity is less than 100
if (opacity < 100) {
// Convert opacity to a percentage
const alpha = Math.min(Math.max(Math.round(opacity), 0), 100) / 100;
// Remove any existing alpha value and trailing ')' from the oklch color
const oklchColor = color.replace(/(\/\s*\d+(\.\d+)?\))|\)$/, '').trim();
// Append the new alpha value
// console.debug(`oklchColor: ${oklchColor} / ${alpha})`);
return `${oklchColor} / ${alpha})`;
}
return `${color}`; // / ${Math.min(Math.max(Math.round(opacity), 0), 100)}%)`;
}
================================================
FILE: interface/src/lib/components/BatteryIndicator.svelte
================================================
{#if charging}
{:else if soc > 75}
{:else if soc > 55}
{:else if soc > 30}
{:else if soc > 5}
{:else}
{/if}
The form below controls the LED via the RESTful service exposed by the ESP device.
Event Socket Example
The switch below controls the LED via the event system which uses WebSocket under the hood.
It will automatically update whenever the LED state changes.
This page displays the last core dump of the device. The core dump is a snapshot of the
memory when the device crashed. This information is useful for debugging.
Arrange the networks according to their priority (most important first).
{/if}
{/if}
{/await}
================================================
FILE: interface/static/manifest.json
================================================
{
"name": "ESP32 SvelteKit",
"icons": [
{
"src": "/favicon.png",
"sizes": "48x48 72x72 96x96 128x128 256x256"
}
],
"start_url": "/",
"display": "fullscreen",
"orientation": "any"
}
================================================
FILE: interface/svelte.config.js
================================================
import adapter from '@sveltejs/adapter-static';
import { vitePreprocess } from '@sveltejs/vite-plugin-svelte';
/** @type {import('@sveltejs/kit').Config} */
const config = {
// Consult https://kit.svelte.dev/docs/integrations#preprocessors
// for more information about preprocessors
preprocess: vitePreprocess(),
kit: {
adapter: adapter({
pages: 'build',
assets: 'build',
fallback: 'index.html',
precompress: false,
strict: true
}),
alias: {
$src: './src'
},
output: {
bundleStrategy: 'single'
}
}
};
export default config;
================================================
FILE: interface/tsconfig.json
================================================
{
"extends": "./.svelte-kit/tsconfig.json",
"compilerOptions": {
"allowJs": true,
"checkJs": true,
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"resolveJsonModule": true,
"skipLibCheck": true,
"sourceMap": true,
"strict": true
}
// Path aliases are handled by https://kit.svelte.dev/docs/configuration#alias
//
// If you want to overwrite includes/excludes, make sure to copy over the relevant includes/excludes
// from the referenced tsconfig.json - TypeScript does not merge them in
}
================================================
FILE: interface/vite-plugin-littlefs.ts
================================================
import type { UserConfig, Plugin } from 'vite';
export default function viteLittleFS(): Plugin[] {
return [
{
name: 'vite-plugin-littlefs',
enforce: 'post',
apply: 'build',
async config(config, _configEnv) {
const { assetFileNames, chunkFileNames, entryFileNames } =
config.build?.rollupOptions?.output;
// Handle Server-build + Client Assets
config.build.rollupOptions.output = {
...config.build?.rollupOptions?.output,
assetFileNames: assetFileNames.replace('.[hash]', '')
}
// Handle Client-build
if (config.build?.rollupOptions?.output.chunkFileNames.includes('hash')) {
config.build.rollupOptions.output = {
...config.build?.rollupOptions?.output,
chunkFileNames: chunkFileNames.replace('.[hash]', ''),
entryFileNames: entryFileNames.replace('.[hash]', ''),
}
}
}
}
]
}
================================================
FILE: interface/vite.config.ts
================================================
import { sveltekit } from '@sveltejs/kit/vite';
import type { UserConfig } from 'vite';
import Icons from 'unplugin-icons/vite';
import viteLittleFS from './vite-plugin-littlefs';
import tailwindcss from '@tailwindcss/vite';
const config: UserConfig = {
plugins: [
sveltekit(),
Icons({
compiler: 'svelte'
}),
tailwindcss(),
// Shorten file names for LittleFS 32 char limit
viteLittleFS()
],
server: {
proxy: {
// Proxying REST: http://localhost:5173/rest/bar -> http://192.168.1.83/rest/bar
'/rest': {
target: 'http://192.168.1.111',
changeOrigin: true
},
// Proxying websockets ws://localhost:5173/ws -> ws://192.168.1.83/ws
'/ws': {
target: 'ws://192.168.1.111',
changeOrigin: true,
ws: true
}
}
},
build: {
minify: 'terser',
sourcemap: false,
rollupOptions: {
output: {
manualChunks(id) {
if (id.includes('node_modules')) return 'vendor';
}
}
},
cssCodeSplit: true
}
};
export default config;
================================================
FILE: lib/PsychicHttp/.gitignore
================================================
**.vscode
**.pio
**.DS_Store
.pioenvs
.clang_complete
.gcc-flags.json
# Compiled Object files
*.slo
*.lo
*.o
*.obj
# Precompiled Headers
*.gch
*.pch
# Compiled Dynamic libraries
*.so
*.dylib
*.dll
# Fortran module files
*.mod
# Compiled Static libraries
*.lai
*.la
*.a
*.lib
# Executables
*.exe
*.out
*.app
# Visual Studio/VisualMicro stuff
Visual\ Micro
*.sdf
*.opensdf
*.suo
.pioenvs
.piolibdeps
.pio
.vscode/c_cpp_properties.json
.vscode/launch.json
.vscode/settings.json
.vscode/.browse.c_cpp.db*
.vscode/ipch
/psychic-http-loadtest.log
/psychic-websocket-loadtest.log
examples/platformio/lib/PsychicHttp
benchmark/.~lock.comparison.ods#
benchmark/psychic-http-loadtest.log
.$request flow.drawio.bkp
.$request flow.drawio.dtmp
benchmark/package-lock.json
benchmark/node_modules
src/secret.h
benchmark/psychichttp/src/_secret.h
benchmark/psychichttps/src/_secret.h
examples/platformio/src/_secret.h
examples/arduino/src/_secret.h
src/cookie.txt
examples/websockets/lib/PsychicHttp
examples/websockets/src/_secret.h
/build
================================================
FILE: lib/PsychicHttp/CHANGELOG.md
================================================
# v1.2.1
* Fix bug with missing include preventing the HTTPS server from compiling.
# v1.2
* Added TemplatePrinter from https://github.com/Chris--A/PsychicHttp/tree/templatePrint
* Support using as ESP IDF component
* Optional using https server in ESP IDF
* Fixed bug with headers
* Add ESP IDF example + CI script
* Added Arduino Captive Portal example and OTAUpdate from @06GitHub
* HTTPS fix for ESP-IDF v5.0.2+ from @06GitHub
* lots of bugfixes from @mathieucarbou
Thanks to @Chris--A, @06GitHub, and @dzungpv for your contributions.
# v1.1
* Changed the internal structure to support request handlers on endpoints and generic requests that do not match an endpoint
* websockets, uploads, etc should now create an appropriate handler and attach to an endpoint with the server.on() syntax
* Added PsychicClient to abstract away some of the internals of ESP-IDF sockets + add convenience
* onOpen and onClose callbacks have changed as a result
* Added support for EventSource / SSE
* Added support for multipart file uploads
* changed getParam() to return a PsychicWebParameter in line with ESPAsyncWebserver
* Renamed various classes / files:
* PsychicHttpFileResponse -> PsychicFileResponse
* PsychicHttpServerEndpoint -> PsychicEndpoint
* PsychicHttpServerRequest -> PsychicRequest
* PsychicHttpServerResponse -> PsychicResponse
* PsychicHttpWebsocket.h -> PsychicWebSocket.h
* Websocket => WebSocket
* Quite a few bugfixes from the community. Thank you @glennsky, @gb88, @KastanEr, @kstam, and @zekageri
================================================
FILE: lib/PsychicHttp/LICENSE
================================================
Copyright (c) 2024 Jeremy Poulter, Zachary Smith, and Mathieu Carbou
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
================================================
FILE: lib/PsychicHttp/README.md
================================================
# PsychicHttp - HTTP on your ESP 🧙🔮
PsychicHttp is a webserver library for ESP32 + Arduino framework which uses the [ESP-IDF HTTP Server](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_http_server.html) library under the hood. It is written in a similar style to the [Arduino WebServer](https://github.com/espressif/arduino-esp32/tree/master/libraries/WebServer), [ESPAsyncWebServer](https://github.com/me-no-dev/ESPAsyncWebServer), and [ArduinoMongoose](https://github.com/jeremypoulter/ArduinoMongoose) libraries to make writing code simple and porting from those other libraries straightforward.
# Features
* Asynchronous approach (server runs in its own FreeRTOS thread)
* Handles all HTTP methods with lots of convenience functions:
* GET/POST parameters
* get/set headers
* get/set cookies
* basic key/value session data storage
* authentication (basic and digest mode)
* HTTPS / SSL support
* Static fileserving (SPIFFS, LittleFS, etc.)
* Chunked response serving for large files
* File uploads (Basic + Multipart)
* Websocket support with onOpen, onFrame, and onClose callbacks
* EventSource / SSE support with onOpen, and onClose callbacks
* Request filters, including Client vs AP mode (ON_STA_FILTER / ON_AP_FILTER)
* TemplatePrinter class for dynamic variables at runtime
## Differences from ESPAsyncWebserver
* No templating system (anyone actually use this?)
* No url rewriting (but you can use request->redirect)
# Usage
## Installation
### Platformio
[PlatformIO](http://platformio.org) is an open source ecosystem for IoT development.
Add "PsychicHttp" to project using [Project Configuration File `platformio.ini`](http://docs.platformio.org/page/projectconf.html) and [lib_deps](http://docs.platformio.org/page/projectconf/section_env_library.html#lib-deps) option:
```ini
[env:myboard]
platform = espressif...
board = ...
framework = arduino
# using the latest stable version
lib_deps = hoeken/PsychicHttp
# or using GIT Url (the latest development version)
lib_deps = https://github.com/hoeken/PsychicHttp
```
### Installation - Arduino
Open *Tools -> Manage Libraries...* and search for PsychicHttp.
# Principles of Operation
## Things to Note
* PsychicHttp is a fully asynchronous server and as such does not run on the loop thread.
* You should not use yield or delay or any function that uses them inside the callbacks.
* The server is smart enough to know when to close the connection and free resources.
* You can not send more than one response to a single request.
## PsychicHttp
* Listens for connections.
* Wraps the incoming request into PsychicRequest.
* Keeps track of clients + calls optional callbacks on client open and close.
* Find the appropriate handler (if any) for a request and pass it on.
## Request Life Cycle
* TCP connection is received by the server.
* HTTP request is wrapped inside ```PsychicRequest``` object + TCP Connection wrapped inside PsychicConnection object.
* When the request head is received, the server goes through all ```PsychicEndpoints``` and finds one that matches the url + method.
* ```handler->filter()``` and ```handler->canHandle()``` are called on the handler to verify the handler should process the request.
* ```handler->needsAuthentication()``` is called and sends an authorization response if required.
* ```handler->handleRequest()``` is called to actually process the HTTP request.
* If the handler cannot process the request, the server will loop through any global handlers and call that handler if it passes filter(), canHandle(), and needsAuthentication().
* If no global handlers are called, the server.defaultEndpoint handler will be called.
* Each handler is responsible for processing the request and sending a response.
* When the response is sent, the client is closed and freed from the memory.
* Unless its a special handler like websockets or eventsource.

### Handlers
* ```PsychicHandler``` is used for processing and responding to specific HTTP requests.
* ```PsychicHandler``` instances can be attached to any endpoint or as global handlers.
* Setting a ```Filter``` to the ```PsychicHandler``` controls when to apply the handler, decision can be based on
request method, url, request host/port/target host, the request client's localIP or remoteIP.
* Two filter callbacks are provided: ```ON_AP_FILTER``` to execute the rewrite when request is made to the AP interface,
```ON_STA_FILTER``` to execute the rewrite when request is made to the STA interface.
* The ```canHandle``` method is used for handler specific control on whether the requests can be handled. Decision can be based on request method, request url, request host/port/target host.
* Depending on how the handler is implemented, it may provide callbacks for adding your own custom processing code to the handler.
* Global ```Handlers``` are evaluated in the order they are attached to the server. The ```canHandle``` is called only
if the ```Filter``` that was set to the ```Handler``` return true.
* The first global ```Handler``` that can handle the request is selected, no further processing of handlers is called.

### Responses and how do they work
* The ```PsychicResponse``` objects are used to send the response data back to the client.
* Typically the response should be fully generated and sent from the callback.
* It may be possible to generate the response outside the callback, but it will be difficult.
* The exceptions are websockets + eventsource where the response is sent, but the connection is maintained and new data can be sent/received outside the handler.
# Porting From ESPAsyncWebserver
If you have existing code using ESPAsyncWebserver, you will feel right at home with PsychicHttp. Even if internally it is much different, the external interface is very similar. Some things are mostly cosmetic, like different class names and callback definitions. A few things might require a bit more in-depth approach. If you're porting your code and run into issues that aren't covered here, please post and issue.
## Globals Stuff
* Change your #include to ```#include ```
* Change your server instance: ```PsychicHttpServer server;```
* Define websocket handler if you have one: ```PsychicWebSocketHandler websocketHandler;```
* Define eventsource if you have one: ```PsychicEventSource eventSource;```
## setup() Stuff
* no more server.begin(), call server.listen(80), before you add your handlers
* server has a configurable limit on .on() endpoints. change it with ```server.config.max_uri_handlers = 20;``` as needed.
* check your callback function definitions:
* AsyncWebServerRequest -> PsychicRequest
* no more onBody() event
* for small bodies (server.maxRequestBodySize, default 16k) it will be automatically loaded and accessed by request->body()
* for large bodies, use an upload handler and onUpload()
* websocket callbacks are much different (and simpler!)
* websocket / eventsource handlers get attached to url in server.on("/url", &handler) instead of passing url to handler constructor.
* eventsource callbacks are onOpen and onClose now.
* HTTP_ANY is not supported by ESP-IDF, so we can't use it either.
* NO server.onFileUpload(onUpload); (you could attach an UploadHandler to the default endpoint i guess?)
* NO server.onRequestBody(onBody); (same)
## Requests / Responses
* request->send is now request->reply()
* if you create a response, call response->send() directly, not request->send(reply)
* request->headers() is not supported by ESP-IDF, you have to just check for the header you need.
* No AsyncCallbackJsonWebHandler (for now... can add if needed)
* No request->beginResponse(). Instanciate a PsychicResponse instead: ```PsychicResponse response(request);```
* No PROGMEM suppport (its not relevant to ESP32: https://esp32.com/viewtopic.php?t=20595)
* No Stream response support just yet
# Usage
## Create the Server
Here is an example of the typical server setup:
```cpp
#include
PsychicHttpServer server;
void setup()
{
//optional low level setup server config stuff here.
//server.config is an ESP-IDF httpd_config struct
//see: https://docs.espressif.com/projects/esp-idf/en/v4.4.6/esp32/api-reference/protocols/esp_http_server.html#_CPPv412httpd_config
//increase maximum number of uri endpoint handlers (.on() calls)
server.config.max_uri_handlers = 20;
//connect to wifi
//start the server listening on port 80 (standard HTTP port)
server.listen(80);
//call server methods to attach endpoints and handlers
server.on(...);
server.serveStatic(...);
server.attachHandler(...);
}
```
## Add Handlers
One major difference from ESPAsyncWebserver is that handlers can be attached to a specific url (endpoint) or as a global handler. The reason for this, is that attaching to a specific URL is more efficient and makes for cleaner code.
### Endpoint Handlers
An endpoint is basically just the URL path (eg. /path/to/file) without any query string. The ```server.on(...)``` function is a convenience function for creating endpoints and attaching a handler to them. There are two main styles: attaching a basic ```WebRequest``` handler and attaching an external handler.
```cpp
//creates a basic PsychicWebHandler that calls the request_callback callback
server.on("/url", HTTP_GET, request_callback);
//same as above, but defaults to HTTP_GET
server.on("/url", request_callback);
//attaches a websocket handler to /ws
PsychicWebSocketHandler websocketHandler;
server.on("/ws", &websocketHandler);
```
The ```server.on(...)``` returns a pointer to the endpoint, which can be used to call various functions like ```setHandler()```, ```setFilter()```, and ```setAuthentication()```.
```cpp
//respond to /url only from requests to the AP
server.on("/url", HTTP_GET, request_callback)->setFilter(ON_AP_FILTER);
//require authentication on /url
server.on("/url", HTTP_GET, request_callback)->setAuthentication("user", "pass");
//attach websocket handler to /ws
PsychicWebSocketHandler websocketHandler;
server.on("/ws")->attachHandler(&websocketHandler);
```
### Basic Requests
The ```PsychicWebHandler``` class is for handling standard web requests. It provides a single callback: ```onRequest()```. This callback is called when the handler receives a valid HTTP request.
One major difference from ESPAsyncWebserver is that this callback needs to return an esp_err_t variable to let the server know the result of processing the request. The ```response->reply()``` and ```request->send()``` functions will return this. It is a good habit to return the result of these functions as sending the response will close the connection.
The function definition for the onRequest callback is:
```cpp
esp_err_t function_name(PsychicRequest *request);
```
Here is a simple example that sends back the client's IP on the URL /ip
```cpp
server.on("/ip", [](PsychicRequest *request)
{
String output = "Your IP is: " + request->client()->remoteIP().toString();
return request->reply(output.c_str());
});
```
### Uploads
The ```PsychicUploadHandler``` class is for handling uploads, both large POST bodies and multipart encoded forms. It provides two callbacks: ```onUpload()``` and ```onRequest()```.
```onUpload(...)``` is called when there is new data. This function may be called multiple times so that you can process the data in chunks. The function definition for the onUpload callback is:
```cpp
esp_err_t function_name(PsychicRequest *request, const String& filename, uint64_t index, uint8_t *data, size_t len, bool final);
```
* request is a pointer to the Request object
* filename is the name of the uploaded file
* index is the overall byte position of the current data
* data is a pointer to the data buffer
* len is the length of the data buffer
* final is a flag to tell if its the last chunk of data
```onRequest(...)``` is called after the successful handling of the upload. Its definition and usage is the same as the basic request example as above.
#### Basic Upload (file is the entire POST body)
It's worth noting that there is no standard way of passing in a filename for this method, so the handler attempts to guess the filename with the following methods:
* Checking the Content-Disposition header
* Checking the _filename query parameter (eg. /upload?filename=filename.txt becomes filename.txt)
* Checking the url and taking the last part as filename (eg. /upload/filename.txt becomes filename.txt). You must set a wildcard url for this to work as in the example below.
```cpp
//handle a very basic upload as post body
PsychicUploadHandler *uploadHandler = new PsychicUploadHandler();
uploadHandler->onUpload([](PsychicRequest *request, const String& filename, uint64_t index, uint8_t *data, size_t len, bool last) {
File file;
String path = "/www/" + filename;
Serial.printf("Writing %d/%d bytes to: %s\n", (int)index+(int)len, request->contentLength(), path.c_str());
if (last)
Serial.printf("%s is finished. Total bytes: %d\n", path.c_str(), (int)index+(int)len);
//our first call?
if (!index)
file = LittleFS.open(path, FILE_WRITE);
else
file = LittleFS.open(path, FILE_APPEND);
if(!file) {
Serial.println("Failed to open file");
return ESP_FAIL;
}
if(!file.write(data, len)) {
Serial.println("Write failed");
return ESP_FAIL;
}
return ESP_OK;
});
//gets called after upload has been handled
uploadHandler->onRequest([](PsychicRequest *request)
{
String url = "/" + request->getFilename();
String output = "" + url + "";
return request->reply(output.c_str());
});
//wildcard basic file upload - POST to /upload/filename.ext
server.on("/upload/*", HTTP_POST, uploadHandler);
```
#### Multipart Upload
Very similar to the basic upload, with 2 key differences:
* multipart requests don't know the total size of the file until after it has been fully processed. You can get a rough idea with request->contentLength(), but that is the length of the entire multipart encoded request.
* you can access form variables, including multipart file infor (name + size) in the onRequest handler using request->getParam()
```cpp
//a little bit more complicated multipart form
PsychicUploadHandler *multipartHandler = new PsychicUploadHandler();
multipartHandler->onUpload([](PsychicRequest *request, const String& filename, uint64_t index, uint8_t *data, size_t len, bool last) {
File file;
String path = "/www/" + filename;
//some progress over serial.
Serial.printf("Writing %d bytes to: %s\n", (int)len, path.c_str());
if (last)
Serial.printf("%s is finished. Total bytes: %d\n", path.c_str(), (int)index+(int)len);
//our first call?
if (!index)
file = LittleFS.open(path, FILE_WRITE);
else
file = LittleFS.open(path, FILE_APPEND);
if(!file) {
Serial.println("Failed to open file");
return ESP_FAIL;
}
if(!file.write(data, len)) {
Serial.println("Write failed");
return ESP_FAIL;
}
return ESP_OK;
});
//gets called after upload has been handled
multipartHandler->onRequest([](PsychicRequest *request)
{
PsychicWebParameter *file = request->getParam("file_upload");
String url = "/" + file->value();
String output;
output += "" + url + " \n";
output += "Bytes: " + String(file->size()) + " \n";
output += "Param 1: " + request->getParam("param1")->value() + " \n";
output += "Param 2: " + request->getParam("param2")->value() + " \n";
return request->reply(output.c_str());
});
//upload to /multipart url
server.on("/multipart", HTTP_POST, multipartHandler);
```
### Static File Serving
The ```PsychicStaticFileHandler``` is a special handler that does not provide any callbacks. It is used to serve a file or files from a specific directory in a filesystem to a directory on the webserver. The syntax is exactly the same as ESPAsyncWebserver. Anything that is derived from the ```FS``` class should work (eg. SPIFFS, LittleFS, SD, etc)
A couple important notes:
* If it finds a file with an extra .gz extension, it will serve it as gzip encoded (eg: /targetfile.ext -> {targetfile.ext}.gz)
* If the file is larger than FILE_CHUNK_SIZE (default 8kb) then it will send it as a chunked response.
* It will detect most basic filetypes and automatically set the appropriate Content-Type
The ```server.serveStatic()``` function handles creating the handler and assigning it to the server:
```cpp
//serve static files from LittleFS/www on / only to clients on same wifi network
//this is where our /index.html file lives
server.serveStatic("/", LittleFS, "/www/")->setFilter(ON_STA_FILTER);
//serve static files from LittleFS/www-ap on / only to clients on SoftAP
//this is where our /index.html file lives
server.serveStatic("/", LittleFS, "/www-ap/")->setFilter(ON_AP_FILTER);
//serve static files from LittleFS/img on /img
//it's more efficient to serve everything from a single www directory, but this is also possible.
server.serveStatic("/img", LittleFS, "/img/");
//you can also serve single files
server.serveStatic("/myfile.txt", LittleFS, "/custom.txt");
```
You could also theoretically use the file response directly:
```cpp
server.on("/ip", [](PsychicRequest *request)
{
String filename = "/path/to/file";
PsychicFileResponse response(request, LittleFS, filename);
return response.send();
});
PsychicFileResponse(PsychicRequest *request, FS &fs, const String& path)
```
### Websockets
The ```PsychicWebSocketHandler``` class is for handling WebSocket connections. It provides 3 callbacks:
```onOpen(...)``` is called when a new WebSocket client connects.
```onFrame(...)``` is called when a new WebSocket frame has arrived.
```onClose(...)``` is called when a new WebSocket client disconnects.
Here are the callback definitions:
```cpp
void open_function(PsychicWebSocketClient *client);
esp_err_t frame_function(PsychicWebSocketRequest *request, httpd_ws_frame *frame);
void close_function(PsychicWebSocketClient *client);
```
WebSockets were the main reason for starting PsychicHttp, so they are well tested. They are also much simplified from the ESPAsyncWebserver style. You do not need to worry about error handling, partial frame assembly, PONG messages, etc. The onFrame() function is called when a complete frame has been received, and can handle frames up to the entire available heap size.
Here is a basic example of using WebSockets:
```cpp
//create our handler... note this should be located as a global or somewhere it wont go out of scope and be destroyed.
PsychicWebSocketHandler websocketHandler();
websocketHandler.onOpen([](PsychicWebSocketClient *client) {
Serial.printf("[socket] connection #%u connected from %s\n", client->socket(), client->remoteIP().toString());
client->sendMessage("Hello!");
});
websocketHandler.onFrame([](PsychicWebSocketRequest *request, httpd_ws_frame *frame) {
Serial.printf("[socket] #%d sent: %s\n", request->client()->socket(), (char *)frame->payload);
return request->reply(frame);
});
websocketHandler.onClose([](PsychicWebSocketClient *client) {
Serial.printf("[socket] connection #%u closed from %s\n", client->socket(), client->remoteIP().toString());
});
//attach the handler to /ws. You can then connect to ws://ip.address/ws
server.on("/ws", &websocketHandler);
```
The onFrame() callback has 2 parameters:
* ```PsychicWebSocketRequest *request``` a special request with helper functions for replying in websocket format.
* ```httpd_ws_frame *frame``` ESP-IDF websocket struct. The important struct members we care about are:
* ```uint8_t *payload; /*!< Pre-allocated data buffer */```
* ```size_t len; /*!< Length of the WebSocket data */```
For sending data on the websocket connection, there are 3 methods:
* ```request->reply()``` - only available in the onFrame() callback context.
* ```webSocketHandler.sendAll()``` - can be used anywhere to send websocket messages to all connected clients.
* ```client->send()``` - can be used anywhere* to send a websocket message to a specific client
All of the above functions either accept simple ```char *``` string of you can construct your own httpd_ws_frame.
*Special Note:* Do not hold on to the ```PsychicWebSocketClient``` for sending messages to clients outside the callbacks. That pointer is destroyed when a client disconnects. Instead, store the ```int client->socket()```. Then when you want to send a message, use this code:
```cpp
//make sure our client is still connected.
PsychicWebSocketClient *client = websocketHandler.getClient(socket);
if (client != NULL)
client->send("Your Message")
```
### EventSource / SSE
The ```PsychicEventSource``` class is for handling EventSource / SSE connections. It provides 2 callbacks:
```onOpen(...)``` is called when a new EventSource client connects.
```onClose(...)``` is called when a new EventSource client disconnects.
Here are the callback definitions:
```cpp
void open_function(PsychicEventSourceClient *client);
void close_function(PsychicEventSourceClient *client);
```
Here is a basic example of using PsychicEventSource:
```cpp
//create our handler... note this should be located as a global or somewhere it wont go out of scope and be destroyed.
PsychicEventSource eventSource;
eventSource.onOpen([](PsychicEventSourceClient *client) {
Serial.printf("[eventsource] connection #%u connected from %s\n", client->socket(), client->remoteIP().toString());
client->send("Hello user!", NULL, millis(), 1000);
});
eventSource.onClose([](PsychicEventSourceClient *client) {
Serial.printf("[eventsource] connection #%u closed from %s\n", client->socket(), client->remoteIP().toString());
});
//attach the handler to /events
server.on("/events", &eventSource);
```
For sending data on the EventSource connection, there are 2 methods:
* ```eventSource.send()``` - can be used anywhere to send events to all connected clients.
* ```client->send()``` - can be used anywhere* to send events to a specific client
All of the above functions accept a simple ```char *``` message, and optionally: ```char *``` event name, id, and reconnect time.
*Special Note:* Do not hold on to the ```PsychicEventSourceClient``` for sending messages to clients outside the callbacks. That pointer is destroyed when a client disconnects. Instead, store the ```int client->socket()```. Then when you want to send a message, use this code:
```cpp
//make sure our client is still connected.
PsychicEventSourceClient *client = eventSource.getClient(socket);
if (client != NULL)
client->send("Your Event")
```
### HTTPS / SSL
PsychicHttp supports HTTPS / SSL out of the box, however there are some limitations (see performance below). Enabling it also increases the code size by about 100kb. To use HTTPS, you need to modify your setup like so:
```cpp
#include
#include
PsychicHttpsServer server;
server.listen(443, server_cert, server_key);
```
```server_cert``` and ```server_key``` are both ```const char *``` parameters which contain the server certificate and private key, respectively.
To generate your own key and self signed certificate, you can use the command below:
```
openssl req -x509 -newkey rsa:4096 -nodes -keyout server.key -out server.crt -sha256 -days 365
```
Including the ```PsychicHttpsServer.h``` also defines ```PSY_ENABLE_SSL``` which you can use in your code to allow enabling / disabling calls in your code based on if the HTTPS server is available:
```cpp
//our main server object
#ifdef PSY_ENABLE_SSL
PsychicHttpsServer server;
#else
PsychicHttpServer server;
#endif
```
Last, but not least, you can create a separate HTTP server on port 80 that redirects all requests to the HTTPS server:
```cpp
//this creates a 2nd server listening on port 80 and redirects all requests HTTPS
PsychicHttpServer *redirectServer = new PsychicHttpServer();
redirectServer->config.ctrl_port = 20420; // just a random port different from the default one
redirectServer->listen(80);
redirectServer->onNotFound([](PsychicRequest *request) {
String url = "https://" + request->host() + request->url();
return request->redirect(url.c_str());
});
```
# TemplatePrinter
**This is not specific to PsychicHttp, and it works with any `Print` object. You could for example, template data out to `File`, `Serial`, etc...**.
The template engine is a `Print` interface and can be printed to directly, however, if you are just templating a few short strings, I'd probably just use `response.printf()` instead. **Its benefit will be seen when templating large inputs such as files.**
One benefit may be **templating a **JSON** file avoiding the need to use ArduinoJson.**
Before closing the underlying `Print`/`Stream` that this writes to, it must be flushed as small amounts of data can be buffered. A convenience method to take care of this is shows in `example 3`.
The header file is not currently added to `PsychicHttp.h` and users will have to add it manually:
```C++
#include
```
## Template parameter definition:
- Must start and end with a preset delimiter, the default is `%`
- Can only contain `a-z`, `A-Z`, `0-9`, and `_`
- Maximum length of 63 characters (buffer is 64 including `null`).
- A parameter must not be zero length (not including delimiters).
- Spaces or any other character do not match as a parameter, and will be output as is.
- Valid examples
- `%MY_PARAM%`
- `%SOME1%`
- **Invalid** examples
- `%MY PARAM%`
- `%SOME1 %`
- `%UNFINISHED`
- `%%`
## Template processing
A function or lambda is used to receive the parameter replacement.
```C++
bool templateHandler(Print &output, const char *param){
//...
}
[](Print &output, const char *param){
//...
}
```
Parameters:
- `Print &output` - the underlying `Print`, print the results of templating to this.
- `const char *param` - a string containing the current parameter.
The handler must return a `bool`.
- `true`: the parameter was handled, continue as normal.
- `false`: the input detected as a parameter is not, print literal.
See output in **example 1** regarding the effects of returning `true` or `false`.
## Template input handler
This is not needed unless using the static convenience function `TemplatePrinter::start()`. See **example 3**.
```C++
bool inputHandler(TemplatePrinter &printer){
//...
}
[](TemplatePrinter &printer){
//...
}
```
Parameters:
- `TemplatePrinter &printer` - The template engine, print your template text to this for processing.
## Example 1 - Simple use with `PsychicStreamResponse`:
This example highlights its most basic usage.
```C++
// Function to handle parameter requests.
bool templateHandler(Print &output, const char *param){
if(strcmp(param, "FREE_HEAP") == 0){
output.print((double)ESP.getFreeHeap() / 1024.0, 2);
}else if(strcmp(param, "MIN_FREE_HEAP") == 0){
output.print((double)ESP.getMinFreeHeap() / 1024.0, 2);
}else if(strcmp(param, "MAX_ALLOC_HEAP") == 0){
output.print((double)ESP.getMaxAllocHeap() / 1024.0, 2);
}else if(strcmp(param, "HEAP_SIZE") == 0){
output.print((double)ESP.getHeapSize() / 1024.0, 2);
}else{
return false;
}
output.print("Kb");
return true;
}
// Example serving a request
server.on("/template", [](PsychicRequest *request) {
PsychicStreamResponse response(request, "text/plain");
response.beginSend();
TemplatePrinter printer(response, templateHandler);
printer.println("My ESP has %FREE_HEAP% left. Its lifetime minimum heap is %MIN_FREE_HEAP%.");
printer.println("The maximum allocation size is %MAX_ALLOC_HEAP%, and its total size is %HEAP_SIZE%.");
printer.println("This is an unhandled parameter: %UNHANDLED_PARAM% and this is an invalid param %INVALID PARAM%.");
printer.println("This line finished with %UNFIN");
printer.flush();
return response.endSend();
});
```
The output for example looks like:
```
My ESP has 170.92Kb left. Its lifetime minimum heap is 169.83Kb.
The maximum allocation size is 107.99Kb, and its total size is 284.19Kb.
This is an unhandled parameter: %UNHANDLED_PARAM% and this is an invalid param %INVALID PARAM%.
This line finished with %UNFIN
```
## Example 2 - Templating a file
```C++
server.on("/home", [](PsychicRequest *request) {
PsychicStreamResponse response(request, "text/html");
File file = SD.open("/www/index.html");
response.beginSend();
TemplatePrinter printer(response, templateHandler);
printer.copyFrom(file);
printer.flush();
file.close();
return response.endSend();
});
```
## Example 3 - Using the `TemplatePrinter::start` method.
This static method allows an RAII approach, allowing you to template a stream, etc... without needing a `flush()`. The function call is laid out as:
```C++
TemplatePrinter::start(host_stream, template_handler, input_handler);
```
\*these examples use the `templateHandler` function defined in example 1.
### Serve a file like example 2
```C++
server.on("/home", [](PsychicRequest *request) {
PsychicStreamResponse response(request, "text/html");
File file = SD.open("/www/index.html");
response.beginSend();
TemplatePrinter::start(response, templateHandler, [&file](TemplatePrinter &printer){
printer.copyFrom(file);
});
file.close();
return response.endSend();
});
```
### Template a string like example 1
```C++
server.on("/template2", [](PsychicRequest *request) {
PsychicStreamResponse response(request, "text/plain");
response.beginSend();
TemplatePrinter::start(response, templateHandler, [](TemplatePrinter &printer){
printer.println("My ESP has %FREE_HEAP% left. Its lifetime minimum heap is %MIN_FREE_HEAP%.");
printer.println("The maximum allocation size is %MAX_ALLOC_HEAP%, and its total size is %HEAP_SIZE%.");
printer.println("This is an unhandled parameter: %UNHANDLED_PARAM% and this is an invalid param %INVALID PARAM%.");
});
return response.endSend();
});
```
# Performance
In order to really see the differences between libraries, I created some basic benchmark firmwares for PsychicHttp, ESPAsyncWebserver, and ArduinoMongoose. I then ran the loadtest-http.sh and loadtest-websocket.sh scripts against each firmware to get some real numbers on the performance of each server library. All of the code and results are available in the /benchmark folder. If you want to see the collated data and graphs, there is a [LibreOffice spreadsheet](/benchmark/comparison.ods).


## HTTPS / SSL
Yes, PsychicHttp supports SSL out of the box, but there are a few caveats:
* Due to memory limitations, it can only handle 2 connections at a time. Each SSL connection takes about 45k ram, and a blank PsychicHttp sketch has about 150k ram free.
* Speed and latency are still pretty good (see graph above) but the SSH handshake seems to take 1500ms. With websockets or browser its not an issue since the connection is kept alive, but if you are loading requests in another way it will be a bit slow
* Unless you want to expose your ESP to the internet, you are limited to self signed keys and the annoying browser security warnings that come with them.
## Analysis
The results clearly show some of the reasons for writing PsychicHttp: ESPAsyncWebserver crashes under heavy load on each test, across the board in a 60s test. That means in normal usage, you're just rolling the dice with how long it will go until it crashes. Every other number is moot, IMHO.
ArduinoMongoose doesn't crash under heavy load, but it does bog down with extremely high latency (15s) for web requests and appears to not even respond at the highest loadings as the loadtest script crashes instead. The code itself doesnt crash, so bonus points there. After the high load, it does go back to serving normally. One area ArduinoMongoose does shine, is in websockets where its performance is almost 2x the performance of PsychicHttp. Both in requests per second and latency. Clearly an area of improvement for PsychicHttp.
PsychicHttp has good performance across the board. No crashes and continously responds during each test. It is a clear winner in requests per second when serving files from memory, dynamic JSON, and has consistent performance when serving files from LittleFS. The only real downside is the lower performance of the websockets with a single connection handling 38rps, and maxing out at 120rps across multiple connections.
## Takeaways
With all due respect to @me-no-dev who has done some amazing work in the open source community, I cannot recommend anyone use the ESPAsyncWebserver for anything other than simple projects that don't need to be reliable. Even then, PsychicHttp has taken the arcane api of the ESP-IDF web server library and made it nice and friendly to use with a very similar API to ESPAsyncWebserver. Also, ESPAsyncWebserver is more or less abandoned, with 150 open issues, 77 pending pull requests, and the last commit in over 2 years.
ArduinoMongoose is a good alternative, although the latency issues when it gets fully loaded can be very annoying. I believe it is also cross platform to other microcontrollers as well, but I haven't tested that. The other issue here is that it is based on an old version of a modified Mongoose library that will be difficult to update as it is a major revision behind and several security updates behind as well. Big thanks to @jeremypoulter though as PsychicHttp is a fork of ArduinoMongoose so it's built on strong bones.
# Roadmap
## v1.2: ESPAsyncWebserver Parity
Change:
Modify the request handling to bring initail url matching and filtering into PsychicHttpServer itself.
Benefits:
* Fix a bug with filter() where endpoint is matched, but filter fails and it doesn't continue matching further endpoints (checks are in different codebases)
* HTTP_ANY support
* unlimited endpoints
* we would use a List to store endpoints
* dont have to pre-declare config.max_uri_handlers;
* much more flexibility for future
Issues
* it would log a warning on every request as if its a 404. (httpd_uri.c:298)
* req->user_ctx is not passed in. (httpd_uri.c:309)
* but... user_ctx is something we could store in the psychicendpoint data
* Websocket support assumes an endpoint with matching url / method (httpd_uri.c:312)
* we could copy and bring this code into our own internal request processor
* would need to manually maintain more code (~100 lines?) and be more prone to esp-idf http_server updates causing problems.
How to implement
* set config.max_uri_handlers = 1;
* possibly do not register any uri_handlers (looks like it would be fastest way to exit httpd_find_uri_handler (httpd_uri.c:94))
* looks like 404 is set by default, so should work.
* modify PsychicEndpoint to store the stuff we would pass to http_server
* create a new function handleRequest() before PsychicHttpServer::defaultNotFoundHandler to process incoming requests.
* bring in code from PsychicHttpServer::notFoundHandler
* add new code to loop over endpoints to call match and filter
* bring code from esp-idf library
* templating system
* regex url matching
* rewrite urls?
* What else are we missing?
## Longterm Wants
* investigate websocket performance gap
* support for esp-idf framework
* support for arduino 3.0 framework
* Enable worker based multithreading with esp-idf v5.x
* 100-continue support?
If anyone wants to take a crack at implementing any of the above features I am more than happy to accept pull requests.
================================================
FILE: lib/PsychicHttp/RELEASE.md
================================================
* Update CHANGELOG
* Bump version in library.json
* Bump version in library.properties
* Make new release + tag
* this will get pulled in automatically by Arduino Library Indexer
* run ```pio pkg publish``` to publish to Platform.io
================================================
FILE: lib/PsychicHttp/library.json
================================================
{
"name": "PsychicHttp",
"version": "1.2.1",
"description": "Arduino style wrapper around ESP-IDF HTTP library. HTTP server with SSL + websockets. Works on esp32 and probably esp8266",
"keywords": "network,http,https,tcp,ssl,tls,websocket,espasyncwebserver",
"repository":
{
"type": "git",
"url": "https://github.com/hoeken/PsychicHttp"
},
"authors":
[
{
"name": "Zach Hoeken",
"email": "hoeken@gmail.com",
"maintainer": true
}
],
"license" : "MIT",
"examples": [
{
"name": "platformio",
"base": "examples/platformio",
"files": [
"src/main.cpp"
]
}
],
"frameworks": "arduino",
"platforms": "espressif32",
"dependencies": [
{
"owner": "bblanchon",
"name": "ArduinoJson",
"version": "^7.0.4"
},
{
"owner": "plageoj",
"name" : "UrlEncode",
"version" : "^1.0.1"
}
],
"export": {
"include": [
"examples/platformio",
"src",
"library.json",
"library.properties",
"LICENSE",
"README.md"
]
}
}
================================================
FILE: lib/PsychicHttp/request flow.drawio
================================================
7Vxbd5s4EP41Pmf3wTkgAcaPza3Zbq/bbNM+yiAbNhi5ICd2f/0KIxmQFIypsZ1jpw+1hBCS5pv5ZgaJHryaLt4maBZ8ID6OesDwFz143QPANIDD/stqlnnNwIJ5xSQJfd6oqPga/sLiTl47D32cVhpSQiIazqqVHolj7NFKHUoS8lxtNiZR9akzNMFKxVcPRWrtQ+jTIK91waCov8PhJBBPNp1hfmWKRGM+kzRAPnkuVcGbHrxKCKH5r+niCkfZ4ol1efhr+RC9f3TevvuS/kT/Xv59//FbP+/sdptb1lNIcExbd+0/B97S/uJ9MrxvX76P0/f9+Gff5MvwhKI5XzA+WboUK5iQeezjrBezBy+fg5DirzPkZVefGWZYXUCnEb+8XiSDFcYkphwRbL3ZRXZbGE9Y0c6uhlF0RSKSrB4Dx3b2j99Vqs//srtpQh5x6Yqz+mNXGq4PX8cnnFC8KKGDr9dbTKaYJkvWRFwVIObYN21efi6QZA95XVBCkevwSsTRO1n3XUiI/eBC0gvsevkufbie3t/Yd9blDfz0bvHQ70NzG4EZVeH8hyldcoGgOSWsiiQ0IBMSo+g9ITPeriQ3Myvj2H+TqSIrjyLiPeZVt2E29NUzWIm3d9eCEtqmoCJCIxxdIu9xshqoEGhMYpx15TP15XMpBndT1LKHsYX8nnV2YYvij/VAWOF6USktRWkR0tJtrPSDDy/7XdyUFcQ9KUUJFXPnI9wObSmZJx6uUUEuP/agCaZ1kueQyhaoFrwJjhANn6r2TwdEfutnErKJrEEPbFgBPRyCahf5jPhdZYOzoSPbkDrKp6x0tNKL9XwaqYpWAODkNaU9UrXtoIpUbTtn10BtajHrRl2Cwd39/WdW8w/+Occp/T2+KwOAzfFyEqE0XRuPWulK/Ocj7I49Lc95Lh6Nu+Q5t6qpQGhqiedMoOE5awc0p52CpQjtB3MiT0x92xLdjtXeaaj2ptlQ7znq+sYFgIZbQV7f5N53WxITTch4nOJ6foKGdVB+shWMfyQKxDej5FUrQTdQ3YhA4c8b+wObVTWxljHYK9gcBWw3sT/jY/yAqBdkELpVTWxApqN52iLwu0XTMMpme4ejJ0xDD2noEkXhJGYFj8kfJ3o0rYNGpyjdr9DLaEINI8dj4Glp1HdGjt1puDiUPGdnoNKooQsXu6JRU40WP6dLLwi9OxT7EVvxs/MjOz+2uUfnRxvpaaR2it5Pi3B9/x6TXoCamH5XLpMNoC25TPtjMcuQWAxILNY2N2ANm9EhwydalpqtGCzVTErQrmSSLRfUj0um6Wp79iMfQVturoVLSd9XjJyxHnAiBqDLEbPUzoSuoOqgaWaH41Ga/ScM+Zm7f4sFZP9sr9ytR4WauLjGYzSPMrgWztvJ87cle12udWE3ZHC7K9mp+YvTi+0KMq5QccHMOyHjjXlzoUdHGBRam4LCpnQKZTo1O4su9Wus5jLOHuur8lib5vZbeKyOpST5Duix2m1VTNJVW3Z9d+Sx2rIqH6XHqqaTPuJnVnGV7+IISax1SA/jnBwyJSS/WXEbJhdAZ26luuMjxQmb0QWJP81wnAkRRdGImcFjkZ9vY9e3dPJzwQh2ugMEwqrpAoODJ4eGivxUx7KgRS9b9dCriqbKw4K2zBJpFRS2iba69O0205bm3VQt6jfSVnlnj0as9m8y1xpWktEWsNqalVw5ISN11LHjB9QgtUQBzJREJH3hxcLJc4Fra1IMe+UCoIapQZ5OYmSwEp2af1qTxQvXBXnUef8nwx6Sb+ZCt2lqQnZTdydzNVQ7Xf4AmrCnVlOOlD9Mw2ob1khGadgwEb8rAhG7GktwvA3jMA2OxXyMXQ/rCWPk2pa9PSjbE8YQNCSMzpxPCGoIg0cPPaC8o0hn2AvHzIoAwzvTw4v0MBCm+HDyVd25kyAH7cZstyE3CKU4Fm4wq6hybPNiWP5rSRTWVt3ujja0smmA0y6Tzes3HK9ub2ibHHV7vapNIZcVq+5kROcHHuTMrt0yGJc7GkCwV6VQXSnGdRQnf/yZ0fI5Bte4VPY+87H6E3iK0DwU55s6znJ7UW4OPLTcVE+YcUnAph16iJ5FVyO6g6ucmvVK8qNAbwoJhiTOZHgc0sMmi1IGOukNnQFE+4xRtNKzzD1K70TzV03PjtYh/kgjlIHV0uFSAmi5o44dLleBYp4N4ScLzwZEY/4HB2du9QVqgtMZiVN8kTLLcZaaRmpu00MR3fnJanRzULu/r+1adfZ8o90fHrfdbxtoy9sdlY52tRdLvPYRzg//FMJL45LbD7bcuzXY8d4tvSKpkcvpKpKhKlLtEY1j1ST56HJTTbLEkQaxed6W7PeONMmxqs8RX815aVxyewjr28vnfKT2HWnSkb0tOagmNd6Of9ya5LTXJAmBg272B8uaIcqvW5PUlIw4p0zprFf6VotxGzFlkrWMebW0qldVl5m/Vin717xKOcSW+cihh6I3/MI09P3VGxed21/VXuVzZ8q30PiIre10r7nbDiTh6T7kAsUOj7I2we3ddlYsvn2XA6H4giC8+R8=7Vtbc5s4FP41ntk+tGMQAvyYOLdNp9NOvTttn3ZkkDGNQA7It/z6FUayBcK3xNhMA34I5+iCdL5P5xwJ0gH9aHGfoMn4C/Ux6Zhdf9EBNx3TNLqmzf9kmmWucSyQK4Ik9EWljWIQvmDZUminoY/TQkVGKWHhpKj0aBxjjxV0KEnovFhtREnxqRMUYE0x8BDRtT9Cn41zrWs6G/0DDoOxfLJh9/KSCMnKYibpGPl0rqjAbQf0E0pZfhct+phkxpN2ue69/J493t0Yzy/92Xf/3v3nKviYd3Z3TJP1FBIcs9N2beZdzxCZCnuJubKlNGBCp7GPs06MDriej0OGBxPkZaVzThmuG7OIiOK1jbpcGNGYCUJwc/NC3iyMAy7CrDQkpE8JTVaPASOY/UQrRZ9fWWuW0CeslNiri5dEdIaGq+FmQ0hwGr6oMmWIKTInOFZl7IeqKHioaA60vkBphhOGFwr3BBr3mEaYJUteRZTyueVNxMoCUBBtvuEpsIVurHDUcoQSibURrPve4M9vBAWOoENPo8MPPHxAsU9w8jZiKFwwuE2uA4LSVPAkR1auTp1GRaL4CLsjr5IQnouHozoRc7sFxCwANcQMswqxugCTA1AQE3Clq2HxUZndPiJkiLynVIOQz5uVFnDBqDGNcQkBoUIkDGIuetzEnBvgOrNiyN3ulSiIQt/PHlNJjA11yn4CVjoRMWKrNmANWFyKbsVS7Dk6sOAEwBqfH8jEnz7+9yv4m4HH5+gruhe+XMWVxt/x8xSn7K8PjVmKELu+VbUUXXMIVr65LsQsGcDlUrQOXIpmXYgZGmIaTDj2r7KUJls3mdFDr4hMcVlwiyXLn6rwKxM+QSneLNTCm6WUFiH7KYMbv1dacWnTKBNkm+NgSuk08fD+OMJQEmC2w2YCC+wXcjgddAVUWIGp1CWYIBbOiplfFdDiCd9oyKercKrk3iEsdpHPW7RSU61yR3axI2Bbn3rqVew2N5PW7YqFayO8nph6jseD+oB6T5i1oX1baLfNM4b2SthARQT4OsFx6/4r3L/dvbT7tyrguktQhFu8qvA6NHOuDS89caZxn9C0xasSL/vSeNnvM73aFdH3pldWs9IroxhiofHa9Ao4uzuqOaFymkLF42i1ly6gWXTpljIy60R0sctp/Ra6cADRUqk2ySqkh/NbDnjruMr1jUJ9fpOP4KTcdf9Q7sJ3wl2zodx1zsBd/XT63wmhyG93sdt2sevIeLFdrORJe5B5YKYNL3+Q+U5PMnf5nL3xR/K8KQGodJQJwYmOMi3rNUeZbw1HcviHhiMIzxCODLPCteURqfVsVZ7t4md0hn5IdyHPdpzN93sfs1nep3sq71Pe6dvnSX+P9jfn2LoZ+pHl7YzzZ5DHsKY4nOZkv845P8+ohkw/tWxf4mwNEM6h79zqCxD68Uj7VmAHYBd/K2Dq28s/JKLbjY7ozqs/jQBbKFRzRHfgcRHdAWeI6GZjdtqnZq/7TthbTmybwt63HcdycfNZe159888B4PZ/
================================================
FILE: lib/PsychicHttp/src/ChunkPrinter.cpp
================================================
#include "ChunkPrinter.h"
ChunkPrinter::ChunkPrinter(PsychicResponse *response, uint8_t *buffer, size_t len) :
_response(response),
_buffer(buffer),
_length(len),
_pos(0)
{}
ChunkPrinter::~ChunkPrinter()
{
flush();
}
size_t ChunkPrinter::write(uint8_t c)
{
esp_err_t err;
//if we're full, send a chunk
if (_pos == _length)
{
_pos = 0;
err = _response->sendChunk(_buffer, _length);
if (err != ESP_OK)
return 0;
}
_buffer[_pos] = c;
_pos++;
return 1;
}
size_t ChunkPrinter::write(const uint8_t *buffer, size_t size)
{
size_t written = 0;
while (written < size)
{
size_t space = _length - _pos;
size_t blockSize = std::min(space, size - written);
memcpy(_buffer + _pos, buffer + written, blockSize);
_pos += blockSize;
if (_pos == _length)
{
_pos = 0;
if (_response->sendChunk(_buffer, _length) != ESP_OK)
return written;
}
written += blockSize; //Update if sent correctly.
}
return written;
}
void ChunkPrinter::flush()
{
if (_pos)
{
_response->sendChunk(_buffer, _pos);
_pos = 0;
}
}
size_t ChunkPrinter::copyFrom(Stream &stream)
{
size_t count = 0;
while (stream.available()){
if (_pos == _length)
{
_response->sendChunk(_buffer, _length);
_pos = 0;
}
size_t readBytes = stream.readBytes(_buffer + _pos, _length - _pos);
_pos += readBytes;
count += readBytes;
}
return count;
}
================================================
FILE: lib/PsychicHttp/src/ChunkPrinter.h
================================================
#ifndef ChunkPrinter_h
#define ChunkPrinter_h
#include "PsychicResponse.h"
#include
class ChunkPrinter : public Print
{
private:
PsychicResponse *_response;
uint8_t *_buffer;
size_t _length;
size_t _pos;
public:
ChunkPrinter(PsychicResponse *response, uint8_t *buffer, size_t len);
~ChunkPrinter();
size_t write(uint8_t c) override;
size_t write(const uint8_t *buffer, size_t size) override;
size_t copyFrom(Stream &stream);
void flush() override;
};
#endif
================================================
FILE: lib/PsychicHttp/src/PsychicClient.cpp
================================================
#include "PsychicClient.h"
#include "PsychicHttpServer.h"
#include
PsychicClient::PsychicClient(httpd_handle_t server, int socket) :
_server(server),
_socket(socket),
_friend(NULL),
isNew(false)
{}
PsychicClient::~PsychicClient() {
}
httpd_handle_t PsychicClient::server() {
return _server;
}
int PsychicClient::socket() {
return _socket;
}
// I'm not sure this is entirely safe to call. I was having issues with race conditions when highly loaded using this.
esp_err_t PsychicClient::close()
{
esp_err_t err = httpd_sess_trigger_close(_server, _socket);
//PsychicHttpServer::closeCallback(_server, _socket); // call this immediately so the client is taken off the list.
return err;
}
IPAddress PsychicClient::localIP()
{
IPAddress address(0,0,0,0);
char ipstr[INET6_ADDRSTRLEN];
struct sockaddr_in6 addr; // esp_http_server uses IPv6 addressing
socklen_t addr_size = sizeof(addr);
if (getsockname(_socket, (struct sockaddr *)&addr, &addr_size) < 0) {
ESP_LOGE(PH_TAG, "Error getting client IP");
return address;
}
// Convert to IPv4 string
inet_ntop(AF_INET, &addr.sin6_addr.un.u32_addr[3], ipstr, sizeof(ipstr));
//ESP_LOGD(PH_TAG, "Client Local IP => %s", ipstr);
address.fromString(ipstr);
return address;
}
IPAddress PsychicClient::remoteIP()
{
IPAddress address(0,0,0,0);
char ipstr[INET6_ADDRSTRLEN];
struct sockaddr_in6 addr; // esp_http_server uses IPv6 addressing
socklen_t addr_size = sizeof(addr);
if (getpeername(_socket, (struct sockaddr *)&addr, &addr_size) < 0) {
ESP_LOGE(PH_TAG, "Error getting client IP");
return address;
}
// Convert to IPv4 string
inet_ntop(AF_INET, &addr.sin6_addr.un.u32_addr[3], ipstr, sizeof(ipstr));
//ESP_LOGD(PH_TAG, "Client Remote IP => %s", ipstr);
address.fromString(ipstr);
return address;
}
================================================
FILE: lib/PsychicHttp/src/PsychicClient.h
================================================
#ifndef PsychicClient_h
#define PsychicClient_h
#include "PsychicCore.h"
/*
* PsychicClient :: Generic wrapper around the ESP-IDF socket
*/
class PsychicClient {
protected:
httpd_handle_t _server;
int _socket;
public:
PsychicClient(httpd_handle_t server, int socket);
~PsychicClient();
//no idea if this is the right way to do it or not, but lets see.
//pointer to our derived class (eg. PsychicWebSocketConnection)
void *_friend;
bool isNew = false;
bool operator==(PsychicClient& rhs) const { return _socket == rhs.socket(); }
httpd_handle_t server();
int socket();
esp_err_t close();
IPAddress localIP();
IPAddress remoteIP();
};
#endif
================================================
FILE: lib/PsychicHttp/src/PsychicCore.h
================================================
#ifndef PsychicCore_h
#define PsychicCore_h
#define PH_TAG "🔮"
// version numbers
#define PSYCHIC_HTTP_VERSION_MAJOR 1
#define PSYCHIC_HTTP_VERSION_MINOR 1
#define PSYCHIC_HTTP_VERSION_PATCH 0
#ifndef MAX_COOKIE_SIZE
#define MAX_COOKIE_SIZE 512
#endif
#ifndef FILE_CHUNK_SIZE
#define FILE_CHUNK_SIZE 8 * 1024
#endif
#ifndef STREAM_CHUNK_SIZE
#define STREAM_CHUNK_SIZE 1024
#endif
#ifndef MAX_UPLOAD_SIZE
#define MAX_UPLOAD_SIZE (2048 * 1024) // 2MB
#endif
#ifndef MAX_REQUEST_BODY_SIZE
#define MAX_REQUEST_BODY_SIZE (16 * 1024) // 16K
#endif
#ifdef ARDUINO
#include
#endif
#include
#include