on some units it can take around 250ms to reply to a request, by which
time we're shoving another command to the unit. if this happens, the
unit gives up and starts replying to the new command, which can again
take 250ms. in this situation effectively nothing gets through.
avoid this by checking if we're in the parser state machine. this also
gives us timeout handling.
tested on 4 different AC units. one which was unusable before is now
functioning as expected, and the other 3 appear just as functional as
they were before.
* WIP Tuya MCU Bridge driver alternative to the TuyaMCU driver
The main difference is this driver does not try and wire MCU data points
(Dps) into the tasmota power/light/etc controls. Instead each Dp ends up
being relayed directly to MQTT and the rules subsystem. If you want to
change the state of something wired up to the MCU, you send tuyamcu
specific commands to manipulate the Dp.
Each Dp gets a type and id specific topic that is sent to MQTT. eg, Dp
id 1 type bool looks like tele/%topic%/TUYAMCUBOOL1. To change state you
send a TuyaMCUBool1 command (ie, the command index value is used as the
DpId, which is nice and symmetrical) with the new value.
Currently Rules operate on TuyaMCU#TypeDpid things, eg, "rule1 on
TuyaMCU#Bool1 do power %value% endon" toggle the power on the tasmota
device when the state of the thing on the MCU changes too.
The most obviously missing stuff at the moment is:
- better relaying of the wifi/mqtt status to the MCU
- handling wifi reset requests from the MCU
- low power stuff?
- support for sending status updates and device info queries.
- restarting the tuya mcu state machine?
- restarting the rx state machine when no bytes are rxed for a period of
time
- time sync
* shorten the log prefix to TYB (3 chars).
requested by arendst
* use the local definition for the SET_DP command.
reaching back to the existing tuyamcu code isnt reliable.
pointed out by arendst
* put the todo list in the code so it can be tracked
* check the wifi/mqtt state every second and update the mcu if it changes.
* fix rule processing when Dp state is changed from a cmnd.
rule processing was done as part of publishing the state, but publishing
the state when it was updated by a command only happened if So59 was
set. split rule processing out of publish and call them separately as
needed.
publish is now called from teleperiod, status updates from the MCU,
and from cmnds if so59 is set. rules are called from status updates from
the MCU and from cmnds.
Co-authored-by: David Gwynne <dlg@defeat.lan.animata.net>
Mark Fickett
David Gwynne
Theo Arends