-
Notifications
You must be signed in to change notification settings - Fork 3
Home
I've been re-working Tuya control in TAS.
It attempts to address the main issues reported by Tuya users - MCU crash (Athom), unexpected dim level after power on, unexpected off after power on.
It obeys the Tuya protocol better, both at a low level, and at the higher level protocol - e.g. waiting for responses when they should be due, rather than relying on sleep(40) to avoid the MCU lowing messages.
It only sends a dp value if the dp value is different to the last rxed value from the MCU (solves an MCU issue with Athom dimmers).
Disables set of dimmer (and other light values) if they were changed as result of the MCU changing the value. This is probably the main reason for 'odd' behaviour between different dimmers - effectively we had a feedback loop, especially when MCUs send all the fade values when fading up or down.
Delays setting of dim/light values for a period after a dim value is rxed from the MCU. This lets any fade on the MCU settle before TAS tries to control it (e.g. on power on).
Disables set of dim/light values of the device has reported that it is 'off'.
TuyaSend7 - sends ANY tuya command like cmd,hexstringpayload
tuyasend7 0, - send a heartbeat
tuyasend7 3,04 - set wifi led mode (controls led on mine)
tuyasend7 0x1c,0110041305060702 - set local time
TuyaDimDelay - set the delay since the last dim rxed from tuya before a dim command can be sent by TAS. Default 2000ms. NOT stored in flash. e.g. tuyadimdelay 1000 to set a 1s delay rather than 2s.
(please add yours here, and add a page for it).
Possibly the template having a button causes the issue of conflict between RXed tuya messages and the Button controlling the device? - needs further investigation.
turning on from TAS or button goes to full intensity? Prior versions restored intensity correctly? - this may have now been addressed, needs re-test.
Original issue of MCU becoming unresponsive resolved. Appears to work well now.