diff --git a/esp32/lib/PsychicHttp/CHANGELOG.md b/esp32/lib/PsychicHttp/CHANGELOG.md
deleted file mode 100644
index 60c2f81..0000000
--- a/esp32/lib/PsychicHttp/CHANGELOG.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# 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
\ No newline at end of file
diff --git a/esp32/lib/PsychicHttp/LICENSE b/esp32/lib/PsychicHttp/LICENSE
deleted file mode 100644
index 0a04128..0000000
--- a/esp32/lib/PsychicHttp/LICENSE
+++ /dev/null
@@ -1,165 +0,0 @@
- 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.
diff --git a/esp32/lib/PsychicHttp/README.md b/esp32/lib/PsychicHttp/README.md
deleted file mode 100644
index 0eedd53..0000000
--- a/esp32/lib/PsychicHttp/README.md
+++ /dev/null
@@ -1,619 +0,0 @@
-# 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)
-
-## 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());
-});
-```
-
-# 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.1: Event Source + Handlers
-
-* Fix all outstanding issues on Github
-* Another pass over the docs
- * DefaultHeaders
-
-
-## v1.2: ESPAsyncWebserver Parity
-
-* HTTP_ANY support (by abusing httpd_req_handle_err)
- * Issue: it would log a warning on every request (httpd_uri.c:298)
- * Issue: req->user_ctx is not passed in. (httpd_uri.c:309)
- * Websocket support assumes an endpoint with matching url / method (httpd_uri.c:312)
-
-* templating system
-* rewrite
-* regex url matching
-* 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.
diff --git a/esp32/lib/PsychicHttp/assets/handler-callbacks.svg b/esp32/lib/PsychicHttp/assets/handler-callbacks.svg
deleted file mode 100644
index 62fcbdf..0000000
--- a/esp32/lib/PsychicHttp/assets/handler-callbacks.svg
+++ /dev/null
@@ -1,4 +0,0 @@
-
-
-
-
\ No newline at end of file
diff --git a/esp32/lib/PsychicHttp/assets/request-flow.svg b/esp32/lib/PsychicHttp/assets/request-flow.svg
deleted file mode 100644
index 999fb00..0000000
--- a/esp32/lib/PsychicHttp/assets/request-flow.svg
+++ /dev/null
@@ -1,4 +0,0 @@
-
-
-
-
\ No newline at end of file
diff --git a/esp32/lib/PsychicHttp/library.json b/esp32/lib/PsychicHttp/library.json
deleted file mode 100644
index 2eca5b1..0000000
--- a/esp32/lib/PsychicHttp/library.json
+++ /dev/null
@@ -1,48 +0,0 @@
-{
- "name": "PsychicHttp",
- "version": "1.0.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" : "LGPL-3.0-or-later",
- "examples": [
- {
- "name": "platformio",
- "base": "examples/platformio",
- "files": [
- "src/main.cpp"
- ]
- }
- ],
- "frameworks": "arduino",
- "platforms": "espressif32",
- "dependencies": [
- {
- "owner": "bblanchon",
- "name": "ArduinoJson",
- "version": "^6.21.4"
- },
- {
- "owner": "bblanchon",
- "name": "ArduinoTrace",
- "version": "^1.2.0"
- },
- {
- "owner": "plageoj",
- "name" : "UrlEncode",
- "version" : "^1.0.1"
- }
- ]
-}
diff --git a/esp32/lib/PsychicHttp/library.properties b/esp32/lib/PsychicHttp/library.properties
deleted file mode 100644
index 8557da1..0000000
--- a/esp32/lib/PsychicHttp/library.properties
+++ /dev/null
@@ -1,11 +0,0 @@
-name=PsychicHttp
-version=1.0.1
-author=Zach Hoeken
-maintainer=Zach Hoeken
-sentence=PsychicHttp is a robust webserver that supports http/https + websockets.
-paragraph=This library is based on the ESP-IDF HTTP Server library which is asynchronous, does http / https+ssl and supports websockets.
-category=Communication
-architectures=esp32
-url=https://github.com/hoeken/PsychicHttp
-includes=PsychicHttp.h
-depends=ArduinoJson,ArduinoTrace,UrlEncode
\ No newline at end of file
diff --git a/esp32/lib/PsychicHttp/request flow.drawio b/esp32/lib/PsychicHttp/request flow.drawio
deleted file mode 100644
index 8915583..0000000
--- a/esp32/lib/PsychicHttp/request flow.drawio
+++ /dev/null
@@ -1 +0,0 @@
-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/
\ No newline at end of file
diff --git a/esp32/lib/PsychicHttp/src/ChunkPrinter.cpp b/esp32/lib/PsychicHttp/src/ChunkPrinter.cpp
deleted file mode 100644
index b3f8713..0000000
--- a/esp32/lib/PsychicHttp/src/ChunkPrinter.cpp
+++ /dev/null
@@ -1,85 +0,0 @@
-
-#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;
-}
\ No newline at end of file
diff --git a/esp32/lib/PsychicHttp/src/ChunkPrinter.h b/esp32/lib/PsychicHttp/src/ChunkPrinter.h
deleted file mode 100644
index f63fac0..0000000
--- a/esp32/lib/PsychicHttp/src/ChunkPrinter.h
+++ /dev/null
@@ -1,27 +0,0 @@
-#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
\ No newline at end of file
diff --git a/esp32/lib/PsychicHttp/src/PsychicClient.cpp b/esp32/lib/PsychicHttp/src/PsychicClient.cpp
deleted file mode 100644
index fd7820d..0000000
--- a/esp32/lib/PsychicHttp/src/PsychicClient.cpp
+++ /dev/null
@@ -1,72 +0,0 @@
-#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;
-}
\ No newline at end of file
diff --git a/esp32/lib/PsychicHttp/src/PsychicClient.h b/esp32/lib/PsychicHttp/src/PsychicClient.h
deleted file mode 100644
index b823df7..0000000
--- a/esp32/lib/PsychicHttp/src/PsychicClient.h
+++ /dev/null
@@ -1,35 +0,0 @@
-#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
\ No newline at end of file
diff --git a/esp32/lib/PsychicHttp/src/PsychicCore.h b/esp32/lib/PsychicHttp/src/PsychicCore.h
deleted file mode 100644
index fe88b38..0000000
--- a/esp32/lib/PsychicHttp/src/PsychicCore.h
+++ /dev/null
@@ -1,107 +0,0 @@
-#ifndef PsychicCore_h
-#define PsychicCore_h
-
-#define PH_TAG "psychic"
-
-//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