Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ESP8266 MQTT disconnecting #4996

Closed
DittelHome opened this issue Mar 1, 2024 · 44 comments · Fixed by #5004 or #5014
Closed

ESP8266 MQTT disconnecting #4996

DittelHome opened this issue Mar 1, 2024 · 44 comments · Fixed by #5004 or #5014

Comments

@DittelHome
Copy link

Hi Experts,
i migrated from ESP_Easy_mega_20231013_normal_ESP8266_4M1M to ESP_Easy_mega_20240229_normal_ESP8266_4M1M.
Now i get at least every three minutes this message in the broker log:

2024-02-29 22:03:21: Client Wohnzimmer_LCD has exceeded timeout, disconnecting.
2024-02-29 22:03:22: New connection from 192.168.1.24:51630 on port 1883.
2024-02-29 22:03:22: New client connected from 192.168.1.24:51630 as Wohnzimmer_LCD (p2, c1, k10).
2024-02-29 22:06:34: Client Wohnzimmer_LCD has exceeded timeout, disconnecting.
2024-02-29 22:07:05: New connection from 192.168.1.24:53168 on port 1883.
2024-02-29 22:07:05: New client connected from 192.168.1.24:53168 as Wohnzimmer_LCD (p2, c1, k10).
2024-02-29 22:08:14: New connection from 192.168.1.14:55943 on port 1883.

The wifi connection is stable, 58 dBm.
Max WiFi TX Power: 17 db
WiFi Sensitivity Margin: 3db
802.11g is enabled (Force B/G on the tools->Advanced page)
ECO mode is disabled
Minimum Send Interval 100ms on MQTT settings
Client Timeout: 1000ms on MQTT settings
Home Assistant (openHAB) MQTT
Broker is Raspberry mosquitto version 2.0.11
MQTT broker is selected via IP 192.168.1.100

regards Klaus
@TD-er
Copy link
Member

TD-er commented Mar 1, 2024

What kind of plugins are you using?
Can you one by one try to disable a task to see if it makes any difference?

@DittelHome
Copy link
Author

DittelHome commented Mar 1, 2024 •
edited
Loading

I use this plugins:

  1. Display - LCD2004
  2. Generic - MQTT Import
  3. Environment - DHT11/12/22 SONOFF2301/7021/MS01
  4. Analog input - internal
  5. Generic - MQTT Import (twice)
  6. Gases - CO2 Senseair

RuleSet1:

on System#Boot do
 timerSet,1,1           // Init Display after 1 Seconds
 lcdcmd,off 
 pwm,5,20
endon

on Rules#Timer=1 do     // Wait until MQTT is connected
 lcdcmd,on              // Start if message MQQT connect apears
 lcd,1,1,Waiting... 
 lcd,2,1,Waiting...
endon

on MQTT#Connected do     // Start Display wrap around 
  timerSet,2,3
  rtttl,4:d=10,o=6,b=180,c,e,g,c,e,g
endon

on MQTT#Disconnected do  // Reset Display when ESP are disconnected ..
 timerSet,2,0
 timerSet,3,0
 timerSet,4,0
 timerSet,5,0
 timerSet,6,0
 lcd,1,1,'MQTT disconnect!'
 lcd,2,1,'be cool ..   '
 notify 1
endon

on Rules#Timer=2  do
 lcd,1,1,'Wind [MQTT_IMPORT1#ws] km/h     x' 
 lcd,2,1,'%sysweekday_s% %sysday%-%sysmonth%-%sysyear%     x'
 timerSet,3,3
endon

on Rules#Timer=3  do
 lcd,1,1,'Out T:[MQTT_IMPORT1#out_temp] H:[MQTT_IMPORT1#out_hum]   x'
 lcd,2,1,'In  T:[T&H#in_temp] H:[T&H#in_hum#D2.0]    x'
 timerSet,4,3
endon

