Move inline classes into a separate file.
Make serialize() into a basic function, support numeric conversions with base option
Refactor numeric conversions and add some more helper functions for the
build flags.
- gpio module now tracks the known providers (right now, hardware and mcp expander)
- refactored relay struct to use 'Provider' implementing setup,notify,change,boot instead of just BasePin actions
- refactored button module to use gpio provider instead of referencing types itself
- removed dual & stm code from buttons, migrate both to relay module
- added status notify and change callbacks for relayStatus (i.e. 'notify' when relay status was called, but not changed. and 'changed' when it did)
- relays runtime configuration keys
- relay command now shows configured relays and current & target statuses
- refactor the code using relayStatus(0, blah) under LIGHT_PROVIDER check to use lightState instead
- remove rfbridge code form relay module. implement through a basic state listener in the rfbridge module, depend on RELAY_SUPPORT
- allow to bind rf codes to real relays
- drop tuya-specific lights provider, remove tuya code from relays and lights modules
- integrate tuya via relay listeners and providers, use lights custom provider
- implement channel transitions for tuya. disabled by default, and transition time and step are overridden to 2000 + 100. needs to be set to some value below the total time (i.e. `total transition time / step time == number of steps`, we need to figure out a correct time that serial comms could handle)
- lights custom provider (global, not per-pin) and state listeners
- remove lights code from relay module. implement through providers & listeners in the lights module, depend on RELAY_SUPPORT
- lights per-channel relay provider (unused atm), depend on RELAY_SUPPORT
- refactored channel transition - calculate step only once, make sure time + step values are sane, generate quick transitions with very small delay (10ms hardcoded) for transitions during OFF state i.e. we no longer waste 500ms (or whatever transition time is set to) on boot doing nothing
- transition time + step parameter for the lightUpdate
- report mask parameter for the lightUpdate
- minor fixes across the board
resolve#2222
- match paths through a custom AsyncWebHandler instead of using generic not-found fallback handler
- allow MQTT-like patterns when registering paths (`simple/path`, `path/+/something`, `path/#`)
Replaces `relay/0`, `relay/1` etc. with `relay/+`. Magnitudes are plain paths, but using `/+` in case there's more than 1 magnitude of the same type.
- restore `std::function` as callback container (no more single-byte arg nonsense). Still, limit to 1 type per handler type
- adds JSON handlers which will receive JsonObject root as both input and output. Same logic as plain - GET returns resource data, PUT updates it.
- breaking change to `apiAuthenticate(request)`, it no longer will do `request->send(403)` and expect this to be handled externally.
- allow `Api-Key` header containing the key, works for both GET & PUT plain requests. The only way to set apikey for JSON.
- add `ApiRequest::param` to retrieve both GET and PUT params (aka args), remove ApiBuffer
- remove `API_BUFFER_SIZE`. Allow custom form-data key=value pairs for requests, allow to send basic `String`.
- add `API_JSON_BUFFER_SIZE` for the JSON buffer (both input and output)
- `/apis` replaced with `/api/list`, no longer uses custom handler and is an `apiRegister` callback
- `/api/rpc` custom handler replaced with an `apiRegister` callback
WIP further down:
- no more `webLog` for API requests, unless `webAccessLog` / `WEB_ACCESS_LOG` is set to `1`. This also needs to happen to the other handlers.
- migrate to ArduinoJson v6, since it become apparent it is actually a good upgrade :)
- actually make use of JSON endpoints more, right now it's just existing GET for sensors and relays
- fork ESPAsyncWebServer to cleanup path parsing and temporary objects attached to the request (also, fix things a lot of things based on PRs there...)
- for some reason we were never checking it's output
no need to increase +1 since we write the exact number
- allow hexEncode output be decoded, enforce even-ness
- raw msg must have at least 3 bytes - start+code+end
- 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
Add new V3.0 version of PZEM004T, not tested. Default to factory default address 0xf8, configurable through pzemv30Addr 8-bit number
Add 'frequency' measurement & 'hz' unit
Add pz.address that configures address
Implemented energy reset
Right now we only support a single device. No way to test this properly (mostly, how exactly we need to connect this stuff), so left as not implemented.
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
- mask is defined as (relay# status << number)
- transparently handle base-2 and base-10 numbers
- if the relay mode requires us to save the mask, it will be saved as base-2
- 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
- remove optional RFRAW_SUPPORT
- enable module when RF_SUPPORT=1, optionally enable RCSwitch
- reorder ifdef checks to treat RFB_DIRECT and old RF_SUPPORT the same
- rename RF_PIN to RFB_RX_PIN
- depend on RF_SUPPORT instead of ITEAD_SONOFF_RFBRIDGE
- runtime TX & RX PIN setting
Maxim Prokhorov
Xose Pérez
Niek van der Maas