Espeasy: MQTT는 20181008 이후 작동 중지

20181004에서는 다음이 변경되었습니다.

• [sendHttp] # 1830 시간 초과 설정 및 시간 초과시 조기 종료
• [WiFiClient] 시간 제한을 설정하고 컨트롤러에 대해 구성 가능하도록 설정
• [코어 2.4.1] 2.4.2에서 코어 2.4.1로 다시 이동

그리고 20181006 :

• [WiFi] ControllerSettings에서 연결 시도 지연 추가

20181003 빌드를 테스트하고 문제를 좁히기 위해 다른 2도 테스트 할 수 있습니까?

노력 할게요하지만 토요일까지 못 할까봐 걱정됩니다. ;-)

MQTT 연결이 끊어 질 때까지 걸리는 시간에 대해 알고 있습니까?
그리고 그것은 어떻게 든 Wi-Fi 재연 결과 일치합니까?

내가 볼 수있는 한, 와이파이 손실은 없었습니다.
MQTT 연결이 끊어 졌다는 것은 오늘 아침 (10 분) 매우 빠르지 만 IOBroker의 마지막 항목에 따르면 몇 시간이 걸렸습니다.
오늘 밤 3 개의 빌드 중 하나 이상을 시작하려고합니다.

수표처럼 직접 빌드합니까, 아니면 야간 빌드를 사용합니까?

확인해야 할 또 다른 사항 :

MQTT가 작동을 멈춘다 고 확신합니까?
여기에있는 나의 것은 잠시 후에 "Connection LOST"를 보여 주지만 모든 것이 여전히 MQTT와 함께 작동합니다.

내가 보는 유일한 버그는 모든 것이 여전히 작동하는 동안 "연결이 끊어졌습니다"라는 메시지입니다.
예를 들어 MQTT 컨트롤러로 가동 시간 (분)을 얻습니다.
잠시 후 (10 분에서 10 시간 사이) "연결 끊김"이 표시되지만 분은 여전히 ​​MQTT를 통해 전송을 계산합니다.

Greetz
사샤

MQTT는 더 이상 연결되지 않았 음을 감지하는 즉시 재 연결을 수행해야합니다.
@ Sasch600xt 기타 관련 문제도 참조하십시오.
https://github.com/letscontrolit/ESPEasy/issues/1873#issuecomment -431170001

20180927 이전에 몇 가지 빌드가 정상적으로 작동한다고보고 한 경우, 브로커가 새 연결을 거부하지 않도록 ESP의 MQTT 클라이언트가 자체적으로 새 클라이언트 ID를 제공하는 MQTT 컨트롤러에 대한 수정 사항을 추가했습니다. 브로커는 여전히 해당 클라이언트의 기존 연결을 가정하고 클라이언트는 연결이 끊어진 것으로 생각합니다.

컨트롤러의 타임 아웃 설정을 늘릴 수 있습니까? 이 설정을 도입하기 전에 기본값은 1000 밀리 초였으며 첫 번째 빌드는 기본값으로 100 밀리 초였습니다. 나중에 기본값 (새 설정의 경우)을 300msec로 변경했습니다.
따라서 테스트로 300 이상 (1000msec 이하)으로 설정할 수 있습니다. (어떤 버전이든, 적어도 하나는 실패했습니다)

나는 1 (5) 유닛에서 동일한 문제를 경험했습니다. MQTT 컨트롤러 설정 (최소 전송 간격, 최대 큐 깊이, 최대 재시도 및 전체 큐 작업)을 약간 사용했습니다. 이 장치에서 지금 작동하는 설정 : 1000ms, 5/5 및 "가장 오래된 항목 삭제".

알겠습니다 ...
12 시간 전에 댓글을 단 blb4github가 언급 한 것과 동일한 문제인 것 같습니다. 새로운 유닛을 가져 왔고 지금까지 문제없이 작동합니다 !!!! "오래된"메모리 문제 나 타이밍 문제가있는 것 같습니다. 나는이 시간을 늘리려 고 노력할 것입니다 ... 계속 알려드립니다 ;-)
Btw .. (죄송합니다 .. Atom으로 Selfbuild .. 왜냐하면 모든 플러그인을 원하지 않기 때문입니다 ...하지만 지금까지는 항상 잘되었습니다 ..) 여러분 모두 이것에 대해 훌륭한 작업을하고 있습니다 ... 그리고 제가 발견 한 한 이 문제가있는 것은 이것뿐입니다 (따라서 최신 SW를 사용하는 것). 설정을 늘리고 알려 드리겠습니다.

