DFPlayer Mini is slow(lag) and unresponsive. (workaround) #5528

wongnam · 2019-03-26T08:51:27Z

BUG DESCRIPTION

I encounter issue regrading to MP3 Player(DF player mini) that it only works about 80% of the time when i type the command to control it. i mean that the command is not effect so i have type again and again.

(note: I am not use MQTT yet that is the reason i already disable the MQTT feature here.)

REQUESTED INFORMATION

Make sure these boxes are checked before submitting your issue. Thank you

FAILURE TO COMPLETE THE REQUESTED INFORMATION WILL RESULT IN YOUR ISSUE BEING CLOSED

Read the Contributing Guide and Policy and the Code of Conduct
Searched the problem in issues (https://github.com/arendst/Sonoff-Tasmota/issues)
Searched the problem in the wiki (https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting)
Searched the problem in the forum (https://groups.google.com/d/forum/sonoffusers)
Searched the problem in the chat (https://discord.gg/Ks2Kzd4)
Device used (i.e. Sonoff Basic) : Node-MCU
Tasmota binary firmware version number used : self-compiled version 6.5.0.2 core-2.4.2 with MP3 Define enable.
Development IDE - Compiler / Upload tools used : VSC / Platform IDE
Provide the output of command status 0 : Yes

STATUS 0 OUTPUT HERE:
15:34:55 CMD: status 0
15:34:55 RSL: STATUS = {"Status":{"Module":18,"FriendlyName":["MP3 Player"],"Topic":"mp3player","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}}
15:34:55 RSL: STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/release/sonoff.bin","RestartReason":"External System","Uptime":"0T00:18:04","StartupUTC":"2019-03-26T08:16:51","Sleep":50,"CfgHolder":4617,"BootCount":22,"SaveCount":80,"SaveAddress":"F4000"}}
15:34:55 RSL: STATUS2 = {"StatusFWR":{"Version":"6.5.0.2(sonoff)","BuildDateTime":"2019-03-25T23:15:09","Boot":31,"Core":"2_4_2","SDK":"2.2.1(cfd48f3)"}}
15:34:55 RSL: STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":2,"SysLog":0,"LogHost":"192.168.12.155","LogPort":514,"SSId":["iot-2","Wong"],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008001","280500000100000000000000000000000000","00000000"]}}
15:34:55 RSL: STATUS4 = {"StatusMEM":{"ProgramSize":481,"Free":520,"Heap":26,"ProgramFlashSize":1024,"FlashSize":4096,"FlashChipId":"164020","FlashMode":3,"Features":["00000809","0F8A2390","2402A000","00B400CE","000013C0"]}}
15:34:55 RSL: STATUS5 = {"StatusNET":{"Hostname":"mp3player-2372","IPAddress":"192.168.137.94","Gateway":"192.168.137.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.137.1","Mac":"2C:3A:E8:43:89:44","Webserver":2,"WifiConfig":4}}
15:34:55 RSL: STATUS7 = {"StatusTIM":{"UTC":"Tue Mar 26 08:34:55 2019","Local":"Tue Mar 26 15:34:55 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":"+07:00","Sunrise":"05:53","Sunset":"18:03"}}
15:34:55 RSL: STATUS10 = {"StatusSNS":{"Time":"2019-03-26T15:34:55"}}
15:34:55 RSL: STATUS11 = {"StatusSTS":{"Time":"2019-03-26T15:34:55","Uptime":"0T00:18:04","Vcc":3.002,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"Wifi":{"AP":2,"SSId":"Wong","BSSId":"22:B9:A5:1C:B0:E4","Channel":11,"RSSI":100,"LinkCount":2,"Downtime":"0T00:03:12"}}}
15:35:05 CMD: mp3play
15:35:06 RSL: RESULT = {"MP3Play"}
15:35:09 CMD: mp3stop
15:35:10 RSL: RESULT = {"MP3Stop"}
15:35:17 CMD: mp3track 001
15:35:18 RSL: RESULT = {"MP3Track":1}
15:35:27 CMD: mp3track 002
15:35:28 RSL: RESULT = {"MP3Track":2}
15:35:33 CMD: mp3track 003
15:35:34 RSL: RESULT = {"MP3Track":3}
15:35:40 CMD: mp3track 003
15:35:41 RSL: RESULT = {"MP3Track":3}
15:35:51 CMD: mp3track 004
15:35:52 RSL: RESULT = {"MP3Track":4}
15:35:58 CMD: mp3stop
15:35:59 RSL: RESULT = {"MP3Stop"}

Provide the output of console when you experience your issue if apply :
(Please use weblog 4 for more debug information)

CONSOLE OUTPUT HERE:
15:43:05 CMD: weblog 4
15:43:05 RSL: RESULT = {"WebLog":4}
15:43:05 WIF: Checking connection...
15:43:05 WIF: Connected
15:43:06 CFG: Saved to flash at FB, Count 81, Bytes 3584
15:43:10 CMD: mp3play
15:43:10 SRC: WebConsole from 192.168.137.1
15:43:10 RSL: Received Topic /mp3play, Data Size 0, Data 
15:43:10 RSL: Group 0, Index 1, Command MP3PLAY, Data 
15:43:11 RSL: RESULT = {"MP3Play"}
15:43:18 CMD: mp3track 005
15:43:18 SRC: WebConsole from 192.168.137.1
15:43:18 RSL: Received Topic /mp3track, Data Size 3, Data 005
15:43:18 RSL: Group 0, Index 1, Command MP3TRACK, Data 005
15:43:19 RSL: RESULT = {"MP3Track":5}
15:43:27 WIF: Checking connection...
15:43:27 WIF: Connected
15:43:31 CMD: mp3track 001
15:43:31 SRC: WebConsole from 192.168.137.1
15:43:31 RSL: Received Topic /mp3track, Data Size 3, Data 001
15:43:31 RSL: Group 0, Index 1, Command MP3TRACK, Data 001
15:43:32 RSL: RESULT = {"MP3Track":1}
15:43:41 CMD: mp3track 002
15:43:41 SRC: WebConsole from 192.168.137.1
15:43:41 RSL: Received Topic /mp3track, Data Size 3, Data 002
15:43:41 RSL: Group 0, Index 1, Command MP3TRACK, Data 002
15:43:42 RSL: RESULT = {"MP3Track":2}
15:43:48 CMD: mp3track 003
15:43:48 SRC: WebConsole from 192.168.137.1
15:43:48 RSL: Received Topic /mp3track, Data Size 3, Data 003
15:43:48 RSL: Group 0, Index 1, Command MP3TRACK, Data 003
15:43:49 RSL: RESULT = {"MP3Track":3}
15:43:50 WIF: Checking connection...
15:43:50 WIF: Connected
15:43:54 CMD: mp3track 003
15:43:54 SRC: WebConsole from 192.168.137.1
15:43:54 RSL: Received Topic /mp3track, Data Size 3, Data 003
15:43:54 RSL: Group 0, Index 1, Command MP3TRACK, Data 003
15:43:55 RSL: RESULT = {"MP3Track":3}
15:44:00 CMD: mp3track 004
15:44:00 SRC: WebConsole from 192.168.137.1
15:44:00 RSL: Received Topic /mp3track, Data Size 3, Data 004
15:44:00 RSL: Group 0, Index 1, Command MP3TRACK, Data 004
15:44:01 RSL: RESULT = {"MP3Track":4}
15:44:05 CMD: mp3stop
15:44:05 SRC: WebConsole from 192.168.137.1
15:44:05 RSL: Received Topic /mp3stop, Data Size 0, Data 
15:44:05 RSL: Group 0, Index 1, Command MP3STOP, Data 
15:44:06 RSL: RESULT = {"MP3Stop"}
15:44:13 WIF: Checking connection...
15:44:13 WIF: Connected
15:44:33 WIF: Checking connection...
15:44:33 WIF: Connected
15:44:53 WIF: Checking connection...
15:44:53 WIF: Connected
15:45:13 WIF: Checking connection...
15:45:13 WIF: Connected

TO REPRODUCE

just type mp3track xxx (xxx is number of mp3 filename. eg: 003.mp3)
if you type 10 command that it will only response 8 commands.

EXPECTED BEHAVIOUR

it should be response all the time, no lack any command, if not it is not useful for voice announcement.

SCREENSHOTS

(Please, remember to close the issue when the problem has been addressed)

The text was updated successfully, but these errors were encountered:

Jason2866 · 2019-03-26T12:00:24Z

The DF Player is a very very cheap device. The problems you describe are not related to Tasmota.
If you search you will find issues...The devices just reacts sometimes not correct to commands and tell it did successfull. You can verify if you setup a test enviroment with a Arduino.

wongnam · 2019-03-26T12:06:31Z

@Jason2866 I also doubt its stability when working with TASMOTA so I will try it with ESPEASY, if the error appears, then it can be concluded that it comes from hardware, otherwise I will go back to TASMOTA to further investigation. I really want it to run with the TASMOTA environment instead of ESPEASY.

Update: @Jason2866 I've just tested DFPlayer with ESP_Easy_mega-20190315_test_core_242_ESP8266_4M.bin that it work and response 100% of time(web cmd and MQTT cmd). so, I can be concluded that the issue is not come from hardware.

wongnam · 2019-03-29T15:04:54Z

It is very appreciated if the project owner(@gemu2015) can check if this is a driver-related error, because I have tried and confirmed that the error is not related to the hardware.
#3628

gemu2015 · 2019-03-30T07:19:38Z

@wongnam
i initiated the development but did not contribute to the final driver. i can confirm that the web ui is very unresponsive now. my initial version did not have that behavior. as i am very short of time i can not figure out what the reason is. in my application i only initiate a play through rules and that works reliably.

Staars · 2019-04-13T18:37:06Z

I just received my dfplayer and it is the cheapest model, that I could find. So I hope it is unreliable ;)

What I think so far:
The drivers for Tasmota and ESP-Easy are very similiar and if there is a difference in reliability, it should have something to do with the rest of the run loop (maybe a timing problem).
I fear, that it will hardly be possible to debug this, because there is only the TX-line used (in ESP-Easy too!).
So I expect, that we can only solve the problem of @wongnam, if we use the RX-line too and check, if the dfplayer responded accordingly.

I will try to add this and report here, if there is something to show.

Staars · 2019-04-15T10:42:43Z

Even though there is nothing to show yet, the „good“ news are, that I have serial connection problems too from time to time. So I have something to work on the table.

Sometimes I get from the device:
no response at all
scrambled responses
real error messages

But it works most of the time.

There is still a lot of basework to do, but as the device never really froze, I am quite optimistic to circumvent the (probably hardware related) issues with a software solution.
The main goal is to not overinflate the code size to insanity in this process. But we will definitly need a bidirectional connection for this.

gemu2015 · 2019-04-15T14:01:23Z

ok i found the bug. if you disable interrupts in tasmota serial write it works 100 % of time.
may be we should always disable irqs during software serial write. (not only in m_high_speed mode)

to test it simply set m_high_speed=1; at the end of subroutine =>
bool TasmotaSerial::begin(long speed, int stop_bits)

Staars · 2019-04-15T14:48:24Z

ok i found the bug. if you disable interrupts in tasmota serial write it works 100 % of time.
may be we should always disable irqs during software serial write. (not only in m_high_speed mode)

to test it simply set m_high_speed=1; at the end of subroutine =>
bool TasmotaSerial::begin(long speed, int stop_bits)

That sounds like a very good idea!!
I will test this too and it would be much better, than endless tests of an unreliable connection.

wongnam · 2019-04-16T06:08:29Z

@gemu2015 Good idea, let me try it tonight.

gemu2015 · 2019-04-16T06:11:16Z

simplest solution just change

=> m_high_speed = (speed > 9600);

to => m_high_speed = (speed >= 9600);

wongnam · 2019-04-16T06:15:04Z

yes, I get your point.

bool TasmotaSerial::begin(long speed, int stop_bits) {
  m_stop_bits = ((stop_bits -1) &1) +1;
  if (m_hardserial) {
    Serial.flush();
    if (2 == m_stop_bits) {
      Serial.begin(speed, SERIAL_8N2);
    } else {
      Serial.begin(speed, SERIAL_8N1);
    }
    if (m_hardswap) {
      Serial.swap();
    }
  } else {
    // Use getCycleCount() loop to get as exact timing as possible
    m_bit_time = F_CPU / speed;
    m_high_speed = (speed >= 9600);
  }
  return m_valid;
}

Staars · 2019-04-16T06:37:52Z

Yes, this seems to work here for me.

Jason2866 · 2019-04-16T16:01:10Z

Cool PR awaited ;-)

