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.
Remove the logic that inhibits the sending of updates to the MCU until
the DP's state has been observed at least once in a status report from
the MCU. This logic was intended to ensure that a DP is not updated
with its current value, which reportedly crashes some very broken
devices.
However, other devices like the Feit DIM/WIFI dimmers do not reliably
report DPs that haven't been changed. So the required status report
would never arrive, resulting in the inability to control these
devices remotely, at least until their state had been changed by a
manual button press, something that is not always practical as it
requires physical device access and needs to be done after every
restart.
Removing this logic allows Tasmota to control the device state.
Marcus Better
Theo Arends
Barbudor