Espeasy: [BUG] [WiFi 안정성] 레이어 2 연결 해제시 ESP 예외 3/29

같은 문제가있는 것 같습니다. 때때로 내 esp가 Wi-Fi 연결을 끊고 몇 시간 동안 Wi-Fi에서 "손실"된 상태를 유지합니다. 워치 독 덕분에 재부팅하고 Wi-Fi에 다시 연결해야하지만 그렇지 않습니다. 콜드 부팅이 문제를 해결합니다.

@wolverinevn 이 마지막으로 설명하는 것은

# 1957에서 논의했듯이 이러한 이상한 WiFi / 네트워킹 문제는이 레이어 2 불안정성에서 비롯된 것입니다. AP를 일부 증가 된 타이밍으로 변경하기 전에 모든 종류의 이상한 동작을 보았습니다 ...

# 1957에서 논의했듯이 이러한 이상한 WiFi / 네트워킹 문제는이 레이어 2 불안정성에서 비롯된 것입니다. AP를 일부 증가 된 타이밍으로 변경하기 전에 모든 종류의 이상한 동작을 보았습니다 ...

해결책을 찾을 수 있기를 바랍니다. 내 Nodemcu 중 하나가 이유없이 5 시간 동안 라우터에서 중단되고 사라졌습니다. 워치 독에서 회복 될 수 있기를 바라지 만 아무 일도 일어나지 않습니다. 지금 수동으로 재부팅해야합니다. 매우 짜증이났습니다!

@wolverinevn 노드에 다시 액세스 할 수

다른 해결 방법은 실제로 조정할 수있는 AP 유형에 따라 액세스 포인트에서 일부 매개 변수를 조정할 수있는 경우입니다.

@ clumsy-stefan ESPeasy의 기본값도이 수준으로 설정해야합니까?

그리고이 값을 sysinfo 페이지에 표시하고 규칙에 사용할 수 있도록해야합니까?

@ TD-er는 기본적으로 일정 수준으로 설정하는 것이 너무 낮지 않으면 나쁘지 않을 것입니다 (연결이 실패하면 항상 발생할 수 있습니다).

문제를 디버깅 할 때 이것이 어떻게 수행되는지 생각할 때 현재 모든 실패한 연결은 카운터를 증가시키고 성공한 연결은 카운터를 감소시킵니다. 성공적으로 연결 되 자마자 0으로 재설정하는 것이 더 논리적 일까 생각했지만, 그것이 더 의미있는 것이 조금 이데올로기적인 질문이라고 생각합니다.

이 숫자의 문제는 10 개의 작업이 있고 각각의 작업이 재시도 횟수가 10이고 재전송 지연이 100ms 인 경우 실제 통신 문제가있는 경우 재부팅이 매우 빠르게 발생한다는 것입니다 (약 10 초 내에 100 번의 재시도). .

예를 들어 항상 5 개의 통신이 실패하고 1 개의 성공이있는 경우 연결 실패가 계속 증가합니다. 이 문제가 항상 발생하면 모든 데이터를 전달할 수 있어도 조만간 노드를 재부팅합니다.

내가보고있는 주요 문제는 어떻게 든 노드가 레이어 2의 연결이 실제로 사라지고 데이터를 계속 전송한다는 것을 인식하지 못한다는 것입니다. 오늘 밤 내가 깨달은 것 외에 와이파이 연결이 없으면 syslog (및 NTP와 같은 다른 통신)는 어떻게됩니까? 이것도 중지됩니까? 이것은 레이어 2가 사라질 때 내 노드가 갑자기 100 % cpu로 점프하는 이유를 설명 할 수 있습니다. 더 이상 작업 데이터가 전송되지 않지만 UDP syslog 패킷을 제거하려고 시도하지만 추측 할 수는 없습니다.

두 가지 간단한 질문에 대한 미안합니다.
기본 수준 : 예, 기본적으로 최대 (100)로 설정합니다 ... 모든 것이 정상이면 문제가되지 않으면 장치에 다시 액세스 할 수 있습니다 ...
sysinfo 페이지 및 규칙 : 아니요, 이것이 동적으로 변경되어야하는 이유는 무엇입니까? 그것은 긴급 가치입니다 ...

@ clumsy-stefan 이미 50으로 설정했습니다. 기다려 보겠습니다. ;)

@wolverinevn hmm ... 50 회는 작업 간격과 재시도 횟수 (5-15 분)에 따라 매우 빠르게 발생해야합니다 ...이게 도움이되지 않으면 노드가 실제로 고정되지 않은 것 같지만 가능합니다. t 네트워크에 다시 연결하십시오. WD 재부팅 후에도이 문제가 발생했습니다. 노드가 AP 모드로 전환을 시도하는지 확인할 수 있습니까? 노드의 AP-WLAN이 보이십니까?

sysinfo 페이지 및 규칙 : 아니요, 이것이 동적으로 변경되어야하는 이유는 무엇입니까? 그것은 긴급 가치입니다 ...

%conn_fail% 와 같은 시스템 변수를 사용하여 규칙을 검사하고 Wi-Fi 재 연결 횟수 옆의 sysinfo 페이지에 표시해야했습니다.
역시 성능 통계치

% conn_fail %과 같은 시스템 변수를 사용하여 규칙을 검사하고 Wi-Fi 재 연결 횟수 옆의 sysinfo 페이지에 표시해야했습니다. 역시 성능 통계치

아, 예, 동의합니다. 그것은 또한 이슈 # 1993과 약간 관련이 있습니다. 제한된 사용 가능한 작업을 낭비하지 않고 정기적으로 컨트롤러에 여러 시스템 / 성능 변수를 보내는 플러그인이 있으면 정말 좋습니다!

@wolverinevn hmm ... 50 회는 작업 간격과 재시도 횟수 (5-15 분)에 따라 매우 빠르게 발생해야합니다 ...이게 도움이되지 않으면 노드가 실제로 고정되지 않은 것 같지만 가능합니다. t 네트워크에 다시 연결하십시오. WD 재부팅 후에도이 문제가 발생했습니다. 노드가 AP 모드로 전환을 시도하는지 확인할 수 있습니까? 노드의 AP-WLAN이 보이십니까?

나는 9 개의 작업을 가지고 있으며 그중 3 개는 Dummy와 MQTT_import입니다. 규칙이 센서를 계산하고 읽는 데 약간 바쁘다고 생각합니다. 몇 분마다 규칙을 호출하여 mqtt_publish를 제한하려고했습니다. 부하는 약 29 %입니다.
제가 기억하는 것처럼 오늘 아침 마지막으로 동결되었을 때 Espeasy의 AP를 찾을 수 없습니다 (AP_WLAN이 AP 모드로 작동하고 있다는 뜻이라면).
내 설정 (네트워크, ESP의 위치)은 3 월에 출시 된 2.3 또는 2.4를 실행하는 다른 Nodemcu와 잘 작동했습니다.

_ 가동 시간은 7 시간 20 분이고 RSSI는 -71dbm이며 주변에 Wi-Fi가 몇 개 있습니다.
마지막 연결 해제 이유 : | (200) 비콘 시간 초과
번호 재 연결 : | 35_

@wolverinevn 이 문제의 문제는 완전히 무작위로 발생한다는 것입니다. 나는 ~ 30 개의 노드를 실행 중이며, 일부는 문제에 직면했고 일부는 재부팅되지 않았고 일부는 AP 모드로 전환되지 않았습니다.

노드가 얼마나 바쁜지, 공기가 얼마나 바쁜지 (예 : wifi 장치의 numebr), AP가 특정 조건을 어떻게 처리하는지 (missnig layer 2 acks 등) ...

따라서 응용 프로그램 (ESPEasy) 내에서이 조건을 안정적으로 감지하고 조치를 취할 수있는 방법을 찾을 때까지 "실제"솔루션은 없습니다 ....

@wolverinevn 추신 : 우연히 mikrotik AP를 사용하지 않습니까?

@wolverinevn 재 연결 횟수 정보 (편집 중)
약 8 시간에 35 번의 재접속은 많은 것입니다.
여기에 몇 번의 재 연결 만있는 노드가 있습니다.
가장 안정적인 것은 현재 20 일 11 시간 46 분 동안 실행되고 1 회만 다시 연결됩니다.

연결됨 | 19 일 22 시간 33 분
-| -
마지막 연결 해제 이유 | (202) 인증 실패
번호 재 연결 | 1

@wolverinevn 추신 : 우연히 mikrotik AP를 사용하지 않습니까?

아니요. Padavan 펌웨어 (ASUS 종류)를 실행하는 라우터를 사용하고 있습니다.

@ TD-er 나는 그것을 알고 있었다. 이유를 조사 중입니다. 근처의 벅 모듈에서 발생하는 소음 일 수 있습니다. 다른 하나는 2 시간 후에 다시 연결되지 않습니다.

아니요. Padavan 펌웨어 (ASUS 종류)를 실행하는 라우터를 사용하고 있습니다.

불행히도 저는이 FW를 전혀 모릅니다 ... 레이어 2 매개 변수를 조정할 기회가 있습니까? 프레임 확인 시간 초과와 같은 것입니까? 어떤 종류의 "거리"설정?

@ clumsy-stefan 불행히도 나는 그런 것을 보지 못했습니다.

@ clumpsy-stefan 어젯밤 50 개의 실패 임계 값이 설정된 상태로 장치가 2 번 재부팅되었습니다. 좋은 소식은 더 이상 동결이 없다는 것입니다. 오늘은 하드웨어 설정을 약간 변경하여 Wi-Fi 연결을 개선하려고 노력할 것입니다.

동일한 AP에 연결된 동일한 방에있는 3 개의 Wemos 장치.
지난 16 시간 이내에 다시 연결됩니다.
규칙 적용 : On WiFi # Connected ....

26 회 WD 재부팅 및 104 회 재 연결 :

9 번의 WD 재부팅 및 32 번의 재 연결

2WD 재부팅 및 40 회 재 연결

모두 50 개의 실패 임계 값이 설정 됨

@Domosapiens & @wolverinevn 한 가지 더 시도 할 수있는 것은 AP에서 그룹 키 타임 아웃을 늘리는 것입니다 (해당 옵션이있는 경우). 일반적으로 약 5 분입니다. 30 분까지 늘릴 수 있습니다. 또는 심지어 1 시간 동안 성장하는지 확인합니다 (초고 보안 네트워크에 있지 않는 한, IoT가 있다고 가정하지 않습니다) ...

@ TD- 어

가장 안정적인 것은 현재 20 일 11 시간 46 분 동안 실행되고 1 회만 다시 연결됩니다.

현재 3 일 이상 실행 된 유닛과 하루 안에 재부팅 된 다른 유닛도 있습니다.

그룹 키를 다시 보관하는 데 몇 가지 문제가 있습니다. 어떻게 든 최신 버전의 코어에서 키 재 지정이 시간 초과로 실행될 수 있습니다. 어디에서 실패하고 있는지 ..

@ clumsy-stefan 귀하의 제안에 감사드립니다.
내 dd-wrt 라우터에서 매개 변수를 봅니다. 값이 3600 (초) 인 "키 갱신 간격".
그래서 괜찮을까요?

다시 입력하면 시간 초과가 발생합니다.

그것은 시간당 다시 연결하는 imho를 설명합니다.
훌륭한 규칙 기능 _WiFi # Connected_ 덕분에 우리는 이것을 볼 수 있습니다.
이것에 대해 이전 버전이 어떻게 수행되었는지 전혀 모릅니다.
이미 오랫동안 숨겨진 문제?

내 그룹 키 갱신을 5 분에서 설정 한 후. 1 시간까지 유닛은 훨씬 더 안정적으로 작동합니다. 40 개의 클라이언트가 5 분마다 하나의 AP에 연결되어 있다고 가정합니다. rekey로 인해 공기가 너무 바빠졌습니다. 그 후에는 프레임 -ack 시간 초과를 다시 줄일 수도 있고 장치가 다시 응답을 얻었습니다. 또한 이러한 매개 변수를 변경 한 후 "연결 시간 초과"가 줄어 듭니다.

@ TD-er 여전히이 "그룹 키 시간 초과"와 "assoc 실패"는 나중에 응용 프로그램에서 캡처하고 처리해야한다고 생각합니다. 장치가 너무 느리게 만들고 다시 유지하는 데 실패하는 재키를 시도하는 동안 장치가 대기중인 메시지를 컨트롤러 / 서버로 계속 보내려고하는 느낌을받습니다. 따라서 레이어 2에서 연결이 끊어집니다.

대략적인 생각이지만, 여전히 그것을 고정 시키려고 노력하고 있습니다. 그러나 그것은 지금까지 제가 얻을 수있는 가장 가까운 것입니다.

@ TD-er jsut 이제 다시 연결 시도의 무한 루프에 들어가고 항상 만료되는 노드를 다시 경험했습니다 (아래 로그 참조). 흥미로운 점은 연결되지 않았 음을 분명히 인식하고 컨트롤러에 데이터를 보내려고하지 않는다는 것입니다. 즉, "실패한 연결 시도"가 더 이상 증가하지 않으므로 실패한 연결 제한에 도달하지 않습니다.

또한 부하가 항상 100 %로 표시되기 때문에 실제로 악수를하기에는 항상 너무 느리기 때문에 다시 연결하는 데 성공하지 못하는 것 같습니다 .... sems는 나에게 꼬리를 물린 것과 같습니다. 단지 메모리가 천천히 감소하고 있습니다. 나는 그것이 mem 때문에 충돌한다고 가정합니다) ...

# 2073으로 테스트하고이 상황이 다시 발생하는지 확인하겠습니다 ... 그러나 두 개의 직렬 연결된 노드에서 매우 드물게 발생하므로 무슨 일이 일어나고 있는지 추적 할 수 있습니다.

