execute multiple transition-initiating functions
when we don't do any transitions or have value changes queued
main application for right now is a simple notification
routine that consists of N single channel on->off transitions
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
- allow both new-pwm and analogWrite (Core) implementations
- rework new-pwm initialization, a bit more sane type for pin config
- remove pin setup from lights, everything is handled by provider already
Core prepares and initializes pins when updating duty, new-pwm does this
when pwm_init is called
- rework internals related to value scaling, allow percentage as pwm duty
and value limit (instead of absolute limit set by lights previously)
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)
Make sure it could be moved further along, and the values inside of it
can be safely moved as well.
Also fixup commands that were missing ctx in OK / Error.
There's no need to move a temporary which is already an rvalue
Clean-up some redundant attributes and function in settings.
Make sure C types are proxied to fixed-sized ones, not the other way around.
Clean-up webprint implementation
- use typed duration for the backlog
- don't duplicate members and types for config, just re-use the struct as-is
- don't go over-the-top with const members, just proxy through a method
- 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
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)
This was causing WebUI colorpicker to jump between positions in rgb mode, after the websocket immediately reported back rgb tuple containing different values
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
resolve#2451
Paranoid locking doesn't really matter in the current setup (but, leave some comments about how to solve it when it actually does).
Also copy internal tuple of save+transition+report and give the copy to the callback. Thus, don't assume the consumer is always nice,
and does not declare refs to internal struct variables, making this kind of hard to track.
Refactor internal code so it does not export functions to the built .o
- more static flash strings and flash string formats
- println() will write \r\n when we mostly just use the \n
(and avoid mixing it up in the same function)
Namespace build configurations of modules, make more things into constexpr
(not fully finished though)
Unify code using ...Count() to parse IDs
Avoid using unsigned char aka uint8_t as index, prefer size_t
as most code already uses it anyway. Making sure we never accidentally
truncate the value or try to read it as 32bit-wide. Also, simplify
access to built in containers, since those use the wide type as well.
Renames led and button types, more consistent initialization and field access.
Make gamma & invert flags only apply to the transition itself.
Revert to previous behaviour, where the modified value is only ever seen
by the provider function.
- clamp values via helper functions
- unify channel access as long
slightly more ram, but we no longer cast values that are 32bit-wide anyway
- remove css option, send unconditionally as /hex
- reimplement hsv conversion functions (based on HA / python's colorsys)
simplify calculations and allow to return standalone value structs for
RGB and HSV
- named channel accessors
- implement HA color inputs / outputs
Make sure 'custom provider' `lightAdd()` scheduled function locks further channel modifications,
and take care of light sanity checks before the light update is even scheduled.
Reworked rtcmem reader / writer to use default values, instead of accidentaly using
the unitialized mem of the stack. Also, reworked const names used by the lights module
to distinguish them from the build flags.
