updated duration parser with a fixed type instead of just millis
separate decimal and floating point converter as well, try to avoid
possible precision loss with microseconds use
see #2578
* deep sleep api without ESP class dependency
* rf + cpu light sleep for cases when deep sleep cannot be used
* generic time-based light sleep; nonos does not halt cpu,
unlike the wakeup variant. timers also keep going, so
this has to be used with extra care
pending some 'deferred' variant and before and after sleep actions
disarm is *required* by the underlying API, don't miss it on start()
while the func uses a resource lock internally, it does not seem to be the
source of system lock-ups encountered so far
c/p PSTR attribute from Core files
dostring declaration with a macro instead of a scary looking boilerplate
saves varying amount of code space, mostly deals with our key and cmd strings
* make sure we don't apply hsv and brightnesss, only take hue and saturation
when calculating inputs. use value as brightness percentage, wrapping
the original function (which also makes other modules use this codepath)
* deduce interface elements based on both setting and incoming
properties. wrap everything in {light: ...} in both inputs and
outputs, alse allow to update multiple properties at the same time
* add light state toggle when special lights relay is not set up
* remove channel, state and brightness elements through css styling
instead of going to the elements directly. no need to chech whether
certain elements exist
* globally accessible system timer class; help out with our internal
scheduling by always using strongly typed duration and dynamic
time adjustment for durations longer than system limits
(see `os_timer_t` documentation)
* our own class for scheduled callbacks which are either choosing a
simple function pointer or std function wrapper, depending on the type
passed into the constructor. specifically for scheduled functions,
this allows us to filter globally scheduled functions and push them to
the front of the queue when necessary to ensure certain order of calls
* replace Ticker instances with SystemTimer
* allow types {h, cpp} in unit tests
One server implementation instead of two, plus simplify I/O operations
scheduling by processing everything in loop regardless of the server
type used.
Make it possible to accept authorization and several commands in a
single packet. If we fail the check, clients discards rest of the data.
Since we finally track connection state, debug info gets set *only* to
authorized clients.
get rid of board module, replace with system calls for hostname, board
and password. move boot (quirks) handlers to system as well
espurna::build { ... } namespace for our app const values
- reduce number of resets that triggers unstable mode
- introduce a reboot reason for stability counter
which only gets handled on soft-reset
- allow to forcibly change to either stable or unstable mode
more explicit terminal comands to leave or enter either mode
rework more namespaces to use `espurna` root
makes internal references much easier (and shorter)
view class is not specific to settings, could use it across the app
remove duplicate code from IR
Separate variables that are used just for the internal loop,
and the ones that are supposed to go into the client as args
Clean up logging and the terminal output, certain things are
now visible through the settings query and there's no need to
dump the build value
Settling on naming 'options' for enumerations (...possibly, everything
else in the future, would that make sense to store for 'setting' object)
Update terminal commands that were reporting status to also report a
full list of 'indexed' settings for the specific entity
Also updates the WebUI outputs which are (hopefuly) are already handled
as-is through the .js processing pipeline and the .html properties
receiving certain special string values
More namespacing and save ~2KiB of RAM by reducing the amount of loaded keys strings
However, ROM side of things may suffer b/c of template specializations for the
generic conversion functions when there are many different types involved.
Make sure we seamlessly handle 'convert' for the number and the string version.
And since it is a two-way map, update 'serialize' to use it as well instead of
either a simple static_cast<int> or duplicating the same strings used in 'convert'
Only string literals or static vars can be used in constexpr context,
but those can still be shoved into the flash region via PROGMEM.
Notably, PSTR(...) inside of a lambda is not a constexpr.
Some quirks to work out
- we don't 'enumerate' things through compiler, enum values may go
missing since it is not a switch-case
- 'get' default value via query still requires us to know the settings
key in the first place. and it still needs an explicit call to
'serialize'
- sensor units are stringified as their display value.
but, this also avoids two different 'string' versions of those
- EnumOptions struct instance may also be in PROGMEM, but one needs
to be very careful to only allow aligned access to it's members
(which currently means we can't use 8bit or 16bit 'enum class'es)
Don't introduce our callback to the type system, continue to bind the
ticker instance as the timer's arg and just use the lambda to pass the
argument to the reset function
```
libraries/Ticker/src/Ticker.h:136:41: warning: cast between incompatible function types from 'void (*)(CustomResetReason)' to 'Ticker::callback_with_arg_t' {aka 'void (*)(void*)'} [-Wcast-function-type]
136 | _attach_ms(milliseconds, false, reinterpret_cast<callback_with_arg_t>(callback), reinterpret_cast<void*>(arg));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Make sure to properly clamp delay times, as the recent issue had shown
it is possible to go below the update limit. SNTP app does not do any
runtime checks, so it's up to us to enforce these limits
Update internal random number generator from raw `secureRandom()` to a custom
'std::random_device'-look-alike, where we could also use it with STL functions
(current implementation is `os_random()` aka `esp_random()`)
Not as clean as other modules, but at least prepare for the further changes.
Implement settings for float duration conversion, and test it out with pulse
and flood window time values.
More safe-guards for an externally-defined pulse time, make sure it is
not either inf or nan and is an actual finite number
Also use EnumerableConfig for the WebUI output, and make sure to use
internal _relays.size() instead of doing a function call
- BREAKING replace loadavg and system check from millis to seconds
- implement all available system clocks, make sure it is correctly
scaled with the origin type
- fix duration::{millis(),ccount(),seconds()} and return a respective
clock's time_point instead of duration. just like led sources, make
sure every module stores timestamps as time_point and intervals as
duration
- no need to track millis overflow on top of existing overflow counter
of the micros64 in getUptime
- remove class overhead in led static delays conversion, just try to
inline the required calculations and use NAME as unique id
also fix some non-apparent issues with heartbeat
- allow zero interval when it is also Mode::Once
- iterating runners to find the interval might return zero
- remove 'local' index and replace sensor code depending on it with the
existing 'slot' aka 'magnitude index' used in value() and type()
- common method to store and retrieve ratios for voltage, current,
active power and energy. default implementation is no-op, sensor
should implement ratio adjustment & calculations to use 'slot' indexes
- re-implement 'expected' values ui. display the actual ratio values,
and have a separate page for updating them in a more apparent way
- remove legacy settings that were adjusting expected values
- remove legacy settings that were resetting ratios and analog calibration
- generic webui action caller, add ratios and analog calibration resets
all of 'emon' sensors were updated to utilize the new approach to the
ratio handling. pulsemeter is somewhat an outlier, but it is unclear
whether removing the energy ratio is justified
terminal part was also updated
- implement `expected` command that hooks into the new ratioFromValue
(and what webui uses to calculate ratios)
- implement `energy` command to list only MAGNITUDE_ENERGY
- remove old pzem004t commands doing ratio reset and total energy count
another global update is related to espurna::duration
- rework module-local heartbeat and led durations into a global
espurna::duration
- update sensor internals to use specific units instead of multiplying things
on line-by-line basis. export count() to the api