105587 : EVENT: WiFi#Disconnected
3105617 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 129 ms
3131325 : WD   : Uptime 52 ConnectFailures 84 FreeMem 12976
3134621 : EVENT: WiFi#Disconnected
3134652 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5141 ms
3141487 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3141488 : WIFI : Connecting clumsy_ap2 attempt #53
3142671 : EVENT: WiFi#Disconnected
3142700 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3153443 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3153444 : WIFI : Connecting clumsy_ap2 attempt #54
3153713 : EVENT: WiFi#Disconnected
3153743 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 157 ms
3161324 : WD   : Uptime 53 ConnectFailures 84 FreeMem 12976
3165518 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3165519 : WIFI : Connecting clumsy_ap2 attempt #55
3178542 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3178543 : WIFI : Connecting clumsy_ap2 attempt #56
3179728 : EVENT: WiFi#Disconnected
3179757 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3189704 : SYS  : 31.00,12808.00,100.00,53.00
3189708 : EVENT: sysinfo#rssi=31.00
3189743 : EVENT: sysinfo#mem=12808.00
3189773 : EVENT: sysinfo#load=100.00
3189804 : EVENT: sysinfo#uptime=53.00
3191297 : WD   : Uptime 53 ConnectFailures 84 FreeMem 12800
3191441 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3191442 : WIFI : Connecting clumsy_ap2 attempt #57
3191576 : EVENT: WiFi#Disconnected
3191606 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 125 ms
3200507 : EVENT: Clock#Time=Tue,10:25
3204458 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3204459 : WIFI : Connecting clumsy_ap2 attempt #58
3217493 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3217493 : WIFI : Connecting clumsy_ap2 attempt #59
3218677 : EVENT: WiFi#Disconnected
3218707 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3221325 : WD   : Uptime 54 ConnectFailures 84 FreeMem 12800
3245444 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3245445 : WIFI : Connecting clumsy_ap2 attempt #61
3249673 : SYS  : -80.00,12632.00,100.00,54.00
3249677 : EVENT: sysinfo#rssi=-80.00
3249709 : EVENT: sysinfo#mem=12632.00
3249741 : EVENT: sysinfo#load=100.00
3249772 : EVENT: sysinfo#uptime=54.00
3250620 : EVENT: WiFi#Disconnected
3250650 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5130 ms
3251307 : WD   : Uptime 54 ConnectFailures 84 FreeMem 12624
3259435 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3259436 : WIFI : Connecting clumsy_ap2 attempt #62
3260490 : EVENT: Clock#Time=Tue,10:26
3260650 : EVENT: WiFi#Disconnected
3260679 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1121 ms
3273521 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3273522 : WIFI : Connecting clumsy_ap2 attempt #63
3273659 : EVENT: WiFi#Disconnected
3273689 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 125 ms
3281281 : WD   : Uptime 55 ConnectFailures 84 FreeMem 12624
3287445 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3287446 : WIFI : Connecting clumsy_ap2 attempt #64

rssi-80과 연결하기 어렵다

RSSI 값은 노드 ESP가 연결되지 않은 경우 신뢰할 수 없습니다! 동일한 노드는 연결될 때 -70 미만입니다 .... 딥 슬립 노드에서는 값을 보낼 때 "연결되지 않음"기본값 인 +31을 표시합니다!
재부팅 후 문제없이 실행됩니다 ... (이동하지 않고 ...) 위를 읽으면 AP에서 매개 변수를 조정할 때 재현 가능한 레이어 2 문제입니다 ....

PS : 직접 시도해 볼 수 있습니다! jsut은 20-30 개의 노드를 연결하고 그룹 키 시간 제한을 5 분으로 낮 춥니 다. 프레임 응답 임계 값을 7과 같은 값으로 설정하면 어떻게되는지보십시오!

layer2 문제에 대한 잘못된 장소라고 생각합니다. esp8266 코어에서 문제를 채우거나 nonos sdk 프로젝트에서 더 나을 수도 있습니다.
하지만 여기서 소리 치지 마세요

ESPeasy에서만 발생하고 내가 시도한 다른 유형의 펌웨어에서는 발생하지 않습니다. 나는 노드가 어느 시점에서 너무 바쁘고 코어에 충분한 시간을 두지 않고 키를 다시 입력하지 않는다고 가정합니다 (모든 것이 여러 번 설명 됨), 디버그 및 설명을 자유롭게 읽으십시오 ...
하지만 동의합니다. 실제로 대답 할 필요는 없습니다.
추신 : @ uzi18 동시에 30 개의 노드를 성공적으로 실행 한 적이 있습니까?

@ TD-어 :에 ESPEasyWifi.ino 라인 650 - 스위치 중 669 switch 문의 기본 일치 나누기 때문에 tryConnectWiFi() 반환 true 비록 WiFi.status() 있다 반드시 WL_CONNECTED 아니지만 다른 상태 일 수 있습니다 (2 개의 잘못된 반환 상태 만 확인됩니다 ..).

WiFi.status() 실제로 WL_CONNECTED 를 반환 한 경우에만이를 호출하고 true 반환하면 내가 직면 한 레이어 2 연결 해제 / 예외 문제 중 하나 이상이 해결됩니다!

어떻게 생각해?
뭔가 빠졌거나 WiFi.status() 가? WL_CONNECTED`가 아닌데 tryConnectWiFi() 반환되어야하는 이유는 무엇입니까?

@ clumsy-stefan 여전히 WiFi 코드를 파헤 치고있는 것을 보니 반갑습니다.

https://github.com/letscontrolit/ESPEasy/blob/5ee18ec556c9c58802af29f5fd78593905ef35c1/src/ESPEasyWifi.ino#L604 -L671

이 기능의 초기 아이디어는 WiFi 연결 시퀀스를 시작하는 것이 었습니다.
아마도 그 이후의 모든 변화에서 그 기능이 약간 변경되었을 것입니다.
그러나 당신은 여기에서 뭔가를 할 수 있습니다.
상태가 연결됨을 반환하는 경우에만 return true (해당 함수의 끝에서)에 대한 적절한 변경 일 수 있다고 생각합니다.

현재 직면하고있는 다른 계층 2 문제에 대해 설명해 주시겠습니까?

다른 예외가 언제 발생했는지 정확히 말할 수는 없지만, 상태가 WL_CONNECTED 일 때이 함수가 true 만 반환하면 차이가 있습니다. 변경 전후에 디버그를 첨부합니다. .

전에

156874 : EVENT: WiFi#Disconnected Processing time:74 milliSeconds
156876 : WIFI : Disconnected! Reason: '(0) Unknown' Connected for 2 m 32 s
156877 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
157208 : WIFI : Connecting clumsy_ap2 attempt #0
157212 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
scandone
160069 : Fatal exception 9(LoadStoreAlignmentCause):
epc1=0x40105cd4, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000003, depc=0x00000000

Exception (9):
epc1=0x40105cd4 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000003 depc=0x00000000

후

108304 : EVENT: WiFi#Disconnected Processing time:73 milliSeconds
108307 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2014 ms
108308 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
109217 : WIFI : Connecting clumsy_ap2 attempt #1
109220 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt

connected with clumsy_ap2, channel 9
dhcp client start...
112113 : WIFI : Connected! AP: clumsy_ap2 (4C:5E:0C:39:F6:55) Ch: 9 Duration: 2895 ms
112115 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_CONNECTED
ip:10.0.10.117,mask:255.255.0.0,gw:10.0.0.2
113751 : WIFI : DHCP IP: 10.0.10.117 (wemos-mini-17-17) GW: 10.0.0.2 SN: 255.255.0.0   duration: 1636 ms
113765 : EVENT: WiFi#Connected

흠 ..이 후에는 내부 상태가 (아직) Arduino 상태와 일치하지 않는다는 것을 깨달았습니다. 이것은 또한 내가 생각하는 문제로 이어질 수 있습니다.

@ clumsy-stefan이 상태는 Arduino wifi 상태를 릴레이 할 수 없기 때문에 @ TD-er가 ESPEasy 상태를 도입 한 이유이지만 코드의 모든 상태가 제대로 확인되었는지 다시 확인할 수 있습니다.

이 Wi-Fi 상태가 코어 2.5.0에서 수정 되었기 때문에 우리 자신의 상태가 쓸모 없게 된 것일 수 있습니다.
WiFi 코드가 다소 복잡해져 오류가 발생하기 쉽기 때문에 좋을 것입니다.

편집하다:
이 오류를보고 있습니다.
Fatal exception 9(LoadStoreAlignmentCause):
코어 2.5.0의 최신 수정 사항 중 하나는 IPAddress 의 생성자에 관한 것으로, 주어진 바이트 시퀀스의 정렬이 32 비트 정렬이 아닐 때 문제를 해결해야합니다.
아마도 이것은 비슷한 것일까 요?

그것은 ESPEasy 상태가 항상 Arduino 상태와 동기화되지는 않는다는 추측 중 하나입니다. 특히 계층 2에서 일시적인 연결 해제 (예 : WiFi 유지)는 실제로 처리 / 실현되지 않을 수 있습니다.

또 다른 한 가지는 ESPEasy가 연결이 끊어 졌다고 생각하고 다시 연결을 시도하지만 코어가 여전히 회의 중이므로 예외가 발생한다는 것입니다. 하지만 아직 증명할 수 없습니다 ...

정렬에 대해, 예, 가능하지만 현재도 이것을 못 박을 수는 없습니다 ...

그래서 현재 내가 확신하는 유일한 것은 tryConnectWiFi() 의 리턴 코드가 실제 연결 상태와 일치하거나 적어도 WL_CONNECTED 확인해야한다는 것입니다.

@ TD-er 나는 다소 더 걱정됩니다

connected with clumsy_ap2, channel 9
dhcp client start...
112113 : WIFI : Connected! AP: clumsy_ap2 (4C:5E:0C:39:F6:55) Ch: 9 Duration: 2895 ms
112115 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_CONNECTED

저에게 마지막 두 줄은 ESPEasy가 그렇게 생각했지만 코어가 아직 상태를 업데이트하지 않았 음을 나타냅니다 ... 그래서 여기에서 어떤 경쟁 조건에 빠질 수 있습니다 ...

이런 일이 발생하면 때때로 나는 많은 것을보기 시작합니다

7989956 : Read settings: ControllerSettings index: 0
7989997 : Read settings: ControllerSettings index: 0
7990130 : Read settings: ControllerSettings index: 0
7990267 : Read settings: ControllerSettings index: 0
7990399 : Read settings: ControllerSettings index: 0
7990531 : Read settings: ControllerSettings index: 0
7990664 : Read settings: ControllerSettings index: 0
7990799 : Read settings: ControllerSettings index: 0
7990938 : Read settings: ControllerSettings index: 0

회복되지 않는 ...

잠시 후 다음과 같이 알려줍니다.

8185850 : ip:169.254.37.119,mask:255.255.0.0,gw:0.0.0.0
Read settings: ControllerSettings index: 0
8185975 : WIFI : DHCP IP: 169.254.37.119 (wemos-mini-18-18) GW: (IP unset) SN: 255.255.0.0
8185990 : EVENT: WiFi#Connected

이것이 어디에서 왔는지 알 수는 없지만, 이후에는 시도 (100)가 부족하고 재부팅 될 때까지 분명히 실패하는 컨트롤러 / 서버에 연결을 시도하기 시작합니다.

편집 : btw, 수동으로 AP에서 노드를 걷어차면이 동작을 강제 할 수 있습니다 ... 때로는 다시 연결되고 때로는 위에서 설명한 것처럼 발생합니다 ...
EDIT2 : 가끔 예외 9로 충돌이 발생하므로 연결 해제에서 정확히 복구하는 방법은 일종의 경쟁 조건 인 것 같습니다! 내 잘못이야, onDisconenct() 콜백에 addLog() 가 있었어 ...

거의 항상 같은 상황입니다. 4 방향 핸드 셰이크가 실패 (재 유지) 된 후에는 더 이상 복구되지 않습니다. 어떻게 강제로 복구할지 모르겠습니다.

적어도 processConnect() 및 processDisconnect delay(100) 를 추가하여 WiFi 상태를 업데이트하는 핵심 시간을 제공하면 WiFi가 다시 동기화됩니다. 이것은 또한 유닛이 아래 상황에 훨씬 덜 자주 들어가게 만듭니다!

900695 : WIFI : DHCP renew probably failed
900697 : Reset WiFi.
900699 : WIFI : Connecting clumsy_ap2 attempt #0
901713 : EVENT: WiFi#Disconnected
901772 : WIFI : Disconnected! Reason: '(8) Assoc leave' Connected for 14 m 56 s
902326 : WD   : Uptime 15 ConnectFailures 44 FreeMem 20248 WiFiStatus 0
907048 : EVENT: WiFi#Disconnected
907106 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 6172 ms
907786 : WIFI : Connecting clumsy_ap2 attempt #1
911821 : EVENT: WiFi#Disconnected
911879 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3860 ms
911894 : WIFI : Connecting clumsy_ap2 attempt #2
912793 : EVENT: Clock#Time=Sat,08:29
919974 : EVENT: WiFi#Disconnected
920033 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 7962 ms
920824 : WIFI : Connecting clumsy_ap2 attempt #3
922083 : EVENT: WiFi#Disconnected
922141 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1125 ms
922805 : WIFI : Connecting clumsy_ap2 attempt #4
923138 : EVENT: WiFi#Disconnected
923196 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 133 ms
925831 : WIFI : Connecting clumsy_ap2 attempt #5
931179 : EVENT: WiFi#Disconnected
931238 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5165 ms
931775 : WIFI : Set WiFi to AP+STA
932701 : EVENT: WiFi#APmodeEnabled
932778 : WIFI : AP Mode ssid will be wemos-mini-17_17 with address 192.168.4.1
932778 : WIFI : Connecting clumsy_ap2 attempt #6
933023 : WD   : Uptime 16 ConnectFailures 44 FreeMem 17856 WiFiStatus 0
934065 : EVENT: WiFi#Disconnected
934122 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1123 ms
935712 : WIFI : Connecting clumsy_ap2 attempt #7
936042 : EVENT: WiFi#Disconnected
936106 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 169 ms
938745 : WIFI : Connecting clumsy_ap2 attempt #8
939079 : EVENT: WiFi#Disconnected
939138 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 131 ms
941778 : WIFI : Connecting clumsy_ap2 attempt #9
947130 : EVENT: WiFi#Disconnected
947189 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5140 ms
947725 : WIFI : Connecting clumsy_ap2 attempt #10
948976 : EVENT: WiFi#Disconnected
949035 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1121 ms
951805 : WIFI : Connecting clumsy_ap2 attempt #11
952140 : EVENT: WiFi#Disconnected
952199 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 134 ms
955778 : WIFI : Connecting clumsy_ap2 attempt #12
956115 : EVENT: WiFi#Disconnected
956174 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 142 ms
959734 : WIFI : Connecting clumsy_ap2 attempt #13
960064 : EVENT: WiFi#Disconnected
960123 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 129 ms

@ TD-er tryConnectWiFi() 는 연결이 성공했는지 여부를 대비하여 true 또는 false 를 반환합니다 ... 그러나 WiFiConnectRelaxed() 실제로이를 확인하지 않습니다. ...

이 기능은 이벤트 기반 WiFi 이전에서 어떻게 되었습니까? 그 함수의 마지막 두 줄에 도달하지 않는 것 같습니다 ...

예, 이벤트 기반 Wi-Fi 이전에 남은 일종이었습니다.
WiFi 코드가 구조화되어 있지 않기 때문에 다시 한 번 살펴보아야한다고 생각합니다.

그래 ... 4way 핸드 셰이크 시간 초과로 인해 정확히 어떤 일이 발생하는지, 왜 노드가 다시 연결되지 않는지 디버깅 중입니다. 그래도 더할 수있는 거기 ....

다른 작은 하나는 WifiCheck() 에있는 것 같습니다. 레이어 2 연결 확인은 IP가 더 이상 유효하지 않을 때만 수행됩니다 (예 : 모든 옥텟이 0). 이로 인해 레이어 2가 연결 해제 (또는 재) / 핸드 셰이 킹 등의 상황이 발생할 수 있지만 IP는 아직 만료되지 않았으므로 (DHCP) 여전히 유효합니다. 그것이 아마도 "DCHP 갱신이 실패했을 것입니다"가리스가 실제로 없어진 오랜 시간 후에 만 ​​발생하는 이유 일 것입니다.하지만 여전히 이것을 확인하고 있습니다 ...

또한 wifiCheck() , WiFiConnected() 및 connectionCheckHandler() 는 모두 일종의 연결 확인을 수행하고 특정 조건에서 resetWiFi() 뿐만 아니라 서로를 호출합니다. 특히 connectionCheckHandler() 는 mqtt_reconnect_count > 10 때만 호출되는 것 같습니다. 그렇다면 비 MQTT 환경에서는 어떻게 될까요?

추신 : 나는 여기에 내 발견 사항을 문서화하여 기본 WiFi 문제를 검색하고 있습니다 ... 그래서 그것에 대한 생각에 만족하지만 꼭 기대하지는 않습니다 ...

어딘가에 일종의 신비한 경쟁 조건이 있어야합니다. AP가 재 인증을 시작하거나 재 유지하는 경우 때때로 노드 / 코어가 핸드 셰이크를 완료하는 데 충분한 CPU 시간을 얻지 못하거나 그렇게하는 동안 중단됩니다 (특히 신호가 낮은 노드에서 핸드 셰이크가 훨씬 더 오래 걸립니다). . (아래 참조).

이러한 재 유지 / 재 인증은 코어가 자동 재협상 또는 재 연결을 수행하더라도 코어에 의해 연결 해제 이벤트를 생성하는 것 같습니다 (내가 이해하는대로). 그러나 수동 재 연결이 트리거됨에 따라이 핸드 셰이크 프로세스가 ESPEasy 상태 시스템에 의해 중단되는 것 같습니다.이 프로세스는 자체적으로 반복되고 종료되지 않습니다 (또는 경우에 따라 wdt를 생성합니다).

` 810114 : EVENT: WiFi#Disconnected 810146 : WIFI : Disconnected! Reason: '(16) Group key update timeout' Connected for 13 m 16 s 810977 : WIFI : Connecting clumsy_ap2 attempt #0 811081 : WIFI : Connection lost to: clumsy_ap2 813089 : EVENT: WiFi#Disconnected 813120 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2011 ms 814977 : EVENT: Clock#Time=Thu,08:55 821529 : WD : Uptime 14 ConnectFailures 0 FreeMem 22000 WiFiStatus 0 831976 : WIFI : Connecting clumsy_ap2 attempt #1 832079 : WIFI : Connection lost to: clumsy_ap2 836831 : EVENT: WiFi#Disconnected 836863 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 4753 ms

