LCtech 4-channel module (maybe clone?) does not switch

[wolfgangr]

relays don't switch on 4CH board

Issue was first raised at parent fork : https://github.com/arendst/Sonoff-Tasmota/pull/4716#issuecomment-453702487

Also, make sure these boxes are checked [x] before submitting your issue - Thank you!

• [*] Searched the problem in issues and in the wiki

arendst/Sonoff-Tasmota issues related to LCtech boards: https://github.com/arendst/Sonoff-Tasmota/pull/4716 https://github.com/arendst/Sonoff-Tasmota/issues/3406 https://github.com/arendst/Sonoff-Tasmota/issues/1714 https://github.com/arendst/Sonoff-Tasmota/pull/1282

Proposal of a workaraound with stock tasmota, using serialsend5 and rules: https://github.com/arendst/Sonoff-Tasmota/wiki/LC-Technology-WiFi-Relay Essence of workaround:

mosquitto_pub -h 192.168.1.150 -t 'cmnd/sonoff/serialsend5' -m '0xa00100a1'

• [*] Hardware used :

12V 4-ch #esp8266 WiFi relay http://www.ebay.de/itm/323518033341 ESP8266 DC 5/12/32/220V WiFi Wireless Switch Relais Modul Smart Home Automation maybe genuine or not - who knows? with ESP-01S module plugged in (shipped with the board)

• [*] Development/Compiler/Upload tools used :

PlatformIO VisualStudioCore 1.30.1 esptool.py v2.5.1 arduino 2:1.0.5+dfsg2-4.1 (serial console) debian 9.6

• [*] If a pre-compiled release or development binary was used, which one? : N/A

• [*] You have tried latest release or development binaries? :

both: b15fff465ceefdbd84b3298d71102c2cb7c476ee (here at development branch) and merge into 6.4.1 as of 2018-12-24 54c2eb283a02e4287640a4595e506bc6eadbd7f2

• [*] Provide the output of commandstatus 0 :

Module in LTech mode Moduel in RAW ESP-01 mode