안부 피터

@fraeggle 여기에 좋은 모듈과 나쁜 모듈 시스템 정보 페이지의 스크린 샷을 붙여 넣을 수 있습니까? (esp 및 저장 섹션)

그리고 하드웨어에 대한 설명.
예를 들어, 최근에 sonoff 모듈에 몇 가지 변경 사항이 있다는 느낌이 있습니다.
Sonoff 기본 및 S20

@fraeggle 문제가있는 노드를 완전히 지우고 정리를 시작할 수도 있습니까?
빈 bin 파일은 릴리스 ZIP 파일에 포함되어 있습니다.

안녕하세요 TD-er
나는 전에 나쁜 노드를 지 웠습니다 ... 시간 초과 설정을 800ms로 변경했기 때문에
안정적입니다. 전압은 120 초마다 업데이트됩니다.

하드웨어는 특별하지 않습니다 .... INA219가 도착하기를 기다리고 있기 때문입니다 .. ;-)

안부 피터

안타깝게도 닫았어요 ..

하지만이 "workaroud"로 닫을 수 있다고 생각합니다. 지금은 정말 단위 문제라고 생각합니다 ..
TD-er에 대해 어떻게 생각하십니까?

여전히이 측면에서 단위가 다른 것은 이상합니다.
Wi-Fi 안정성이 한 장치에서 더 나쁘다는 것을 암시합니다.

동의하지만이 단위는 공차 범위가 너무 크다고 생각합니다. 내가 말했듯이 800ms로 변경했기 때문에 잘 작동합니다 ...
따라서 동의하면 시간 제한을 변경할 수있는 기능이 있기 때문에이 항목을 닫겠습니다.

당신의 도움을 주셔서 감사합니다..

안부 피터

나는 "20181007 MQTT Open Hab이"연결이 끊어졌습니다 "# 1873을 보여주기 때문에 찾았습니다.
같은 문제일까요?
TD-er가 로그 또는 이와 유사한 것을 생성하여 도움을 줄 수 있는지 알려주십시오.
Openhab 사용 (IOBroker 사용). 하지만 지금까지 Timeout을 800ms로 설정 한 후 오류가 없습니다.

OpenHAB 용 MQTT 브로커가 실행 중이거나 자체 네트워크의 컴퓨터에 설치되어 있습니까, 아니면 외부에 있습니까?
그리고 로컬이라면 리소스가 부족한 컴퓨터에 설치되어 있습니까?

20181020에서 394 분 이후로 테스트를 실행했습니다.
800ms의 시간 초과.
때로는 24 시간 이상이 지나면 연결 끊김으로 표시됩니다. 그러나 나는 2 일에 도달하지 못했습니다.
다시 말하지만 "연결이 끊어졌습니다"라는 메시지가 표시된 후에도 여전히 작동합니다. 그래서 그것은 저에게 혼란스러운 메시지입니다. 계속 알려 드릴게요

연결 끊김은 연결이 끊 겼음을 나타내는 정보 메시지 일뿐입니다.
그러나 새 연결을 다시 시작해야합니다.
sysinfo 페이지에서 WiFi 연결이 끊어지고 재 구축 된 빈도와 액세스 포인트에 마지막 (재) 연결 한 이후 WiFi에 연결된 시간을 확인할 수 있습니다.

WiFi 연결이 중단 되 자마자 MQTT 연결을 다시 구축해야한다고 가정하므로 MQTT 브로커에 대한 연결이 끊어진 것으로 간주합니다.
4 주 전까지는 브로커가 여전히 클라이언트가 연결된 것으로 간주했기 때문에 MQTT 브로커가 새 연결 시도를 수락하지 않을 수있었습니다.
이로 인해 클라이언트가 계속 연결을 시도하고 브로커가 연결을 수락하지 않을 때 무제한 재 연결 시도가 발생할 수 있습니다.
다시 연결할 때마다 MQTT 클라이언트 ID를 변경하여 (클라이언트 ID에 다시 연결 횟수 추가) 브로커가이를 새 클라이언트로 간주합니다.
이로 인해 빠른 재 연결이 가능하며 유일한 단점은 클라이언트가 연결이 끊어진 것으로 가정하므로 브로커가 LWT (마지막 유언장)를 보냅니다.