그렇다면 Wi-Fi 이벤트를 사용하여 프로세스를 모니터링하고 직접 조치를 취하지 않아야할까요?
이것을 변경하면 2.3.0 및 2.4.0 빌드를 사용할 수 없게됩니다.

아니요, 그렇게하지 않을 것입니다 ... 제 지점에서 이미 몇 가지 (그다지 방해가되지 않는) 변경 작업을 수행하여 이러한 경우가 자주 발생하지 않게합니다 ...

방금 또 다른 작은 것을 찾았습니다. tryConnectWiFi() 에서 WiFi.status() 확인은 WiFi.begin() 호출이 WL_DISCONNECTED 를 반환하기 시작한 후 종료됩니다. 문서에 따르면 이것은 "모듈이 스테이션 모드에서 구성되지 않은 경우"를 의미합니다. 왜 이런 일이 발생하는지 또는 실제로 WiFi.begin() 호출하기 전에 esp를 명시 적으로 AP 모드로 설정하는 것이 도움이되는지 알아보기

그래서 나는 여전히 왜 이러한 포장 마차가 발생하는 "진짜"근본적인 문제를 찾기를 희망합니다. 만약 그렇다면 (손가락이 교차) 나는 당신 (그리고 다른 사람들)이 검토 할 수 있도록 모든 변경 사항으로 PR을 할 것을 제안합니다 ....

WiFi.status() 가 정확하지 않은 상황도 많이 보았습니다.
따라서 핵심 라이브러리에 이제 수정 사항이 있으며 WiFi가 안정적으로 작동하도록 모든 시도에서 어딘가에서 엉망이되었을 가능성이 큽니다.
이 문제를 직접 재현 할 수없고 다른 사용자의 보고서에 따라 조치를 취해야했기 때문에 디버깅이 매우 어려웠습니다.
최근에 WiFi와 관련하여 잘못 작동하는 모듈이 있으므로 이것이 제가 가장 좋아하는 WiFi 테스트 모듈입니다. 그러나 일부 부품이 사양을 벗어 났을 때 문제가 악화 될 수도 있다는 표시 일 수도 있습니다. 예를 들어 전원 공급 장치, 디커플링 커패시터 누락, (너무) 얇은 PCB 트레이스, 차폐 감소 등.

물론, 제가 HW 문제를 배제하고있는 것은 아닙니다. 그러나 나는 모든 종류의 전원 공급 장치, 다른 보드, 브랜드 등으로 ~ 40 개의 노드를 실행하고 있으며, 어느 시점에서 대부분의 노드는 연결 문제에 직면합니다. 특히 Wi-Fi 범위가 약하거나 GPIO가 사용 중입니다 ..

그리고 나는 현재 약간의 디버깅을 할 시간이 있으며 여전히 매우 흥미롭고 도전적입니다.) 이제는 연결, 확인, 연결 해제 등의 전체 시퀀스가 ​​어떻게 작동하는지 이해하기 시작했습니다.)

그래서 괜찮다면 이러한 연결 문제에 대해 계속해서 더 깊이 파고들 것입니다 .... 당신은 사장입니다 ....

계속 파세요 :)
재현이 거의 불가능한 모든 연결 끊김 문제에서 벗어나고 싶습니다.
그들은 이미 너무 오래 걸렸고 그들이 고쳐지면 정말 좋을 것입니다.

약 4 ~ 24 시간의 가동 시간과 평균 2 ~ 10 시간의 다운 타임이 발생합니다.
다운 타임 동안 노드는 계속 작동하지만 Wi-Fi 연결은 없습니다.

액세스 포인트 (MikroTik)는 다음을 표시합니다.

18:16:15 wireless,info 80:xx:xx:xx:xx:xx<strong i="8">@iotnet</strong>: connected, signal strength -62 
18:16:20 wireless,info 80:xx:xx:xx:xx:xx<strong i="9">@iotnet</strong>: disconnected, unicast key exchange timeout 
18:17:31 wireless,info 80:xx:xx:xx:xx:xx<strong i="10">@iotnet</strong>: connected, signal strength -60 
18:17:36 wireless,info 80:xx:xx:xx:xx:xx<strong i="11">@iotnet</strong>: disconnected, unicast key exchange timeout 

ESP Easy | 정보 |
----- | ----- |
빌드 : ⋄ | 20103-메가 |
라이브러리 : ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP : 2.0.3 PUYA 지원 |
GIT 버전 : ⋄ | mega-20190110 |
플러그인 : ⋄ | 7 [일반] [Sonoff POW R1 / R2] |
빌드 시간 : ⋄ | 2019 년 1 월 10 일 03 : 21 : 19 |
바이너리 파일 이름 : ⋄ | ESP_Easy_mega-20190110_hard_SONOFF_POW_4M.bin |

이것은 이전 버전의 문제가 아닙니다 (여전히 채널 14를 사용할 수 있고 hidden-ssid 네트워크가있을 때).

WiFi 채널이 고정되어 있습니까, 아니면 가변적입니까?
나는 Tasmota의 문제 해결 페이지를 읽고 있었고 그들은 WiFi 채널을 수정하도록 강력히 조언합니다.
채널 14를 사용할 수없는 경우 모든 국가에서 채널 1-11 만 허용되므로 지역 설정과 관련된 내용이 변경되었을 수 있습니다.
또한 채널 1, 6 및 11은 실제로 다른 채널의 간섭없이 사용할 수있는 유일한 채널입니다.

11이 아닌 1-10 채널 만 작동합니다. 다음을 참조하십시오 : https://github.com/letscontrolit/ESPEasy/issues/1337#issuecomment -394118989

물론 와이파이 채널은 고정되어 있습니다.

모든 채널은 다른 채널의 간섭을받을 수 있으며 제어 할 방법이 없습니다. 지옥, 같은 채널에서 간섭이있을 수도 있습니다.

btw, 내가 직면 한 문제와 관련하여-wifi 상태 led (inversed GPIO13)는 일반적으로 파란색이지만 장치가 오프라인이면 0,0,0,0,0,1,2,3 패턴으로 이동합니다. 4,5,6,7,8,9,0,0,0,0,0,0,0,0,1,2,3,4,5,6,7,8,9,0,0, 0,0,0, ... 밝기.

고정 IP 및 DCS, 그러나 채널은 과거에 변경되지 않았습니다.

폰 : Gijs Noorlander [mailto : [email protected]]
Gesendet : Freitag, 2019 년 1 월 11 일 21:47
An : letscontrolit / ESPEasy
참조 : 구독
Betreff : Re : [letscontrolit / ESPEasy] [BUG] [WiFi 안정성] 레이어 2 연결 해제시 ESP 예외 3/29 (# 1987)

WiFi 채널이 고정되어 있습니까, 아니면 가변적입니까?
나는 Tasmota의 문제 해결 페이지를 읽고 있었고 그들은 WiFi 채널을 수정하도록 강력히 조언합니다.
채널 14를 사용할 수없는 경우 모든 국가에서 채널 1-11 만 허용되므로 지역 설정과 관련된 내용이 변경되었을 수 있습니다.
또한 채널 1, 6 및 11은 실제로 다른 채널의 간섭없이 사용할 수있는 유일한 채널입니다.
—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 회신하거나 GitHub https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment-453651579 에서 보거나 https://github.com/notifications/unsubscribe-auth/AomgSxPjVKWrp0MSQTtbESKxFqaPVt90ks5vCPgxgaJpZM4YDivqaP 스레드를 음소거합니다. https://github.com/notifications/beacon/AomgS_fhHQnmg1AdpX11mVL9yNra8S_kks5vCPgxgaJpZM4YDivP.gif

Mikrotik 물건은 큰 힘을 제공하지만 Wi-Fi의 기본 설정조차 옳지 않습니다.

• 보안 설정 tkip에 없는지 확인하고 aes ccm 암호화 만 활성화하십시오.
• 30 분 또는 1 시간과 같은 키 그룹 업데이트를 입력하세요.
• 채널에서 채널 폭은 20Mhz이고 어떤 의견으로는 B 대역을 분리하고 G / N으로 이동합니다.
• 확장 채널 비활성화
• PMKID를 비활성화 (보안에 대해 히스테리가있는 경우 권장)하는 것만으로 Esp veeeery를 불행하게 만드는 것 같습니다.
• 국가를 Wi-Fi 설정에 추가하거나 보유한 AP의 최대 전력을 확인하고 전송 전력을 3만큼 낮 춥니 다. 이것은 매우 자주 Wi-Fi 성능을 향상시킵니다 (직관적입니다.)

나는 일반적으로 연결이 끊어지지 않습니다 (이 PMKID가있을 때 제외)

어쨌든 AP 설정을 게시하는 것은 어쨌든 통찰력이있을 것입니다 :-)

좋은 팁입니다. 나는 네트워크에 정통하고 mikrotik에 더 많은 경험을 가지고 있으며 그룹 키를 제외한 모든 것을 구성했습니다.

그룹 키 업데이트는 문제가있는 유니 캐스트 키가 아닌 그룹 키와 만 관련이 있지만 실험 목적으로 해당 설정을 다운 그레이드했습니다.

