Skip to content
btsimonh edited this page Oct 13, 2022 · 10 revisions

Current testing version:

On top of lastest dev (2022/10/12)

2022-10-13 07:29: tasmota-lite.bin.gz

tasmota.bin.gz

=======================================

Older tested version

Program Version 11.0.0.5(lite)

Build Date & Time 2022-04-15T08:03:21

Core/SDK Version 2_7_4_9/2.2.2-dev(38a443e)

(lite and full version compilation times will normally be within a few minutes).

tasmota.bin.gz

tasmota-lite.bin.gz

Updates (see the commits for full details):

recent

2022-04-15 - Most common logs shortened - yes now it's cryptic, but maybe we'll have fewer missed. State logs now MORE_DEBUG.

2022-04-12 - set 'last_source' in ExecuteCommand() in support_command.ino - use this is TuyaSetChannels to disable set of dimmer values if the command CAME FROM THE MCU. This is likely to help a lot with manual panel operation, and also with MCUs which report all fading values.

2022-04-10 - increase character timeout. Disable 55AA mid message reset of low level protocol.

main major changes over tas 11

The major changes are:

1/ low level protocol parsing improved:

Added byte timeout, detection 55AA rather than just 55 as a reset, incrementing error count.

2/ high level messages processing:

Always goes through a 'correct' startup sequence before sending DPs to the MCU.

All messages wait for a response from the MCU - I did observe the MCU ignoring messages before this was in place.

3/ DPs are ONLY sent if they are different to what TAS thinks the MCU value is:

This resolves an issue on my dimmers, where if 'OFF' was sent whilst the dimmer was off, the dimmer would no longer control the light (i.e. dead forever, no way to restore operation that I could find).

4/ when power or dim is sent, a timer is set (tuyadimdelay - default 2000ms, but changeable, not stored in flash) to delay dim commands untilt he timer expires.

5/ when the MCU has reported 'power off' state, dim commands are not sent to the MCU (some MCUs will turn back on again).

Known issues/questions:

Use of a button on a GPIO driven by the MCU may cause problems of toggling TAS when TAS sends power commands - this is under investigation. Do we NEED the button on the GPIO? (WF-DS01)

Untested on dual dimmer.

untested on sensors/power plugs. (basically only tested on single dimmers...)

Dim value - both TAS and the MCU have an impression of the last dim value. What should we do at power on? How does setopiton20/setoption54 affect this? Should we ignore all dim values from the MCU, and only apply one's that TAS has been told to use? (the issue here is that some dimmers will report the dim value during a fade down, and so TAS will currently store the last value received which may be close to zero. Can storing the fade down value be avoided? How would we determine how to do this with all the different MCU types out there?

Can we identify ALL the most common MCU firmwares (I'm not aware of a list of tuya product codes - although each MCU does send one...)?