그 결과 원치 않는 행동이 발생하면 새로운 전략으로 변경할 수 있습니다.
예를 들어 실패한 재 연결 시도에서 먼저 적절한 연결 해제 메시지를 보내려고 할 수 있습니다.

요컨대, 브로커와의 연결이 끊어 질 수있는 수많은 옵션이 있으며 귀하의 경우 왜 끊어 지는지 잘 모르겠습니다.
시간 초과, WiFi 연결 끊김, 브로커의 알 수없는 응답 또는 기타 이유 일 수 있습니다.

알았어 ..... 알았어.
아주 좋은 말입니다, 감사합니다.
지금 507 분 / HAB 컨트롤러 열기 / 800ms 시간 초과입니다.
지금까지 모두 좋습니다 :)

컨트롤러의 새 인스턴스에 대한 기본 시간 제한을 다시 1000 밀리 초로 설정해야합니까?

음 ... 36 시간 더 줘 ..... 그러면 버그가 800ms인지 아닌지 더 잘 알고 있습니다.

629 분 이제 문제없이 ...

이상합니다 ... 800ms로 변경 한 후 발견되었습니다.
마지막 연결 해제 이유 | (200) 비콘 시간 초과
번호 재 연결 | 삼
das Beacon Timeout은 무엇을 의미합니까?
MQTT는 여전히 실행 중이지만 현재 Sasch600txt와 동일합니다. 하지만 이전과는 다른 ... MQTT는 여전히 작동합니다.
오직 브로커 만이 연결되지 않았다고 알려줍니다.

비콘 프레임에 대한 자세한 내용은 Wikipedia를 참조하십시오.
요컨대, 액세스 포인트는 네트워크에 대한 정보가 포함 된 패킷을 주기적으로 보냅니다.
이 간격은 일반적으로 100TU (102.4msec)입니다.
ESP 모듈은 매번이 비콘을 수신하려고하지만 여러 가지 이유로 비콘 프레임을 놓칠 수 있습니다. 시간 초과가 100TU보다 길기 때문에 비콘 시간 초과를보고하려면 이러한 비콘 프레임 수를 놓쳐 야합니다.
이러한 비콘 프레임을 놓치는 이유는 다음과 같습니다.

• 다른 차단 작업을 처리하는 데 너무 바쁘다 (매우 가능성 있음)
• 다른 사람의 높은 트래픽 요구로 인해 비콘을 보내지 않는 액세스 포인트 (브랜드 / 모델 / 설정에 따라 다름)
• RF 장애 (얼마나 자주 발생하는지는 알 수 없음)
• 클럭 드리프트 (그럴 가능성은 거의 없음)

따라서 "비콘 타임 아웃"은 때때로 ESP 노드에서 발생합니다.
모든 플러그인 / 컨트롤러가 짧은 시간 조각을 사용하여 작업을 최대한 차단하도록 만들기 위해 열심히 노력하고 있습니다.

나는 fraeggle이 말한 모든 것을 확인할 수 있습니다.
언젠가 오늘 밤 "연결이 끊어졌습니다"

좋은 주말 되세요 :)
사샤

@fraeggle :
"Connection Lost"로 표시되면 ESPEasy의 컨트롤러 설정으로 이동하여 컨트롤러를 비활성화하고-> 저장하고 다시 활성화-> 저장하십시오. 그런 다음 적어도 나에게는 다시 연결된 것으로 표시됩니다. 해결책은 아니지만 적어도 intresting :)이 IPSymcon을 사용하고 있습니까?

@ TD-er :
너무 바쁜 작업? 음 ...... 여기에서 실행중인 "TEST UNIT"에서는 60 초마다 가동 시간 (분) 만 보냅니다 ....이 장치에서는 더 이상 실행되지 않습니다 ..... 그래서 아마도 가능한 가장 작은 시스템 일 것입니다.

@ Sasch600xt "너무 바쁘다"라는 용어는 실제 문제를 설명하는 가장 좋은 용어가 아닐 수 있습니다.
Arduino 방식은 다음과 같습니다.

• setup()
• loop() 계속해서 전화하세요.