@ 0ki Cool은 RouterOS의 전문가가 어디에 있는지 몰랐습니다!

ESPEasy 소프트웨어의 버그라고 결론을 내 렸습니다. 왼쪽에서 오작동하는 클라이언트를 연결 해제하는 RouterOS와 일치하는 문제가있는 동작을 오른쪽에서 볼 수 있습니다. 보시다시피 라디오 스펙트럼은 명확합니다.

불행히도 지금은 ESPEasy 코드베이스를 탐구 할 시간이 없지만 나쁜 의사 소통과 좋은 의사 소통의 비교가 유용 할 것이라고 믿습니다.
범례 : __red-액세스 포인트 | 블루-espeasy | 녹색-내 IoT 네트워크의 다른 장치 __

ESP_easy는 어떤 이유로 assoc 응답 (왼쪽 프레임 380)을 수신 한 후 AP 모드로 전환하고 4 방향 핸드 셰이크를 계속하지 않기로 결정했다고 생각합니다. espeasy macaddress의 변경도 주목하십시오. 첫 번째 옥텟은 80에서 82로 변경됩니다.

@ 0ki

ESPEasy 소프트웨어의 버그라고 결론을 내 렸습니다.

나도 그래도 버그가 어디에 있어야할지 모르겠다.
연결이 끊긴 상태에 대한 ESPeasy의 내부 상태가 실제 상태와 동기화되지 않은 것 같습니다.
해당 코드를 작성하는 중에 오류가 발생했거나 핵심 라이브러리의 버그 일 가능성이 매우 높습니다.

구체적으로 "그 코드"가 의미하는 파일은 무엇입니까? 한두 개의 파일을 가리키면 제가 살펴볼 수 있습니다.

그렇지 않으면-지금 당신은 그것이 발생하는 정확한 순간을 보았으므로 자세히 살펴볼 수 있기를 바랍니다.

이 문제를 파헤 치고있는 동안 (현재 약 2 개월 동안) ESPEasy 코드 자체인지 더 이상 확실하지 않습니다. 더 많은 ESPEasy와 WiFi 코어 / 라이브러리 간의 상호 작용 ... 내 디버그 / 로그에 따르면 그룹 키 교환 / 재 유지 후에 항상 "연결 해제"가 발생합니다. 그러나 콜백은 키 재 지정 시간 초과 후 인증이 실패한 후에 만 ​​호출됩니다. 현재 내 생각에는 ESPEasy가 실제로 재 키핑을 수행하기에 충분한 CPU 시간을 코어에 남겨 두지 않는다는 것입니다. 노드가이 재 유지 노드 또는 재 인증 모드에 있는지 알 수있는 방법을 찾지 못해 재 유지 재 인증이 성공할 수 있도록 충분한 delay() 호출을 추가 할 수 있습니다.

문제를 적시에 정확히 찾아 내기 위해 다음과 같이 정상적으로 작동했습니다.

Build   20100 - Mega (core 2_3_0)
GIT version mega-20180224
Plugins 48 [Normal]
Build Md5   719b94a4d6bc257b86916e4989eed3a0
Md5 check   passed.
Build time  Feb 24 2018 03:03:12

그리고 확인은 연결 해제가 없었을뿐만 아니라 채널 14의 숨겨진 AP에 연결하는 것도 문제가되지 않았 음을 의미합니다.

@ clumsy-stefan, 나는 처음에 연결이 끊어지는 문제를 포착하는 것을 전적으로 지원하지만 솔직히 Wi-Fi Assoc이 떨어질 수있는 여러 가지 이유가있을 수 있습니다. 물론 그룹 키 교환은 그들.

더 시급한 문제는 연결이 끊어진 후 다시 연결할 수 없다는 것입니다. 4way HS의 메시지 2로 응답하는 데 무려 5000ms를 espeasy에 제공하므로 타이밍 문제가 될 수 없습니다.

문제는 keyexchange가 실패한 후에 만 ​​연결이 끊어진다는 것입니다 ... 그래서 이제는 거래가 실제로 시작될 때 절대로 코어에 더 많은 시간을 할애해야합니다.

로그에서 ESPEasy는 연결되어 있지 않더라도 (노드에 대한 핑도 실패하더라도) 꽤 오랫동안 연결되어 있다고 생각하지만 노드는 여전히 데이터를 보내려고합니다 (분명히 연결이 실패합니다).

내가 완전히 동의하는 두 번째 문제는 연결이 끊긴 경우에도 완전히 새로운 연결 시퀀스로 다시 연결할 수 없다는 것입니다. 모듈이나 코어가 이상한 상태로 멈춘 것 같습니다.

편집 : 추신 : 4way HS는 항상 실패하지 않습니다. (나는 10 분마다 수행합니다.) 따라서 ESPEasy의 상태 / 바쁜 상태와 HS 발생 시간의 조합 인 것 같습니다.

내가 할 수있는 일은 WiFi를 완전히 끊고 (모뎀도 끄고) 예기치 않은 연결이 끊어지면 완전히 새로 다시 연결하는 것입니다.
이 스레드에 있는지 확실하지 않지만 이러한 문제 중 하나에서 누군가가 Shelly의 트윗으로 답장을 보냈습니다.

@ TD-er도 최신 버전에 넣은 것입니다. processDisconnect() 내에서 setWifiMode(WIFI_OFF); 추가했지만 그게 충분하다면 ... 현재 일부 테스트 노드에서 실행 중입니다 (약 1 시간 이후) ...

@ TD-er 멋진 아이디어입니다. 자식 릴리스를 푸시하면 내 물건을 플래시 할 것입니다!

5 분 전에 코드베이스 일부를 읽기 시작 했으므로 이것은 관련이 없을 수도 있지만 : 또한 해당 시점에서 wifi_connect_attempt가 0으로 설정되어 있는지 확인하십시오.

흠 ... 각 서브 루틴 호출 후 backgroundtasks() delay(0) 를 추가하면 첫 번째 문제 (4way-HS)가 조금 더 안정화되는 것 같습니다. 우연의 일치인지 확실하지 않습니다 ...
@ TD-er는 backgroundtasks() 가 특정 시점에서 실행을 차단하고있을 수 있습니까?

일반적으로 말해서 타이밍 통계가 긴 처리 시간을 보여주는 모든 종류의 다른 장소에 delay(0) 을 추가하면 4way-HS 처리가 많이 향상되는 것으로 보입니다. 현재 문제를 재 유지하는 것보다 더 많은 SW / HW 감시 장치가 있습니다 (하지만 여전히 일부가 있습니다). 그리고 AP는 대답을 기다리는 것에 지쳐 있습니다.

내가 또한 보는 것은 때때로 client.connect() 또는 sendData() 가 상당히 많은 시간 (최대 2 초)이 걸릴 수 있다는 것입니다. 일부 문서에서 50ms 이상 걸리는 경우 delay(0) inbetween ....을 호출해야하지만 라이브러리에서 수행 할 때 이러한 호출을 분할 할 수 없습니다.

코어에 또 다른 콜백 onStationModeAuthModeChanged 있습니다. 실제 연결이 끊어지기 전에 트리거 될 가능성이 있으므로 살펴볼 가치가있을 것입니다. 하지만 문서화가 거의 없습니다 ... 누구든지 이것에 대한 경험이 있습니까?

편집 : AP가 키 재 입력을 요청할 때 다른 일들과의 우연 / 경주 조건 인 것 같습니다.

AP에서 보낸 이러한 요청이 얼마나 자주 재전송되는지 모르겠습니다.
일반적으로 AP의 비콘 신호는 102.4msec마다 전송됩니다. 일부 작업이 그보다 더 많은 시간이 소요되면 ESP는 이러한 비콘 프레임 중 하나를 놓치게됩니다. 그래서 이것이 얼마나 나쁜지 잘 모르겠습니다.
ARP 요청이 때때로 누락되어 스위치가 해당 MAC 주소로 패킷을 라우팅하는 방법을 더 이상 알지 못하여 ESP에 도달 할 수 없게 만드는 문제가 발생한다는 것을 알고 있습니다.

누락 된 비콘 프레임은 아무것도 아닙니다. 어쨌든 내 숨겨진 네트워크를 적극적으로 검색해야하므로 비콘 프레임도 필요하지 않습니다.

나는 WiFi 전문가가 아닙니다.
내가 이해했듯이 비콘 간격은 ESP가 WiFi를 청취하려고 시도하는 유일하게 보장되는 순간이며 그 사이에는 가능한 한 잠을 자려고 시도합니다.

그리고 내가 이해했듯이 '숨겨진'네트워크와 '숨겨지지 않은'네트워크의 유일한 차이점은 SSID가 브로드 캐스트되지 않는다는 것입니다. 따라서 실제로 BSSID (MAC-address of AP)로만 연결됩니다.
그것은 또한 ESP가 (숨겨지지 않은) WiFi 네트워크에 연결할 때 수행하는 작업이며, 이전에 스캔을 수행하고 주어진 것과 일치하는 SSID가있는 BSSID를 찾으려고 시도한다는 유일한 차이점이 있습니다.
자동 재 연결을 수행 할 때 검색을 수행하지 않고 마지막으로 알려진 BSSID + 채널 조합을 먼저 시도합니다. 즉, 연결할 때만 다릅니다.

내 지식으로는 네트워크에 연결되어있는 한 비콘 프레임도 수신합니다.

나는 WiFi 전문가가 아닙니다.
내가 이해했듯이 비콘 간격은 ESP가 WiFi를 청취하려고 시도하는 유일하게 보장되는 순간이며 그 사이에는 가능한 한 잠을 자려고 시도합니다.

그리고 내가 이해했듯이, '숨겨진'네트워크와 '숨겨지지 않은'네트워크의 유일한 차이점 ..........

오, 그것은 나에게 꽤 중요한 것을 상기시켜줍니다. 숨겨진 SSID에서 내 ESP를 실행합니다.
그런데 여전히 내 노드에서 연결이 끊기거나 재부팅되지 않습니다 (5 분 그룹 키 업데이트 시도).

내 노드 중 하나가 정전으로 인해 12 월 5 일에 재부팅되었습니다.

이것은 그 중 하나입니다.

단위 : | 5
-| -
현지 시간 : | 2019-01-15 23:27:32
가동 시간 : | 41 일 12 시간 46 분
로드 : | 15.80 % (LC = 9135)
무료 메모리 : | 12160 (5360-sendContentBlocking)
무료 스택 : | 3552 (1520-SensorSendTask)
부팅 : | 콜드 부트 (0)
재설정 이유 : | 외부 시스템
네트워크 ❔
Wi-Fi : | 802.11N (RSSI -67dB)
IP 구성 : | DHCP
IP / 서브넷 : | 192.168.1.89 / 255.255.255.0
GW : | 192.168.1.1
클라이언트 IP : | 192.168.1.67
DNS : | 192.168.1.1 / 0.0.0.0
허용 된 IP 범위 : | 모두 허용
STA MAC : | 5C : CF : 7F : B1 : 3F : 12
AP MAC : | 5E : CF : 7F : B1 : 3F : 12
SSID : | Lurch4 (34 : 31 : C4 : B1 : 8D : C7)
채널 : | 11
연결됨 : | 20 시간 4 분
마지막 연결 해제 이유 : | (202) 인증 실패
번호 재 연결 : | 61
펌웨어
빌드 : ⋄ | 20102-메가
라이브러리 : ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP : 2.0.3 PUYA 지원
GIT 버전 : ⋄ | mega-20181109
플러그인 : ⋄ | 46 [일반]
Md5 빌드 : | 47f19d99d0c3f083314b45668b1f5c
Md5 확인 : | 통과했습니다.
빌드 시간 : ⋄ | 2018 년 11 월 9 일 03:23:22
이진 파일 이름 : ⋄ | ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

보시다시피, 평균적으로 하루에 한 번 이상 연결이 끊어집니다. AVM Fritzbox 1750E에 연결됩니다.

비콘 프레임이 그다지 중요하지 않다고 생각합니다. 연결이 끊긴 후에도 정상적인 WiFi.begin() 시퀀스가 항상 '(2) Auth expire' 오류로 실패하는 이유가 아직 명확하지 않습니다.

유일한 표시는이 시점에서 CPU로드가 항상 100 %를 표시하고 코어가 핸드 셰이크를 수행 할 시간이 충분하지 않다는 것을 암시한다는 것입니다.

내 생각 엔 핵심 라이브러리 (LWIP 또는 Arduino 또는 ESP)에 문제가 있으며 Wi-Fi를 재설정해야합니다.
따라서 Wi-Fi를 끄고 다시 시작하십시오. 버퍼가 비워 지거나 적어도 플러시되고 미해결 요청이 적극적으로 취소되었는지 확인하기 위해 이러한 단계 사이에 대기 할 수도 있습니다.

@ TD-er이 변경 사항을 푸시하여 작동하는지 확인할 수 있습니까?

지난 2 개의 게시물에서 논의 된 변경 사항은 무엇입니까?
아직 구현되지 않았지만 오늘 저녁에 코드를 작성하고 테스트 빌드를 만들 수 있습니다.

네, Wi-Fi를 재설정합니다.

@ TD-er는 다음과 같이 썼습니다.

따라서 Wi-Fi를 끄고 다시 시작하십시오. 버퍼가 비워 지거나 적어도 플러시되고 미해결 요청이 적극적으로 취소되었는지 확인하기 위해 이러한 단계 사이에 대기 할 수도 있습니다.

플러싱이 확실하지 않습니다 ... client.stop() 전에 모든 client.flush() 호출을 제거했기 때문에 연결 끊김이 덜 자주 발생하는 것 같습니다. 일부 문서를 읽는 동안 플러시가 모든 (tcp) 입력 버퍼를 방출하는 것을 보았으므로 이론적으로 응답이 손실 될 수 있습니다.

