- retain setting
- generate topic and message in the discovery object instead of
creating them all at once
- re-implement relays, lights and sensors discovery
- rework name normalization, use relative magnitude indexes
- replace original lights code with schema: json, subscribe to a special
topic to handle lights instead of using the common API
(still wip - colors, hs, temperature settings)
resolve#630resolve#1564resolve#2403
- shrink utils source file, move heartbeat and boot management into system
- improvise with 'heartbeat' functionality. include scheduler implementation that will
manage the per-module heartbeat callbacks with individual 'mode' and
'interval' settings. current ones are mqtt (including relays, lights, thermostat), debug and
influxdb. preserve heartbeat NONE, ONCE and REPEAT, REPEAT_STATUS is effectively a hbReport & status bit.
- mqtt heartbeat is managed through mqttHeartbeat() callbacks
- tweak mqtt callbacks to use lists instead of the vector, slighly reducing the size of the .bin
- update WebUI, include report setting and update hbMode values
- make sure general.h settings include new heartbeat,
move constant definitions outside of the header
- correctly include dependencies through the .cpp, avoid leaking
internal details.
- as a side-effect, base headers are no longer included recursively
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 sensor classes to support a generic way to store energy values
- Update sensor conversion code to deal with units and not magnitudes
- Add magnitude<->unit for sensors, generic way of defining used unit. Convert from sensor magnitude unit to the one used for display.
- Reset energy value based on index through external means (MQTT, HTTP)
- Rework energy timestamping, update webui with 'last saved' value
While this solves the energy conversion issues and we are finally seeing the real value, what I don't really like:
- KilowattHour and WattHour are separate enum tags, thus sort-of are different types altogether
- Conversion code in Energy object should probably use some generic 'ratio' calculation? (https://en.cppreference.com/w/cpp/numeric/ratio/ratio)
- We are still using runtime checks to do calculations and depend that sensor outputs only one specific value type.
Consider this a fix for energy display / storage and preliminary work on sensor.ino
Further sensor refactoring... soon.
- stack-like discovery struct to store pending mqtt topic and
message
- use separate json objects for sensor and switch data (different solution for the #1957)
- customize relay TOGGLE payload
- match payload string when receiving mqtt status message
- reference enum values instead of raw integers, spell out intended status
- remove dead code
amend #1885, capitalize `relayPayload...` suffix instead of using uppercase
add `relayPayloadToggle`
- remove "platform" key, see #1440. this implicitly sets schema to "basic". pending some other clean-up regarding json and mqtt queueing, other schema can be added down the line
- updated ws module queue elem to capture callbacks list, allows to pass more than one callback (for example, when they are generated on the fly as lambdas, see ha wsPost usage)
- modified method to send ha config to use global ws queue, fix#1762 problem with empty topics and ensure json allocation is consistent.
- use existing defines to set mqtt payload options. amend #1085, #1188, #1883 to use the set payload value. drop HOMEASSISTANT_PAYLOAD... defines.
- update MQTT_STATUS_ONLINE/OFFLINE and RELAY_MQTT_ON/OFF with runtime configuration
- filter payload strings so that the resulting yaml value is not interpreted as bool (python True, False)
- helper method for settings to streamline string values manipulation
- 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
Maxim Prokhorov
Alex. Tircovnicu
Thomas
copyrights
Xose Pérez
abmantis
Yonsm