또한 ESP8266 (및 ESP32 Arduino) 용 Arduino 버전은 Arduino 부품의 loop() 외부에서 일부 작업을 실행하고 있습니다.
이러한 작업은 네트워크 연결 및 수신 트래픽 처리 등과 같은 백그라운드 프로세스에 관한 것입니다.
백그라운드 작업은 다음 위치에서만 실행됩니다.

• loop() 끝
• Arduino 공간 내에서 delay() 또는 yield() 를 호출 할 때.

루프 실행에 102.4msec 이상이 걸리고 yield () 또는 delay ()에 대한 호출이 수행되지 않으면 ESP 노드가 비콘 간격을 놓친 것입니다.
또한 WiFi 액세스 포인트가 비콘을 보내는 순간에 항상 바쁜 여러 차단 작업을 실행하는 경우 많은 비콘이 누락됩니다.

직렬 로그를 보면 (디버그 수준이 활성화 된 상태) 타이밍 통계가 표시됩니다.
그들 중 일부는 수십 msec를 만들 수 있으므로 이러한 '연결 해제'이유를 유발할 수 있습니다.

스케줄러에 작업을 추가하여 102.4msec마다 비콘을 청취 할 수 있습니다. 유일한 것은, 그러한 표지가 언제 보 였는지 어떻게 볼 수 있는지 잘 모르겠다는 것입니다.

이 문제에 대해 연결이 끊어졌을 때 MQTT의 연결 해제 / 재 연결을 조사 할 수 있습니다.
어떤 브로커를 사용하고 있습니까? 나는 여기서 모기를 사용하고 있으며 현재 동작으로 잘 작동합니다.

좋아요, "너무 바빠요"는 나에 대해 조금 쉬운 말이었습니다. :)

MQTT 브로커 용 ipsymcon housecontrol eviroment 에서 실행되는 스크립트를 사용하고 있습니다.

Greetz
사샤

안녕 Sascha .. IOBroker 사용.
@ TD-er는 빌드 27092018로 돌아갔습니다. 브로커가 여전히 연결되어 있다고 알려줍니다 ...
정말 혼란 스럽습니다 .. 14 시간 이내에 오류 없음 (재 연결 횟수 | 0)

무슨 일이 일어나고 있는지보기 위해 지금 내 컴퓨터에 IObroker를 설치하고 있습니다.

편집하다:
45 분 후 컴퓨터에서 IObroker를 실행할 수 없습니다.
여기서 무슨 일이 일어나고 있는지 확실하지 않지만 Windows 설치 프로그램이 작동하지 않고 (서비스 bat 파일을 찾을 수 없음) Linux에서의 설치가 완료되지 않습니다. 동일한 npm 설치를 반복해서 시도합니다.
Intel CPU 호스트의 Ubuntu 18.04 및 Windows의 Bash (Ubuntu 18.04)에서 테스트되었습니다.

Windows와 확실하지 않습니다 .. 일부 소프트웨어 종속성이 있다고 생각합니다. Raspberry에서 실행 중입니다.
Windows 용 ioBroker 버전 Node.js는 Plattform 및 setzt diese voraus를 지원합니다. (다운로드 : http://nodejs.org/download/) 먼저 node.js를 설치해야합니다.

또한 4 개의 DS18B20 센서가 연결된 모듈 하나에 문제가 있습니다.
나는 그것이 내 RasPi라고 생각했지만 깨끗한 Raspbian Streth 이미지를 가져 와서 모기와 노드 레드를 설치했습니다. 같은 문제, 6-12 시간 후에 연결이 끊어집니다.

대시 보드 : https://emoncms.org/Edegem/scrtmp2e
ESP의 4 개의 곡선은 CV_aanvoer, CV_retour 및 Sanitair_warm, Sanitair_koud입니다.

공식 빌드를 사용한다면 @fluppie ?

아니요, PlatformIO / Atom으로 직접 구축합니다.
편집 : 하, 나는 잘 읽지 않았고, 공식 빌드를 시도 할 것입니다.

이걸 보자!

안녕하세요

나는 HomeAssistant를 사용하고 있지만 ESPEasy_mega-20181111 fw 이후에 문제가 해결 된 것처럼 보입니다.

고마워
티

2 ~ 3 일 후에도 여전히 연결이 끊어졌습니다. ESP_Easy_mega-20181112_normal_ESP8266_4096.bin으로 업데이트하겠습니다.

보자!

내 것은 죄수를 잃었다. 1-10 시간 후. 나는 ~ 10h30min 가동 시간과 모든 (5pcs) 관련 모듈이 연결되어 있습니다. :-)

