- Changed RSSI display format to 'xx% (-yy dBm)' in EQ3 TRV and MI BLE sensor WebUI
- Show BLE data in WebUI only when BLE is enabled
- Disable BLE when device is in boot loop
* Added "cam":1 in the discovery message, so that we can create a home assistant camera.
* Update tasmota/tasmota_xdrv_driver/xdrv_12_discovery.ino
Co-authored-by: Erik Kunze <eku@users.noreply.github.com>
* Rearrange the newly added field by size, for better packing.
---------
Co-authored-by: Erik Kunze <eku@users.noreply.github.com>
* Refactored Wifi for ESP32 to allow for Core3
* Fix case in include
* Grrr
* Fix compilation
* Fix Ethernet IPv6
* Fix wrong hostname due to mac address unknown at start
The driver tried to avoid loops when state updates from the MCU (eg
from physical button press) could be reflected back by Tasmota and
trigger another MCU command, followed by a state update. It did this
by tracking the source of the command in the last_source and
last_command_source variables, suppressing the command if either of
those was SRC_SWITCH.
However this logic is faulty: Since there are two last_source
variables to check, a command might reset one of them, but the other
would still suppress the update. As it turns out, MQTT commands would
only set last_source but not last_command_source. As a result, any
dimmer changes via MQTT would be dropped by the driver and not applied
to the MCU.
Switch functionality (on/off) was still working because those do not
rely on last_command_source, only last_source.
This change removes the loop detection logic altogether for dimmer
updates. This should be safe, because the driver already has the
latest dimmer value in its shadow state, and will not try to re-apply
a current value, thus breaking the loop.
This patch has been tested with several CE-WF500D dimmers which had
this problem.