wongnam · 2019-04-17T02:37:41Z

@gemu2015 It's great for me now. the DFPlayer Mini work perfectly after fixed as your advice. Thank you.
Yes, PR please!

gemu2015 · 2019-04-18T06:33:58Z

are you serious? a pr for one line of code ?

i am sure @arendst is reading this. he may consider to change this line

arendst · 2019-04-18T06:56:42Z

Will chk a d do.

Change disable interrupts during SerialSend from 9600 bps and up (#5528)

arendst · 2019-04-18T08:23:06Z

Upgrade TasmotaSerial library from 2.3.0 to 2.3.1

wongnam · 2019-04-18T10:13:03Z

Thanks @arendst I always got error message when compile it.

Compiling .pioenvs\sonoff\src\sonoff.ino.cpp.o
Linking .pioenvs\sonoff\firmware.elf
.pioenvs\sonoff\src\sonoff.ino.cpp.o:(.text._Z18Ade7953EverySecondv+0x4): undefined reference to `AdcTemperature()'
.pioenvs\sonoff\src\sonoff.ino.cpp.o:(.text._Z18Ade7953EverySecondv+0x15): undefined reference to `AdcTemperature()'
collect2.exe: error: ld returned 1 exit status
*** [.pioenvs\sonoff\firmware.elf] Error 1

Jason2866 · 2019-04-18T10:20:39Z

@wongnam It is your setup latest dev version compiles fine with #define USE_MP3_PLAYER

Have you replaced new version of lib Tasmota Serial?

arendst · 2019-04-18T12:14:32Z

Compile error is my fault and has to do with Sehlly 2.5. Fixed in latest commit.

6.5.0.9 20190418 * Add command SetOption63 0/1 to disable relay state feedback scan at restart (#5594, #5663) * Fix TasmotaSerial at 9600 bps solving DFPlayer comms (#5528) * Fix Shelly 2.5 overtemp

wongnam · 2019-04-18T15:42:27Z

@arendst It's working fine now. Thanks.
Hi Guys, Thank you very much for your advice and solutions.

wongnam changed the title ~~DF Player Mini only work~~ DF Player Mini only work about 80% of the time Mar 26, 2019

wongnam changed the title ~~DF Player Mini only work about 80% of the time~~ DFPlayer Mini is slow(lag) and unresponsive. (workaround) Apr 17, 2019

ascillato2 added the bug Type - Confirmated Bug label Apr 18, 2019

arendst self-assigned this Apr 18, 2019

arendst added a commit that referenced this issue Apr 18, 2019

Change disable interrupts during SerialSend from 9600 bps and up (#5528)

a03c1c9

Change disable interrupts during SerialSend from 9600 bps and up (#5528)

arendst added the fixed Result - The work on the issue has ended label Apr 18, 2019

arendst removed their assignment Apr 18, 2019

wongnam closed this as completed Apr 18, 2019

Staars mentioned this issue Sep 25, 2019

experimental bidirectional MP3-driver with Web-GUI arendst/Tasmota-Playground#1

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DFPlayer Mini is slow(lag) and unresponsive. (workaround) #5528

DFPlayer Mini is slow(lag) and unresponsive. (workaround) #5528

wongnam commented Mar 26, 2019

Jason2866 commented Mar 26, 2019

wongnam commented Mar 26, 2019 •

edited

Loading

wongnam commented Mar 29, 2019 •

edited

Loading

gemu2015 commented Mar 30, 2019

Staars commented Apr 13, 2019

Staars commented Apr 15, 2019

gemu2015 commented Apr 15, 2019

Staars commented Apr 15, 2019

wongnam commented Apr 16, 2019

gemu2015 commented Apr 16, 2019

wongnam commented Apr 16, 2019 •

edited

Loading

Staars commented Apr 16, 2019

Jason2866 commented Apr 16, 2019

wongnam commented Apr 17, 2019 •

edited

Loading

gemu2015 commented Apr 18, 2019

arendst commented Apr 18, 2019

arendst commented Apr 18, 2019

wongnam commented Apr 18, 2019

Jason2866 commented Apr 18, 2019 •

edited

Loading

arendst commented Apr 18, 2019

wongnam commented Apr 18, 2019

DFPlayer Mini is slow(lag) and unresponsive. (workaround) #5528

DFPlayer Mini is slow(lag) and unresponsive. (workaround) #5528

Comments

wongnam commented Mar 26, 2019

BUG DESCRIPTION

REQUESTED INFORMATION

TO REPRODUCE

EXPECTED BEHAVIOUR

SCREENSHOTS

Jason2866 commented Mar 26, 2019

wongnam commented Mar 26, 2019 • edited Loading

wongnam commented Mar 29, 2019 • edited Loading

gemu2015 commented Mar 30, 2019

Staars commented Apr 13, 2019

Staars commented Apr 15, 2019

gemu2015 commented Apr 15, 2019

Staars commented Apr 15, 2019

wongnam commented Apr 16, 2019

gemu2015 commented Apr 16, 2019

wongnam commented Apr 16, 2019 • edited Loading

Staars commented Apr 16, 2019

Jason2866 commented Apr 16, 2019

wongnam commented Apr 17, 2019 • edited Loading

gemu2015 commented Apr 18, 2019

arendst commented Apr 18, 2019

arendst commented Apr 18, 2019

wongnam commented Apr 18, 2019

Jason2866 commented Apr 18, 2019 • edited Loading

arendst commented Apr 18, 2019

wongnam commented Apr 18, 2019

wongnam commented Mar 26, 2019 •

edited

Loading

wongnam commented Mar 29, 2019 •

edited

Loading

wongnam commented Apr 16, 2019 •

edited

Loading

wongnam commented Apr 17, 2019 •

edited

Loading

Jason2866 commented Apr 18, 2019 •

edited

Loading