Fork of the espurna firmware for `mhsw` switches
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

100 lines
2.4 KiB

Terminal: change command-line parser (#2247) Change the underlying command line handling: - switch to a custom parser, inspired by redis / sds - update terminalRegisterCommand signature, pass only bare minimum - clean-up `help` & `commands`. update settings `set`, `get` and `del` - allow our custom test suite to run command-line tests - clean-up Stream IO to allow us to print large things into debug stream (for example, `eeprom.dump`) - send parsing errors to the debug log As a proof of concept, introduce `TERMINAL_MQTT_SUPPORT` and `TERMINAL_WEB_API_SUPPORT` - MQTT subscribes to the `<root>/cmd/set` and sends response to the `<root>/cmd`. We can't output too much, as we don't have any large-send API. - Web API listens to the `/api/cmd?apikey=...&line=...` (or PUT, params inside the body). This one is intended as a possible replacement of the `API_SUPPORT`. Internals introduce a 'task' around the AsyncWebServerRequest object that will simulate what WiFiClient does and push data into it continuously, switching between CONT and SYS. Both are experimental. We only accept a single command and not every command is updated to use Print `ctx.output` object. We are also somewhat limited by the Print / Stream overall, perhaps I am overestimating the usefulness of Arduino compatibility to such an extent :) Web API handler can also sometimes show only part of the result, whenever the command tries to yield() by itself waiting for something. Perhaps we would need to create a custom request handler for that specific use-case.
4 years ago
Terminal: change command-line parser (#2247) Change the underlying command line handling: - switch to a custom parser, inspired by redis / sds - update terminalRegisterCommand signature, pass only bare minimum - clean-up `help` & `commands`. update settings `set`, `get` and `del` - allow our custom test suite to run command-line tests - clean-up Stream IO to allow us to print large things into debug stream (for example, `eeprom.dump`) - send parsing errors to the debug log As a proof of concept, introduce `TERMINAL_MQTT_SUPPORT` and `TERMINAL_WEB_API_SUPPORT` - MQTT subscribes to the `<root>/cmd/set` and sends response to the `<root>/cmd`. We can't output too much, as we don't have any large-send API. - Web API listens to the `/api/cmd?apikey=...&line=...` (or PUT, params inside the body). This one is intended as a possible replacement of the `API_SUPPORT`. Internals introduce a 'task' around the AsyncWebServerRequest object that will simulate what WiFiClient does and push data into it continuously, switching between CONT and SYS. Both are experimental. We only accept a single command and not every command is updated to use Print `ctx.output` object. We are also somewhat limited by the Print / Stream overall, perhaps I am overestimating the usefulness of Arduino compatibility to such an extent :) Web API handler can also sometimes show only part of the result, whenever the command tries to yield() by itself waiting for something. Perhaps we would need to create a custom request handler for that specific use-case.
4 years ago
Terminal: change command-line parser (#2247) Change the underlying command line handling: - switch to a custom parser, inspired by redis / sds - update terminalRegisterCommand signature, pass only bare minimum - clean-up `help` & `commands`. update settings `set`, `get` and `del` - allow our custom test suite to run command-line tests - clean-up Stream IO to allow us to print large things into debug stream (for example, `eeprom.dump`) - send parsing errors to the debug log As a proof of concept, introduce `TERMINAL_MQTT_SUPPORT` and `TERMINAL_WEB_API_SUPPORT` - MQTT subscribes to the `<root>/cmd/set` and sends response to the `<root>/cmd`. We can't output too much, as we don't have any large-send API. - Web API listens to the `/api/cmd?apikey=...&line=...` (or PUT, params inside the body). This one is intended as a possible replacement of the `API_SUPPORT`. Internals introduce a 'task' around the AsyncWebServerRequest object that will simulate what WiFiClient does and push data into it continuously, switching between CONT and SYS. Both are experimental. We only accept a single command and not every command is updated to use Print `ctx.output` object. We are also somewhat limited by the Print / Stream overall, perhaps I am overestimating the usefulness of Arduino compatibility to such an extent :) Web API handler can also sometimes show only part of the result, whenever the command tries to yield() by itself waiting for something. Perhaps we would need to create a custom request handler for that specific use-case.
4 years ago
  1. /*
  2. WEBSERVER MODULE
  3. Copyright (C) 2016-2019 by Xose Pérez <xose dot perez at gmail dot com>
  4. */
  5. #pragma once
  6. #include "espurna.h"
  7. #if WEB_SUPPORT
  8. #include <functional>
  9. #include <list>
  10. #include <vector>
  11. #include <Print.h>
  12. #include <ESPAsyncTCP.h>
  13. #include <ESPAsyncWebServer.h>
  14. #include <Hash.h>
  15. #include <FS.h>
  16. #include <AsyncJson.h>
  17. #include <ArduinoJson.h>
  18. struct AsyncWebPrintConfig {
  19. const char* const mimeType;
  20. const size_t backlogCountMax;
  21. const size_t backlogSizeMax;
  22. const decltype(millis()) backlogTimeout;
  23. };
  24. struct AsyncWebPrint : public Print {
  25. enum class State {
  26. None,
  27. Sending,
  28. Done,
  29. Error
  30. };
  31. using BufferType = std::vector<uint8_t>;
  32. // To be able to safely output data right from the request callback,
  33. // we schedule a 'printer' task that will print into the request response buffer via AsyncChunkedResponse
  34. // Note: implementation must be included in the header
  35. template<typename CallbackType>
  36. static void scheduleFromRequest(const AsyncWebPrintConfig& config, AsyncWebServerRequest*, CallbackType);
  37. template<typename CallbackType>
  38. static void scheduleFromRequest(AsyncWebServerRequest*, CallbackType);
  39. State getState();
  40. void setState(State);
  41. // note: existing implementation only expects this to be available via AsyncWebPrint
  42. #if defined(ARDUINO_ESP8266_RELEASE_2_3_0)
  43. void flush();
  44. #else
  45. void flush() final override;
  46. #endif
  47. size_t write(uint8_t) final override;
  48. size_t write(const uint8_t *buffer, size_t size) final override;
  49. const char* const mimeType;
  50. const size_t backlogCountMax;
  51. const size_t backlogSizeMax;
  52. const decltype(millis()) backlogTimeout;
  53. protected:
  54. std::list<BufferType> _buffers;
  55. AsyncWebServerRequest* const _request;
  56. State _state;
  57. AsyncWebPrint(const AsyncWebPrintConfig&, AsyncWebServerRequest* req);
  58. bool _addBuffer();
  59. bool _exhaustBuffers();
  60. void _prepareRequest();
  61. };
  62. using web_body_callback_f = std::function<bool(AsyncWebServerRequest*, uint8_t* data, size_t len, size_t index, size_t total)>;
  63. using web_request_callback_f = std::function<bool(AsyncWebServerRequest*)>;
  64. AsyncWebServer* webServer();
  65. bool webAuthenticate(AsyncWebServerRequest *request);
  66. void webLog(AsyncWebServerRequest *request);
  67. void webBodyRegister(web_body_callback_f);
  68. void webRequestRegister(web_request_callback_f);
  69. uint16_t webPort();
  70. void webSetup();
  71. #endif // WEB_SUPPORT == 1