i have a tuyamcu based device that occasionally gets a flipped bit in
messages it receives from the muc. those usually show up as checksum
failures, but if the bit flips in the length field then we wait for
bytes that just arent going to arrive, so we don't get to the cksum
field for that test to fail. instead, add a timeout that the tick
checks, and reset the recv state machine on a timeout.
if the message that was corrupted was a dp update, we'll end up with
an inconsistent view of the state of the DPs. maybe we should send a
request for all datapoint values when this or a cksum failure happens?
* support on/true/off/false/toggle in the tuyamcubool command.
i wanted a tasmotized wall switch to be able to blindly send "toggle" to
a fan/light and have it do the right thing. the dp value is kept by the
driver, so it can easily read, modify, and write it.
* "on"/"off"/"toggle" etc are parsed when XdrvMailbox is set up
so i don't have to do it, i just have to use the payload.
* handle get local time requests from the MCU.
from what i can tell from the tuya serial communication protocol
documentation, we only have to send the time if MCU requests it. this is
unlike how TUYA_SET_TIME is implementing in xdrv_16, where if
USE_TUYA_TIME is enabled it will send unsolicited time updates every
minute as well as in response to a request from the MCU.
i couldn't find an easy to check flag to see if tasmota was synced to a
real clock, so this blindly tells the MCU that our time is valid and
copies it over, the same as xdrv_16.
the tuya doco also describes a "Get system time in GMT" request and
response structure which would be mostly a copy of this code if i knew
if and where tasmota keeps track of UTC/GMT.
lastly, i'm not convinced RtcTime.day_of_week is right. it's friday
here which should be 6 if you start counting sunday as 1, but i read 2
* local time sync is implemented, but not gmtime
* 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>
David Gwynne