안정적인 연결이 필요하기 때문에 여전히 2709에서 시도해 볼 가치가 있습니다. Pls는 나에게 정보를 제공합니다. :-))

https://emoncms.org/Edegem/scrtmp2e를 통해 팔로우하고 CV_ 및 Sanitair_ 그래프가 있는지 확인할 수도 있습니다. :).

1 일 가동이지만 여전히 괜찮습니다. :-)

https://emoncms.org/Edegem/scrtmp2e를 통해 팔로우하고 CV_ 및 Sanitair_ 그래프가 있는지 확인할 수도 있습니다. :).

:-D Sanitair_warm 거의 60 C? 작은 모닥불? ;-)
회사에 도전하겠습니다 .. 감사합니다 ...

나는 샤워하고 있었다 ;-)

1 일 ... 여전히 연결됨 :-D
12112018 사용

~ 3 일 3 시간 후 내 장치 중 하나가 MQTT 연결이 끊어졌습니다. :-( (mega-20181112 4096 VCC fw)

@redskinhu :
확인하기 위해 장치가 MQTT 연결을 잃은 후에도 여전히 잘 작동합니까?
내 쪽에서는 "연결이 끊어졌습니다"로만 표시되지만 모든 MQTT 작업에서 여전히 잘 작동하기 때문입니다.

Greetz
사샤

사실, 연결이 끊기는 경우가 드물지 않습니다.
사람의 개입없이 연결이 재 구축되는 한 문제가 없습니다.
WiFi 연결은 때때로 재설정되며이를 방지하기 위해 할 수있는 일은 없습니다.
이러한 연결이 끊어지면 동일한 노드의 MQTT 클라이언트에 다시 연결하도록 알립니다.

일종의 LWT 관련 문제로 보입니다. MQTT는 완전히 연결 해제되지 않았고, ESPEasy는 MQTT 메시지를 전송 / 수신하지만 LWT가 갱신되지 않아 HomeAssistant가 LWT 연결 메시지를받지 못해 관련 센서 / 스위치를 사용할 수 없음을 표시합니다. 이것은 내 이론입니다 ...

내 첫 번째 게시물과 달리 여전히 연결되어 있고 MQTT LWT도 연결되어 있다고 말합니다. 좋아 보인다.

사실, 연결이 끊기는 경우가 드물지 않습니다.
사람의 개입없이 연결이 재 구축되는 한 문제가 없습니다.
WiFi 연결은 때때로 재설정되며이를 방지하기 위해 할 수있는 일은 없습니다.
이러한 연결이 끊어지면 동일한 노드의 MQTT 클라이언트에 다시 연결하도록 알립니다.

이 경우 연결된 LWT를 갱신 할 수 있습니까?

연결을 갱신하는 순간 LWT를 보내야합니다.

LWT에서 분리 된 것으로 표시된 노드가 있으며 측정 값을 잘 보냅니다. 조금 오래된 빌드 ... 어쩌면 이것은 당신에게 뭔가를 알려줍니다

GIT 버전 : | mega-20181008
가동 시간 : | 3 일 17 시간 36 분

ESP 노드가 연결이 끊어 졌다고 생각하고 다시 연결해야한다고 생각할 때 이상한 일을 보았지만 브로커는 동의하지 않습니다.

안녕하세요

나는 작은 조사를했다. LWT가 문제인 것 같습니다. 내 ESP 중 하나가이 MQTT "연결 끊김"을 다시 생성했습니다.

모든 것이 잘 작동합니다. 센서 / 스위치. 그러나 구성에서 LWT 세부 정보를 제공했기 때문에 홈 어시스턴트가 볼 수 없었습니다.

- platform: mqtt
  name: "Socket 02"
  command_topic: "home/Socket02_ESP12F/GPIO/13"
  state_topic: "home/Socket02_ESP12F/Relay/State"
  availability_topic: "home/Socket02_ESP12F/status/LWT"
  payload_available: "Connected"
  payload_not_available: "Connection Lost"
  payload_on: "1"
  payload_off: "0"
  qos: 1

MQTT 트래픽을 확인했습니다. 센서 데이터를 얻었고 GPIO를 켜고 끌 수있었습니다. 모든 것이 괜찮습니다. LWT.

LWT "Connected"메시지를 공개 한 후 모든 것이 정상으로 돌아 왔습니다.

도움이 되었기를 바랍니다.

티

추신:
LWT 메시지가 Disconnected 인 경우 LWT Connected 메시지를 게시 할 수있는 규칙 하나에 대해 생각하고 있지만 슬프게도 MQTT 문자열을 가져올 수 없습니다 ;-)