2c를 추가하기 만하면 몇 개의 Mikrotik AP가 있으며, 몇 개의 sonoff는 espurna를 실행하고 몇 개의 NodeMCU는 ESPEasy를 실행합니다. 백업과 같이 네트워크에서 트래픽이 많은 기간 동안 ESP 장치를 잃어 버릴 것이기 때문에 ESP 장치에 대한 추가 AP를 추가해야했습니다. 나는 이것이 WiFi 신호 강도 및 트래픽 관련이라고 생각합니다. 추가 AP가 추가되면이 문제를 다시 본 기억이 없습니다.

하지만 내 NodeMCU와 ESPEasy 장치에는 약간의 연결이 끊어졌습니다. 장치에 netdata ping 모니터를 설정하고 언제, 어떻게, 왜 이런 일이 발생할 수 있는지 파악하고 정보를 다시 제공하는지 확인합니다.

또 다른 메모는 @ clumsy-stefan과 같은 40 개 이상의 장치가 없으며 약 5 명의 사용자와 모바일 장치 및 TV와 같은 이상한 스마트 장치가 있지만 Mikrotik 장치가 과부하되었거나 WiFi RF 네트워크가 포화 상태 일 수 있습니다. ?

RF 노이즈의 양을 확인할 수있는 방법이 있었으면합니다. AP의 수와 WiFi 채널이 어떻게 확산되는지를 보여주는 앱 (WiFi Analyzer)이 있습니다. 이 도구를 사용하여 다른 WiFi AP에 대한 WiFi 채널을 설정했습니다.

그러나 다른 RF 간섭이 있는지 실제로 알 수 없습니다.

과부하 된 Mikrotik 장치에 대한 아이디어는 MikroTik 951UI-2HND를 주 라우터로 사용하고 MikroTik RB9412nD hAP lite를 ESP AP로 사용하고 있습니다.

그 정보가 어떤 식 으로든 유용한 지 궁금합니다.

@LeeNX 힌트 주셔서 감사합니다. 내 노드는 3 개의 AP에 분산되어 있고 RF는 다소 균형을 이루고 있습니다 (AP 당 최대 20 개의 클라이언트). 따라서 가능한 한 간섭이 거의 없습니다 (물론 아무것도 없을 수 없습니다 ...). 따라서 MT가 과부하라고 생각하지 않습니다 (전문 이벤트 등을 위해 네트워크 백본 연결 및 WLAN을 제공하는 회사에서 일하고 있으므로 인프라 스트럭처에 대한 심층 테스트를 많이 받았습니다). 문제가 되더라도 ...하지만 노드가 연결이 끊긴 후 250 번 이상 재 연결할 수 없었고 재부팅 한 후 즉시 다시 연결됩니다. 방송 시간 문제가 될 수 없다고 생각합니다. 다른 장치에서 볼 수 있습니다 ...
그래서 나는 여전히 내부 와이파이 칩의 상태, 와이파이 코어가 얻는 CPU 시간의 양, ESPEasy 부분에서 실행되는 다른 작업 사이의 우연 또는 경쟁 조건이라고 생각합니다.

@ clumsy-stefan 나는 당신의 통찰력에 동의합니다. 40 개 이상의 노드가있는 작은 Mikrotik AP를 사용하면 Mikrotik CPU 또는 RAM이 제한 될 수 있다는 점을 지적하고 싶었지만 문제가되지 않는 것 같습니다.

기본 ESPEasy 코어 외에는 아무것도없는 ESP32 및 NodeMCU 장치를 dpeloying하고이를 실행하여 ESP CPU를 테스트하고 다른 플러그인 영향을받지 않는지 궁금합니다. 배포 할 수있는 항목과 netdata ping 테스트를 확인하세요.

유용한 정보가 있으면 다시보고하겠습니다.

감사합니다!

여기에 아무 것도 실행되지 않는 노드 (IR RX / TX)가 있으며 문제없이 몇 주 동안 실행됩니다.
가동 시간이 40 일 이상인 다른 노드는 Domoticz MQTT 및 BME280 + MH-Z19 CO2를 실행합니다.
따라서 실행중인 플러그인과 읽기 간격이 항상 다른 플러그인의 읽기 간격과 일치하는지 여부에 따라 달라질 수 있습니다.

스케줄러에서 초기 오프셋을 사용하여 주기적 함수 호출 (10 / 초, 1 / 초 및 30 초)을 이미 설정하여 다른 루프 호출에서 가능한 한 많이 계속 실행됩니다.

Tasker 와 같은 인터럽트 타이머 구동 이벤트를 추가하고 (또는 내가 작성한 스케줄러 대신 tasker를 사용) 지연 (0)을 실행하기 위해 10msec 간격으로 하나의 작업을 설정해야 할 수도 있습니다.
유일한 것은 다른 GPIO 전송을 방해하여 센서 판독 값을 방해 할 수 있다는 것입니다.

아마도 4way-HS 문제를 해결할 수 있겠지만 재 연결 문제는 아닌 것 같아요 ... 여전히 가장 이상한 문제입니다 ... 테스트 노드가 12 시간 동안 다시 실패하여 AP에 300 회 이상 재 연결을 시도했습니다. 성공. (소프트) 재부팅 후 즉시 재 연결 (재부팅 + 재 연결 약 5 초 정도 소요) ...

방금 우리가 여기서보고있는 것과 매우 관련이있는이 문제를 발견했습니다.
https://github.com/esp8266/Arduino/issues/5527

네, 비슷 ...하지만 와이파이 OFF를 호출하면 (즉, 시도), 현재 내가 함께 노력하고 변화하지 않는 것 WiFi.setOutputPower(0) 호출하기 전에 WiFi.begin() 여기 제안
https://github.com/esp8266/Arduino/issues/2235
그리고 여기
https://github.com/esp8266/Arduino/issues/2186#issuecomment -233853152
아직도 힘든 일이 일어나기를 기다리고 있습니다 ...

비슷하지만 같지는 않습니다. 사실 우리의 경우 AP를 재부팅하면 문제가 해결됩니다. Gijs가 게시 한 문제에서 AP를 재부팅해도 문제가 해결되지 않습니다.

@ giig1967g AP를 재부팅해도 문제가 해결되지 않습니다! 노드를 재부팅하면 다시 연결됩니다 (내 환경에서) ...

@ giig1967g @ clumsy-stefan이 언급 한 문제에서 AP의이 재부팅도 언급됩니다. https://github.com/esp8266/Arduino/issues/2235#issuecomment -248851270

따라서 여기에 몇 가지 문제가있는 것 같습니다.

안녕하세요
그래. 그리고 내 경우에는 Mikrotik에서만 ... :(
@ TD- 어
어떤 AP 브랜드 / 모델을 사용하고 있는지 물어봐야합니다.

@ giig1967g 또한 여기에 도달 할 수없는 일부 노드가 있었지만 해당 이벤트의 간격이 10 일 이상 이었으므로 이러한 문제 중 하나와 관련이 있는지 말하기가 조금 어렵습니다.
이제 내 노드의 약 절반이 Mikrotik에 연결되고 나머지 절반은 Fritzbox 1750E에 연결됩니다.

@ giig1967g 또한 MT 만 가지고 있습니다 ... 신호가 약한 노드와 GPIO가 사용중인 노드 (특히 PCF)에서 더 자주 발생하는 것 같습니다 ...

RF 노이즈의 양을 확인할 수있는 방법이 있었으면합니다. AP의 수와 WiFi 채널이 어떻게 확산되는지를 보여주는 앱 (WiFi Analyzer)이 있습니다. 이 도구를 사용하여 다른 WiFi AP에 대한 WiFi 채널을 설정했습니다.

그러나 다른 RF 간섭이 있는지 실제로 알 수 없습니다.

snr을보기 위해 mikrotik에서 /interface wireless registration-table print interval=1 를 할 수 있습니다.

안타깝게도 WiFi.setOutputPower(0) 도 도움이되지 않았습니다 ... 거의 6 시간 동안 원활하게 실행 된 후 (WiFi 인프라를 변경하지 않고 갑자기 다시 교착 상태가되어 (아래 직렬 출력 참조) 복구되지 않습니다. 우연히 SW 또는 HW WDT가 시작되는 경우를 제외하고 ...

이것은 "그룹 키 업데이트 시간 초과"또는 "4 방향 핸드 셰이크 실패"후에 만 발생하는 것으로 보입니다. 수동으로 AP에서 노드를 킥오프하면 "인증 만료"가 발생하지만 즉시 다시 연결할 수 있습니다.

직렬 출력 (부하는 100 %가되지 않음) ...

20457441 : WIFI : Disconnected! Reason: '(16) Group key update timeout' Connected for 2h19m
20457593 : WIFI : Connecting clumsy_ap2 attempt #0
20458607 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20459707 : EVENT: WiFi#Disconnected
20459763 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2012 ms
20470762 : SYS  : 31.00,20048.00,66.70,341.00
20470766 : EVENT: sysinfo#rssi=31.00
20470824 : EVENT: sysinfo#mem=20048.00
20470882 : EVENT: sysinfo#load=66.70
20470940 : EVENT: sysinfo#uptime=341.00
20472658 : EVENT: Clock#Time=Thu,14:22
20473264 : WD   : Uptime 341 ConnectFailures 22 FreeMem 20040 WiFiStatus 0
20477609 : WIFI : Connecting clumsy_ap2 attempt #1
20478135 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20482577 : EVENT: WiFi#Disconnected
20482635 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 4771 ms
20503270 : WD   : Uptime 342 ConnectFailures 22 FreeMem 18440 WiFiStatus 0
20505709 : WIFI : Connecting clumsy_ap2 attempt #2
20506235 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20509784 : EVENT: WiFi#Disconnected
20509845 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3879 ms
20530897 : SYS  : 31.00,16248.00,100.00,342.00
20530902 : EVENT: sysinfo#rssi=31.00
20530963 : EVENT: sysinfo#mem=16248.00
20531025 : EVENT: sysinfo#load=100.00
20531087 : EVENT: sysinfo#uptime=342.00
20532688 : EVENT: Clock#Time=Thu,14:23
20533158 : WD   : Uptime 342 ConnectFailures 22 FreeMem 16240 WiFiStatus 0
20533716 : WIFI : Connecting clumsy_ap2 attempt #3
20534242 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20537788 : EVENT: WiFi#Disconnected
20537851 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3865 ms

간단히 말해서 wifi_set_phy_mode(PHY_MODE_11G); 추가하고 노드를 802.11g 모드로 강제 설정하는 것이 적어도 해결 방법 인 것 같습니다. 몇 시간 이후로 장치를 재부팅하지 않았으며 위의 그룹 키 시간 초과 문제에서 장치를 한두 번 복구했습니다.
아마 관련

• ESP8266 SoftAP는 802.11b / g 만 지원합니다.

문서에 언급되어 있습니다 ...

안정적이면 나중에 / 내일 업데이트하겠습니다 ...

다른 사람이 이미 언급했듯이 (몇 번) 802.11G로 전환하여 감도를 높여야합니다.
이에 대한 나의 목표는 대부분의 AP가 N, G 및 B 사이를 전환 할 때 문제가 있다는 것입니다.
혼합 클라이언트가 있습니까? (G 및 N) 동일한 AP에서 활성화 되었습니까?

모든 Mikrotik에서 다른 모드를 사용합니다. B / G / N / AC 혼합, 또한 가상 AP를 포함하여 2 / 5GHz 대역 모두 ... 여러 클라이언트가 문제없이 동일한 AP에서 서로 다른 모드로 연결됩니다 (esp8266 제외) ..

(적어도 나에게는) 좋은 소식입니다 ... 내 노드는 연결 해제 / 재부팅 / 멈춤없이 지난 12 시간 동안 실행되었습니다!

노드를 802.11g로 강제하는 것은 MikroTik AP와 원활하게 작동하는 것 같습니다. 최소한 이것은 간단한 해결 방법입니다 (802.11n의 추가 속도가 필요하지 않은 경우).

누군가 자신을 테스트하고 싶다면 tryConnectWiFi() 함수의 644 행 주위에 ESPEasyWifi.ino 를 다음 행 ( setupStaticIPconfig(); 뒤에)에 추가하십시오.
WiFi.setPhyMode(WIFI_PHY_MODE_11G);

SoftAP 모드가 802.11n을 지원하지 않고 노드가 N 모드로 연결되어 있기 때문에 문제가 발생한다고 추측 할 수 있습니다. 코어는 어떻게 든 "혼란스러워집니다."하지만 이것이 핵심 사람들과 함께 제기해야 할 문제라고 생각합니다. ..

ESPEasy의 경우 이것은 구성 가능하게 만들 수 있습니다 (@ TD-er?) ESP가 (B / G / N)에서 실행되어야하는 구성 페이지에서 선택할 수 있습니다.

네, 고급 설정에서 선택 옵션을 추가하겠습니다.
누가 먼저 물어 봤는지 잊었 어.하지만 찾아보고 커밋에서 그에게도 인정할 것이다.)

완전한!! 나는 일하는 데 필요한 신용이 필요하지 않습니다.) 그래서 그에게 그것을 바치십시오! 😄

디버깅하는 동안 변경을 제안하는 다른 작은 것들을 발견했습니다 (플러그인 호출 후 무조건 delay() 호출, 일부 추가 {} 및 로깅 출력에 대한 일부 추가). PR을 수행해야합니까? 이 ASPIT 또는 그대로 유지하고 싶습니까 (나는 이것이 중요한 변화가 아니라 약간의 개선 사항이라고 생각합니다)?

홍보 해주세요.
적어도 토론에 도움이되며 결과를 추적 할 수 있습니다.
또한 확인한 내용에 댓글을 추가하면 도움이 될 것입니다.

참조 # 2012
개발자에 대한 모든 크레딧. 팀!

이 패치에는 WiFi.setOutputPower (0) 아이디어도 포함되어 있습니까?

