Generic way to find out which units the magnitude type supports.
Clean-up UI related to temperature, energy and power units.
Resolves#2482
Also apply some refactoring to the 'schema'-generated
payloads by using the EnumerableConfig helper class.
Class received some new features:
- optional callback, verifying that index should be used at all
specific use-case is magnitudes list that needs only 'counted' ones
- std::iota / ranges::iota_view -like helper object for sequences
starting with something other than 0
Reordered payloads, prefer queueing over sending everything at once.
given that relay, button and led settings may be hardcoded,
explicitly remove from -core and -core-webui
restore telnet debugging though, since the terminal output needs it
for -core-webui, disables mdns and the generic webui server + webui blob
per 56f74cfe, make the resulting .bin even smaller
* Add SERIAL_SENSOR support
* Implement "MQTT.SEND" command, remove all other commands (#2477)
* Move command to mqtt.cpp and drop extra files
* Update CHANGELOG.md
Co-authored-by: Max Prokhorov <prokhorov.max@outlook.com>
As noticed in the #2472
Internal implemementation still lacks the support for the GPIO16,
as it needs to use 'special' IO16 registers (and due to the fact that the 'normal'
registers only fit in an u16[16], from 0 to 15, so internals need to change as well)
One possible way is to attach certain implementation funcs to the
struct handling the isr, avoiding a bunch of in-line checks for `pin == 16`
Another option is to just use Core's `analogWrite`, which hides the
implementation from us and should work pretty seamlessly.
(...but, currently has 2 different waveform generator types, and it is
not really clear which one is a better default, as it needs to be set at
build-time)
Implement strongly-typed time units via std::chrono,
compile-time checks with static delays and limit possible values in the
pattern parser. Clamp 'repeats' as well, instead of relying on overflow
Rework internal loop & template runners, so there's no need to
proxy status and led struct all over. Instead, simply declare two
separate funcs that are supposed to be run during the pattern and at
it's end.
Instead of cloning the 'delays' array, implement a sequence iterator
that is tracking the currently used delay and it's repeats, and which
also jumps to the next entry in the list.
(but, this uses c++ iterators, and *may* be prone to errors)
Implement small terminal command 'led <ID> [<PATTERN STRING>]'.
Running without the 'PATTERN STRING' resets the LED to the values in settings.
Move re2c-generated parser back into a separate file, use .cpp.inc as
include and .re as the source
ref. #2476, fix 'finite' pattern handling
Another type of payload from the IRremoteESP8266, intended to be used
with HVAC devices. Also add a bunch of comments in regards to IRac.h
More tweaks to the internal StringView and ParseResult, make
sure the implementation closely follows the STL alternatives.
More configuration options for the:
- Transmitter, support INPUT_PULLUP
- Receiver, allow to set signal inversion and modulation.
Correctly implement buffer size setting.
- MQTT topics, allow to override both in and out
Also fix the 'simple' parser HEX range, accepting 8byte payloads (16chars)
and allowing lowercase inputs.
Declare settings under it's own namespace, where previous version used
function prefix. Allow to have configurable timeout and buffer size for
rx; default series, repeats and delay values for tx.
Values are reloaded with the appropriate configure() function from the
namespace, unless they apply to the IR{send,recv} object itself.
Also, no need to define 'default' fields for either of the Payload
structures. After parsing is done, pass all of string views to the
function defined in the .cpp that will prepare the resulting value.
- provide a queue for the outgoing messages, don't depend on the MQTT
callback implementation details and always postpone the actual transfer.
- generate user input parsers using re2c, adds special PlatformIO build handlers
- add terminal command to show GPIO info and send a simple payload
- rework button<->action presets into value<->terminal command presets and custom ones
through the use of `irCmd<VALUE>` settings, where the VALUE is taken from the simple payload
(yet, it does not understand repeated codes, but that's something to add later *or* use rpnlib)
- add tx message integration for the relay module via `irRelayOn#` and `irRelayOff#`
- rework simple payload to include 'repeats' value for the 'IRsend::send()'
also adds internal 'series', 'delay' and includes full 64bit 'value'
(as uppercase HEX, instead of decimal)
- rework raw payload to use 'series' instead of 'repeats', and provide a
clear distinction between the usec time and the options of the message
by moving the required options to the front and separating them using ':'
(just like the simple variant)
- make RX and TX pin a runtime setting, make RX and TX support a build flag
- small test framework to check whether internal string encode<->decode works
Also updates the hexEncode & hexDecode implementations to use
'iterators' instead of just pointer + index.
This was causing WebUI colorpicker to jump between positions in rgb mode, after the websocket immediately reported back rgb tuple containing different values
When building single source, enums for HTTP status codes have a name conflict.
ESP8266WebServer is included only in the OTA_WEB_SUPPORT=1 and WEB_SUPPORT=0,
so guard by checking for WEB_SUPPORT before including anything related to the async variant.
Using Core's ESP8266WebServer + some additional handlers.
Includes barebones page, without authorization.
Allows to explicitly set OTA_WEB_SUPPORT=1 with the ESPURNA_CORE and still get a web page.
Around the same size as ArduinoOTA + MDNS, so it might also be a good
suggestion to disable those when web support is enabled.
Replace with a postponed message, where it is actually relevant.
For the NoFUSS - as with all OTA methods, page will be reloaded automatically.
And no more strlen_P into a variable-length array.
Indexed address settings & build flags.
Old parsing code is still here, but depends on the old build flag presence.
Remove most of the singleton-related code, update terminal commands to
use ctx instead of just dumping debug strings.
Since the initialization happens in the sensor setup, and we know the
pzem pointer - simply pass the 'sensor' address to the function and
utilize the c++ local static variable feature that allows their use in
the function body and any lambdas declared within it.
Multiplexing is still happening with the index-math, due for a change at
a later date (...with serial / hwserial / stream changes...)
Reading clang-tidy reports... Make sure to explicitly handle instances
of float -> (unsigned) long silently removing the fractional part.
Also, small adjustments to the way these values are parsed.
Specifically:
- calculating step & time in the transition function
- rgb channels temperature adjustment from kelvins
Get rid of input & target as bool param. Replace it with more
specific functions, named accordingly, returning the Rgb struct.
(also fixes `rgb` command not returning what the rest of the API returns)
As a side-effect, make RGB payload conversion use a more paranoid parsing & serialization methods.
So it's no longer required to change any values or the state
Slightly changed the inputValue -> value transformation classes,
actually using the recursive template to apply things in order.
Still a bit quirky, but nothing better comes to mind for this.
Fixes color+(white or cct) brightness function factor calculation
to actually do what the comment says it does.
No more unsigned char for value, consistent integer math and
explicit clamping of the input & output values.
As a follow-up for the a55cf0b, reworks brightness functions:
- value input and application implemented as part of the channel class
- track value changes externally, no need for OnceFlag
- simple all, only-rgb, color+white and color+cct are distinct
functions, where brightness classes implement the actual math
- avoid accidentally doing an actual function call through
`lightChannels()` by not accessing channels elements & size directly
through the vector (yay c++ strictness regarding *public* symbols)
In case the rgb+white(cct) brightness function was selected by the
configuration, internal calculations will always result in 'changed' being 'true'
and as a result it will continiously re-create the transition object.
fix#2467 (at least for now, the brightness function should be actually fixed)
Otherwise, some things are still hidden
(or, depend on the order of incoming messages)
Make thermostat code use those as well, instead of injecting
thermostatVisible in every json payload