어쨌든 나는 새로운 fw 릴리스를 간절히 고대하고 있습니다. 긴 4 일 ....

나는 월요일 / 화요일에 집을 비 웠고 그 다음날은 정말 바빴습니다.)

다시 연결할 때 게시되지 않는 이유를 찾을 수 있는지 확인하기 위해 LWT를 살펴 보겠습니다.

MQTT 브로커의 제한 시간 설정은 무엇입니까?
브로커가 연결이 끊어진 것으로 가정 할 가능성에 대해 생각하고 있지만 ESP 노드는 여전히 활성 상태이고 여전히 연결된 것처럼 작동합니다.

나는 100-1000ms를 시도했습니다. 이제 300입니다. 상관 없습니다.

컨트롤러가 아니라 브로커에 있습니다.
이러한 타이밍은 10 ~ 15 초 정도입니다.
따라서 브로커의 설정에서 어떤 타임 아웃이 사용되고 있는지 확인하십시오.

LWT 시간 제한에 대해 아무것도 변경하지 않았고 Mosquitto 구성에서 관련 설정을 찾을 수 없습니다. 기본값이어야합니다. 문서에서도 LWT 제한 시간 설정을 찾을 수 없습니다.

LWT 제한 시간이 아니라 브로커의 제한 시간입니다.
클라이언트가 제한 시간 내에 메시지를 보내지 않으면 브로커는 연결이 끊어진 것으로 간주합니다.
따라서 클라이언트가 다른 제한 시간 설정을 사용하는 경우 브로커가 클라이언트 연결이 끊어진 것으로 간주하고 클라이언트가 다시 연결을 시도하지 않을 수 있습니다.

mqtt 사양에서 이해하는 것은 브로커가 클라이언트가 설정 한 Keep Alive 기간 내에 클라이언트로부터 메시지를받지 못하면 LWT를 보냅니다. 브로커 측에서 구성 할 사항이 없습니다.

https://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over 참조

과

https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament

그것은 사실입니다. 그러나 제가 알고 싶은 것은이 "Keep Alive Period"가 브로커 측에 무엇인지입니다.
나는 그것이 ESPeasy 쪽에서 고정되어 있다는 것을 알고 있습니다.
그러나 이것이 서로 동기화되지 않으면 이상한 일이 일어나는 것을 보게 될 것입니다.

음 난 이런 걸 설정할 가능성이 없어

그러나 여전히 "연결됨"이라고 말합니다. 4 일 :-D

메가 -20181006 한 대가 똑같이했습니다. LWT가 온라인으로 업데이트되지 않았지만 정상적으로 작동하는 MQTT

@ jimmys01 클라이언트 ID에 기반한 결정을 중개인에서 볼 수 있습니까? (연결이 끊어지면 변경됨)
이 클라이언트 ID 변경은 9 월 말 빌드에서 추가 한 것입니다.

@ TD-er, 나는 이것을 재현하는 방법을 찾았습니다! 나는 mikrotik 라우터에서 wemos를 인증 해제하고 바로 백업에 연결하지만 mqtt가 여전히 작동하는 동안 LWT는 오프라인으로 유지됩니다. 마음대로 테스트 할 빌드 보내기

MQTT 브로커에서도 클라이언트 ID를 볼 수 있습니까?
클라이언트 ID 뒤에 "-1"또는 무언가가 있으면 새 클라이언트 ID를 수락한다는 의미입니다.
그렇지 않다면 얼마 전에 만든 클라이언트 ID 변경과 관련이있을 수 있습니다.