지금까지 7 일 동안 실험을하고 있습니다.
mega-20180224 노드-재부팅 없음
mega-20190110 노드-35 회 재부팅; 오늘 9 명.

코드에 관련 줄을 남겼지 만 주석 처리했습니다. 따라서 ESPEasyWiFi.ino 에서 // (약 644 행)을 제거하고 다시 컴파일해야합니다!

@oki 죄송합니다, 방금 귀하의 질문을 잘못 읽은 것을 봤습니다 ... 다시 연결하기 전에 전원을 0으로 설정할 때 차이가 없음을 볼 수 있었기 때문에 이것은 포함되지 않았습니다 ... 그래서 나는 그것을 다시 버렸습니다!

지금까지 7 일 동안 실험을하고 있습니다.
mega-20180224 노드-재부팅 없음
mega-20190110 노드-35 회 재부팅; 오늘 9 명.

이는 효과적으로 비교하는 것입니다.

• 이벤트 기반 Wi-Fi가없는 코어 2.3.0
• 이벤트 기반 와이파 이와 코어 2.4.2.

(적어도 나에게는) 좋은 소식입니다 ... 내 노드는 연결 해제 / 재부팅 / 멈춤없이 지난 12 시간 동안 실행되었습니다!

노드를 802.11g로 강제하는 것은 MikroTik AP와 원활하게 작동하는 것 같습니다. 최소한 이것은 간단한 해결 방법입니다 (802.11n의 추가 속도가 필요하지 않은 경우).

테스트를 위해 다른 방법으로 수행했습니다.
Mikrotik을 N-Mode로만 설정했고 모든 ESP는 한 번의 재부팅없이> 12 시간 이후로 실행됩니다.

좋고 유효한 접근법도 있습니다! 불행히도 나는 N 능력이없는 많은 클라이언트를하기 때문에 이것을 할 수 없습니다 ...

B 모드를 비활성화하고 G / N 만 활성화하면됩니다. B 모드가없는 것이 좋습니다. B 모드 및 속도 만 지원하는 10 년 전의 오래된 전화기 또는 (일반적으로) wifi 바코드 스캐너가없는 경우.

B 모드에서 안테나의 추가 감도도 범위에서 중요한 역할을하지 않습니다. B 모드는 방송 시간을 낭비합니다. B 모드를 사용하지 않는 데에는 말 그대로 결점이 없으며 G보다 N 모드를 사용하는데도 결점이 없습니다. N 모드는 B와 G보다 더 나은 범위를 가지고 있습니다.

@ jimmys01 맞아요, B 모드는 더 이상 어디에서나 사용되지 않을 것입니다 ...하지만 N 만 갈 수는 없습니다 ... 따라서 노드가 안정적으로 유지되면 G / N 모드에서 어떤 일이 발생하는지 테스트해야합니다. 4way HS 타임 아웃시 재접속이 가능합니다.

g / n은 저에게 불안정합니다.

이것은 esp8266이 모드 (B / G / N) 사이를 전환 할 때마다 문제가 발생한다는 것을 의미합니까?

이것은 esp8266이 모드 (B / G / N) 사이를 전환 할 때마다 문제가 발생한다는 것을 의미합니까?

가능성이 매우 높다.
G 모드 만 지원하는 일부 장치 (ESP 장치가 아님)에서 많은 문제를 보았습니다.
N 개 장치와 함께 사용하면 연결할 수없는 것처럼 보일 수 있습니다.
악명 높은 것은 HomeWizard와 일부 WiFi 카메라입니다.

이 새로운 버전의 mega-20190121을 사용하면 ESP가 더 안정된 것처럼 보였고 지금까지 충돌 / Wlan 문제가 없었습니다.
하지만 이제는 더 이상 OLED (framedPlugin)를 끌 수 없습니다. OLEDFRAMEDCMD를 보낼 때 끄면 잠시 동안 디스플레이가 꺼졌다가 다시 켜집니다.
이전 버전 (2018 년부터)으로 연속 테스트를 수행했는데 디스플레이가 예상대로 반응합니다.

mega-20190121을 사용해 보았고 WiFi 안정성은 동일합니다. 시작 후 약 1 시간 이내에 충돌합니다.

@ TD-er, 변경 사항을 논의하여 테스트 할 수 있도록 언제 버전을 푸시 할 수 있다고 생각하십니까?

빠른 업데이트 : 모드 수정을 802.11g로 설정했기 때문에 더 이상 멈춤, 재부팅 등이 없습니다! AP가 혼합 g / n 모드에서 작동하더라도 ... 그래서 esp에서 wifi 모드를 구성 할 수있게하는 패치에 투표하겠습니다!

곧 패치를 희망합니다 😉

B / G 만 선택하기위한 커밋을 추가했습니다.
아직 ESP32에서 제대로 작동하지 않으므로 ESP32에서 선택하는 옵션을 비활성화했습니다.
또한 AP가 B / G 만 허용하지 않는 경우 다시 연결할 수 있도록 대체 옵션을 추가했습니다.

@ TD-er이 변경 사항을 의미합니다.

내 생각 엔 핵심 라이브러리 (LWIP 또는 Arduino 또는 ESP)에 문제가 있으며 Wi-Fi를 재설정해야합니다.
따라서 Wi-Fi를 끄고 다시 시작하십시오. 버퍼가 비워 지거나 적어도 플러시되고 미해결 요청이 적극적으로 취소되었는지 확인하기 위해 이러한 단계 사이에 대기 할 수도 있습니다.

지난 2 개의 게시물에서 논의 된 변경 사항은 무엇입니까?
아직 구현되지 않았지만 오늘 저녁에 코드를 작성하고 테스트 빌드를 만들 수 있습니다.

@oki 두 가지 변형을 모두 시도하여 출력 전력을 0으로 설정하고 문제가 발생하면 적극적으로 연결 해제 / 재 연결했습니다. 두 버전 모두 AP 재설정 / 재 연결에 도움이되지 않았습니다 ... (내 환경에서) ... 위의 세부 정보 ...
안정적으로 만든 유일한 방법은 N 모드를 사용하는 것입니다.

나는 그것을 잘 알고 있습니다. 곧 패치를 기대하므로 디버깅을 계속할 수 있습니다.

@ 0ki 이 최신 커밋을 사용하여 테스트 빌드를 만들 수 있습니다.
아니면 WiFi를 비활성화하여 테스트 하시겠습니까?

그렇다면 어떤 옵션이 필요합니까? WiFi를 끄고 켜고 모든 서비스를 다시 시작 하시겠습니까?
소켓을 사용하는 모든 서비스가 제대로 다시 시작되었는지 완전히 확신 할 수 없기 때문에 마지막 부분 (서비스 다시 시작)도 잘 살펴 봐야합니다.
이로 인해 WiFi 연결이 다시 생성 될 때 몇 가지 문제가 발생할 수 있습니다.

연결이 끊어지면 Wi-Fi 송신기를 자동으로 완전히 껐다가 켭니다.

코드를 추가 한 것을 확인했습니다. 이것을 테스트하기 위해 어떤 버전을 가져올 수 있습니까?

확실하지 않지만 테스트를 위해 새 빌드를 만들 것입니다.
+/- 30 분 후에 완료됩니다.

테스트 빌드
B / G 모드에서 연결하기 위해 변경된 PR # 2235와 오늘 제가 병합 한 것을 기반으로합니다.
해당 PR의 일부 플러그인에 문제가있는 것 같아서 아직 병합되지 않은 이유입니다.

감사! 테스트 빌드를 플래시했습니다.

이제 다음 설정이 있습니다.
Connection Failure Threshold: 0 Force WiFi B/G: NO Restart WiFi on lost conn.: YES

PLATFORMIO_ESP12E를 가지고 있다는 점을 고려하면 다른 방식으로 테스트해야한다고 생각하십니까?
즉, b / g가 esp12e에서 작동하는지와 연결 실패 임계 값이 정확히 무엇인지 잊어 버렸습니다.

이 임계 값은 실패한 연결 시도 횟수가 해당 값을 초과하는 경우 재부팅을 시작하는 카운터 일뿐입니다.
0은 기본값이며 재부팅을 수행하지 않음을 의미합니다.

50 또는 100으로 설정하면 도달하기 어려울 수 있고 재 연결 루프가 발생할 때 재부팅하는 데 도움이 될 것 같습니다.

이 설정을 사용해도 이미 많은 노드가 표시했듯이 HW 워치 독 재부팅이 표시 될 수 있습니다.
B / G 모드가 활성화 된 상태에서는 재현하기가 더 어려울 수 있습니다.

테스트 빌드
B / G 모드에서 연결하기 위해 변경된 PR # 2235와 오늘 제가 병합 한 것을 기반으로합니다.
해당 PR의 일부 플러그인에 문제가있는 것 같아서 아직 병합되지 않은 이유입니다.

테스트 빌드에 감사드립니다.
이전에 가장 불안정한 ESP12F는 재부팅하지 않고 59 시간 이후로 작동합니다. :)

편집 : 설정은 다음과 같습니다.
강제 WiFi B / G : 예
연결이 끊어지면 WiFi 다시 시작 : 예

해당 커밋 (B / G WiFi)을 별도의 PR로 분할 할 것이므로 현재 병합 대기중인 나머지 PR을 수정하기 전에 병합 할 수 있습니다.

좋은 생각!

내 이전 설정 RestartWifi = YES는 유용하지 않았습니다.

이제 나는

Connection Failure Threshold: 0
Force WiFi B/G: YES
Restart WiFi on lost conn.: NO

재부팅하거나 단 한 번의 연결을 끊지 않고 이틀 동안 작동했습니다. 놀랄 만한. 이 테스트 릴리스에서 멀어 질 것이라고 생각하지 않습니다.

