Serial MCU controlled relay/switch

[enesbcs]

Is there a way to use this with the 4x channel LC Tech relay? Works on my 2ch version, but the only option in 'number of relays' is 1 or 2.

Then you are using an old version. Latest plugin supports 4channel. Binaries attached in the first post if this thread, i guess you need the last Puya version...
download/file.php?id=3336&sid=622fad533 ... 869d1d3f58

[mikeoh90]

Is there a way to use this with the 4x channel LC Tech relay? Works on my 2ch version, but the only option in 'number of relays' is 1 or 2.

Then you are using an old version. Latest plugin supports 4channel. Binaries attached in the first post if this thread, i guess you need the last Puya version...
download/file.php?id=3336&sid=622fad533 ... 869d1d3f58

You're absolutely right! thanks! Working great now.

I'm using it to simulate remote control presses on a velux blind remote - soldered wires from the output of the first three relays to up, down and stop. Using MQTT commands from homeassistant to simulate the button presses on and off. Only problem I'm having is that sometimes the delay between MQTT commands is a bit long and it thinks the button has been held (on button hold, the blinds will move until the remote button is released), meaning the blind only moves minimally before stopping. Is there a way open the relay only briefly and close it automatically after a short time (100-500ms) - like a pulse on option - so I can just send one MQTT command for the relay to turn on then immediately off again?

[enesbcs]

Is there a way open the relay only briefly and close it automatically after a short time (100-500ms) - like a pulse on option - so I can just send one MQTT command for the relay to turn on then immediately off again?

Yes. If you read the header of the plugin, you will see that "relaypulse" command is already supported:
https://github.com/letscontrolit/ESPEas ... Switch.ino

[mikeoh90]

Is there a way open the relay only briefly and close it automatically after a short time (100-500ms) - like a pulse on option - so I can just send one MQTT command for the relay to turn on then immediately off again?

Yes. If you read the header of the plugin, you will see that "relaypulse" command is already supported:
https://github.com/letscontrolit/ESPEas ... Switch.ino

Yes!! I knew I'd read this somewhere but then couldn't find it again when I needed it. Thanks so much, works like a dream now!

[riker1]

Hi
could you please double check.
Do not see FHEM as Controller?

Yep, sorry i forgot, that i not just deleted the file, but removed my pluginset completely before.
Recompiled.

Hi

is it possible to have an updated firmware?
- required:
controller:
FHEM, MQTT,

device: of courcse MCU relais
- is it possible to add generic MQTT import?
- generic system info with 4 variables?

Thanks a lot

T

[enesbcs]

is it possible to have an updated firmware?

Sorry, the latest ESPEasy version i tested with this plugin is dated 2018.08.17 with core 2.4.0 and currently i have no time for testing.
Core 2.4.1 and 2.4.2 is not working well with serial 2 way communication, and with 2.5.0 i have absolutely zero experiences. New ESPEasy versions tends to change a lot in it's core code (which requires more attention from the plugin creators), and be more complexer, even bigger than i ever needed for switching a lamp to ON. However I can compile some testing binaries to you which may work or will make your device to stop responding...

[riker1]

is it possible to have an updated firmware?

Sorry, the latest ESPEasy version i tested with this plugin is dated 2018.08.17 with core 2.4.0 and currently i have no time for testing.
Core 2.4.1 and 2.4.2 is not working well with serial 2 way communication, and with 2.5.0 i have absolutely zero experiences. New ESPEasy versions tends to change a lot in it's core code (which requires more attention from the plugin creators), and be more complexer, even bigger than i ever needed for switching a lamp to ON. However I can compile some testing binaries to you which may work or will make your device to stop responding...

ok, thanks understood.

Is there a plan to integrate this 165 plugin into the mega firmware?

[enesbcs]

is it possible to have an updated firmware?
- required:
controller:
FHEM, MQTT,

device: of courcse MCU relais
- is it possible to add generic MQTT import?
- generic system info with 4 variables?

New binary attached with 20190311 sources compiled against Arduino ESP core 2.5.0.
UNTESTED and totally UNSUPPORTED! Use and test only your own risk. I warned you.
Serial comm may or may not work. Puya version not mentioned so i skipped it.
(Prepare with some screwdrivers and soldering iron and serial-USB programmer, before using these binaries.)

[riker1]

ok perfect thanks will test it

[riker1]

Hi

I checked with ESP01 and had a problem writing config data.

so setting a device destroyed the config.

Looks like it is not working.

Any idea?

thanks T

[enesbcs]

I checked with ESP01 and had a problem writing config data.

so setting a device destroyed the config.

Did you use PUYA-safe builds from the previous stable release on that chip?

[riker1]

I checked with ESP01 and had a problem writing config data.

so setting a device destroyed the config.

Did you use PUYA-safe builds from the previous stable release on that chip?

Hi

formerly I used your firmware provided in post #196
viewtopic.php?f=6&t=3245&start=150#p33633

[neo1975]

ok. I have a few of these relays and esp8266 laying around. After following the instructions here : viewtopic.php?f=6&t=3245&start=100#p28044 i was able to get them working by using the bin file here: viewtopic.php?f=6&t=3245&start=100#p27863 .

What i wold like to have is the source code for Arduino so i can modify the HTML used so that I can use it to unlock, lock, and or start my vehicle. I need these relays to activate systems already installed in the Jeep. Anyway thats another long story..

what am i looking for? the source code for ESPEasy_1M_128kSPIFFS_PUYA, not the BIN file becasue i want to modify the HTML that it uses. To do that, I have to load ESPEasy_1M_128kSPIFFS_PUYA into Arduino.

Thanks in advance!
-Neo

[enesbcs]

ok. I have a few of these relays and esp8266 laying around. After following the instructions here : viewtopic.php?f=6&t=3245&start=100#p28044 i was able to get them working by using the bin file here: viewtopic.php?f=6&t=3245&start=100#p27863 .

What i wold like to have is the source code for Arduino so i can modify the HTML used so that I can use it to unlock, lock, and or start my vehicle. I need these relays to activate systems already installed in the Jeep. Anyway thats another long story..

what am i looking for? the source code for ESPEasy_1M_128kSPIFFS_PUYA, not the BIN file becasue i want to modify the HTML that it uses. To do that, I have to load ESPEasy_1M_128kSPIFFS_PUYA into Arduino.

Thanks in advance!
-Neo

Here you can find the used ESPEasy source where you can modify HTML:
https://github.com/letscontrolit/ESPEas ... a-20180818
And here is the plugin that you has to copy into ESPEasy sources:
https://github.com/enesbcs/ESPEasyPlugi ... Switch.ino

[neo1975]

So finally! After days of working with this I finally got Arduino IDE 1.8.9 to compile the sketch without errors. As I patiently wait while the board flashes.. lights are blinking.. then Arduino says done! Low and behold, the board does not boot up. When i reflash using the ESPEasy_1M_128kSPIFFS_PUYA.zip and the flash tool, it works just fine. So, reflash with Arduino and nothing. I did remove some plugins but i cant see that being my issue. Any ideas what is getting me here?

[Mravko]

Hi there,

I have yet another Tuya-based family of Wi-Fi switches and power outlet devices that are also controlled by the MCU and serail comms to the TYWE3S Wi-Fi module.
I'm guessing this plug-in will work fine.
I have noticed, however, that both the switches (1, 2, 3 and 4 Gang) as well as the Power outlets have current sensors. With the "Smart Life"/"TuyaSmart" app I can read the current utilization (in Watts), which I assume is being read by the MCU and the data goes, via comm, through the TYWE3S to the cloud. I assume that because there is no other GPIO connection except TX/RX on the TYWE3S.