나는 클라이언트 ID가 Mosquitto에있는 곳을 더럽 히지 않았지만 로그에 클라이언트가 연결되지 않고 새 클라이언트가 연결된 것처럼 표시됩니다. 아마도 wifi de-auth 및 auth 프로세스가 MQTT 프로토콜의 하트 비트보다 빠르기 때문일 것입니다.

esp와 브로커를 모두 다시 시작한 후 새 연결

 New connection from 10.10.1.53 on port 1883.
1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').

클라이언트의 인증을 해제하면 클라이언트가 다시 연결됩니다. 이번에 브로커는 어떤 이유로 클라이언트 LWT를 온라인 상태로 남겼습니다 ...

1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965308: New connection from 10.10.1.53 on port 1883.

두 번째 인증 취소

1542965308: New client connected from 10.10.1.53 as aquariums_1_1 (c1, k10, u'openhabian').
1542965308: Socket error on client aquariums_1, disconnecting.
1542965385: New connection from 10.10.1.53 on port 1883.

이 재연 결과 LWT에서 오프라인 상태로 유지되면 MQTT 메시지가 제대로 작동합니다. 클라이언트 이름에 추가 _1_1이 있습니다.

1542965385: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965385: Socket error on client aquariums_1_1, disconnecting.
1542965448: Socket error on client aquariums_1, disconnecting.

알겠습니다. 그러면 클라이언트 ID 변경을 되돌립니다.
클라이언트가 연결된 것으로 간주되면 원격으로 확인할 수도 있습니까?
브로커가 클라이언트가 여전히 연결된 것으로 간주하고 클라이언트가 다시 연결을 시도 할 때 연결이 거부되는 것을 보았습니다.
짧은 간격으로 재 시도하면이 상태가 유지되므로 클라이언트는 다시 연결할 수 없습니다.

이것에 대한 상태 업데이트가 있습니까?

아니, 아직.
그러나 우리는 다른 안정성 문제에 대해 (마지막으로) 약간의 진전을 이루고 있으므로 내 목록에 다음이 될 것 같습니다.
핑 주셔서 감사합니다;)

다시 연결할 때 클라이언트 ID를 변경하는 것을 선택 사항으로 만들었습니다. (도구 => 고급, 다른 MQTT 설정 옆)

지금 작동하는 경우 문제를 닫으십시오.
고정으로 설정하겠습니다.

어쨌든 클라이언트 ID를 변경하는 이유는 무엇입니까?

브로커가 클라이언트가 여전히 연결되어 있다고 가정하는 한 브로커가 연결 시도를 거부했다는보고가있었습니다.
그래서 클라이언트는 거절 당했고 다시 시도했습니다.
그러나 어떻게 든 이러한 재 연결은 연결 시도를 해당 클라이언트의 최근 활동으로 간주하기 위해 브로커 측에서 무언가를 트리거하므로 클라이언트가 연결 해제 된 것으로 간주하지 않습니다.

좋아,이게 전부 였지만, 그 확인란을 보는 다른 사람들에게는 해결책이 자명하지 않습니다.
Wi-Fi가 끊긴 후 재 연결 문제가있는 경우 표시 할 팝업을 추가 할 수 있습니다.
tasmota 문제를 검색하면 MQTT 보유와 관련된 유사한 문제가 브로커 문제인 것처럼 보임을 알 수 있습니다.
또한 한 클라이언트가 인증을 해제 한 후 Wi-Fi에 다시 연결하지 않는 경우도있었습니다. 조사해야합니다.

이것을 문서에 추가 할 것입니다.
우리는 문서를 최신 상태로 유지하고 위키에서 ReadTheDocs로 많은 문서를 옮기기 위해 매우 열심히 노력하고 있습니다. 이를 통해 버전별로 문서를 보유 할 수 있습니다.
문서 파일은 GitHub 저장소에도 포함되어 있습니다.

이상적으로 코드 수정에 대한 커밋에는 문서 업데이트도 포함됩니다.
이제이 문제를 닫겠습니다.
언급 한 다른 문제에 대한 추가 정보가있는 경우 새 문제를여십시오.

안녕하세요

최근에 20190110 릴리스를 설치했습니다. 유망 해 보인다. 테스트 5 일 후 LWT 문제가 없습니다. :-)
"재 연결시 MQTT 변경 ClientId"옵션이 활성화 된 노드와 비활성화 된 노드가 있습니다.

좋은 소식!

티