on Rules#Timer=4  do
 lcd,1,1,'Rain [MQTT_IMPORT1#Raintoday] l/qm   x '  
// lcd,2,1,'WiFi %rssi%  dBm     x'
 lcd,2,1,'CO2  [CO2#CO2] ppm          x'
 timerSet,5,3
endon

on Rules#Timer=5  do
 lcd,1,1,'APS-A [MQTT_IMPORT2#Pressure] hPA      x'
 lcd,2,1,'Time  %systime%     x'
  timerSet,6,3
endon

on Rules#Timer=6  do
   if [MQTT_IMPORT2#Tendency] > 0
    lcd,1,1,'APS-T +[MQTT_IMPORT2#Tendency] (3h)    x'
  else
    lcd,1,1,'APS-T [MQTT_IMPORT2#Tendency] (3h)    x'
  endif
  lcd,2,1,'SR %sunrise% SS %sunset% '
  timerSet,2,3
endon

//
// CO2 Steuerung:
//
on CO2#co2 do 
 if %eventvalue% > 2000 
      tone,4,2100,10000
 endif
 if %eventvalue% > 1500 and %eventvalue%< 2000
      tone,4,2100,5000
 endif
endon

RuleSet2:

on LDR#Light do
 if  %eventvalue% >0   and   %eventvalue% <=20
  pwm,5,1,3000
 elseif  %eventvalue% >20   and   %eventvalue% <=100
  pwm,5,5,3000
 elseif %eventvalue% >100 and   %eventvalue% <=550
  pwm,5,10,3000
 elseif  %eventvalue% >550 and   %eventvalue% <=650
  pwm,5,20,3000
 elseif  %eventvalue% >650 and   %eventvalue% <=750
  pwm,5,40,3000
 elseif  %eventvalue% >750 and   %eventvalue% <=900
  pwm,5,50,3000
 elseif  %eventvalue% >900 and   %eventvalue% <1010
  pwm,5,100,3000
 elseif  %eventvalue% >=1010
  pwm,5,800,3000
 endif
endon

on Clock#Time=All,**:00 do   //**:** ==> jede Minute  **:00 ==> jede Stunde
  If %systime% > 05:00:00 and %systime% < 23:00:00
    rtttl,4:d=3000,o=8,b=12,a,,a
    //rtttl,4:d=4,o=5,b=100:16e6,16e6
  endif
endon

I will try do disable Plugins, but if i disable for example Analog input my RuleSet2 doenst work anymore ..
I report after testing ..

@hoorna
Copy link

hoorna commented Mar 1, 2024 •
edited
Loading

I also updated (this morning) with ESP_Easy_mega_20240229_normal_ESP8266_4M1M. I do not know if it is related (it looks like) but since the update my DSMR docker does not get readings anymore from ESP8266. I use ESP8266 for reading my P1 "Slimme meter". ESP Easy gives only the following log messages:

11122155: Ser2Net: Client connected!
11123839: Ser2Net: Client disconnected!
11134805: WD : Uptime 186 ConnectFailures 0 FreeMem 19672 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
11164805: WD : Uptime 186 ConnectFailures 0 FreeMem 19648 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
11184135: Ser2Net: Client connected!
11185823: Ser2Net: Client disconnected!
11194806: WD : Uptime 187 ConnectFailures 0 FreeMem 19672 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
11201247: Command unknown: 1-0:21.7.0(00.1-0:32.7.0(238.5!(1-0:32.32.0(00011-0:1.7.0(00.7221-0:99.97.0(2)(0<

The connection between the ESP8266 and the DSMR docker instance worked for years. My latest working update was from 23-12-2023.

I reverted back now to the 23-12-2023 version and everyting is working again.

What can be wrong? Do I have to open a new issue?

@tonhuisman
Copy link
Contributor

my DSMR docker does not get readings anymore from ESP8266.

Can you change the RX Receive Timeout to 10 mSec, that should fix it, assuming that it's now at 0.

@hoorna
Copy link

hoorna commented Mar 1, 2024 •
edited
Loading

@tonhuisman, thanks for your reply!

Can you change the RX Receive Timeout to 10 mSec, that should fix it, assuming that it's now at 0.<

That did the trick! (RX Receive Timeout was indeed declared at 0). DSMR is now receiving meter readings again. You are incredible. Thanks!

ESP Easy gives now (with the 29-02-2024 update) the following log messages. A message with "Command unkwon" appears regularly. Do you know if this is a problem and do you know what it means?

190150: Ser2Net: Client connected!
191825: Ser2Net: Client disconnected!
194644: WD : Uptime 3 ConnectFailures 0 FreeMem 18384 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
224766: WD : Uptime 4 ConnectFailures 0 FreeMem 18360 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
243389: Command unknown: 0-0:96.7.9(00001.7.0(011A)
252185: Ser2Net: Client connected!
253866: Ser2Net: Client disconnected!
254736: WD : Uptime 4 ConnectFailures 0 FreeMem 18360 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
284644: WD : Uptime 5 ConnectFailures 0 FreeMem 18360 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
287385: Command unknown: (200515112714S)(11A)
314224: Ser2Net: Client connected!
314644: WD : Uptime 5 ConnectFailures 0 FreeMem 18192 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
315890: Ser2Net: Client disconnected!
344644: WD : Uptime 6 ConnectFailures 0 FreeMem 19808 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
374644: WD : Uptime 6 ConnectFailures 0 FreeMem 19808 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
376250: Ser2Net: Client connected!
377927: Ser2Net: Client disconnected!
392376: Command unknown: 11A)
404644: WD : Uptime 7 ConnectFailures 0 FreeMem 19784 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
415355: Command unknown: )
434644: WD : Uptime 7 ConnectFailures 0 FreeMem 19784 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
438295: Ser2Net: Client connected!
438310: Command unknown: (
439671: Ser2Net: Client disconnected!
464644: WD : Uptime 8 ConnectFailures 0 FreeMem 19808 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
494644: WD : Uptime 8 ConnectFailures 0 FreeMem 19808 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
500003: Ser2Net: Client connected!
500681: Ser2Net: Client disconnected!
524644: WD : Uptime 9 ConnectFailures 0 FreeMem 19808 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
554644: WD : Uptime 9 ConnectFailures 0 FreeMem 19808 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
558519: Command unknown: (1)
561032: Ser2Net: Client connected!
561791: Ser2Net: Client disconnected!
584644: WD : Uptime 10 ConnectFailures 0 FreeMem 19808 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
614644: WD : Uptime 10 ConnectFailures 0 FreeMem 19808 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
622077: Ser2Net: Client connected!
622744: Ser2Net: Client disconnected!
625196: Command unknown: !((0002)
636207: Command unknown: 1-0:32.7.0(235.2668kW)
644644: WD : Uptime 11 ConnectFailures 0 FreeMem 19808 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
674644: WD : Uptime 11 ConnectFailures 0 FreeMem 19808 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
683107: Ser2Net: Client connected!
683776: Ser2Net: Client disconnected!
704644: WD : Uptime 12 ConnectFailures 0 FreeMem 19808 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
734644: WD : Uptime 12 ConnectFailures 0 FreeMem 19808 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
744138: Ser2Net: Client connected!
745810: Ser2Net: Client disconnected!<

@tonhuisman
Copy link
Contributor

the following log messages. A message with "Command unkwon" appears regularly. Do you know if this is a problem and do you know what it means?

This will happen when having the Serial log enabled on the Tools Advanced page, while also using the same Serial0 port for receiving the P1 meter data (the 'unknown command' looks exactly like the data that's to be received from the meter 😉)
Either use another serial port for your P1 input (that's quite hard on an ESP8266, as you shouldn't use SoftwareSerial at 115200 baud), or disable the Serial log on the Tools/Advanced page.
You can still view the logging via Tools/Log, assuming you didn't disable the Web log on the Tools/Advanced page (by default it's enabled).

@hoorna
Copy link

hoorna commented Mar 1, 2024 •
edited
Loading

Thanks for the clarification. With

or disable the Serial log on the ToolsAdvanced page <

the 'problem' is solved!

@DittelHome
Copy link
Author

Ok, i have tested...
I installed again the version from 29.02 as yesterday and all is fine, until i switch my TV on.
It seems that the new version is extremely prone to wifi failure...

@DittelHome
Copy link
Author

Further Test's:

TV OFF - Leap Version

ping 192.168.1.24 -n 30

Ping wird ausgeführt für 192.168.1.24 mit 32 Bytes Daten:
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=9ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=15ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=89ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=18ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=14ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=38ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=25ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=11ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=30ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=48ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=62ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=53ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=57ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=74ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=19ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=78ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=26ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=18ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=7ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=18ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=22ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=41ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=63ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=38ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=17ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=23ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=80ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=31ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=12ms TTL=255

Ping-Statistik für 192.168.1.24:
    Pakete: Gesendet = 30, Empfangen = 30, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 4ms, Maximum = 89ms, Mittelwert = 34ms

TV ON - Leap Version

ping 192.168.1.24 -n 30

Ping wird ausgeführt für 192.168.1.24 mit 32 Bytes Daten:
Antwort von 192.168.1.24: Bytes=32 Zeit=33ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=277ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=7ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=23ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=100ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=73ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=65ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=10ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=88ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=16ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.1.24: Bytes=32 Zeit=32ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=14ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=37ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=355ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=16ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=20ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=250ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.1.24: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=197ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=8ms TTL=255

Ping-Statistik für 192.168.1.24:
    Pakete: Gesendet = 30, Empfangen = 26, Verloren = 4
    (13% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 3ms, Maximum = 355ms, Mittelwert = 63ms

TV OFF - Version from 13.10.2023

ping 192.168.1.24 -n 30

Ping wird ausgeführt für 192.168.1.24 mit 32 Bytes Daten:
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=36ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=22ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=7ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=7ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=9ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=9ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=7ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=57ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=7ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=11ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255

Ping-Statistik für 192.168.1.24:
    Pakete: Gesendet = 30, Empfangen = 30, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 3ms, Maximum = 57ms, Mittelwert = 8ms

TV ON - Version from 13.10.2023

ping 192.168.1.24 -n 30

Ping wird ausgeführt für 192.168.1.24 mit 32 Bytes Daten:
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=7ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=8ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=11ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=13ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=10ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=13ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=10ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=7ms TTL=255

Ping-Statistik für 192.168.1.24:
    Pakete: Gesendet = 30, Empfangen = 30, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 3ms, Maximum = 13ms, Mittelwert = 6ms

Fact is that the leap version has a very weak and susceptible WLAN

@tonhuisman
Copy link
Contributor

It seems like your TV has an unused but enabled WiFi interface that's spamming the 2.4 MHz frequency band, causing ESPEasy to try and respond to all it's invalid signals 🤔

@DittelHome
Copy link
Author

100% agree
But ESP_Easy_mega_20231013_normal_ESP8266_4M1M ist working and
ESP_Easy_mega_20240229_normal_ESP8266_4M1M not.
For the moment, i am back to 20231013 ..

@tonhuisman
Copy link
Contributor

There is also the Christmas release, 20231225, have you tried/tested that release, and what results do you get with that?

@tonhuisman
Copy link
Contributor

And what's the distance between the ESP and the TV?

@DittelHome
Copy link
Author

The distance to the TV is round about 6 meters.

The problem already exits wirh the Christmas release, 20231225. (see ping report)
The last working release is mega_20231013.

ping 192.168.1.24 -n 30

Ping wird ausgeführt für 192.168.1.24 mit 32 Bytes Daten:
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=207ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=169ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=2ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=122ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=107ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 192.168.1.24: Bytes=32 Zeit=156ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=75ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=3ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=55ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=134ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=12ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=119ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=62ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=66ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=4ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=5ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=69ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=7ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=28ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=76ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=51ms TTL=255
Antwort von 192.168.1.24: Bytes=32 Zeit=106ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 192.168.1.24:
    Pakete: Gesendet = 30, Empfangen = 27, Verloren = 3
    (10% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 2ms, Maximum = 207ms, Mittelwert = 61ms

@TD-er
Copy link
Member

TD-er commented Mar 2, 2024

Can you check the sysinfo page to see which SDK is used?
It is possible the SDK version has been changed for other ESP8266 builds to either SDK3.1.2 or maybe while testing with 2nd heap support I have switched to another WiFi binary and didn't revert?
You can also try to flash one marked explicitly with "274" in the name to see if it makes a difference.

@DittelHome
Copy link
Author

29.02. - ESP82xx Core 2843a5ac, NONOS SDK 2.2.2-dev(38a443e), LWIP: 2.1.2 PUYA support
13.10. - ESP82xx Core 2843a5ac, NONOS SDK 2.2.2-dev(38a443e), LWIP: 2.1.2 PUYA support

@TD-er
Copy link
Member

TD-er commented Mar 2, 2024

OK, that doesn't look different.

Maybe also test with "Force b/g" mode enabled?
And ECO mode disabled (if it was enabled)

@DittelHome
Copy link
Author

Both are :
802.11g is enabled (Force B/G on the tools->Advanced page)
ECO mode is disabled

@laserrichi
Copy link

laserrichi commented Mar 3, 2024 •
edited
Loading

I also have problems with the latest versions.
I have 3x esp8266, 2 of which are further away with -74db and they both use serial servers through which modbus is run. And both also have pulse counters.
It is sent to fhem controller.

Version 20230409 ran for over 300 days without disconnecting. From the December version I have wifi disconnects.
Fhem sporadically receives erroneous messages
ESPEasy__value_100...

I have set Force WiFi No Sleep. Force WiFi B/G had no effect whether with or without. Also Extra Wifi wait and Enable SDK WiFi Auto Reconnect.

What I tested is from which version the problems occurred. Version 23_10_2023 works. November I'm not quite sure, I'm currently testing it. December and February fail.

I had the problem with an ESP that with the February version it no longer connected to the WiFi even after multiple reboots, and the local access point was also not visible.

@TD-er
Copy link
Member

TD-er commented Mar 9, 2024

I have tried for the last few days to reproduce this issue on several ESP8266 boards.
I also got a very similar report from another user via email, so I do believe there really is some issue here but I really can't reproduce it.

So I would like to have a bit more information on the specifics how this may occur.

Things I do know from the user via email:

  • Uses quite expensive access points -> May do things like band steering or other WiFi mesh related issues
  • WiFi reception is sub-optimal (RSSI less than -70)
  • Uses static IP.

Those issues caused by the more expensive access points can all be mitigated by forcing 802.11b/g mode. (Tools->Advanced page "Force WiFi B/G:")

The low RSSI can cause issues with the automatic TX power, but this can be avoided by checking the checkbox (Tools->Advanced page) "Send With Max TX Power:"

In short, when using the settings as shown in this screenshot, it should work fine:
image

Only thing can be that on some ESP boards, especially with really poorly tuned antennas, you may get better results when you reduce the Max TX power.
But this really depends on very specific use cases as it also may cause the ESP to be no longer heard by the access point.

Using static IP has always been a bit tricky, but I know Ton is using static IP all the time.
One of the reasons why it may be tricky is when multiple devices use the same IP, you can get all kinds of odd issues.

@TD-er
Copy link
Member

TD-er commented Mar 9, 2024

I also have problems with the latest versions. I have 3x esp8266, 2 of which are further away with -74db and they both use serial servers through which modbus is run. And both also have pulse counters. It is sent to fhem controller.

Version 20230409 ran for over 300 days without disconnecting. From the December version I have wifi disconnects. Fhem sporadically receives erroneous messages ESPEasy__value_100...

I have set Force WiFi No Sleep. Force WiFi B/G had no effect whether with or without. Also Extra Wifi wait and Enable SDK WiFi Auto Reconnect.

What I tested is from which version the problems occurred. Version 23_10_2023 works. November I'm not quite sure, I'm currently testing it. December and February fail.

I had the problem with an ESP that with the February version it no longer connected to the WiFi even after multiple reboots, and the local access point was also not visible.

Do you use software serial for those plugins requiring serial?
Which "modbus" plugins do you use?

@TD-er
Copy link
Member

TD-er commented Mar 9, 2024

I may have found a possible issue where on ESP8266 the capability flags were not initialized on SDK2.7.4 builds.
See: #5004

@TD-er TD-er mentioned this issue Mar 9, 2024
Merged
@DittelHome
Copy link
Author

DittelHome commented Mar 9, 2024 •
edited
Loading

I am ready for test's ..
Here on my side, i can reproduce the situation .. (TV)

@TD-er
Copy link
Member

TD-er commented Mar 9, 2024

Have you tried this test build?

@DittelHome
Copy link
Author

OK, i have checked the test build, and i dont have any disconnects so far .... !!
Same behavior as with version from 20231013.
Ping test with TV are also succesfull !!

@DittelHome
Copy link
Author

OK Uptime: 01h01m => no disconnect (with TV)

@TD-er
Copy link
Member

TD-er commented Mar 9, 2024

OK, now I'm really curious to what special settings (and what model/brand) you have on your access point.
Which exact build do you use? (binary file)

@DittelHome
Copy link
Author

DittelHome commented Mar 10, 2024 •
edited
Loading

OK, i have a TP-Link Archer C7 V2 Router, configured as repeater with OpenWrt (actuell version)..
Look here: doku
I use ESP_Easy_mega_20240309_normal_ESP8266_4M1M.bin actuell. (Your test build)

@TD-er
Copy link
Member

TD-er commented Mar 10, 2024

And do you have anything special set, like "N-only" or something else?
Do you use static IP or DHCP? (for the ESP)
Do you use a fixed WiFi channel or is it dynamic?

@DittelHome
Copy link
Author

And do you have anything special set, like "N-only" or something else?

  • YES N is set, but legacy 802.11b rates are also allowed
    (Openwrt recommandation: Legacy or badly behaving devices may require legacy 802.11b rates to interoperate. Airtime efficiency may be significantly reduced where these are used. It is recommended to not allow 802.11b rates where possible.)
  • Maximum Transmit power is slightly increased ;)
  • Right now 7 devices connected/activ with the AP

Do you use static IP or DHCP? (for the ESP)

  • I use static IP for all my ESP's

Do you use a fixed WiFi channel or is it dynamic?

  • Channel of AP is fixed

@TD-er
Copy link
Member

TD-er commented Mar 10, 2024

I don't know if this "Mode" option (where also the "Allow legacy 802.11b rates" checkbox is shown according to the screenshots) also has options for "G+N" or something similar?
The reason I'm looking into this is that the changes I made in the build you tested is about picking G/N mode and retrying in the other mode if one failed.

@TD-er
Copy link
Member

TD-er commented Mar 10, 2024

By the way, increasing TX power on the access point rarely (if ever) improves reliability of the WiFi connection.
It may increase TX range, but it doesn't make the RX on the AP more sensitive (quite te opposite) so a device may 'see' the AP, but when it tries to connect, it cannot be heard by the AP.
If you increase the TX power of the AP, you should have the checkbox in ESPEasy checked for always sending with max. TX power as the TX power limiting algorithm in ESPEasy will not taking into account any out-of-spec TX power of the AP.
Or you can increase the "WiFi Sensitivity Margin" with the same number of dB's as you've added to the TX power of the AP. (e.g. if you're allowed to run at 14 dBm, but set it to 20, you should add 6 dBm to the "WiFi Sensitivity Margin")

Another reason why increasing TX power of the AP rarely is beneficial is that it only improves RSSI on the receiver end but also decreases the SNR as it adds distortion to the signal and probably makes reflected signals stronger.

Also the RX sensitivity of the radio in the AP may actually decrease.

Since you effectively require all other devices to send at higher TX power, you may also see that some devices (typically cheap ESP boards with badly tuned antennas) operate less reliable at higher TX power due to RF signals being fed back into the ESP and power supply of the ESP board not able to keep up with the power demands.

@DittelHome
Copy link
Author

Thanks for the TX/RX Power dependencies explanation .

OK, i reduced Power to again 100 mw ..., test is ongoing ..
Take a look on the screenshot for the iee802.11b setting..

grafik

@TD-er
Copy link
Member

TD-er commented Mar 10, 2024

What options are available for the "Mode"? Now it only shows "N", but what are the other options?

@DittelHome
Copy link
Author

grafik

@TD-er
Copy link
Member

TD-er commented Mar 10, 2024

I don't think the "Allow legacy 802.11b rates" checkbox will make any difference if it is using N-only
Can you take a screenshot of the selection combo-box unfolded?

@DittelHome
Copy link
Author

grafik

@DittelHome
Copy link
Author

The ESP says: WiFi Connection: | 802.11g (RSSI -62 dBm) and Force WiFi B/G: is set.
It seems it works ..

@TD-er
Copy link
Member

TD-er commented Mar 10, 2024

I am glad it is working, but to be honest I am not 100% sure why as the fix I did shouldn't have made any difference.
I did look a bit more at the code and the bits I now explicitly set to false should have been set to false already.

I have to look into this a bit more to be sure.
For those reading along with the same or similar issues, I uploaded the test build to the "latest" web flasher page

@DittelHome
Copy link
Author

Just for clarification, with the leap build a get disconnects, no matter which settings ..
With the test build (20230309) and the build from 20231013 all is fine (again).

@sincze sincze mentioned this issue Mar 15, 2024
Open
@dareksin78
Copy link

dareksin78 commented Mar 26, 2024 •
edited
Loading

ESP_Easy_mega_20231225_normal_ESP8266_4M1M
I have the same problem.
I was looking for 2 days... and I think I found the solution, or so I think.

If I set value corrections here, there is a problem with mqtt!!!

image

Mqtt works fine if I don't set any rules.

Back to ESP_Easy_mega 20231225_normal_ESP8266_4M1M
does not help.

It's ok here: ESP_Easy_mega_20231130_normal_ESP8266_4M1M.

Please check and let me know if this is the reason for you.

@dareksin78 dareksin78 mentioned this issue Mar 26, 2024
Closed
@TD-er
Copy link
Member

TD-er commented Mar 26, 2024

Hmm that's interesting.
I will have a look to see if this can be the result of recent changes and of course how to fix it.

@TD-er TD-er reopened this Mar 26, 2024
@sincze
Copy link

sincze commented Mar 26, 2024

Hmm that's interesting. I will have a look to see if this can be the result of recent changes and of course how to fix it.

if you need some additional testers I might be able to help here.

@TD-er TD-er mentioned this issue Mar 28, 2024
Merged
@TD-er
Copy link
Member

TD-er commented Mar 28, 2024

I uploaded the build which should fix this to the webflasher
Would be great if it could be tested by anyone who experienced this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
7 participants
@tonhuisman @TD-er @sincze @hoorna @DittelHome @dareksin78 @laserrichi