- return PID when sending and subscribing, allow to subscribe
to a special event when receiving acknowledgement from the broker
(separate from normal lifecycle callback, since we allow a generic callable)
- rework HomeAssistant to publish with QoS 1 and wait until the broker responds.
lwmqtt sync library already did that, so this change only affects async library
- re-add `ha.send` command
- don't send HomeAssistant config when disabled, unless requested
- some more comments
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.
Make sure transition is always pushed into the vector the same way
Only happens with ESPURNA_BUILD_SINGLE_SOURCE=1:
/home/runner/.platformio/packages/toolchain-xtensa/xtensa-lx106-elf/include/c++/4.8.2/bits/vector.tcc:405:31: error: __c causes a section type conflict with __c
_M_check_len(size_type(1), __EXCSTR("vector::_M_emplace_back_aux"));
^
/home/runner/.platformio/packages/toolchain-xtensa/xtensa-lx106-elf/include/c++/4.8.2/bits/vector.tcc:71:23: note: '__c' was declared here
__throw_length_error(__EXCSTR(__N("vector::reserve")));
- make sure we have custom provider before calling the update,
replace old check in the update function
- fix race condition in the provider function, causing complete lock-up of
lights controls (triggered by sending light updates very fast. for example,
using arrow keys with the webui sliders; ref. #2424)
- rework state change functions to work using loop() func instead of a
pair of scheduled functions. we should not go out-of-sync now, and it
also avoids forcibly creating std::func object each invocation
- rework other providers to be more in line with custom callbacks -
introduce state, value and update calls as a common way to handle lights
- correctly handle state change when turning OFF and ON
- update tuya to store the last state, never send channel values when OFF (ref. #2424)
inline-source uses 'image/ico' otherwise
supposed to be fixed upstream via the usage of type="image/x-icon" as
link attribute, but there's no npmjs release yet
- 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