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
Moderators: grovkillen, Stuntteam, TD-er
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...
You're absolutely right!enesbcs wrote: ↑24 Feb 2019, 00:08Then 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
Yes. If you read the header of the plugin, you will see that "relaypulse" command is already supported:
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!enesbcs wrote: ↑24 Feb 2019, 15:35Yes. If you read the header of the plugin, you will see that "relaypulse" command is already supported:
https://github.com/letscontrolit/ESPEas ... Switch.ino
Hi
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.
ok, thanks understood.enesbcs wrote: ↑07 Mar 2019, 19:44Sorry, 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...
New binary attached with 20190311 sources compiled against Arduino ESP core 2.5.0.
Did you use PUYA-safe builds from the previous stable release on that chip?
Here you can find the used ESPEasy source where you can modify HTML:neo1975 wrote: ↑01 Apr 2019, 19:58 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
I guess you did not applied the PUYA patch to the ESP core before compiling:
I only have a 1 gang simple Tuya based wall switch without power metering function.
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 the switches have a controller board and a relay board, as well as the current sensors.
Adding an option is not so hard, few minutes... but compiling and testing is a much more challanging quest.Mravko wrote: ↑28 Apr 2019, 14:54 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?
in the logs my 4 Gang shows this every time:enesbcs wrote: ↑28 Apr 2019, 16:01Adding an option is not so hard, few minutes... but compiling and testing is a much more challanging quest.Mravko wrote: ↑28 Apr 2019, 14:54 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?
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.
Thanks heaps!
Ok here's how it went:
Serial packet format and or length changed from original. This may cause this interference.Mravko wrote: ↑29 Apr 2019, 10:20 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
Ok, so here is the capture file I've managed to produce.enesbcs wrote: ↑29 Apr 2019, 18:10Serial packet format and or length changed from original. This may cause this interference.Mravko wrote: ↑29 Apr 2019, 10:20 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
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
Thank you for debugging it, the results seems to be consistent.Mravko wrote: ↑30 Apr 2019, 06:56 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 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 wrote: ↑30 Apr 2019, 11:33 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
You're most welcome.enesbcs wrote: ↑30 Apr 2019, 18:13Thank you for debugging it, the results seems to be consistent.Mravko wrote: ↑30 Apr 2019, 06:56 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 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 wrote: ↑30 Apr 2019, 11:33 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
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?Mravko wrote: ↑01 May 2019, 05:57 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.
Agreed.enesbcs wrote: ↑01 May 2019, 10:37You 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?Mravko wrote: ↑01 May 2019, 05:57 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.
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 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.
This header specifies the package start, offset 0. Treat as a sync field.
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?
https://github.com/enesbcs/ESPEasyPlugi ... Switch.inoMravko wrote: ↑01 May 2019, 12:52 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?
I am sorry. My Tuya switch has 4MB flash.
So let me get this straight:enesbcs wrote: ↑01 May 2019, 14:47I 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.This header specifies the package start, offset 0. Treat as a sync field.
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?https://github.com/enesbcs/ESPEasyPlugi ... Switch.inoMravko wrote: ↑01 May 2019, 12:52 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?
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.
I've loaded this version up and after introducing a 5 sec interval I got a somewhat cleaner output:enesbcs wrote: ↑01 May 2019, 10:37You 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?Mravko wrote: ↑01 May 2019, 05:57 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.
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...
Yes, this was the idea.Mravko wrote: ↑01 May 2019, 16:22 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?
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.
Serial buffer overflow, first package or at least the first package sync bits lost somewhere.
And what if you set 0 sec intervals?
I do not know, but i doubt that. Serial communication works as its name implies: one-by-one.
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.
Neither i am. It just works for me with my device.
enesbcs wrote: ↑01 May 2019, 17:33And what if you set 0 sec intervals?
I do not know, but i doubt that. Serial communication works as its name implies: one-by-one.
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.
Neither i am. It just works for me with my device.
If I select 0, it doesn't parse anything from the MCU.And what if you set 0 sec intervals?
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.
Hi enesbcs,enesbcs wrote: ↑02 May 2019, 18:30It 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.
Url? At the description page the seller usually writes about the usable commands...
If you convert "0D 0A 2B 49 50 44 2C 30 2C 34 3A" to ASCII you'll getBohbe wrote: ↑03 May 2019, 21:29 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
Yes the Tuya addresses buttons from 1, the plugin addresses EVERYTHING from 0.
Code: Select all
byte btnnum = (serial_buf[6] - 1);
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.
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.
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.
Users browsing this forum: Ahrefs [Bot] and 147 guests