I have briefly read the tuya serial communication protocol and have noticed that they have mentionned some other comms relating to reporting of sorts (e.g. temperature).
I'm wondering how we could add these readings to the plug-in and take full advantage of the protocol rather than just switch on, off and dim?

Thoughts?

[Mravko]

Oh and one more thing...
The Tuya only has 1 relay and 3 (or 1 + 2 dimmer)

My tuya switches hav 1, 2, 3 and 4 relays.

I am unable to select 4 relays in the Yewelink/TUYA type

How hard is it to add the 4 relays to the TUYA switch type drop-down?

[enesbcs]

... then Arduino says done! Low and behold, the board does not boot up. When i reflash using the ESPEasy_1M_128kSPIFFS_PUYA.zip and the flash tool, it works just fine. So, reflash with Arduino and nothing...

I guess you did not applied the PUYA patch to the ESP core before compiling:
https://github.com/letscontrolit/ESPEas ... 3.patch#L8
Use platformio if you do not want to do that manually:
https://github.com/letscontrolit/ESPEasy/issues/2233

[enesbcs]

I have noticed, however, that both the switches (1, 2, 3 and 4 Gang) as well as the Power outlets have current sensors.
...
I'm wondering how we could add these readings to the plug-in and take full advantage of the protocol rather than just switch on, off and dim?

I only have a 1 gang simple Tuya based wall switch without power metering function.
So this task is free to anybody who has such a device...

Two years ago, when i ordered it, i didnt want to believe that there are no open source firmware for it, so i wrote this plugin to use it. I've decoded the protocol with Wireshark and the ESPEasy serial server plugin, also using the original Chinese Tuya API documentation with Google translate.

[enesbcs]

Oh and one more thing...
The Tuya only has 1 relay and 3 (or 1 + 2 dimmer)

My tuya switches hav 1, 2, 3 and 4 relays.

I am unable to select 4 relays in the Yewelink/TUYA type

How hard is it to add the 4 relays to the TUYA switch type drop-down?

I've never seen a Tuya device with more than 3 buttons. But adding a new entry to the drop-down is really not hard.

[Mravko]

Oh and one more thing...
The Tuya only has 1 relay and 3 (or 1 + 2 dimmer)

My tuya switches hav 1, 2, 3 and 4 relays.

I am unable to select 4 relays in the Yewelink/TUYA type

How hard is it to add the 4 relays to the TUYA switch type drop-down?

I've never seen a Tuya device with more than 3 buttons. But adding a new entry to the drop-down is really not hard.

So here is the 4 gang wall switch

4ch - back.jpg (2.01 MiB) Viewed 216777 times

the switches have a controller board and a relay board, as well as the current sensors.