{"Status":{"Module":64,"FriendlyName":["Sonoff"],"Topic":"sonoff","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}

Module set to LCTech 4-Relay Module mode

{"Status":{"Module":63,"FriendlyName":["Sonoff","Sonoff2","Sonoff3","Sonoff4"],"Topic":"sonoff","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}

To Reproduce build, flash, run, select Module type "LCTech 4-Relay Module"

Expected behavior relays switch as buttons are pressed

Screenshots N/A

Additional context see following posts and linked issues in tasmota mainstream git

[wolfgangr]

Collecting info from distributed places (btw: How can I link into google group discussion??) essence from my Post form 201-01-07: '========== Last night I flashed tasmota on a really cheap ( EUR 8,50 each) 4 channel china relais card I bought form chinese ebay diystore. It looks like there are similiar widgets flooding in from the far east, 1 and 2 channel, too. Basically, It works, i.e I can switch the relais on and off by issuing serial command strings, but it does not well integrate into the rest of tasmota framework. So I had to keep track of relais state in some mqtt client, maybe FHEM (in some distant future end...)

So preferably, we could expand the sonoff 4CH backend stuff to use those thingies with the sonoff 4CH frontend (web buttons, dedicated relais commands, status message...)

It has a (presumably) ESP-01-s (1MB) plugged on its board, talking serially to some other µcontroller for the relais. Similiar to the sonoff 4CH, but obviously not identical.

"API" of the thingie in a nutshell, as delivered on the sellers ebay page: Relay control instructions (hex hexadecimal): Open the first relay: A0 01 01 A2 Turn off the first relay: A0 01 00 A1 Open the second relay: A0 02 01 A3 Close the second relay: A0 02 00 A2 Open the third relay: A0 03 01 A4 Turn off the third relay: A0 03 00 A3 Open the fourth relay: A0 04 01 A5 Turn off the fourth relay: A0 04 00 A4

what I did:

• flash a stock sonoff-sensors.bin (v6.4.1) on the ESP
• configure it as "Generic" with all GPIO left unassigned
• (kept an Arduiono console for debugging on the line to find out what's going on)
• plug the ESP to the board again
• issue a

  $ mosquitto_pub -h 192.168.XXX.YYY -t 'cmnd/sonoff/serialsend5' -m '0xa00101a2'

voila - that's it :-) No soldering or board tweaking required :-) (well, actually I crafted a programming plug for the ESP01, because I think I will buy some more of those...)

I Tried to assign the RX/TX GPIO 1&3 to "SerBR", but this broke communication on the serial line, as I could watch on the arduino console. The same happens when I switch the module type to some sonoff 4ch variant.

[wolfgangr]

copy om my comment in mainstream tasmota https://github.com/arendst/Sonoff-Tasmota/pull/4716#issuecomment-453730925 '======================== Hope it is OK to continue here with testing of @VerboteneZone 's fork. can't create an issue there. I merged it with curren development. First impression was great, but relais did not switch (4CH device). Changing to Generic device and sending serialsend5 commands DO work - without any resetting of the relais controller. LogLevel4 reveals a trailing 0x0a as compared to the sendstrings. Jan 12 00:37:35 sonoff-7353 ESP-LCT: Sent new serial state to relay 0 (state: 0): 0xa0, 0x01, 0x00, 0xa1, 0x0a May this be the issue? Or is serialsend5 adding as well, anyway? Tried to remove the trailing 0x0a, but did not help. '========================== continue testing.... Trying it with unchanged fork from @VerboteneZone . same picture removing the trailing 0x0afrom send buffer - same picture

However - adding additional 0x0a to serialsend does NOT hurt serialsend5' -m '0xa00400a40a0a' So the trailing 0x0a are not the culprit, obviously.

Tried to debug the serial output - no success yet: Conntecting the naked ESP-01S to the serial adaptor, I can see patterns of scrap on the arduino serial moitor both with serialsend and with xdrv_20_lc_tech_relay.ino , however, they look different. At lest I can say, that SOMETHING is sent.

Could not find yet a way to precisely debug the hex stream, at best with timing information. Can't switch arduino serial monitor to "hex" mode. PlatformIO appears to call minicom, which crashes. cat /dev/ttyUSB0 finishes immediately. Still playing with unbuffered serial reaing with perl - no success yet. can't find 'hex serial monitor' or sth like that on google.

stty settings? This is what I get after I ran arduino serial console on it:

...$ stty -F /dev/ttyUSB0 
speed 115200 baud; line = 0;
min = 0; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

Any Idea?

One thing that comes to mind is a timing issue.
I remeber stumbling across this in one of the other issue threads around here, but can't find it any more. Since xdrv_20_lc_tech_relay.ino always updates all four relays, not just the one switched, commands may come to fast. Delays are forbidden in a preemptive pseudo RTOS multitasking environment - I understand.

What about keeping relay state in a buffer and updating only one channel every 25 or 100 ms in the respective loops?

[wolfgangr]

Answer to this post https://github.com/arendst/Sonoff-Tasmota/pull/4716#issuecomment-453735322 '=============================

Hi Wolfgang, I enabled the issue tracker and thanks for responses. Pls use issue tracker at verbotenezone, so its a better way to find a solution here.

thanks and voila :-)

I did some tests, with the boards in my stock. You are partially right, I can acknowledge, that all 4 channels are switched on one of my boards.

My theory is, that I got a four channel board, which is not really LC-Tech. They seem to be equal at frist glance, but on my testing device, there are some extra diodes and resistors. So it is possible, I bought a clone, which doesnt behave like the genuine ones.

Who can ever know, when we all buy at alibaba or chinese ebay sellers? So skd of a board identification wiki woud be gret as well. lot's of chances in these FOSS world...

[wolfgangr]

Where is it that the calling of sending is triggered? I'm afraid, deep in sonota.ino... How is the timing? How did you implement the delay (some dark remembrance....) I know it may screw WiFI, but at leas for testing. When tests yield that delay helps, I'd try to implement a nonblocking version.

[wolfgangr]

just found the snipped where somebody was referring to a delay: https://github.com/arendst/Sonoff-Tasmota/issues/1714#issuecomment-370190786

Serial.write(0xA0); Serial.write(i+1); Serial.write(state); 
Serial.write(0xA0+i+1+state); Serial.write('\n'); 
delay(20);

I'll go an try this - hope it will not blow my WiFI...

[wolfgangr]

Just found this file on my machine:

:~/tmp/hex$ xxd serialsend5.hex
00000000: a004 01a5 00a0 0400 a4                   .........

Looks lke I could accidentially capture a sequence from serialsend, but unfortunately cannot reproduce it. Anyway, it might be a hint that trailing 0x00 after the command might help.

[wolfgangr]

played with delay() (up to 20 ms) and Serial.flush(), arbitrarily placed around SerialSendRaw(buffer), no success yet leaving the trailing 0x0A or replacing it by 0x00 - no success ... focusing on a debug solution now...

[wolfgangr]

Hacked some perl to debug serial line hex patterns. Added microsecond timer as well, to debug timing. Take your grain of salt about timing resolution of a linux workstation with hundreds of processes running. To get some idea of latency incurred: reading from a local file, each character needs ~15 µs. Witout the formated daytime (nice to sync with log entries) this reduces to ~ 7 µs)

usage:

:~/tmp/hex$ ./watch-serial.pl < /dev/ttyUSB0

To configure the tty settings I just opened and closed the arduino serial console. This may have to be repeated after each unplugging of the serial USB.

:~/tmp/hex$ cat watch-serial.pl
#!/usr/bin/perl

# high resolution timing libs
use Time::Format qw/%time/;
use Time::HiRes qw/gettimeofday time/;
use POSIX qw/strftime/ ;

# read one char at a time
local $/ = \1;
while(1) {
  $reads=<> ;
  $t = time;
  if ( defined($reads) ) {
    $date = strftime "%H:%M:%S", localtime $t;
    $date .= sprintf ".%06d", ($t-int($t))*1000000; # without rounding
    # printf (" %06d : %02X\n", $microseconds ,  ord($reads) ) ;
    printf (" %s : %02X\n", $date ,  ord($reads) ) ;
    undef $reads;
  }
}

Output pattern looks like (input was "$%2345&") :

 16:53:53.189440 : 24
 16:53:53.189533 : 25
 16:53:53.189553 : 32
 16:53:53.189568 : 33
 16:53:53.189587 : 34
 16:53:53.189603 : 35
 16:53:53.189619 : 26
 16:53:53.189635 : 0A

[wolfgangr]

Having the module set to "Generic" and sending our SerialSend5 commands, we get: "Relay 1 ON"

 16:39:31.286396 : 00
 16:39:31.286482 : A0
 16:39:31.286499 : 01
 16:39:31.286510 : 01
 16:39:31.286521 : A2

"Relay 1 OFF"

 16:39:42.556299 : 00
 16:39:42.556344 : A0
 16:39:42.556360 : 01
 16:39:42.556377 : 00
 16:39:42.556392 : A1

The corresponding syslog: "Relay 1 ON"

Jan 12 16:39:31 sonoff-7353 ESP-SRC: MQTT
Jan 12 16:39:31 sonoff-7353 ESP-RSL: Received Topic cmnd/sonoff/serialsend5, Data Size 10, Data 0xa00101a2
Jan 12 16:39:31 sonoff-7353 ESP-RSL: Group 0, Index 5, Command SERIALSEND, Data 0xa00101a2
Jan 12 16:39:31 sonoff-7353 ESP-MQT: stat/sonoff/RESULT = {"SerialSend":"Done"}
Jan 12 16:39:36 sonoff-7353 ESP-WIF: Checking connection...
Jan 12 16:39:36 sonoff-7353 ESP-WIF: Connected

"Relay 1 OFF"

Jan 12 16:39:42 sonoff-7353 ESP-SRC: MQTT
Jan 12 16:39:42 sonoff-7353 ESP-RSL: Received Topic cmnd/sonoff/serialsend5, Data Size 10, Data 0xa00100a1
Jan 12 16:39:42 sonoff-7353 ESP-RSL: Group 0, Index 5, Command SERIALSEND, Data 0xa00100a1
Jan 12 16:39:42 sonoff-7353 ESP-MQT: stat/sonoff/RESULT = {"SerialSend":"Done"}
Jan 12 16:39:56 sonoff-7353 ESP-WIF: Checking connection...
Jan 12 16:39:56 sonoff-7353 ESP-WIF: Connected

Nothing to worry. The relais would switch.

[wolfgangr]

But now I set my gadget to "LCTech 4-Relay Module" (same DuT: the ESP-01S, unplugged from the relais module, connected to the serial flash adapter)

(Web-GUI Button Relais 1 ->ON)

 16:47:39.390842 : 00
 16:47:39.390891 : 00
 16:47:39.442830 : 00
 16:47:39.493827 : 00
 16:47:39.544888 : 00

(Web-GUI Button Relais 1 ->OFF)

 16:47:41.438815 : 00
 16:47:41.490818 : 00
 16:47:41.542937 : 00
 16:47:41.592825 : 00

(Web-GUI Button Relais 1 ->ON)

Jan 12 16:47:39 sonoff-7353 ESP-SRC: WebGui from 192.168.0.50
Jan 12 16:47:39 sonoff-7353 ESP-LCT: Sent new serial state to relay 0 (state: 1): 0xa0, 0x01, 0x01, 0xa2
Jan 12 16:47:39 sonoff-7353 ESP-LCT: Sent new serial state to relay 1 (state: 0): 0xa0, 0x02, 0x00, 0xa2
Jan 12 16:47:39 sonoff-7353 ESP-LCT: Sent new serial state to relay 2 (state: 0): 0xa0, 0x03, 0x00, 0xa3
Jan 12 16:47:39 sonoff-7353 ESP-LCT: Sent new serial state to relay 3 (state: 0): 0xa0, 0x04, 0x00, 0xa4
Jan 12 16:47:39 sonoff-7353 ESP-MQT: stat/sonoff/RESULT = {"POWER1":"ON"}
Jan 12 16:47:39 sonoff-7353 ESP-MQT: stat/sonoff/POWER1 = ON
Jan 12 16:47:39 sonoff-7353 ESP-CFG: Saved to flash at F4, Count 32, Bytes 3584

(Web-GUI Button Relais 1 ->OFF)

Jan 12 16:47:41 sonoff-7353 ESP-SRC: WebGui from 192.168.0.50
Jan 12 16:47:41 sonoff-7353 ESP-LCT: Sent new serial state to relay 0 (state: 0): 0xa0, 0x01, 0x00, 0xa1
Jan 12 16:47:41 sonoff-7353 ESP-LCT: Sent new serial state to relay 1 (state: 0): 0xa0, 0x02, 0x00, 0xa2
Jan 12 16:47:41 sonoff-7353 ESP-LCT: Sent new serial state to relay 2 (state: 0): 0xa0, 0x03, 0x00, 0xa3
Jan 12 16:47:41 sonoff-7353 ESP-LCT: Sent new serial state to relay 3 (state: 0): 0xa0, 0x04, 0x00, 0xa4
Jan 12 16:47:41 sonoff-7353 ESP-MQT: stat/sonoff/RESULT = {"POWER1":"OFF"}
Jan 12 16:47:41 sonoff-7353 ESP-MQT: stat/sonoff/POWER1 = OFF
Jan 12 16:47:41 sonoff-7353 ESP-CFG: Saved to flash at FB, Count 33, Bytes 3584

So,obviously, there is only one single ASCII-NULL sent per line, and another boguous NULL-Character on send action (this is reproducable). Did I screw your code so miserably :-O ? Will just try it with single and dual relais settings...

[wolfgangr]

same picture... Rel 1 ON

 17:14:55.516901 : 00
 17:14:55.516948 : 00
 17:14:55.568921 : 00

Rel 1 OFF

 17:14:58.166886 : 00
 17:14:58.217885 : 00

Rel 2 ON

 17:15:00.666867 : 00
 17:15:00.718875 : 00
 17:15:00.718924 : 00

Rel 2 OFF

 17:15:02.466860 : 00
 17:15:02.517849 : 00

and again, the corresponding syslog

Jan 12 17:14:55 sonoff-7353 ESP-SRC: WebGui from 192.168.0.50
Jan 12 17:14:55 sonoff-7353 ESP-LCT: Sent new serial state to relay 0 (state: 1): 0xa0, 0x01, 0x01, 0xa2
Jan 12 17:14:55 sonoff-7353 ESP-LCT: Sent new serial state to relay 1 (state: 0): 0xa0, 0x02, 0x00, 0xa2
Jan 12 17:14:55 sonoff-7353 ESP-MQT: stat/sonoff/RESULT = {"POWER1":"ON"}
Jan 12 17:14:55 sonoff-7353 ESP-MQT: stat/sonoff/POWER1 = ON
Jan 12 17:14:55 sonoff-7353 ESP-CFG: Saved to flash at F6, Count 38, Bytes 3584
Jan 12 17:14:58 sonoff-7353 ESP-SRC: WebGui from 192.168.0.50
Jan 12 17:14:58 sonoff-7353 ESP-LCT: Sent new serial state to relay 0 (state: 0): 0xa0, 0x01, 0x00, 0xa1
Jan 12 17:14:58 sonoff-7353 ESP-LCT: Sent new serial state to relay 1 (state: 0): 0xa0, 0x02, 0x00, 0xa2
Jan 12 17:14:58 sonoff-7353 ESP-MQT: stat/sonoff/RESULT = {"POWER1":"OFF"}
Jan 12 17:14:58 sonoff-7353 ESP-MQT: stat/sonoff/POWER1 = OFF
Jan 12 17:14:58 sonoff-7353 ESP-CFG: Saved to flash at F5, Count 39, Bytes 3584
Jan 12 17:14:58 sonoff-7353 ESP-WIF: Checking connection...
Jan 12 17:14:58 sonoff-7353 ESP-WIF: Connected
Jan 12 17:15:00 sonoff-7353 ESP-SRC: WebGui from 192.168.0.50
Jan 12 17:15:00 sonoff-7353 ESP-LCT: Sent new serial state to relay 0 (state: 0): 0xa0, 0x01, 0x00, 0xa1
Jan 12 17:15:00 sonoff-7353 ESP-LCT: Sent new serial state to relay 1 (state: 1): 0xa0, 0x02, 0x01, 0xa3
Jan 12 17:15:00 sonoff-7353 ESP-MQT: stat/sonoff/RESULT = {"POWER2":"ON"}
Jan 12 17:15:00 sonoff-7353 ESP-MQT: stat/sonoff/POWER2 = ON
Jan 12 17:15:00 sonoff-7353 ESP-CFG: Saved to flash at F4, Count 40, Bytes 3584
Jan 12 17:15:02 sonoff-7353 ESP-SRC: WebGui from 192.168.0.50
Jan 12 17:15:02 sonoff-7353 ESP-LCT: Sent new serial state to relay 0 (state: 0): 0xa0, 0x01, 0x00, 0xa1
Jan 12 17:15:02 sonoff-7353 ESP-LCT: Sent new serial state to relay 1 (state: 0): 0xa0, 0x02, 0x00, 0xa2
Jan 12 17:15:02 sonoff-7353 ESP-MQT: stat/sonoff/RESULT = {"POWER2":"OFF"}
Jan 12 17:15:02 sonoff-7353 ESP-MQT: stat/sonoff/POWER2 = OFF
Jan 12 17:15:02 sonoff-7353 ESP-CFG: Saved to flash at FB, Count 41, Bytes 3584

Will switch back to your code version, before merging and any other changes...

[wolfgangr]

Confusion growing ad infinitum {8}-[<>] checked out Branch b15fff465ceefdbd84b3298d71102c2cb7c476ee (identified by hash) what it pretends to do

Jan 12 17:43:33 sonoff-7353 ESP-LCT: Sent new serial state to relay 0 (state: 0): 0xa0, 0x01, 0x00, 0xa1, 0x0a
Jan 12 17:43:33 sonoff-7353 ESP-LCT: Sent new serial state to relay 1 (state: 0): 0xa0, 0x02, 0x00, 0xa2, 0x0a
Jan 12 17:43:33 sonoff-7353 ESP-LCT: Sent new serial state to relay 2 (state: 0): 0xa0, 0x03, 0x00, 0xa3, 0x0a
Jan 12 17:43:33 sonoff-7353 ESP-LCT: Sent new serial state to relay 3 (state: 1): 0xa0, 0x04, 0x01, 0xa5, 0x0a

and what it really does:

 17:43:33.677897 : 00
 17:43:33.677947 : 00
 17:43:33.677967 : 00
 17:43:33.677980 : 00
 17:43:33.677994 : 00
 17:43:33.678009 : 0F
 17:43:33.678023 : F9
 17:43:33.678037 : 35
 17:43:33.678052 : 03
 17:43:33.678066 : 0E
 17:43:33.678081 : 00
 17:43:33.678097 : 00

[wolfgangr]

hm..... do you call "SerialSendRaw" from support,ino? this uses strlen internally, which expects 0x00 delimited string. That may not be a good idea for strings containing 0x00, agree? I can't just believe that I were the first one to realize? Or did SerialSendRaw change below your radar? anyway.... we're coming closer...

[wolfgangr]

It works now :-)

/*
  char buffer[5] = {

.....

  SerialSendRaw(buffer);
 */
  // Serial.write(0x00);
  Serial.write(0xa0);
  Serial.write(LCTByteDevID);
  Serial.write(LCTByteDevState);
  Serial.write(LCTByteEnd);
  // Serial.write();
  Serial.write(0x0a);
  // Serial.write(0x00);

  snprintf_P(log_data, sizeof(log_data), PSTR( "LCT: Sent new serial state to relay %d (state: %d): 0x%02x, 0x%02x, 0x%02x, 0x%02x, 0x%02x"), id, nc ? 1 : 0, LCTByteBegin, LCTByteDevID, LCTByteDevState, LCTByteEnd, LCTByteReset);
  AddLog(LOG_LEVEL_DEBUG);

  delay(20);

Multiple issues coming together: SerialSendRaw() appers to be designed to receive data in nibble-wise ascii-text representation, So, it's not a good idea to send raw binary stuff there. I replaced the char buffer... SendSerialRaw(buffer) stanza by a series of direct Serial.write() calls. This produced output that looked good, however, only Relay 4 switched.

Uncommenting trailing and leading 0x00 did not help. delay(20), however DID work.

Now all 4 relays can be switched by the web GUI as intended. While this is easily hacked in, it's not supposed to stay there, I'm afraid, since such a long delays might interfere with the espressif WiFi management tasks. I'll try a nonblocking delayed update, but not this night any more...

[wolfgangr]

OK, have succesfully crafted and tested unblocking delays now. Will try to uplaod it to git...

[wolfgangr]

Here it is, so I hope: https://github.com/wolfgangr/Sonoff-Tasmota/commit/c1102a48638742d4fd565b1c5d56df2877e50927

The essential changes are in xdrv_20_lc_tech_relay.ino https://github.com/wolfgangr/Sonoff-Tasmota/blob/LCT_noblock/sonoff/xdrv_20_lc_tech_relay.ino

I added some

// state variables for the nonblocking delay handler
power_t target_state = 0;
uint8_t next_update =0;
uint8_t fast_update_count =0;

target_state is the desired relay power pattern. next_update is the next relay to receive commands in a round robin sequence. If a toggle is detected, the round robin pointer is reset to the corresponding relay to provide switching as fast as possible without exceeding delay limit. fast_update_count is explained below.

LCTSetState just sets this variables and returns to the caller immediately. The actual update work is done by the LCTLoopHandler. It is plugged into the main loop of sonoff.ino using the interface as provided by this snippet:

      case FUNC_LOOP:
      result = LCTLoopHandler();

The rest is ordinary nonblocking delay craftswork with some extra quirks. I added three config variables in my_config.h:

#define USE_LC_TECH_RELAY                        // Add support for LC Technology relay boards
  #define LCT_SWITCH_DELAY  40                      // min ms to wait between relay commands when toggled
  #define LCT_FAST_REPEAT   2                       // how many times commands are repeated in fast mode
  #define LCT_HOLD_DELAY    1000                     // min ms to wait between relay commands when unchanged

Commands sent from the ESP to the relay board are separated by an interval of at least LCT_SWITCH_DELAY milliseconds. However, my tests showed that with my config (Web server + MQTT TLS + remote syslog) the main loop is not cycled more often than ~ once per 100 ms. This might run faster, if some stuff ist disabled, of course.

I added a second level of command timing to provide a balance between switching speed, reliability and load burden. When a switch is toggled, commands are sent in round robin fashion to all of the relays at least LCT_SWITCH_DELAY apart. This fast round is repeated LCT_FAST_REPEAT times. After that, commands are repeated at (supposedly longer) LCT_HOLD_DELAY intervals, to make sure, that settings are corrected if ever one command might have got lost. I could not manage to fool my code by quick manual pressing of buttons or sending MQTT from the command line. However, it might be possible to do so by deliberately crafted fast scripted MQTT commands in an evil manner, when "last button pressed" chages faster than the update cycle. And of course, we do not know what kind of quirky clones might be out there in the far east. I hope these config suffices to satisfy most of them.

[WelterRocks]

Hi Wolfgangr,

first of all thanks, for your detailed tests and work.

I am currently in hospital, so pls excuse my late responses. I told my wife to bring some boards and esp01, so I can test this again.

I will check your changes and will do some merges, even to Tasmota main branch.

Because Theo doesnt want to have LC Tech native support in Tasmota, I started a complete code rewrite, called WESPOTA. Goal of WESPOTA is, to support as many devices as possible and therefore the way, device drivers are support, has to be changed in general.

Thanks for your support, I will review your changes, after the hardware has been arrived.

[WelterRocks]

Merged wolfgangr fixes.

I will move to WESPOTA soon, see https://github.com/VerboteneZone/WESPOTA. Therefore the wolfgangr fixes are already there.

[andreas-bulling]

Merged wolfgangr fixes.

I will move to WESPOTA soon, see https://github.com/VerboteneZone/WESPOTA. Therefore the wolfgangr fixes are already there.

Have you thought of a way to keep the development of both platforms in sync as far as the "non-horizontal" part is concerned (i.e. basic features etc)? Otherwise I'd be a bit worried that both develop away from each other quite a bit over time (which would be a shame for all those of us who want a fully Tasmota-based infrastructure where all parts work nicely together.)

[wolfgangr]

Hi Andreas, If you look around here, you will see that this is a quite rudimentary early stage of a might-be-fork. I see your worries - and share them. I personally have not the intention nor the time to reinvent the wheel. I whish the best to Oliver and hope he will soon drop in again with his full creative power. Before all, this fork is his idea. I'm just dropping monologs here ;-(

[andreas-bulling]

It would be really nice to be able to easily activate "Tasmota-experimental" or so and that the additional packages would be automatically downloaded/installed or so. Changes to the core cannot be easily integrated this way, of course, but maybe Tasmota could provide a new facility to "overwrite" core functions. I don't know its architecture though, maybe not possible.

[wolfgangr]

When I looked into the code my first thought was Oh my god, that's like the power distribution cabinet of an age-old factory:

• solid core that once may have done its simple job very well
• dozens of adds on and expansions that might have been done differently if planned before
• some crude hacks that were intended for a short time but then last forever
• some things nobody knows/understands but better not to touch....
• so overcrowded that the lid does not close any more

Imho, this code base is not ready for easy expansion, not at all at an automated level. Both because of its complexity it has inherited during its unplanned growth and because it hits the resource limit of the esp host platform. That's why any feature requests are bogged down immediately. I can understand that.

I see two approaches that might work in theory - at best in combination:

• complete redesign of the inner architecture with modularity as primary design goal
• mainstream maintenance with all possible modules in, where the maintenance and development is done and - above all - mutual compatibiity is kept Any special subset combination of features is created as a derivation from this main repo.

Compare this to the linux world - there you have:

• the all inclusive but chaotic and incompatible codebase spread around there
• debian as a maintainer of a very comprehensive but integrated and quality assured code repo
• ubuntu as debian subset (to a large degree)
• ubuntu subset mint as out of the box and user focuesed one-build-for-80%-of-the peole approach
• raspberry as a different subset, which however +- automagically inherits the wealth of its ancestor

To apply this analogy to tasmota, This would require to shift the main work being applied to the extended codebase repo, not to the restriction. But that's a individual decision of each of the contributors themselves. There is no authority that can sanctionize them to do so.

I think that many of the core team feel dissatiesfied a little bit with the current situation, but not so much that they'd like to go and decide to elect their king. Will crowd intelligence solve this once a day? I don't know.

I think that Oliver and me share thies view, but at the moment I see no ressourcs at all to get it on its feet. Whether this will change when oliver is on his feet gain? I don't know.