약 후. 100 시간 동안 모듈이 마침내 리셋을했습니다. :(

재설정 이유 : 하드웨어 감시

그러나 이는 어려운 구성 (12 x 1-wire 센서 및 FHEM 서버)으로 인해 발생할 수도 있습니다.

이 패치를 추가 할 수도 있습니다 : https://github.com/letscontrolit/ESPEasy/pull/2235/commits/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf2
아마도 그것은 또한 안정성을 향상시키는 데 도움이 될 것입니다.
이 테스트 빌드에 포함되어 있습니다.

이 패치를 추가 할 수도 있습니다 : 9a05eaf
아마도 그것은 또한 안정성을 향상시키는 데 도움이 될 것입니다.
이 테스트 빌드에 포함되어 있습니다.

감사!
완전히 다른 두 개의 구성 장치에 설치하고 피드백을 제공합니다.

내 테스트 노드 중 하나에서 실행했습니다.
https://github.com/letscontrolit/ESPEasy/commit/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf 불행히도 group-key-timout 문제가 다시 발생하고 복구되지 않거나 AP에 다시 연결되지 않을 때까지 약 2 시간이 걸렸습니다. "연결이 끊겼을 때 Wi-Fi 다시 시작"을 활성화하고 B / G로 강제하지 않습니다. 따라서 N은 여전히 ​​문제인 것 같습니다.
그래서 저에게 B / G 모드는 여전히 안정적인 작업 옵션입니다.

N 개의 지원이 완전히 사라지는 것을 볼 수 있습니까? 그런 간단한 장치를 위해 N이 제공하는 혜택이 필요합니까?

@ TD-er가 내장 한 B / G 모드를 강제하는 "새로운"옵션이있는

이것을 기본 설정으로 옮길 때이 옵션이 기본적으로 켜져있는 것이 좋습니다.

동적으로 만들 수 있습니다.
연결이 불가능하면 N 옵션을 켜고 다시 시도하십시오.

AP에서 N 만 체크 한 설정이 많이 있습니다. 따라서 이러한 환경에서는 ESPeasy에서 N 지원을 비활성화하면 돌아갈 수 없습니다.

이 패치를 추가 할 수도 있습니다 : 9a05eaf
아마도 그것은 또한 안정성을 향상시키는 데 도움이 될 것입니다.
이 테스트 빌드에 포함되어 있습니다.

감사!
완전히 다른 두 개의 구성 장치에 설치하고 피드백을 제공합니다.

지금까지 하나의 모듈은 2 일 후에 다시 시작되었고 다른 하나는 5 일 후에 다시 시작되었습니다.
둘 다 재설정 이유로 "Hardware Watchdog"을 표시했습니다.
두 모듈 모두 "Force WiFi B / G : Yes"및 "Restart WiFi on lost conn .: Yes"로 설정되어 있습니다.
AP는 B / G로만 설정된 Mikrotik입니다 (가동 시간 49 일).
AP와 모듈 사이의 거리 2 ... 3m.

동적으로 만들 겠다는 내 제안 (B / G 전용 설정에서 N으로 돌아 가기)이 왜 2 개의 "투표"를 받았는지 궁금합니다.
좋은 제안이 아닌 이유를 자세히 설명해주십시오.

동적으로 만들 겠다는 내 제안 (B / G 전용 설정에서 N으로 돌아 가기)이 왜 2 개의 "투표"를 받았는지 궁금합니다.
좋은 제안이 아닌 이유를 자세히 설명해주십시오.

제 생각에 누군가이 옵션을 켜면 그는 이미 더 많은 안정성을 필사적으로 찾고 있었고 이것이 그의 AP 설정에 어떤 의미인지 알고 있습니다.
나는 B / G 전용 옵션을 선택할 때 B / G를 사용하고 있다고 생각하지만 다시 사용하지 않는 상황에 처하고 싶지 않기 때문에 정적 솔루션을 선호합니다.
그러나 내 노드가 어쨌든 재부팅되기 때문에 (훨씬 덜 자주) 나는 새로운 코어와 관련된 문제에 대한 실제 솔루션을 갖고 싶습니다.

이해하지만 사용자가 설정이 무엇을하는지 모르고 도달 할 수없는 노드로 끝날 때 문제를 이해해야합니다.
따라서 N 지원으로 다시 전환하기 전에 큰 임계 값이 있어야합니다.
예를 들어 손상된 플러그인에 대한 대체 방법은 다음과 같습니다.
10 번의 재부팅에 실패하면 1 개의 플러그인 또는 컨트롤러가 비활성화되어 재부팅이 성공할 수 있는지 확인합니다.

Wi-Fi 연결에도 유사한 것을 적용 할 수 있습니다.
재 연결 시도가 X 회 실패하면 허용되는 802.11N으로 연결할 수 있습니다.
수신 품질은 G 모드 네트워크에서 더 좋기 때문에 X를 10과 같이 넣으면 G 대신 N으로 연결될 가능성이 거의 없습니다. 특히 N 모드에서 시도 할 때마다이 카운터를 재설정하면 더욱 그렇습니다.

흠 ESPeasy의 지난 몇 주 동안 내가 구현할 계획이나 구현 된 내용에 대한 기억을 모호하게 만들었습니다.

나는 방금 이것에 대한 코드를 보았고 다음을 발견했습니다.

void setConnectionSpeed() {
  #ifdef ESP8266
  if (!Settings.ForceWiFi_bg_mode() || wifi_connect_attempt > 10) {
    WiFi.setPhyMode(WIFI_PHY_MODE_11N);
  } else {
    WiFi.setPhyMode(WIFI_PHY_MODE_11G);
  }
  #endif

따라서 wifi_connect_attempt 가> 10 일 때 N 만 허용하도록 이미 구현되었습니다.
이 카운터는 Wi-Fi에 성공적으로 연결하는 즉시 0으로 재설정됩니다.

이것이 허용 가능한 솔루션입니까?

흠 ESPeasy의 지난 몇 주 동안 내가 구현할 계획이나 구현 된 내용에 대한 기억을 모호하게 만들었습니다.

나는 방금 이것에 대한 코드를 보았고 다음을 발견했습니다.

void setConnectionSpeed() {
  #ifdef ESP8266
  if (!Settings.ForceWiFi_bg_mode() || wifi_connect_attempt > 10) {
    WiFi.setPhyMode(WIFI_PHY_MODE_11N);
  } else {
    WiFi.setPhyMode(WIFI_PHY_MODE_11G);
  }
  #endif

따라서 wifi_connect_attempt 가> 10 일 때 N 만 허용하도록 이미 구현되었습니다.
이 카운터는 Wi-Fi에 성공적으로 연결하는 즉시 0으로 재설정됩니다.

이것이 허용 가능한 솔루션입니까?

글쎄 .. 나는 예라고 말할 것입니다 (2.5.0의 버그가 곧 발견되기를 바랍니다).

B / G 설정에 대한 피드백 만 있습니다.
20 분마다 재부팅되는 하나의 장치에 테스트 fw를 설치했습니다. -72dBi로 N에 연결되기 전에. 연결을 끊지 않을만큼 충분한 신호 였어야합니다. -105dBi 수신 기능을 갖춘 엔터프라이즈 급 AP를 운영하고 있습니다. 따라서 다시 채널을 삭제해서는 안됩니다.

테스트 FW로 몇 시간 후 지금까지 재설정이 없었습니다.
계속 실행하고보고하겠습니다.

PS : 나는 그것이 어떻게 든 N과 관련이 있다는 것에 동의합니다.
PSS : 4M으로 업그레이드 된 20 x ESP-07 노드를 실행하고 있습니다. 시간이 많이 걸리지 만 재 플래싱이 필요할 때 비용을 지불합니다.

120 개 이상의 노드가 모두 GN (mega-20190202)에서 실행 중입니다. 그들은 모두 N에 연결되어 있다고보고합니다.

@ jimmys01 동일한 AP에 몇 개의 노드가 연결되어 있습니까?
그리고 그 AP의 브랜드는 무엇입니까? (미크로 틱?)

거의 모두 다른 AP (호텔 객실당 1 개)에 연결됩니다. 스위치 (PIR 센서), HTU 온도 및 습도 센서, IR LED가 있습니다.
AP 브랜드는 Mikrotik입니다.
설정은 다음과 같습니다.
국가가 설정 됨
제어 채널 : 20Mhz
밴드 : GN
확장 채널 : 비활성화 됨
인증 유형 : WPA2 PSK 전용
암호화 : aes ccm 전용
그룹 암호화 : aes ccm
Groyp 키 업데이트 : 00:01:00

B / G 설정에 대한 피드백 만 있습니다.
20 분마다 재부팅되는 하나의 장치에 테스트 fw를 설치했습니다. -72dBi로 N에 연결되기 전에. 연결을 끊지 않을만큼 충분한 신호 였어야합니다. -105dBi 수신 기능을 갖춘 엔터프라이즈 급 AP를 운영하고 있습니다. 따라서 다시 채널을 삭제해서는 안됩니다.

테스트 FW로 몇 시간 후 지금까지 재설정이 없었습니다.
계속 실행하고보고하겠습니다.

PS : 나는 그것이 어떻게 든 N과 관련이 있다는 것에 동의합니다.
PSS : 4M으로 업그레이드 된 20 x ESP-07 노드를 실행하고 있습니다. 시간이 많이 걸리지 만 재 플래싱이 필요할 때 비용을 지불합니다.

불행히도 유닛은 임의의 시간 후에 계속 재설정됩니다. 1-4 시간 이내의 모든 것.
B / G only FW가 문제를 해결하지 못함

동적으로 만들 겠다는 내 제안 (B / G 전용 설정에서 N으로 돌아 가기)이 왜 2 개의 "투표"를 받았는지 궁금합니다.
좋은 제안이 아닌 이유를 자세히 설명해주십시오.

외부 / 환경 적 상황으로 인해 Wi-Fi 자체가 한 시간 동안 다운되었다고 가정 해 보겠습니다. 내 노드가 N으로 전환되고 다시 매우 불안정 해집니다 (내 애플리케이션은 재부팅에 민감합니다. Wi-Fi는 항상 거기에있을 필요는 없지만 노드 자체는 항상 작동해야합니다).

나는 불안정성을 피하고 N에 연결하지 않는 내 노드에 대한 구성을 원합니다.

이것을 기본 설정으로 옮길 때이 옵션이 기본적으로 켜져있는 것이 좋습니다.

해결책으로 기본적으로 B / G 전용 또는 B / G / N으로 전환 할 수있는 폴백 모드 (B / G-then-N)로 배송 할 수 있습니다.

2.5.0의 실제 솔루션은 다음을 시도하십시오.

#include "esp_wifi.h"
esp_wifi_set_ps(WIFI_PS_NONE);

120 개 이상의 노드가 모두 GN (mega-20190202)에서 실행 중입니다. 그들은 모두 N에 연결되어 있다고보고합니다.

허용되는 기간 내에 120 개 이상의 노드를 어떻게 업데이트합니까 ??
".. 어떤 문제도 없습니다 ..."각 노드의 가동 시간을 확인 했습니까?
마지막으로 예정된 재부팅 이후 모두 동일합니까?

가동 시간은 일을 계산하며 모두 0 개의 재 연결이 있습니다. AP에서 PMKID를 비활성화했을 때를 제외하고는 몇 달 동안 연결에 문제가 없었습니다. 아마도 새로운 코어는 와이파이 설정에 대해 더 까다로워 졌거나 무엇인지 모르겠습니다. 나는 또한 2A 전원 공급 장치로 모든 것을 실행합니다. 다음 달에 esp8266을 80 개 더 배포 할 계획입니다. 그건 그렇고, @ TD-er 당신이 특정 설정을 볼 수 있도록 액세스를 원한다면, 나는 당신에게 그것을 줄 수있어서 기쁩니다. ESPEasy가 정말 멋있기를 바랍니다. 많은 도움이되었습니다.

편집 : @ chunter1 배치 스크립트를 사용하여 업데이트합니다.

curl -# -o /dev/null --form update=@ESP_Easy.bin --max-time 40 --connect-timeout 20 --retry 1 http://x.x.x.x/update

@ jimmys01 최근에 Mikrotik을 구입하여 물건을 테스트 할 수 있습니다.

그리고 코어 2.5.0 빌드에 대한 알림입니다.
다가오는 야간 빌드에는 2.5.0 빌드가 포함되어 있지 않습니다. 코어 2.5.0에 버그가있어 웹 서버가 응답을 멈추고 노드가 충돌하도록합니다.
이 문제가 해결되면 코어 2.5.0 빌드가 다시 생깁니다.
지난 밤 빌드에는 코어 2.6.0 알파가 포함되어 있습니다. 이것은 본질적으로 코어 라이브러리의 github에서 가져온 최신 코드이므로 직접 확인할 수 있습니다.

B / G가있는 2.6.0은 2 개의 모듈에서 4 일 이후로만 실행되었고 첫 번째 모듈은 재부팅했습니다.
재설정 이유는 일반적인 "하드웨어 감시 장치"였습니다.
"B / G"전용 모드가 활성화 되었기 때문에 내가 관찰 한 것은 재설정이 발생하기 전 3..5 일의 런타임입니다.

Wi-Fi 연결 해제 횟수를 비교할 수도 있습니다. 이러한 연결 해제는 충돌과 관련이있는 것 같습니다.

두 모듈 모두 Mikrotik AP에서 불과 2..3m 떨어진 지하실에 있습니다.
방금 동일한 FW 버전을 실행하는 두 번째 모듈을 확인했는데 0 회 재 연결 및 4d02h 가동 시간이 표시됩니다 (깜박임 이후 재부팅 없음).
나는 리셋을 한 다른 모듈을 매우 믿습니다. 또한 재설정하기 전에 0 개의 재 연결이있었습니다.

두 개의 테스트 모듈에 구성된 작업과 관련하여 :
재설정 된 모듈에는 120 초마다 값을 FHEM 서버로 전송하도록 구성된 12 개의 DS18B20 센서가 있습니다.
지금까지 재설정되지 않은 Tho 모듈에는 120 초마다 값을 동일한 FHEM 서버로 보내는 두 개의 gpios 만 구성되어 있습니다.

따라서 AP (Mikrotik)는 동일하고 거리 (2..3mm)는 동일하며 FHEM 서버는 동일합니다. 12 개의 온도 센서가있는 모듈 만 2gpios를 사용하는 모듈보다 확실히 더 자주 재설정됩니다.

내 노드에서 이것은 주로 fhem이 응답하기에 너무 느리거나 도달 할 수 없을 때 발생합니다.

내 노드에서 이것은 주로 fhem이 응답하기에 너무 느리거나 도달 할 수 없을 때 발생합니다.

재 시도가 100 회를 넘으면 노드를 재부팅해야하는 이유는 무엇입니까?
(테스트를 위해 재 시도를 0으로 설정했습니다)

도구-> 고급-> 연결 실패 임계 값

어떤 이유로 모듈의 Wi-Fi가 질식하면 잠시 후 재부팅됩니다.

"재시도"는 FHEM의 컨트롤러 설정에서 "최대 재시도 :"가 아니라 "연결 실패 임계 값 :"을 의미합니다.
연결 실패 임계 값을 0으로 설정했습니다.

BTW : 처음으로 "only B / G"가 활성화 되었음에도 불구하고 4WHS 타임 아웃 문제에 갇힌 노드가있었습니다 ... 지금까지 그런 적이 없었습니다 (자체 컴파일, 2.5.0 코어) .... 우연의 일치라면 계속 지켜 볼게요 ...

SDK3.0.0에는 많은 문제가 있으므로 사용 된 SDK를 SDK2.2.1로 되 돌리는 핵심 2.5.1이 곧 출시 될 것입니다.
이것은 또한 노드가 wifi에서 반응하는 방식을 변경할 수 있으며 코어 2.4.2와 다시 비교할 수 있습니다.
우리가 직면 한 다른 문제를 해결할 수있는 코어 2.5.0의 수정 사항이 포함되어 있는지 확실하지 않습니다.

@ chunter1 가지고있는 노드에 대해.
재부팅 된 사람이 컨트롤러에 더 많은 메시지를 보내는 것처럼 보이므로 통계적으로 말하면 프로세스 어딘가에 멈춰있는 무언가를 보내려고 할 가능성이 더 높습니다.

@ clumsy-stefan Github에서 현재 코드를 테스트 할 수 있습니까? (또는 최신 빌드)

네트워크 관련 활동을 수행하는 방법을 변경했습니다.

이걸 의미합니까?

ESP_Easy_mega-20190227_test_core_260_sdk3_alpha_ESP8266_4M.bin

어젯밤의 거의 모든 빌드.
또한 SDK2를 사용하여 코어 2.6.0 용 "일반"버전을 추가했습니다.
Core 2.6.0 SDK2는 이제 여러 노드에서 실행 중이며 리소스가 매우 낮은 (고용량 메모리 플러그인을 많이 실행하는) 그중 하나에 HW 워치 독 만 있고 플래시 메모리가 마모되었을 가능성이있는 노드 ( 1000의 펌웨어 업데이트가 있었으므로 버리십시오)

@ TD-er 저는 2test 노드에서 약 6 시간 전에 git에서 컴파일하고 설치했습니다.하지만 여전히 인터넷 액세스가 매우 제한되어 있으므로 24 시간 후에 만보고 할 수 있습니다.

Mikrotik 라우터를 사용하여 "Force B / G 모드"로 최신 펌웨어를 테스트 해 왔는데 지금까지 안정적으로 작동하는 것 같습니다. 다시보고합니다.

@ TD-er 한 가지 질문 : "강제 B / G 모드"가 설정되어있을 때 N 모드로 대체하는 규칙은 무엇입니까?

헉헉
_B / G only_로 AP 연결에 10 회 이상 실패하면 기본 BGN 모드로 복귀합니다.

따라서 AP가 한동안 오프라인 상태 인 경우 N 모드로 연결될 가능성이 있습니다.
이것이 진짜 문제인 것 같으면 10 번째 시도마다 그렇게하도록 설정할 수 있지만, 폴백 ssid를 시도 할 때도 시도하도록 설정해야합니다.

안녕하세요 @ TD-er
폴백은 나쁜 생각이라고 생각합니다.
이 시나리오를보세요 : 내 장치가 Mikrotik과 함께 행복하게 실행되는 B / G 모드로 설정되었습니다.
어떤 이유로 내 Mikrotik이 오프라인 상태가됩니다 (업데이트, 재부팅 등).
mikrotik이 다시 나타날 때마다 ESP는 N 모드로 연결되어 장치의 안정성을 잃었습니다.

즉, Force B / G 모드를 설정하고 연결이 실패하면 AP (192.168.4.1)가되어야하지만 N 모드로 대체해서는 안됩니다. 대체 가능성은 사용자에게 잘못된 기대치를 생성합니다.

오해하지 마십시오. 폴백은 변경 사항의 유효성을 테스트하는 데 유용했지만 이제 문제를 해결하는 것으로 입증되었으므로 (적어도 지금까지) 폴백을 제거해야합니다.

@ chunter1 댓글에 동의합니다 : https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment -462295204

다음 시나리오에 대해 어떻게 생각하십니까?
B / G 만 사용하여 주어진 AP에 연결할 수있게되면 더 이상 폴백을 제공하지 않도록 추가 플래그가 설정됩니다.
이러한 설정 중 일부 (B / G 만 또는 기타 AP 설정)가 변경되면 주어진 AP에 성공적으로 연결될 때까지 폴 백이 다시 활성화됩니다.

편집하다:
폴백이란 "폴백 SSID"가 아닌 추가 설정을 의미합니다.

즉, 폴백은 AP에 처음으로 성공적으로 연결될 때까지만 활성 상태를 유지 한 다음 제거됩니다. 이 경우 syspage에서 wifi 모드를 보는 것이 도움이 될 것입니다.
Force B / G를 설정하면 여전히 N으로 폴백을 피하는 것을 선호하더라도 가능한 솔루션입니다.
사용자가 실수를 할 가능성을 알고 있지만 사용자가 SSID를 잘못 입력하여 어떤 경우에도 장치에 액세스하지 못할 수 있습니다.

또 다른 질문 : 현재 구현에서 유닛이 AP가되는 시나리오는 무엇입니까?
B / G를 10 번 시도한 다음 N을 시도하는 것 같아서 결국 포기하고 AP가 될까요?

아니요, AP 모드는 주어진 AP에 대한 연결을 테스트하는 동안 활성 상태를 유지합니다.
가동 시간에 대한 선택적 검사를 추가하고 노드가 부팅 된 처음 10 분 동안 만 AP 모드를 시작하도록 허용해야 할 수도 있습니다.
추가 보안을 위해 그리고 AP 모드가 주어진 Wi-Fi 네트워크에 연결할 수없는 ESP에 영향을 미칠 수있는 가능성을 배제하기 위해.

그리고 우리는 프로젝트의 "쉬운"부분에 계속 집중해야합니다.
이는 적절한 기본값과 제공되는 과도한 양의 설정을 의미하지 않지만 모든 작업을 수행 할 수있는 옵션을 전문가에게 제공합니다.
이는 또한 경험이 적은 사용자를위한 적절한 대체 방법이 있어야 함을 의미합니다.
특히 B / G 전용 설정의 경우. ESPeasy로 시작하는 사람들의 90 % 이상이 802.11B / G / N의 차이점을 인식하지 못하는 것 같습니다. 따라서 폴백을 사용하여 매우 잘 처리 할 수있는 문제가 발생하면 다른 프로젝트를 찾게 될 수 있습니다. .
또한이 폴 백이 '안정성'에 대한 잘못된 인식을 제공해서는 안되는 이유를 이해하므로 현재 구현에 개선의 여지가있는 이유를 정말로 이해합니다. 그러나 "첫 번째 연결 시도 성공 => 대체 비활성화"가 자동으로 설정되면 경험이 많은 사용자에게도 완벽합니다. (누가 어리석은 실수를 저지르는 지, 내가 경험에서 알 수 있듯이;))

어떤 연결 설정이 적극적으로 사용되는지 더 명확히해야한다는 데 동의합니다.

이해했습니다.
따라서 prosal은 다음과 같습니다.
유닛 부츠.
N-fallback 플래그가 true로 설정됩니다.
FORCE B / G가 설정되어 있으면 B / G의 wifi AP에 10 회 접속을 시도합니다.
연결할 수 있으면 N-fallback flack을 false로 설정합니다.
연결할 수 없으면 N 모드로 시도합니다.

Force B / G가 설정된이 시나리오도 고려하십시오 : 정전.
ESP 및 Wifi 라우터의 전원이 꺼져 있습니다.
그런 다음 전원이 다시 들어오고 ESP가 Wi-Fi 라우터보다 빠르게 작동합니다.
이 경우 10 번 후에도 WiFi AP가 여전히 수신하지 않을 수 있습니다.
따라서 유닛은 N 모드를 시도하고 결국 성공할 것입니다.
(경험자) 사용자는 연결이 N- 모드인지 모를 것이고 안정성이 부족한 B / G 모드라고 생각합니다.

나는 주장하고 싶지 않지만 실제로이 HW 및 동결 문제는 1 년 이후로 진행되고 있습니다. 이제 커뮤니티의 도움으로 하나의 작동하는 솔루션을 찾았으므로 적용 할 수 있도록 강력하게 조언합니다. 경험이없는 사용자가 "Force B / G 모드"를 설정하는 위험은 동일한 결과로 잘못된 SSID를 설정하는 것보다 적습니다. 액세스 포인트에 액세스 할 수 없습니다.

암시:
경험이 부족한 사용자가 실수하지 않도록 "테스트 B / G 모드"에 버튼을 추가하는 것은 어떻습니까? 성공하면 "FORCE B / G 모드"를 활성화하고 그렇지 않으면 비활성화 상태로 유지합니다.

이 경우 경험이 적은 사용자는 자신이 무엇을하는지 알 수 있고 경험이 많은 사용자는 ForceB / G 모드가 설정되어있을 때 N으로 폴백 할 수 없음을 확신 할 것입니다.

어떻게 생각해?

당신은 할 수 있습니다

부팅하는 경우뿐만 아니라 대체 옵션이 설정에서 비활성화되고 저장됩니다.

확인. 그러면 자동 검사 대신 수동 검사가 더 적합합니다. 당신은 생각하지 않습니까?

예, 우선 재정의를 비활성화하기 위해 간단한 확인 표시를 추가합니다.
그러나 나중에 "전문가"가 실수를 덜하는 데 도움이되도록 더 동적으로 만들어야합니다. :)

확인

버전 2019_02_16은 이제 재부팅없이 9 일 동안 실행되었습니다 (B / G에 강제 적용). 어제 다시 재부팅하기 시작했습니다. 하드웨어 워치 독이 이것을 두 번 강제했습니다.
잠시 후 장치에 더 이상 연결할 수 없습니다. WLAN 라우터를 전환해도 도움이되지 않았습니다 (3 회 시도, 최대 30 분). 전원 퓨즈를 전환하여 ESP를 다시 시작해도 도움이되지 않았습니다.
wlan을 다시 종료하고 192.168.4.1을 통해 ESP에 직접 연결하여 액세스해야했습니다.

나는 무슨 일이 일어 났는지 전혀 모른다

@kischde 어떤 종류의 액세스 포인트를 사용하고 있습니까?
어젯밤 새 AP 설치를 실험하면서 비슷한 경험을했습니다.
MikroTik AP를 설치하려고했는데 ESP가 다시 연결해야 할 때까지 모두 정상적으로 작동했습니다.
MikroTik의 웹 인터페이스를 통해 노드가 WiFi에 연결되어 있음을 알 수 있지만 IP 주소를받지 못했습니다.
휴대폰의 핫스팟에 연결을 시도해도 ESP를 재부팅 할 수 있었지만이 동작을 반복했습니다.
메인 AP 구성을 다른 AP로 설정해야만 정상적으로 연결되기 시작했습니다.

이를 위해 노드가 재부팅되지 않았습니다.

내가 가지고있는 다른 MikroTik에 비해 해당 AP에서 "잘못됨"으로 설정된 한 가지는 "거리"설정이 "실내"로 설정되어 있다는 것입니다.
여기서 차이점을 확인하기 위해 더 많은 테스트를 수행 할 것이지만 앞에서 설명한 것처럼 패킷에 대한 응답에 대한 시간 초과 설정 인 것 같습니다.
그리고 ESP가 DHCP 요청에 응답하는 데 약간의 시간이 걸리는 것을 상상할 수 있습니다. 이는이 설정에 비해 너무 짧을 수 있습니다.

저는 Swisscom AP (swiss Telecom provider AP)를 사용하고 있지만 MikroTik을 사용하는 사람들과 같은 다른 장소에서 동일한 문제를 모두 여기에 기록했습니다. 따라서 동일한 칩셋이있을 수 있지만 설정에서 많은 것을 변경할 수 없습니다 (예 : 확장 설정).
전원을 다시 켜기 전에 나는 또한 당신과 같은 행동으로 내 모빌 전화와 연결을 시도했습니다.
고정 IP를 사용하고 DHCP는 사용하지 않습니다.
이제 실제 2019_03_05로 전환했습니다.

최근에 WiFi 설정을 변경하셨습니까?
예를 들어 MAC 주소가 BB : BB : BB : BB : BB : BB 인 SSID의 다른 AP의 위치 1에 MAC 주소가 AA : AA : AA : AA : AA 인 액세스 포인트
ESP의 일부 위치에 저장하지 않은 일부 설정이 남아 있다는 느낌을 받았습니다.

또한 NonOS 문서에서 WiFi 설정을 변경할 때 어떻게 효과적으로 지울 수 있는지 알아 보려고합니다.
또한 내 테스트에서 2 개 이상의 SSID를 사용하는 것이 정말 유용한 것으로 보입니다.
또한 여기에 더 많은 필드를 추가하거나 SPIFFS에 암호화 된 파일을 저장하여 거의 무제한의 WiFi AP를 저장하도록 허용 할 것입니다.

최근에 WiFi 설정을 변경하셨습니까?

아니요, AP가 하나뿐이므로 IMO가 필요하지 않았습니다.

확인. 알아 둘만 한.
이 문제의 원인을 아직 알지 못하기 때문에 가능한 한 많은 알려지지 않은 항목을 제거하려고합니다.
따라서 다시 작동하도록하려면 Wi-Fi 설정을 다시 추가해야합니다.

아니, 더 적은
192.168.4.1을 통해 esp에 직접 연결하도록 강요했습니다 (AP 비활성화).
모든 것을 확인했지만 비정상적인 것을 찾지 못했습니다. 그래서 ESP를 재설정하고 다시 실행하는 것보다 AP를 다시 시도하고 다시 시작합니다. 그래서 IMO는 "일반 / 기타"WLAN 연결을 강제로 수행해야했습니다.
BTW 또한 AP에서 연결되는 것을 보았지만 IP 주소가 할당되지 않았지만 고정되어 있습니다.

흠, 제가 가지고 노는 MikroTik에 5 개의 노드가 연결된 상태에서 조금 놀았습니다.

"Hw. Fragmentation Threshold"(옵션 '펼치기')를 설정하자마자 ESP 노드는 더 이상 IP 주소를받을 수 없습니다.
이 설정의 기본값은 256입니다. 1600 (전체 MTU에 맞음)으로 설정하면 모든 노드가 IP 주소를 받고 계속 작동합니다.

노드가 통신 할 수있을 때 MikroTik UI에 표시됩니다.

그리고 데이터를 송수신 할 수없는 경우 (WiFi 레이어에 연결되어 있음)

@ TD-er 새로운 esp8266 코어에 LWIP_FEATURES 라는 옵션이 있다는 것을 보셨나요?이 옵션은 IP 리 어셈블리를 활성화 할 것입니다 ... 아마도 빌드에 정의되어 있지 않습니까?

여기를 참조하십시오 : https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L748 -L754

IP 조각화에 대한 지원도 다음과 같이 설정됩니다.
https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L756 -L763

흠, 기본값이 무엇인지 잘 모르겠습니다.
Doxygen 문서 의 첫 번째 줄에있는 숫자가 기본값입니까?

글쎄요 ... 저는 아두 이노 IDE에서 plattforms 정의 파일을 포함하고 정의할지 여부를 선택할 수 있습니다.

저는 항상 LWIP 부분이 코어 배포판에 미리 컴파일 된 라이브러리로 포함되어 있다고 생각했습니다.
따라서 LWIP가 올바른 플래그를 사용하여 다시 작성되는지 확인하는 것은 매우 어렵습니다.

예, 그러나 어떤 링크에 연결하는지에 따라 다릅니다 (boards.txt에서) :

-llwip2-536-feat
-llwip2-536
-llwip2-1460
-llwip2

그래서 그들은 다음 플래그를 사용하고 있습니다.

https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/boards.txt#L357 -L387

| 레이블 | build.lwip_lib | build.lwip_flags |
| --- | --- | --- |
| v2 낮은 메모리 | -llwip2-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 더 높은 대역폭 | -llwip2-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 낮은 메모리 (기능 없음) | -llwip2-536 | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 더 높은 대역폭 (기능 없음) | -llwip2-1460 | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 IPv6 하위 메모리 | -llwip6-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v2 IPv6 더 높은 대역폭 | -llwip6-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v1.4 더 높은 대역폭 | -llwip_gcc | -DLWIP_OPEN_SRC |
| v1.4 소스에서 컴파일 | -llwip_src | -DLWIP_OPEN_SRC |

따라서 모든 v2 버전에는 "기능 없음"으로 표시된 버전을 제외하고 LWIP_FEATURES=1 가 있습니다.

예,하지만 -l 문을 보면 마지막에 -feat 있는 라이브러리를 확인해야합니다 (라벨과 달리 약간 직관적 임) ...