I guess the current sensors are not that important (it's more of a nice-to-have), especially for the GPOs.

But if it isnt too much trouble, may I ask for a version of the firmware where there is a 4 relay option?

[enesbcs]

So here is the 4 gang wall switch
4ch - back.jpg

the switches have a controller board and a relay board, as well as the current sensors.

I guess the current sensors are not that important (it's more of a nice-to-have), especially for the GPOs.

But if it isnt too much trouble, may I ask for a version of the firmware where there is a 4 relay option?

Adding an option is not so hard, few minutes... but compiling and testing is a much more challanging quest.
As i see there are some troubles with the ESP 2.5.0 core, so i had to first reinstall 2.4.0. This is the last version that proven to work with serial communication both ways. Interesting fact, that both the 1gang and the dimmer version broadcasting all three (non existent) gang's status informations everytime when either gang is changed their state, so i thought that 3 gang is the limit. As i see your image i was wrong. But i am curious if it will be enough to add a new id or the packages changed for the 4th gang somehow. I hope that i be able to upload the modified firmware soon.

[Mravko]

So here is the 4 gang wall switch
4ch - back.jpg

the switches have a controller board and a relay board, as well as the current sensors.

I guess the current sensors are not that important (it's more of a nice-to-have), especially for the GPOs.

But if it isnt too much trouble, may I ask for a version of the firmware where there is a 4 relay option?

Adding an option is not so hard, few minutes... but compiling and testing is a much more challanging quest.
As i see there are some troubles with the ESP 2.5.0 core, so i had to first reinstall 2.4.0. This is the last version that proven to work with serial communication both ways. Interesting fact, that both the 1gang and the dimmer version broadcasting all three (non existent) gang's status informations everytime when either gang is changed their state, so i thought that 3 gang is the limit. As i see your image i was wrong. But i am curious if it will be enough to add a new id or the packages changed for the 4th gang somehow. I hope that i be able to upload the modified firmware soon.

in the logs my 4 Gang shows this every time:

33470478: SerSW : Dimmer
33470480: EVENT: MCU#Relay0=0.00
33470482: EVENT: MCU#Relay1=0.00
33470484: EVENT: MCU#Relay2=1.00
33470485: EVENT: MCU#Relay3=0.00

Note: Incidentally, all four relays are off to start with but after toggling the third relay, it stays on even after it was switched off. Not sure why that happens.

If I switch on all four channels, I get:

33701576: SerSW : State
33701577: EVENT: MCU#Relay0=1.00
33701579: EVENT: MCU#Relay1=1.00
33701581: EVENT: MCU#Relay2=1.00
33701582: EVENT: MCU#Relay3=0.00
33711511: EVENT: MCU#Relay0=1.00
33711513: EVENT: MCU#Relay1=1.00
33711515: EVENT: MCU#Relay2=1.00
33711517: EVENT: MCU#Relay3=0.00
33712510: SerSW : Dimmer
33712512: EVENT: MCU#Relay0=1.00
33712514: EVENT: MCU#Relay1=1.00
33712516: EVENT: MCU#Relay2=1.00
33712517: EVENT: MCU#Relay3=0.00
33713534: WD : Uptime 558 ConnectFailures 0 FreeMem 17368

which suggests it doesnt know how to parse the fourth channel (which I expected). I have selected three channels under the TUYA type.

Let me know if you need me to do a serial capture or something. I suspect that I'd be able to capture it using the Serial Server plug-in, right?

[enesbcs]

Added 4th button for TUYA.

I've compiled for core240 (this core proved itself working earlier), core241 (may work), core242 (may not work) with the last ESPEasy sources with untouched serial code. (20181231)
4M and 1M builds and 1M/PUYA builds also included.

[Mravko]

Added 4th button for TUYA.

I've compiled for core240 (this core proved itself working earlier), core241 (may work), core242 (may not work) with the last ESPEasy sources with untouched serial code. (20181231)
4M and 1M builds and 1M/PUYA builds also included.

Thanks heaps!

I'll let you know how it goes

[Mravko]

Added 4th button for TUYA.

I've compiled for core240 (this core proved itself working earlier), core241 (may work), core242 (may not work) with the last ESPEasy sources with untouched serial code. (20181231)
4M and 1M builds and 1M/PUYA builds also included.

Thanks heaps!

I'll let you know how it goes

Ok here's how it went:

There is a 4 relay selection in the TUYA type. <tick>


However:
The log shows the same thing.
With all four switches are "on" the output is:
SerSW : Dimmer
364670: EVENT: MCU#Relay0=1.00
364674: EVENT: MCU#Relay1=1.00
364676: EVENT: MCU#Relay2=1.00
364679: EVENT: MCU#Relay3=0.00
error: So he fourth relay is not reporting that it is on

and with all switches "off" again, the output is:
730420: SerSW : Dimmer
730423: EVENT: MCU#Relay0=0.00
730427: EVENT: MCU#Relay1=0.00
730430: EVENT: MCU#Relay2=1.00
730432: EVENT: MCU#Relay3=0.00
error: The third relay, "Relay2" still reports a 1.00

and only when I do a cold reboot the switches all report 0s:
>> NetworkError when attempting to fetch resource. <<
18031: SerSW : Dimmer
18034: EVENT: MCU#Relay0=0.00
18038: EVENT: MCU#Relay1=0.00
18041: EVENT: MCU#Relay2=0.00
18044: EVENT: MCU#Relay3=0.00

[Mravko]

Have you developed this in PlatformIO or Arduino IDE?

If PlatformIO, provide the source in a zip, if you like.
I''ll give it a go myself and post the results.

Mravko...

[enesbcs]

However:
The log shows the same thing.
With all four switches are "on" the output is:
SerSW : Dimmer
364670: EVENT: MCU#Relay0=1.00
364674: EVENT: MCU#Relay1=1.00
364676: EVENT: MCU#Relay2=1.00
364679: EVENT: MCU#Relay3=0.00
error: So he fourth relay is not reporting that it is on

and with all switches "off" again, the output is:
730420: SerSW : Dimmer
730423: EVENT: MCU#Relay0=0.00
730427: EVENT: MCU#Relay1=0.00
730430: EVENT: MCU#Relay2=1.00
730432: EVENT: MCU#Relay3=0.00
error: The third relay, "Relay2" still reports a 1.00

Serial packet format and or length changed from original. This may cause this interference.
Debug:
- Enable serial port usage, but disable serial logging, also disable all plugin (P165) and device that using serial pins.
- Setup "Communication - Serial Server" plugin for debugging (port 23, baud 9600, 8n1)
https://www.letscontrolit.com/wiki/index.php/Ser2Net
- install Realterm to your PC, setup for displaying in hexadecimal in Display menu, in Capture write the ESP device IP address and port (23) and set the serial settings that matches with the ESP Ser2Net plugin

[enesbcs]

Have you developed this in PlatformIO or Arduino IDE?

If PlatformIO, provide the source in a zip, if you like.
I''ll give it a go myself and post the results.

Mravko...

Arduino.

https://github.com/letscontrolit/ESPEas ... a-20181231

https://github.com/enesbcs/ESPEasyPlugi ... Switch.ino

[Mravko]

However:
The log shows the same thing.
With all four switches are "on" the output is:
SerSW : Dimmer
364670: EVENT: MCU#Relay0=1.00
364674: EVENT: MCU#Relay1=1.00
364676: EVENT: MCU#Relay2=1.00
364679: EVENT: MCU#Relay3=0.00
error: So he fourth relay is not reporting that it is on

and with all switches "off" again, the output is:
730420: SerSW : Dimmer
730423: EVENT: MCU#Relay0=0.00
730427: EVENT: MCU#Relay1=0.00
730430: EVENT: MCU#Relay2=1.00
730432: EVENT: MCU#Relay3=0.00
error: The third relay, "Relay2" still reports a 1.00

Serial packet format and or length changed from original. This may cause this interference.
Debug:
- Enable serial port usage, but disable serial logging, also disable all plugin (P165) and device that using serial pins.
- Setup "Communication - Serial Server" plugin for debugging (port 23, baud 9600, 8n1)
https://www.letscontrolit.com/wiki/index.php/Ser2Net
- install Realterm to your PC, setup for displaying in hexadecimal in Display menu, in Capture write the ESP device IP address and port (23) and set the serial settings that matches with the ESP Ser2Net plugin

Ok, so here is the capture file I've managed to produce.

While capturing i've gone through the sequence of switching on and off all four switches (i.e.1, 2, 3, 4 on then, 4, 3, 2, 1 off and so on...)

attached is the capture file
I hope this helps.

Mravko...

capture.zip

(446 Bytes) Downloaded 1323 times

or this file is easier readable

capture2.zip

(1 KiB) Downloaded 1482 times

One step further and here is what I have:
55AA 01 07 05 01 01 00 01 00 0F /Switch OFF
55AA 01 07 05 02 01 00 01 00 10 /Switch OFF
55AA 01 07 05 03 01 00 01 00 11 /Switch OFF
55AA 01 07 05 04 01 00 01 00 12 /Switch OFF

55AA 01 07 05 01 01 00 01 01 10 /Switch ON*
55AA 01 07 05 02 01 00 01 00 10 /Switch OFF
55AA 01 07 05 03 01 00 01 00 11 /Switch OFF
55AA 01 07 05 04 01 00 01 00 12 /Switch OFF

55AA 01 07 05 01 01 00 01 01 10 /Switch ON*
55AA 01 07 05 02 01 00 01 01 11 /Switch ON*
55AA 01 07 05 03 01 00 01 00 11 /Switch OFF
55AA 01 07 05 04 01 00 01 00 12 /Switch OFF

55AA 01 07 05 01 01 00 01 01 10 /Switch ON*
55AA 01 07 05 02 01 00 01 01 11 /Switch ON*
55AA 01 07 05 03 01 00 01 01 12 /Switch ON*
55AA 01 07 05 04 01 00 01 00 12 /Switch OFF

55AA 01 07 05 01 01 00 01 01 10 /Switch ON*
55AA 01 07 05 02 01 00 01 01 11 /Switch ON*
55AA 01 07 05 03 01 00 01 01 12 /Switch ON*
55AA 01 07 05 04 01 00 01 01 13 /Switch ON*

55AA 01 07 05 01 01 00 01 01 10 /Switch ON*
55AA 01 07 05 02 01 00 01 01 11 /Switch ON*
55AA 01 07 05 03 01 00 01 01 12 /Switch ON*
55AA 01 07 05 04 01 00 01 00 12 /Switch OFF

55AA 01 07 05 01 01 00 01 01 10 /Switch ON*
55AA 01 07 05 02 01 00 01 01 11 /Switch ON*
55AA 01 07 05 03 01 00 01 00 11 /Switch OFF
55AA 01 07 05 04 01 00 01 00 12 /Switch OFF

55AA 01 07 05 01 01 00 01 01 10 /Switch ON*
55AA 01 07 05 02 01 00 01 00 10 /Switch OFF
55AA 01 07 05 03 01 00 01 00 11 /Switch OFF
55AA 01 07 05 04 01 00 01 00 12 /Switch OFF

55AA 01 07 05 01 01 00 01 00 0F /...and so on...
55AA 01 07 05 02 01 00 01 00 10
55AA 01 07 05 03 01 00 01 00 11
55AA 01 07 05 04 01 00 01 00 12

55AA 01 07 05 01 01 00 01 00 0F
55AA 01 07 05 02 01 00 01 00 10
55AA 01 07 05 03 01 00 01 00 11
55AA 01 07 05 04 01 00 01 01 13

55AA 01 07 05 01 01 00 01 00 0F
55AA 01 07 05 02 01 00 01 00 10
55AA 01 07 05 03 01 00 01 01 12
55AA 01 07 05 04 01 00 01 01 13

55AA 01 07 05 01 01 00 01 00 0F
55AA 01 07 05 02 01 00 01 01 11
55AA 01 07 05 03 01 00 01 01 12
55AA 01 07 05 04 01 00 01 01 13

55AA 01 07 05 01 01 00 01 01 10
55AA 01 07 05 02 01 00 01 01 11
55AA 01 07 05 03 01 00 01 01 12
55AA 01 07 05 04 01 00 01 01 13

55AA 01 07 05 01 01 00 01 00 0F
55AA 01 07 05 02 01 00 01 01 11
55AA 01 07 05 03 01 00 01 01 12
55AA 01 07 05 04 01 00 01 01 13

55AA 01 07 05 01 01 00 01 00 0F
55AA 01 07 05 02 01 00 01 00 10
55AA 01 07 05 03 01 00 01 01 12
55AA 01 07 05 04 01 00 01 01 13

55AA 01 07 05 01 01 00 01 00 0F
55AA 01 07 05 02 01 00 01 00 10
55AA 01 07 05 03 01 00 01 00 11
55AA 01 07 05 04 01 00 01 01 13

55AA 01 07 05 01 01 00 01 00 0F
55AA 01 07 05 02 01 00 01 00 10
55AA 01 07 05 03 01 00 01 00 11
55AA 01 07 05 04 01 00 01 00 12

55AA 01 07 05 01 01 00 01 00 0F
55AA 01 07 05 02 01 00 01 00 10
55AA 01 07 05 03 01 00 01 00 11
55AA 01 07 05 04 01 00 01 00 12

[Mravko]

Looking into the plug-in code I've noticed two things:

1. There might be a typo and a case missing:

from line 390:

log = F("SerSW : State ");
if (Plugin_165_ostate[0] != Plugin_165_switchstate[0]) {
UserVar[event->BaseVarIndex] = Plugin_165_switchstate[0];
log += F(" r0:");
log += Plugin_165_switchstate[0];
}
if (Plugin_165_ostate[1] != Plugin_165_switchstate[1]) {
UserVar[event->BaseVarIndex + 1] = Plugin_165_switchstate[1];
log += F(" r1:");
log += Plugin_165_switchstate[1];
}
if (Plugin_165_ostate[2] != Plugin_165_switchstate[2]) {
UserVar[event->BaseVarIndex + 2] = Plugin_165_switchstate[2];
log += F(" b2:"); <------------------------------------------------------------ should this be "r2", not "b2"
log += Plugin_165_switchstate[1];
}
addLog(LOG_LEVEL_INFO, log);
if ( (Plugin_165_ostate[0] != Plugin_165_switchstate[0]) || (Plugin_165_ostate[1] != Plugin_165_switchstate[1]) || (Plugin_165_ostate[2] != Plugin_165_switchstate[2]) ) {
event->sensorType = Plugin_165_type;
sendData(event);

and there might be a missing set for the fourth relay, like:

if (Plugin_165_ostate[3] != Plugin_165_switchstate[3]) {
UserVar[event->BaseVarIndex + 3] = Plugin_165_switchstate[2];
log += F(" r3:");
log += Plugin_165_switchstate[1];
}



2. There might be a case missing:

from line 425:
if (Plugin_165_ostate[btnnum] != Plugin_165_switchstate[btnnum]) {
log = F("SerSW : State");
switch (btnnum) {
case 0: {
if (Plugin_165_numrelay > 0) {
UserVar[event->BaseVarIndex + btnnum] = Plugin_165_switchstate[btnnum];
log += F(" r0:");
log += Plugin_165_switchstate[btnnum];
}
break;
}
case 1: {
if (Plugin_165_numrelay > 1) {
UserVar[event->BaseVarIndex + btnnum] = Plugin_165_switchstate[btnnum];
log += F(" r1:");
log += Plugin_165_switchstate[btnnum];
}
break;
}
case 2: {
if (Plugin_165_numrelay > 2) {
UserVar[event->BaseVarIndex + btnnum] = Plugin_165_switchstate[btnnum];
log += F(" r2:");
log += Plugin_165_switchstate[btnnum];
}
break;
}
}

Should there be a fourth case (case 3:) to deal with the fourth button?

Like:
case 3: {
if (Plugin_165_numrelay > 3) {
UserVar[event->BaseVarIndex + btnnum] = Plugin_165_switchstate[btnnum];
log += F(" r3:");
log += Plugin_165_switchstate[btnnum];
}
break;
}

I've included the mods in your plug-in for your perusal.

I really don't have a way to compile the code easily and quickly so are you able to recompile with this file?

_P165_SerSwitch.ino.zip

(5.79 KiB) Downloaded 1260 times

[enesbcs]

One step further and here is what I have:
55AA 01 07 05 01 01 00 01 00 0F /Switch OFF
55AA 01 07 05 02 01 00 01 00 10 /Switch OFF
55AA 01 07 05 03 01 00 01 00 11 /Switch OFF
55AA 01 07 05 04 01 00 01 00 12 /Switch OFF

55AA 01 07 05 01 01 00 01 01 10 /Switch ON*
55AA 01 07 05 02 01 00 01 00 10 /Switch OFF
55AA 01 07 05 03 01 00 01 00 11 /Switch OFF
55AA 01 07 05 04 01 00 01 00 12 /Switch OFF

Thank you for debugging it, the results seems to be consistent.

Should there be a fourth case (case 3:) to deal with the fourth button?

Like:
case 3: {
if (Plugin_165_numrelay > 3) {
UserVar[event->BaseVarIndex + btnnum] = Plugin_165_switchstate[btnnum];
log += F(" r3:");
log += Plugin_165_switchstate[btnnum];
}
break;
}

I've included the mods in your plug-in for your perusal.

I really don't have a way to compile the code easily and quickly so are you able to recompile with this file?

_P165_SerSwitch.ino.zip

Thank you for your hard work, i totally forgot about this section of the code, i am not really sure while i was done at this way and not a simple "for" cycle... but indeed your solution seems OK. I will compile it, but can you tell me that which core version works (at least the first two button)? 242 is ok?

[Mravko]

One step further and here is what I have:
55AA 01 07 05 01 01 00 01 00 0F /Switch OFF
55AA 01 07 05 02 01 00 01 00 10 /Switch OFF
55AA 01 07 05 03 01 00 01 00 11 /Switch OFF
55AA 01 07 05 04 01 00 01 00 12 /Switch OFF

55AA 01 07 05 01 01 00 01 01 10 /Switch ON*
55AA 01 07 05 02 01 00 01 00 10 /Switch OFF
55AA 01 07 05 03 01 00 01 00 11 /Switch OFF
55AA 01 07 05 04 01 00 01 00 12 /Switch OFF

Thank you for debugging it, the results seems to be consistent.

Should there be a fourth case (case 3:) to deal with the fourth button?

Like:
case 3: {
if (Plugin_165_numrelay > 3) {
UserVar[event->BaseVarIndex + btnnum] = Plugin_165_switchstate[btnnum];
log += F(" r3:");
log += Plugin_165_switchstate[btnnum];
}
break;
}

I've included the mods in your plug-in for your perusal.

I really don't have a way to compile the code easily and quickly so are you able to recompile with this file?

_P165_SerSwitch.ino.zip

Thank you for your hard work, i totally forgot about this section of the code, i am not really sure while i was done at this way and not a simple "for" cycle... but indeed your solution seems OK. I will compile it, but can you tell me that which core version works (at least the first two button)? 242 is ok?

You're most welcome.
My work wasn't hard at all. You did the hard work. I merely looked through the code syntax and found the error based on the output.
I knew it must have been a typo' for relay 2 because it sets and then never resets. Turns out it was a simple typo (b2 instead of r2)
The case was pretty simple to miss as well.

I would compile it myself but I've tried PlatformIO, but I have no idea how to add another plugin to the main distribution. I've spent a couple of hours with no joy.

Yes, 242 should be fine. I really appreciate you re-compiling it for me.

Cheers,
MM

[Mravko]

Hi enesbcs,

Ok we are nearly there. One more issue.

1. When the switch has been power-cycled it reports all 4 switches off: (Good)

Screen Shot 2019-05-01 at 1.30.02 pm.png (18.39 KiB) Viewed 216664 times

2. When I toggle all four switches, it reports all 4 switches are on: (Good)

Screen Shot 2019-05-01 at 1.39.59 pm.png (18.27 KiB) Viewed 216664 times

Screen Shot 2019-05-01 at 1.31.49 pm.png (12.57 KiB) Viewed 216664 times

3. When I switch them all off, the first two switches report off but switch 3 and 4 report staying on (Not so good)

Screen Shot 2019-05-01 at 1.32.32 pm.png (18.23 KiB) Viewed 216664 times

Important note:
I believe this has to do with the way the info (fom the MCU) is being parsed by the plug-in.
switch 1 and switch 2 work fine but switch 3 and 4 toggle on correctly but once the bits are set on them, they cannot be reset (even if I switch them off on the panel, they will still report being on). It seems that it doesnt re-read the MCU message any more. The switches are actually "off" on the panel but the plug-in is reporting them as on.

Screen Shot 2019-05-01 at 1.53.41 pm.png (13.02 KiB) Viewed 216664 times

note 2:
Interesting thing is, if I toggle switch3 or switch4 quickly, it'll turn on and off, but if I wait 5-10 seconds, it gets stuck. This suggests that the plugin sends the right command but reads back incorrectly after that (or something like that)


My thoughts:

I'm wondering if it has anything to do with the way the device sends an update (~ every 10 seconds)? and the way that plugin deals with the info:

every 10 seconds it will send this (I have added the <return>'s for easier reading:
55AA0107000501010001000F
55AA01070005020100010010
55AA01070005030100010011
55AA01070005040100010012
55AA0107000807020004000000001C
55AA0107000808020004000000001D
55AA0107000809020004000000001E
55AA010700080A020004000000001F
55AA0107000865020004000000007A
55AA0107000866020004000000007B
55AA0107000867020004000000007C
55AA0107000868020004000009870D

So that's 12 status items every 10 seconds (without a white_space or CR/LF), ie:

55AA0107000501010001000F55AA0107000502010001001055AA0107000503010001001155AA0107000504010001001255AA0107000807020004000000001C55AA0107000808020004000000001D55AA0107000809020004000000001E55AA010700080A020004000000001F55AA0107000865020004000000007A55AA0107000866020004000000007B55AA0107000867020004000000007C55AA0107000868020004000009870D

I don't have too much programming experience but am wondering if your parsing methodology (doing it via "case "n") is able to parse it properly?
So the first 4 items are switch status reports from MCU i.e. 55AA01070005
the subsequent 8 items are (according to the tuya documentation, something to do with target temperature. i.e. 55AA01070008, (which I'm not really sure it is accurate, btw).

Screen Shot 2019-05-01 at 4.30.05 pm.png (137.01 KiB) Viewed 216660 times

I think that the plugin is ignoring (or not reading the MCU corectly) everything, beyond the first two items and therefore not updating the status.


looking at the logs I get
...EVENT: MCU#Relay0=0.00
10676455: EVENT: MCU#Relay1=0.00
10676458: EVENT: MCU#Relay2=1.00
10676461: EVENT: MCU#Relay3=1.00
10677313: SerSW : SetSwitch r2:0
10678313: SerSW : SetSwitch r3:0
10681455: EVENT: MCU#Relay1=0.00
10681458: EVENT: MCU#Relay2=1.00
10681461: EVENT: MCU#Relay3=1.00
10681575: WD : Uptime 178 ConnectFailures 0 FreeMem 16928
10681635: SerSW : Dimmer
10681638: EVENT: MCU#Relay0=0.00
10681641: EVENT: MCU#Relay1=0.00
10681644: EVENT: MCU#Relay2=1.00
10681647: EVENT: MCU#Relay3=1.00

so even the logs recognise the setting of the relays to "0":
10677313: SerSW : SetSwitch r2:0
10678313: SerSW : SetSwitch r3:0
but the plug-in still doesn't change the status:
10681638: EVENT: MCU#Relay0=0.00
10681641: EVENT: MCU#Relay1=0.00
10681644: EVENT: MCU#Relay2=1.00
10681647: EVENT: MCU#Relay3=1.00

...even though I'm almost certain that the MCU is reporting the status as all 4 switches off (cannot confirm only gut feeling):
55AA0107000501010001000F
55AA01070005020100010010
55AA01070005030100010011
55AA01070005040100010012

I hope all this helps?!

Regards,
MM

[enesbcs]

3. When I switch them all off, the first two switches report off but switch 3 and 4 report staying on (Not so good)
Screen Shot 2019-05-01 at 1.32.32 pm.png

My thoughts:

I'm wondering if it has anything to do with the way the device sends an update (~ every 10 seconds)? and the way that plugin deals with the info:

every 10 seconds it will send this (I have added the <return>'s for easier reading:
55AA0107000501010001000F
55AA01070005020100010010
55AA01070005030100010011
55AA01070005040100010012
55AA0107000807020004000000001C
55AA0107000808020004000000001D
55AA0107000809020004000000001E
55AA010700080A020004000000001F
55AA0107000865020004000000007A
55AA0107000866020004000000007B
55AA0107000867020004000000007C
55AA0107000868020004000009870D

So that's 12 status items every 10 seconds (without a white_space or CR/LF), ie:

55AA0107000501010001000F55AA0107000502010001001055AA0107000503010001001155AA0107000504010001001255AA0107000807020004000000001C55AA0107000808020004000000001D55AA0107000809020004000000001E55AA010700080A020004000000001F55AA0107000865020004000000007A55AA0107000866020004000000007B55AA0107000867020004000000007C55AA0107000868020004000009870D

I don't have too much programming experience but am wondering if your parsing methodology (doing it via "case "n") is able to parse it properly?
So the first 4 items are switch status reports from MCU i.e. 55AA01070005
the subsequent 8 items are (according to the tuya documentation, something to do with target temperature. i.e. 55AA01070008, (which I'm not really sure it is accurate, btw).

Screen Shot 2019-05-01 at 4.30.05 pm.png

I think that the plugin is ignoring (or not reading the MCU corectly) everything, beyond the first two items and therefore not updating the status.

You are right the packages with length 8 has to be the informational packages which is skipped by the code. I've seen such errors when the serial buffer overflowed. Did you try 242, 241 and 240 version also?

The device i have only sends updates when the buttons pressed and it is working fine for me. Except if you specify 10 seconds instead the default 0 sec in the plugin settings page.
My one button device sends 3x12=36bytes per message and it is nicely work in the increased 128bytes serial buffer. (default serial buffer was 32bytes and it was really low caused collisions)
Your device sends 4*12+8*15=168bytes for one package (to the 128bytes serial buffer) which may cause some interference when breaking package header near the end...

[Mravko]

3. When I switch them all off, the first two switches report off but switch 3 and 4 report staying on (Not so good)
Screen Shot 2019-05-01 at 1.32.32 pm.png

My thoughts:

I'm wondering if it has anything to do with the way the device sends an update (~ every 10 seconds)? and the way that plugin deals with the info:

every 10 seconds it will send this (I have added the <return>'s for easier reading:
55AA0107000501010001000F
55AA01070005020100010010
55AA01070005030100010011
55AA01070005040100010012
55AA0107000807020004000000001C
55AA0107000808020004000000001D
55AA0107000809020004000000001E
55AA010700080A020004000000001F
55AA0107000865020004000000007A
55AA0107000866020004000000007B
55AA0107000867020004000000007C
55AA0107000868020004000009870D

So that's 12 status items every 10 seconds (without a white_space or CR/LF), ie:

55AA0107000501010001000F55AA0107000502010001001055AA0107000503010001001155AA0107000504010001001255AA0107000807020004000000001C55AA0107000808020004000000001D55AA0107000809020004000000001E55AA010700080A020004000000001F55AA0107000865020004000000007A55AA0107000866020004000000007B55AA0107000867020004000000007C55AA0107000868020004000009870D

I don't have too much programming experience but am wondering if your parsing methodology (doing it via "case "n") is able to parse it properly?
So the first 4 items are switch status reports from MCU i.e. 55AA01070005
the subsequent 8 items are (according to the tuya documentation, something to do with target temperature. i.e. 55AA01070008, (which I'm not really sure it is accurate, btw).

Screen Shot 2019-05-01 at 4.30.05 pm.png

I think that the plugin is ignoring (or not reading the MCU corectly) everything, beyond the first two items and therefore not updating the status.

You are right the packages with length 8 has to be the informational packages which is skipped by the code. I've seen such errors when the serial buffer overflowed. Did you try 242, 241 and 240 version also?

The device i have only sends updates when the buttons pressed and it is working fine for me. Except if you specify 10 seconds instead the default 0 sec in the plugin settings page.
My one button device sends 3x12=36bytes per message and it is nicely work in the increased 128bytes serial buffer. (default serial buffer was 32bytes and it was really low caused collisions)
Your device sends 4*12+8*15=168bytes for one package (to the 128bytes serial buffer) which may cause some interference when breaking package header near the end...

Agreed.
Not only that, but because it constantly sends packets, the logic of receiving data should have something like:
1. Start of message - Wait for a gap longer than say 100ms and then start grabbing the data.
2. End of message - Payload is complete when there is no more data for 100ms.
3. Parsing -
a) I wouldn't even go into the 55AA checking (although it's a good thing I guess)
b) Chunk it up into 4 x 12 bytes
c) for each of the 4 lines:
Read the 7th byte = Switch number and
Read the 11th byte = Status
4. feed the line through the rest of the plugin
5. Increment line until line < 5

I tired to understand the logic of the code but couldn't follow it past the reading of the second byte. My logic fell over as I think the third byte didnt get checked, or at least, I don't understand how it goes on to parse the rest.

can you send me the net plugin code used when compiling this v3?

Regards,
MM

[Mravko]

Another problem I have now is I'm unable to do an OTA upload on a 1M chip as the code exceeded 600ish kb.

I have to cut the RX track, solder the wires, upload the firmware via USB, un-solder the wires, place the RX track back and so on.

[enesbcs]

1. Start of message - Wait for a gap longer than say 100ms and then start grabbing the data.
2. End of message - Payload is complete when there is no more data for 100ms.

I see no reason for waiting anything, neither checking the message end. To know where is the package end, you have to check and harvest every size field in the headers (4+8 per packet), which is slower than the current implementation which skips everything that is not necessarry.

3. Parsing -
a) I wouldn't even go into the 55AA checking (although it's a good thing I guess)

This header specifies the package start, offset 0. Treat as a sync field.

b) Chunk it up into 4 x 12 bytes
c) for each of the 4 lines:
Read the 7th byte = Switch number and
Read the 11th byte = Status
4. feed the line through the rest of the plugin
5. Increment line until line < 5

Serial communication is not working in this way, there are no way to read 7th byte, bytes coming continously. Offset 0 is the "55" as i wrote. If you try to "chunk it" for 4x12 bytes, what will you do with the following 8x15bytes?

I tired to understand the logic of the code but couldn't follow it past the reading of the second byte. My logic fell over as I think the third byte didnt get checked, or at least, I don't understand how it goes on to parse the rest.

can you send me the net plugin code used when compiling this v3?

https://github.com/enesbcs/ESPEasyPlugi ... Switch.ino

My code checks if byte3 is 7 (status) and byte5 (size field) is 5. Then byte6 - 1 is the switch number and byte10 is it's state. (everything is 0 based...) Then reads until a new valid header received through serial. This is the simplest approach.
I do not wait until the buffer is full, so there are nothing to "chunk" data arrives bytes after bytes through serial. Although the ESP has an internal serial buffer which may overflow (not the plugin's buffer), this is what i wrote previously.

[enesbcs]

Another problem I have now is I'm unable to do an OTA upload on a 1M chip as the code exceeded 600ish kb.

I have to cut the RX track, solder the wires, upload the firmware via USB, un-solder the wires, place the RX track back and so on.

I am sorry. My Tuya switch has 4MB flash.
ESPEasy core is getting bigger after every new version. I can compile you from an older codebase, if you need a smaller one.

[Mravko]

1. Start of message - Wait for a gap longer than say 100ms and then start grabbing the data.
2. End of message - Payload is complete when there is no more data for 100ms.

I see no reason for waiting anything, neither checking the message end. To know where is the package end, you have to check and harvest every size field in the headers (4+8 per packet), which is slower than the current implementation which skips everything that is not necessarry.

3. Parsing -
a) I wouldn't even go into the 55AA checking (although it's a good thing I guess)

This header specifies the package start, offset 0. Treat as a sync field.

b) Chunk it up into 4 x 12 bytes
c) for each of the 4 lines:
Read the 7th byte = Switch number and
Read the 11th byte = Status
4. feed the line through the rest of the plugin
5. Increment line until line < 5

Serial communication is not working in this way, there are no way to read 7th byte, bytes coming continously. Offset 0 is the "55" as i wrote. If you try to "chunk it" for 4x12 bytes, what will you do with the following 8x15bytes?

I tired to understand the logic of the code but couldn't follow it past the reading of the second byte. My logic fell over as I think the third byte didnt get checked, or at least, I don't understand how it goes on to parse the rest.

can you send me the net plugin code used when compiling this v3?

https://github.com/enesbcs/ESPEasyPlugi ... Switch.ino

My code checks if byte3 is 7 (status) and byte5 (size field) is 5. Then byte6 - 1 is the switch number and byte10 is it's state. (everything is 0 based...) Then reads until a new valid header received through serial. This is the simplest approach.
I do not wait until the buffer is full, so there are nothing to "chunk" data arrives bytes after bytes through serial. Although the ESP has an internal serial buffer which may overflow (not the plugin's buffer), this is what i wrote previously.

So let me get this straight:

Does the code constantly look for 55AA in the stream and every time it gets it, it parses the info?

so when it receives a load like this:
55AA0107000501010001000F55AA0107000502010001001055AA0107000503010001001155AA0107000504010001001255AA0107000807020004000000001C55AA0107000808020004000000001D55AA0107000809020004000000001E55AA010700080A020004000000001F55AA0107000865020004000000007A55AA0107000866020004000000007B55AA0107000867020004000000007C55AA0107000868020004000009870D

it will parse all 12 messages, at once, that begin with 55AA?
therefore will it process (action) the first four and ignore the other 8?



Another thing is the logs seem to show what the code suggest it should send to the log i.e.

0824093: EVENT: MCU#Relay0=0.00
20824107: EVENT: MCU#Relay1=0.00
20824123: EVENT: MCU#Relay2=1.00
20824138: EVENT: MCU#Relay3=1.00
20824181: SerSW : Dimmer
20824188: EVENT: MCU#Relay0=0.00
20824202: EVENT: MCU#Relay1=0.00
20824218: EVENT: MCU#Relay2=1.00
20824232: EVENT: MCU#Relay3=1.00
20833087: EVENT: MCU#Relay0=0.00
20833101: EVENT: MCU#Relay1=0.00
20833116: EVENT: MCU#Relay2=1.00
20833132: EVENT: MCU#Relay3=1.00
20833175: SerSW : Dimmer <--- what does this mean?
20833182: EVENT: MCU#Relay0=0.00
20833196: EVENT: MCU#Relay1=0.00
20833211: EVENT: MCU#Relay2=1.00
20833226: EVENT: MCU#Relay3=1.00
20842100: EVENT: MCU#Relay1=0.00 <----skipped Relay0=0.00
20842114: EVENT: MCU#Relay2=1.00
20842129: EVENT: MCU#Relay3=1.00
20842177: SerSW : Dimmer
20842183: EVENT: MCU#Relay0=0.00
20842197: EVENT: MCU#Relay1=0.00
20842212: EVENT: MCU#Relay2=1.00
20842227: EVENT: MCU#Relay3=1.00
20842291: EVENT: Clock#Time=Thu,00:16
... and so on in circle

but I'n not sure where the message "SerSW : Dimmer" came from and what it implies?
Also Im not sure why the logs are not reporting each switch in sequence, every time

[Mravko]

3. When I switch them all off, the first two switches report off but switch 3 and 4 report staying on (Not so good)
Screen Shot 2019-05-01 at 1.32.32 pm.png

My thoughts:

I'm wondering if it has anything to do with the way the device sends an update (~ every 10 seconds)? and the way that plugin deals with the info:

every 10 seconds it will send this (I have added the <return>'s for easier reading:
55AA0107000501010001000F
55AA01070005020100010010
55AA01070005030100010011
55AA01070005040100010012
55AA0107000807020004000000001C
55AA0107000808020004000000001D
55AA0107000809020004000000001E
55AA010700080A020004000000001F
55AA0107000865020004000000007A
55AA0107000866020004000000007B
55AA0107000867020004000000007C
55AA0107000868020004000009870D

So that's 12 status items every 10 seconds (without a white_space or CR/LF), ie:

55AA0107000501010001000F55AA0107000502010001001055AA0107000503010001001155AA0107000504010001001255AA0107000807020004000000001C55AA0107000808020004000000001D55AA0107000809020004000000001E55AA010700080A020004000000001F55AA0107000865020004000000007A55AA0107000866020004000000007B55AA0107000867020004000000007C55AA0107000868020004000009870D

I don't have too much programming experience but am wondering if your parsing methodology (doing it via "case "n") is able to parse it properly?
So the first 4 items are switch status reports from MCU i.e. 55AA01070005
the subsequent 8 items are (according to the tuya documentation, something to do with target temperature. i.e. 55AA01070008, (which I'm not really sure it is accurate, btw).

Screen Shot 2019-05-01 at 4.30.05 pm.png

I think that the plugin is ignoring (or not reading the MCU corectly) everything, beyond the first two items and therefore not updating the status.

You are right the packages with length 8 has to be the informational packages which is skipped by the code. I've seen such errors when the serial buffer overflowed. Did you try 242, 241 and 240 version also?

The device i have only sends updates when the buttons pressed and it is working fine for me. Except if you specify 10 seconds instead the default 0 sec in the plugin settings page.
My one button device sends 3x12=36bytes per message and it is nicely work in the increased 128bytes serial buffer. (default serial buffer was 32bytes and it was really low caused collisions)
Your device sends 4*12+8*15=168bytes for one package (to the 128bytes serial buffer) which may cause some interference when breaking package header near the end...

I've loaded this version up and after introducing a 5 sec interval I got a somewhat cleaner output:

687686: SerSW : ReadState
687696: EVENT: MCU#Relay0=0.00
687702: EVENT: MCU#Relay1=0.00
687706: EVENT: MCU#Relay2=1.00
687709: EVENT: MCU#Relay3=1.00
691907: WD : Uptime 12 ConnectFailures 0 FreeMem 24200
692686: SerSW : ReadState
692696: EVENT: MCU#Relay0=0.00
692702: EVENT: MCU#Relay1=0.00
692705: EVENT: MCU#Relay2=1.00
692709: EVENT: MCU#Relay3=1.00
...

I can also confirm that the sending commands to the MCU works perfect!

however, as you can see we have the same problem with the reading

I'm wondering..., when reading the States of the input, is there a way to discard everything before the 100ms delay?
As the MCU sends the whole lot, at ~5 second intervals, is there way not to read half way through the stream and read from the beginning?

and can you tell me where in the code it parses switch 3 and 4?
i.e.
55AA 01 07 0005 01 0100010110 <---Switch 1 is "on"
55AA 01 07 0005 02 0100010010 <---Switch 2 is "off"
55AA 01 07 0005 03 0100010011 <---Switch 3 is "off"
55AA 01 07 0005 04 0100010012 <---Switch 4 is "off"

I don't really have a way to debug this.

[enesbcs]

So let me get this straight:

Does the code constantly look for 55AA in the stream and every time it gets it, it parses the info?

so when it receives a load like this:
55AA0107000501010001000F55AA0107000502010001001055AA0107000503010001001155AA0107000504010001001255AA0107000807020004000000001C55AA0107000808020004000000001D55AA0107000809020004000000001E55AA010700080A020004000000001F55AA0107000865020004000000007A55AA0107000866020004000000007B55AA0107000867020004000000007C55AA0107000868020004000009870D

it will parse all 12 messages, at once, that begin with 55AA?
therefore will it process (action) the first four and ignore the other 8?

Yes, this was the idea.

20833132: EVENT: MCU#Relay3=1.00
20833175: SerSW : Dimmer <--- what does this mean?
20833182: EVENT: MCU#Relay0=0.00

Length 8 data structure is used by the Tuya dimmer switch, which is also used by reporting to this device. It has no effect on this case.

20833226: EVENT: MCU#Relay3=1.00
20842100: EVENT: MCU#Relay1=0.00 <----skipped Relay0=0.00
20842114: EVENT: MCU#Relay2=1.00

Serial buffer overflow, first package or at least the first package sync bits lost somewhere.

[enesbcs]

I've loaded this version up and after introducing a 5 sec interval I got a somewhat cleaner output:

And what if you set 0 sec intervals?

I'm wondering..., when reading the States of the input, is there a way to discard everything before the 100ms delay?
As the MCU sends the whole lot, at ~5 second intervals, is there way not to read half way through the stream and read from the beginning?

I do not know, but i doubt that. Serial communication works as its name implies: one-by-one.

and can you tell me where in the code it parses switch 3 and 4?

The same place when the 1st and 2nd switch. (Line 418) My internal buffer is rolling, only containing one package at a time... The whole message is stored in the internal buffer of the ESP which is read by the Serial.read() one-by-one... if this internal buffer is overflowed or cleared in the process of decoding other packages, there are nothing to read.

I don't really have a way to debug this.

Neither i am. It just works for me with my device.

[Mravko]

I've loaded this version up and after introducing a 5 sec interval I got a somewhat cleaner output:

And what if you set 0 sec intervals?

I'm wondering..., when reading the States of the input, is there a way to discard everything before the 100ms delay?
As the MCU sends the whole lot, at ~5 second intervals, is there way not to read half way through the stream and read from the beginning?

I do not know, but i doubt that. Serial communication works as its name implies: one-by-one.

and can you tell me where in the code it parses switch 3 and 4?

The same place when the 1st and 2nd switch. (Line 418) My internal buffer is rolling, only containing one package at a time... The whole message is stored in the internal buffer of the ESP which is read by the Serial.read() one-by-one... if this internal buffer is overflowed or cleared in the process of decoding other packages, there are nothing to read.

I don't really have a way to debug this.

Neither i am. It just works for me with my device.

And what if you set 0 sec intervals?

If I select 0, it doesn't parse anything from the MCU.
I may get 1 set of four log entries, every 1-2 minutes

[enesbcs]

If I select 0, it doesn't parse anything from the MCU.
I may get 1 set of four log entries, every 1-2 minutes

It is very sad. My old Tuya unit reports its state on its own when any status is changed on it without any periodic check. If it is true, than i will never buy Tuya switches again. Sonoff and Shelly is all better. Maybe you can try the core240 binary, as Core 2.4 worked better with serial devices in the past.

I've increased the serial buffer to 336 bytes in the following binaries. All of it is under 600k in size.

[Mravko]

So two things:

1. looking into the following code:

line 681:
void sendmcucommand(byte btnnum, byte state, byte swtype, byte btnum_mode) // btnnum=0,1,2, state=0/1
{
byte sstate;

switch (swtype)
{
case SER_SWITCH_YEWE:
{
Serial.write(0x55); // Tuya header 55AA
Serial.write(0xAA);
Serial.write(0x00); // version 00
Serial.write(0x06); // Tuya command 06 - send order
Serial.write(0x00);
Serial.write(0x05); // following data length 0x05
Serial.write( (btnnum + 1) ); // relay number 1,2,3
Serial.write(0x01); // ?
Serial.write(0x00); // ?
Serial.write(0x01); // ?
Serial.write( state ); // status
Serial.write((13 + btnnum + state)); // checksum:sum of all bytes in packet mod 256
Serial.flush();
break;
}


I'm interested in the byte "btnnum". What's confusing is this line "Serial.write( (btnnum + 1) ); // relay number 1,2,3"
Are we adding "+ 1" because btnnum = 01 for the first relay?

according to my logs:
55AA 01 070005 01 010001 00 0F
55AA 01 070005 02 010001 00 10
55AA 01 070005 03 010001 00 11
55AA 01 070005 04 010001 01 13

I'm wondering if the hex of switch 3 and 4 are not read correctly in the read section. you know 0x00, 0x01, 0x0a and 0x0b.
I'm wondering if a and b are not interpreted correctly when reading.

This writing code looks ok (and that's why the writing of commands to the MCU works.

As I don't really follow the reading of the status, I cant figure out what bytes it's expecting for switch 3 and switch 4?

2.
line 749:

void sendmcudim(byte dimvalue)
{
Serial.write(0x55); // Tuya header 55AA
Serial.write(0xAA);
Serial.write(0x00); // version 00
Serial.write(0x06); // Tuya command 06 - send order
Serial.write(0x00);
Serial.write(0x08); // following data length 0x08
Serial.write(Plugin_165_numrelay); // dimmer order-id? select it at plugin settings 2/3!!!
Serial.write(0x02); // type=value
Serial.write(0x00); // length hi
Serial.write(0x04); // length low
Serial.write(0x00); // ?
Serial.write(0x00); // ?
Serial.write(0x00); // ?
Serial.write( dimvalue ); // dim value (0-255)
Serial.write( byte(19 + Plugin_165_numrelay + dimvalue) ); // checksum:sum of all bytes in packet mod 256
Serial.flush();
}

If in the context of your TUYA type you can select (Number of Relays):
1,
2/Dimmer,
3/Dimmer,
4

Could the dimmer selection be interfering with the reading?
I noticed it's 8 bytes and I think my logs show that it is sending those valies, so when it is processing 2, 3 and 4 is it expecting dimmer values or switch values?

[Mravko]

If I select 0, it doesn't parse anything from the MCU.
I may get 1 set of four log entries, every 1-2 minutes

It is very sad. My old Tuya unit reports its state on its own when any status is changed on it without any periodic check. If it is true, than i will never buy Tuya switches again. Sonoff and Shelly is all better. Maybe you can try the core240 binary, as Core 2.4 worked better with serial devices in the past.

I've increased the serial buffer to 336 bytes in the following binaries. All of it is under 600k in size.

Hi enesbcs,

Ok, I'l load it and will let you know

[Bohbe]

Hi,

This is my first post in this forum, so bare with me. I went to Aliexpress and got some LCTech 2ch relays. I have a really hard time to get it to work with ESP Easy. I realized that the 2-channel version I got had a Nuvoton N76E003 MCU instedad of the STM.

After a lot of trials with software (different configs, baud rate etc). I looked at the signal in the original SW provided in the ESP and compared it with the ESP Easy programmed ESP. I saw that the baud rate was the same, 115200, but the data sent was completely different. Being a hardware guy I borrowed the logic analyzer from work and deciphered the original ESP SW UART message for the N76E003 and found the following:

Relay 1 on : (Hex) 0D 0A 2B 49 50 44 2C 30 2C 34 3A A0 01 01 A2
Relay 1 off: (Hex) 0D 0A 2B 49 50 44 2C 30 2C 34 3A A0 01 00 A1
Relay 2 on : (Hex) 0D 0A 2B 49 50 44 2C 30 2C 34 3A A0 02 01 A3
Relay 2 off: (Hex) 0D 0A 2B 49 50 44 2C 30 2C 34 3A A0 02 00 A2

They have added 11 bytes of the same data, maybe as an address Has anyone else seen the same thing? Or am I doing anything else wrong here?
Next step is to try to compile a simple test version of ESP Easy to add the data to the message and see how it work. It might take some time though, I havent done compiling in looong time. Or if someone can help me with that...

[enesbcs]

This is my first post in this forum, so bare with me. I went to Aliexpress and got some LCTech 2ch relays. I have a really hard time to get it to work with ESP Easy. I realized that the 2-channel version I got had a Nuvoton N76E003 MCU instedad of the STM.

Url? At the description page the seller usually writes about the usable commands...

Relay 1 on : (Hex) 0D 0A 2B 49 50 44 2C 30 2C 34 3A A0 01 01 A2
Relay 1 off: (Hex) 0D 0A 2B 49 50 44 2C 30 2C 34 3A A0 01 00 A1
Relay 2 on : (Hex) 0D 0A 2B 49 50 44 2C 30 2C 34 3A A0 02 01 A3
Relay 2 off: (Hex) 0D 0A 2B 49 50 44 2C 30 2C 34 3A A0 02 00 A2

They have added 11 bytes of the same data, maybe as an address

If you convert "0D 0A 2B 49 50 44 2C 30 2C 34 3A" to ASCII you'll get
"
+IPD,0,4:" which is a simple AT modem command for the ESP (means transfer the following 4 bytes)... the real commands for the MCU seems to be the same as always: A0 01 01 A2, A0 01 00 A1, etc... which is already supported by this plugin.

[enesbcs]

1. looking into the following code:

line 681:
I'm interested in the byte "btnnum". What's confusing is this line "Serial.write( (btnnum + 1) ); // relay number 1,2,3"
Are we adding "+ 1" because btnnum = 01 for the first relay?

Yes the Tuya addresses buttons from 1, the plugin addresses EVERYTHING from 0.
Incoming switch numbers decoded at line 426:

Code: Select all

byte btnnum = (serial_buf[6] - 1);

Who has worked with arrays knows why starting from 0 is handy.

I'm wondering if the hex of switch 3 and 4 are not read correctly in the read section. you know 0x00, 0x01, 0x0a and 0x0b.
I'm wondering if a and b are not interpreted correctly when reading.

I don't quite understand your point, it does not matter if you write it in hex or decimal, everything is binary. Byte values arriving from serial which do not need any interpreting.

As I don't really follow the reading of the status, I cant figure out what bytes it's expecting for switch 3 and switch 4?

The same as switch 1 and switch 2 as the packet format is equal. You wont find a difference where there are no difference, this is handled by the case from line 434.

Could the dimmer selection be interfering with the reading?
I noticed it's 8 bytes and I think my logs show that it is sending those valies, so when it is processing 2, 3 and 4 is it expecting dimmer values or switch values?

If you see "SerSW : Dimmer" it does not process anything but execute a sendto() command which may update the device status in MQTT.. but if it bother you, i can hide it.
If you see "SerSW : Dimmer d1:" or "SerSW : Dimmer d2:" in your logs, than yes, it may interfere.