alexa device discovery/state calls use URL of type
/api/hash_id_key_whatever/lights
This is blocked when API is disabled and fails
also when http API is enabled because no apikey is
sent by amazon calls
Don't try to use the http api for alexa calls.
Responses for alexa are done by fauxmoesp lib,
so there's no need for the http api call.
- reduce overall size of the structure, store a single required entity
inside of Api object itself.
- tweak internal functions to expect a certain path size
- (kind of a hack) add manual calls to vector<Api>::reserve() as we go over
the current capacity and vector increases it's size times 2.
e.g. for 9 relays, we would allocate space for 32 Api objects
when vector size goes from 16 to 32, after we add 18 Api objects with relay + pulse
- (breaking) json calls on a separate path, don't waste time encoding
a single entity as json object when we can encode more things
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.
- general conversion from .ino modules into a separate .cpp files
- clean-up internal headers, place libraries into .h. guard .cpp with _SUPPORT flags
- fix some instances of shared variables instead of public methods
- tweak build system to still build a single source file via os environment variable ESPURNA_BUILD_SINGLE_SOURCE
- update every dynamicjsonbuffer with fixed size constructor argument
- change to ws callback registration to use a class builder (just cosmetic)
- test multiple ws data callbacks for each module
- remove some of the static strings in favour of ws data callback
- improve sensor ws callback data size, remove duplicated strings
- use static buffer in wsDebugSend
- postpone wsSend until loop, implement wsPost to allow other modules to queue message callbacks. remove Ticker based ws callbacks for data
- update WebUI files
aL1aL7
Maxim Prokhorov
Malachi Soord
Xose Pérez