deconz-rest-plugin 🚀 - IKEA 조명이 때때로 연결이 끊어짐

여기 2.05.58과 동일합니다. 하나의 Tradfri GU10은 무책임한 ATM으로 보입니다.

며칠 전에 색조 라이트 스트립과 함께 나에게 발생했기 때문에 IKEA 특정 문제가 없다고 생각합니다. 장치는 전원을 껐다가 켜야하며 그 후에는 정상적으로 돌아옵니다. 어떤 경우에는 여전히 성가신 데, 대부분 직접 전원이 공급되고 전원을 껐다 켜는 벽 스위치가없는 FLOALT 패널의 경우입니다.

peer69 에 2019년 02월 14일

이유는 무엇입니까?

REST API 플러그인은 상태에 대해 조명을 폴링 할 때 몇 번 응답을받지 못하면 조명을 연결할 수 없음으로 표시합니다. 응답을받지 못하는 원인은 다음과 같습니다.
ㅏ. 조명의 전원이 차단되었습니다 (예 : 20 세기 벽 스위치에 의해);
비. Zigbee 네트워크에 딸꾹질이 있습니다 (예 : 메시의 무선 간섭 또는 라우팅 문제로 인해). 이 경우 라이트는 여전히 그룹 명령에 반응합니다.
씨. 라이트의 펌웨어가 충돌했습니다.

연결을 복구 한 후 전원을 분리 / 연결할 수 있습니까?

a) 및 c) : 아니요. b) : 예.

REST API 플러그인은 라이트에서 메시지를 수신 할 때 도달 가능한 것으로 표시합니다. 조명을 켜면 _Device Announcement_ 메시지가 전송됩니다. b)에서 일반적으로 다음 폴링이 성공하면 빛이 자발적으로 돌아옵니다. deCONZ GUI에서 노드를 선택하고 0 누를 수도 있습니다.

ebaauw 에 2019년 02월 14일

👍1

버전 2.05.59에서도 같은 문제입니다.

thomas70 에 2019년 02월 14일

2.05.59로 업그레이드 한 후에도이 문제가 있습니다. 오늘은 나의 세 가지 실외 조명 "사라진"중 하나였습니다.
그것의 Tradfri 전구는 모두 세 가지입니다.

rich710se 에 2019년 02월 15일

@ebaauw 설명해 주셔서 감사합니다.

ㅏ. 조명의 전원이 차단되었습니다 (예 : 20 세기 벽 스위치에 의해);

이 조명에 사용할 수있는 벽 스위치가 없으므로 실수로 전원을 차단할 수 없습니다.

비. Zigbee 네트워크에 딸꾹질이 있습니다 (예 : 메시의 무선 간섭 또는 라우팅 문제로 인해). 이 경우 라이트는 여전히 그룹 명령에 반응합니다.

연결이 끊어지면 조명이 그룹 명령에 반응하지 않습니다 (조명은 Phoscon 앱의 Hue Dimmer에 할당되고 연결이 끊어지면 Hue Dimmer에 응답하지 않음).

씨. 라이트의 펌웨어가 충돌했습니다.

펌웨어 1.2.214가 모든 IKEA GU10 스팟에 설치되어 있습니다. 20 개 이상을 확보하고 임의의 조명이 오프라인으로 전환됩니다. 2-3 주에 하나씩 있다고 가정 해 보겠습니다.

JBS5 에 2019년 02월 15일

https://github.com/dresden-elektronik/deconz-rest-plugin/commit/48d2c39a267b5c6d025577eed7530be27932aa2c 에서 최신 deCONZ 버전을 사용해 볼 수 있습니다

ebaauw 에 2019년 02월 15일

두 개의 서로 다른 E14 IKEA 전구 (IKEA fw 1.2.214)로 지난 달에 두 번 같은 경험을했습니다.
파워 사이클링은 저에게 두 번 모두 작동했습니다.

tubalainen 에 2019년 02월 15일

씨. 라이트의 펌웨어가 충돌했습니다.

조명이 그룹 명령에도 반응하지 않으면 펌웨어 충돌처럼 보입니다.

2.05.59는 IKEA 게이트웨이 매개 변수를 조정하여 조명 상태보고를 구성했습니다. 주로 IKEA 자체에서 테스트하지 않는 구성을 사용하여 버그를 유발하지 않기를 바랍니다. 참고로 변경으로 인해 더 이상 장치에서보고하는 데 타이머가 사용되지 않습니다.

조명이 켜지면 새 구성이 적용됩니다.

우리는 여전히 그룹 멤버십 및 인접 테이블 쿼리와 같은 일부 유지 관리 요청을 조명에 보내고 안정성이 2.05.59로 개선되지 않으면 추가로 제한 할 수 있습니다.

또한 게이트웨이가 보내는 요청과 관련이없는 라이트 펌웨어에 버그가있을 가능성도 있습니다.

manup 에 2019년 02월 15일

👍3

씨. 라이트의 펌웨어가 충돌했습니다.
조명이 그룹 명령에도 반응하지 않으면 펌웨어 충돌처럼 보입니다.
2.05.59는 IKEA 게이트웨이 매개 변수를 조정하여 조명 상태보고를 구성했습니다. 주로 IKEA 자체에서 테스트하지 않는 구성을 사용하여 버그를 유발하지 않기를 바랍니다. 참고로 변경으로 인해 더 이상 장치에서보고하는 데 타이머가 사용되지 않습니다.
조명이 켜지면 새 구성이 적용됩니다.
우리는 여전히 그룹 멤버십 및 인접 테이블 쿼리와 같은 일부 유지 관리 요청을 조명에 보내고 안정성이 2.05.59로 개선되지 않으면 추가로 제한 할 수 있습니다.
또한 게이트웨이가 보내는 요청과 관련이없는 라이트 펌웨어에 버그가있을 가능성도 있습니다.

제조업체 FW의 Zigbee 표준 해석과 관련하여 "deconz와 반드시 관련이있는 것이 아니라 Zigbee 네트워크 또는 제조업체 FW"에 +1.

tubalainen 에 2019년 02월 15일

방금 2.05.59로 업데이트했으며 deconz를 다시 시작한 후 동일한 조명에 다시 연결할 수 없습니다. GUI에서 0을 눌러도 다시 가져 오지 않습니다. 다른 모든 조명이 작동합니다. 제 경우에는 이것은 빛 자체에 문제가 될 수도 있습니다.

peer69 에 2019년 02월 15일

@ peer69 @ thomas70 https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -463948127에서 @manup 이 언급 한대로 조명의 전원을 껐 습니까?

조명이 켜지면 새 구성이 적용됩니다.

JBS5 에 2019년 02월 15일

좋은 힌트입니다. 지금은 다른 이유로 .58로 돌아 가야했습니다 (높은 CPU 부하로 인해 게이트웨이가 응답하지 않음). 오늘 나중에 .59로 다시 시도하고 모든 이케아 조명의 전원을 껐다가 켭니다.

peer69 에 2019년 02월 15일

나는 또한이 문제가 있는데, 동일한 GU 10 조명에 대해 두 번 발생했습니다. 현재 2.05.59를 실행 중이며 업데이트 후 조명을 껐다가 켰습니다.

jurriaan 에 2019년 02월 17일

때때로 계속 고장 나는 전구처럼 보인다는 것을 덧붙이는 것을 잊었습니다. 얼마 전에 다른 전구에 문제가 있었는데 항상 반응을 멈출 것이 었습니다.

jurriaan 에 2019년 02월 17일

전원을 껐다 켜면 IKEA 전구가 돌아 왔습니다. 하지만 내 IKEA FLOALT 패널 WS는 여전히 오프라인 상태입니다.

thomas70 에 2019년 02월 17일

나는 이와 똑같은 문제를 겪고 있고 꽤 오랫동안 그렇게 해왔고 .59가 실제로 나를 위해 상황을 악화 시켰다고 말할 수 있습니다. 나는 80 개의 노드를 가지고 있는데 그 중 32 개는 Trådfri 조명과 스위치이고, 5 개는 Hue 조명이고 나머지는 온도, 동작, 연기 감지기 등과 같은 다른 Xiaomi 배터리 구동 장치입니다. 모든 단일 유형의 장치는 적어도 한 번은 응답하지 않았습니다. Trådfri 조명뿐만 아니라 그 당시에는 Trådfri 및 Hue 조명에 문제가 있습니다.

문제는 이전에 Xiaomi 게이트웨이를 통해 Hue 브리지와 Xiaomi 센서를 통해 모든 조명을 실행 한 후 모두 견고했기 때문에 원인이 아닌 경우 내 경우에 범인이 장치 펌웨어라고 생각하지 않습니다. 상황의 변화.

이전에는 완벽하게 작동했던 6 개의 Trådfri GU10 조명이 한 위치에 있지만 .59로 업그레이드하고 몇 번의 전원을 껐다가 다시 켜면 이제 거의 완전히 응답하지 않으므로 재설정해야 할 것입니다. 이상한 점은이 무 반응이 어떤 조명이 파워를 가지고 있는지에 따라 다른 조명에서 "움직이는"것처럼 보인다는 것입니다. 응답하지 않는 일부 조명의 전원을 차단하면 시간이 걸릴 수 있으며 갑자기 제대로 작동하지 않는 다른 조명이됩니다. 어딘가에 문제를 일으키는 오프셋이 있습니까?

Bllstc 에 2019년 02월 18일

문제는 이전에 Xiaomi 게이트웨이를 통해 Hue 브리지와 Xiaomi 센서를 통해 모든 조명을 실행 한 후 모두 견고했기 때문에 원인이 아닌 경우 내 경우에 범인이 장치 펌웨어라고 생각하지 않습니다. 상황의 변화.

흥미롭게도 Hue 네트워크에 32 개의 Ikea 조명이 모두 있습니까? Hue 브리지는 폴링 만 사용하고 속성보고를 구성하지 않기 때문에 묻는 것입니다.

Xiaomi 네트워크에 Hue 또는 Ikea 조명과 같은 라우터 장치도 있습니까?

이전에는 완벽하게 작동했던 6 개의 Trådfri GU10 조명이 한 위치에 있지만 .59로 업그레이드하고 몇 번의 전원을 껐다가 다시 켜면 이제 거의 완전히 응답하지 않으므로 재설정해야 할 것입니다. 이상한 점은이 무 반응이 어떤 조명이 파워를 가지고 있는지에 따라 다른 조명에서 "움직이는"것처럼 보인다는 것입니다. 응답하지 않는 일부 조명의 전원을 차단하면 시간이 걸릴 수 있으며 갑자기 제대로 작동하지 않는 다른 조명이됩니다. 어딘가에 문제를 일으키는 오프셋이 있습니까?

흠 정말 나쁘 네요. 어떻게 이런 일이 일어나는지 궁금합니다. 2.05.59는 이전 버전보다 Ikea 조명에 "친숙"합니다. 구성은 이제 Ikea 게이트웨이가 수행하는 것처럼 발생합니다.

조명이 응답하지 않을 때 deCONZ에서 노드를 선택하고 다시 응답 / 노란색이되면 0 눌러 전원을 껐다 켤 필요가 없습니다. 이 경우 좀비가되는 조명은 곧 수정 될 예정이며 현재 특정 네트워크 집합에서 발생할 수 있습니다.

그런데 일반적인 질문 :

어떤 펌웨어 버전을 사용하고 있습니까?
RaspBee 또는 ConBee?
ConBee가 USB 연장 케이블을 사용한다면?

manup 에 2019년 02월 18일

예상보다 시간이 오래 걸렸지 만 이제 모든 것이 실제로 다시 정상적으로 작동하는 것처럼 보입니다. 적어도 지금은 내가 말할 수있는 것에서.

서버를 재부팅하고 네트워크의 모든 주전원 조명을 껐다 켜서 최신 구성을 가져 왔는지 확인했지만, 그럼에도 불구하고 문제가 해결되기까지 몇 시간이 걸렸기 때문에 내 가정에 약간 이르렀습니다. 즉시 작동하지 않았기 때문에 문제가 남아 있습니다.

흥미롭게도 Hue 네트워크에 32 개의 Ikea 조명이 모두 있습니까? Hue 브리지는 폴링 만 사용하고 속성보고를 구성하지 않기 때문에 묻는 것입니다.

예, 일종의. Hue 네트워크에는 31 개의 Ikea 조명과 Hue 조명이 있습니다. 32 번째 Ikea 장치는 그때 구입하지 않은 스위치 콘센트입니다.

Xiaomi 네트워크에 Hue 또는 Ikea 조명과 같은 라우터 장치도 있습니까?

아니요, 배터리 구동 식 센서 만

조명이 응답하지 않을 때 deCONZ에서 노드를 선택하고 다시 응답 / 노란색이되면 0 눌러 전원을 껐다 켤 필요가 없습니다. 이 경우 좀비가되는 조명은 곧 수정 될 예정이며 현재 특정 네트워크 집합에서 발생할 수 있습니다.

나는 효과없이 이것을 여러 번 더 일찍 시도했습니다. 그리고 하드웨어 및 설정에 관해서는 USB 연장 케이블과 262F0500이있는 ConBee를 사용하고 있습니다. 모든 것이 잘 작동하는 것 같기 때문에 지금은이 정보가 아무 소용이 없을 수도 있지만 결론에 도달하지 않도록 노력하고 문제가 발생하지 않는지 확인하기 위해 며칠 동안 네트워크를 실행하도록 할 것입니다. 반환.

Bllstc 에 2019년 02월 19일

지난 주말 이후로 .59를 실행했지만 여전히 무작위 Ikea 조명이 손실됩니다. (집 외관에 16 개의 E27 전구.)
Bulb FW는 Ikea Gateway에있는 다른 것들과 동일합니다.
262F0500 FW로 ConBee 사용.
지난 주말에 나는 HUE 브리지도 구입했고 .59에 대한 'Under the hood'릴리스 노트를 발견했을 때 조명을 이동하기 시작했습니다. 연기하기로 결정했지만 다가오는 주말을 다시 고려할 것입니다.
Deconz는 여전히 최고의 Xiaomi / mi Cube 컨트롤러가 될 것입니다. 아직 제스처를 놓치지 않았습니다.

olemr 에 2019년 02월 20일

지난 주말 이후로 .59를 실행했지만 여전히 무작위 Ikea 조명이 손실됩니다. (집 외관에 16 개의 E27 전구.)
Bulb FW는 Ikea Gateway에있는 다른 것들과 동일합니다.
262F0500 FW로 ConBee 사용.
지난 주말에 나는 HUE 브리지도 구입했고 .59에 대한 'Under the hood'릴리스 노트를 발견했을 때 조명을 이동하기 시작했습니다. 연기하기로 결정했지만 다가오는 주말을 다시 고려할 것입니다.
Deconz는 여전히 최고의 Xiaomi / mi Cube 컨트롤러가 될 것입니다. 아직 제스처를 놓치지 않았습니다.

나는 여기에 같은 상황이 있는데, 16 개의 IKEA 조명, 2 개의 IKEA 제어 콘센트, Heiman 플러그와 innr 플러그 및 일부 Xiaomi 센서 (큐브 / 도어 센서 / 모션 센서)입니다. IKEA 이외의 장치에는 문제가 없었습니다. 그러나 현재 거의 매일 IKEA 표시등이 네트워크에서 떨어지는 문제가 있습니다.

펌웨어 0x26300500 및 deCONZ .59에서 USB 확장 케이블이있는 Conbee를 사용합니다.

jurriaan 에 2019년 02월 21일

내 조명은 한동안 잘 작동했지만 며칠 전에 Trådfri E14 전구가 갑자기 응답하지 않게되었습니다. 한 번의 전원주기 후에 다시 살아났습니다.

오늘은 GU10 중 하나가 중퇴 할 때였습니다. 앞서 언급 한 E14와 물리적으로 매우 가깝기 때문에 우연인지 아닌지 잘 모르겠습니다. GU10은 모든 조명이 ConBee 범위 내에 있더라도 E14를 통해 라우팅되었을 수 있습니다.

노드를 선택하고 deCONZ에서 0을 눌러도 아무 작업도 수행되지 않습니다. 또한 deCONZ 컨테이너를 재부팅하려고 시도했으며 시작시 네트워크를 다시 라우팅하는 동안 특정 전구에 대한 경로를 연결하지 않습니다. 문제 해결을 진행하는 가장 좋은 방법은 무엇입니까?

Bllstc 에 2019년 02월 25일

12 일 후 다른 GU10에 연결할 수 없게되며 전원을 껐다가 켜면 다시 연결되지 않습니다.

이 문제를 해결하는 데 필요한 모든 정보를 공유하게되어 기쁩니다.

JBS5 에 2019년 02월 26일

여기도 마찬가지입니다. 어제 6 일 간의 완벽한 연결 후 Tradfri 전구 중 하나를 잃었습니다. 전원 켜기 / 끄기 및 재설정이 도움이되지 않았습니다. deConz에서는 여전히 노란색이지만 연결하거나 제어 할 수 없습니다.

rich710se 에 2019년 02월 27일

여기도 마찬가지입니다. 며칠 후 아무 문제없이 오늘 두 개의 GU10 Tradfri 램프가 응답을 멈췄습니다. GUI에서 0을 눌러서 하나를 되 살릴 수 있었지만 다른 하나는 Powercycle을해야했습니다.
다행히도 이것은 GU10 장치 atm에서만 발생하는 것 같습니다. 내 FLOALT 패널에는 아직 문제가 없었습니다 (내 설정에서는 회로 차단기를 사용하여 전원을 껐다가 켤 수 있음).

peer69 에 2019년 03월 01일

문제는 나에게도 계속되었습니다. 이제 3 ~ 4 개의 GU10 전구가 연결이 끊어지고 Hue E27 중 하나와 Xiaomi 도어 센서 (자석)가 끊어지는 것을 경험했습니다. 일부 조명은 전원을 껐다 켜면 다시 작동하기 시작했지만 다른 조명은 작동하지 않았습니다. 0을 누르면 아무 작업도 수행되지 않습니다.

인접하고 응답하지 않는 GU10의 전원을 껐다가 켠 후 Xiaomi 센서가 다시 작동하기 시작한 것도 주목할 만하므로 센서가 해당 조명을 통해 라우팅되고 있다고 가정하지만 연결 문제가 있으면 자동으로 다시 라우팅해서는 안됩니까?

Bllstc 에 2019년 03월 01일

여기에도 같은 문제가 있습니다. 어제 최신 버전 .59로 업데이트했습니다. 이제 Ikea 조명 몇 개가 응답하지 않습니다.

Webserve 에 2019년 03월 04일

안녕하세요, 네트워크 크기 및 기타 전원 공급 장치와 같은 전체 네트워크에 대한 더 많은 통찰력을 제공 할 수 있습니까?

며칠 전에 홈 네트워크를 다음과 같이 재정렬했습니다.

5x IKEA WS GU10 (펌웨어 1.2.221, 제품 코드 LED1537R6GU10EU)
MAC 주소 0x000b57ff ..... (이전 배치)
2x IKEA 디밍 가능 E27 (펌웨어 1.2.214)
IKEA E14 WS 조명 1 개 (펌웨어 1.2.221)
1x IKEA 중계기 (펌웨어 2.0.019)
1x IKEA 콘센트 (펌웨어 2.0.019)
1x OSRAM GU 10
1x OSRAM E27 컬러 전구
1x OSRAM 플러그
1x Hue E27 컬러 전구
1x Hue E27 조광 가능한 럭스 전구

deCONZ 2.05.59; ConBee 펌웨어 0x26300500 (하지만 0x262f0500도 괜찮습니다).

4x FLS-PP lp가 있지만 매우 강력한 신호 리피터 역할을하므로 테스트를 위해 전원이 꺼져 있습니다.

센서와 스위치의 총 네트워크 크기는 55입니다.
모든 조명은 항상 전원이 공급되며 지금까지는 정전이 전혀 없습니다.

manup 에 2019년 03월 04일

도움이 될 수있는 경우 내 네트워크에 대한 자세한 사양은 다음과 같습니다. 나는 여전히 262F0500과 ConBee의 연장 코드로 2.05.59를 실행하고 있습니다. 위에서 언급했듯이 2.05.59로 처음 업데이트하고 모든 주전원 장치의 전원을 껐다가 켜고 몇 시간을 기다린 후 네트워크는 거의 일주일 동안 결함이 없었으므로 문제가 나타나기 시작하는 데 시간이 걸리는 것 같습니다. 안타깝게도 문제가 다시 나타 났고 모든 주 전원 장치의 전체 전원주기와 deCONZ 재부팅으로 문제가 더 이상 해결되지 않습니다. 때로는 조명이 잠시 동안 응답하지 않을 수 있고 자체적으로 해결되기 때문에 문제가 장치에서 장치로 이동하는 것처럼 보입니다.

오늘 초에 Trådfri E14와 Hue E27이 반응하지 않는 문제가있었습니다. E27의 전원을 껐다가 켠 후 E14는 제가 건드리지도 않고 다시 살아났습니다. 때때로 거래 장소 인 것처럼 보이는 응답하지 않는 GU10도 마찬가지입니다. 따라서 매일 최소 두 개의 응답하지 않는 GU10이 있지만 항상 같은 조명이 아니므로 일부는 작동을 시작하고 다른 일부는 고장 나고 그 반대도 마찬가지입니다.

내 네트워크는 현재 ConBee를 포함한 다음 80 개의 장치로 구성되어 있으며 주 전원 장치는 연중 무휴로 전원이 공급됩니다.

전원 공급

| 수량 | 유형 | 펌웨어 |
| ---------- | ------ | ------------- |
| 30 | Trådfri GU10 디밍 가능 | 1.2.214 |
| 4 | Trådfri GU10 백색 스펙트럼 | 1.2.217 |
| 1 | Trådfri E14 오팔 조광 가능 | 1.2.217 |
| 1 | Trådfri 제어 콘센트 | 1.4.020 |
| 3 | 색조 E27 흰색 및 색상 A19 | 1.29.0_r21169 |
| 2 | Hue E14 흰색 분위기 LTW012 | 1.29.0_r21169 |

배터리 전원

수량 | 유형 | 펌웨어
--------- | ------ | -----------
1 | Trådfri 켜기 / 끄기 스위치 | 1.4.018
10 | Xiaomi Aqara 멀티 센서 (스퀘어 온도 / 험 / 프레스) | 20161129
3 | Xiaomi Aqara 모션 센서 (모션 / 럭스) | 20170627
4 | Xiaomi Aqara 물 센서 | 20170721
1 | 색조 모션 센서 | 6.1.0.18912
11 | Xiaomi Aqara 접촉 센서 | 20161128
8 | Xiaomi / Honeywell 연기 센서 | 해당 없음

Bllstc 에 2019년 03월 04일

지난주에 deconz는 잘 돌아가는 것 같았지만 어제 다른 IKEA 전구 (흰색 스펙트럼)가 deconz와 연결이 끊어졌습니다. 껐다가 다시 켜도 도움이되지 않았습니다. 어떻게 든 다시 작동하려면 deconz를 다시 시작해야했습니다.

주로 IKEA 전구, Heiman 콘센트 및 상당수의 Xiaomi 센서가있는 네트워크가 있습니다.

jurriaan 에 2019년 03월 10일

내 zigbee 네트워크의 일부 사양 :

NUC에 확장 케이블이있는 Conbee 펌웨어 262F0500.
Docker의 deCONZ 2.05.55이므로 가장 먼저해야 할 일은 2.05.59로 업그레이드하는 것입니다.

전원 공급 (24/7)

| 수량 | 유형 | 펌웨어 |
| ------------- | ------------- | ------------- |
| 4x | Tradfri E27 흰색 | 1.1.1.0-5.7.2.0 |
| 2x | Tradfri E27 흰색 | 1.2.214 |
| 21x | Tradfri GU10 디밍 가능 | 1.2.214 |
| 3x | Osram Smart + 소켓 | 1.04.12 |

배터리 전원

| 수량 | 유형 | 펌웨어 |
| ------------- | ------------- | ------------- |
| 3x | 색조 조광기 스위치 | 5.45.1.17846 |
| 1x | Aqara 스마트 스위치 | 20180525 |
| 1x | Aqara 스마트 스위치 | 20161128 |
| 1x | Aqara 이중 무선 스위치 | 20170411 |
| 1x | TRADFRI 원격 | 1.2.214 |
| 6x | Aqara 멀티 센서 | 20161129 |
| 10x | Aqara 접촉 센서 | 20161128 |
| 5x | Aqara 모션 센서 | 20170627 |
| 1x | Aqara 누출 센서 | 20170721 |
| 1x | Aqara 진동 센서 | 20180130 |

JBS5 에 2019년 03월 11일

현재 버전에 대한 업데이트가 있습니까? 3 일 동안 .60을 실행했지만 아직 연결이 끊어지지 않았습니다.

peer69 에 2019년 03월 15일

불행히도 나는 이미 .60의 일반 Tradfri E27 흰색 전구와 최신 펌웨어와의 연결이 끊어졌습니다.

jurriaan 에 2019년 03월 15일

그것은 나쁜 소식입니다. 제가 올바르게 이해한다면 폴링 간격이 .60에서 덜 공격적으로 변경되었습니다. 빛을 끊는 공격적인 폴링은 나에게 완벽하게 이해가되었고, 이것이 우리 문제의 해결책이 아닌 것 같습니다.

peer69 에 2019년 03월 15일

어제 나는 모든 주전원 장치의 전원을 끄고 다시 켜기 전에 2.05.60 및 26320500으로 업데이트했습니다. 그런 다음 조명은 모두 약 24 시간 동안 잘 작동했지만 몇 분 전에 GU10 중 하나가 응답을 멈춘 것을 알았습니다. 운 좋게도 몇 분 후에 제 쪽에서 수동 상호 작용없이 다시 살아 났으므로 네트워크가 막혔을 수 있습니다.

Bllstc 에 2019년 03월 16일

@ JBS5 1.1.1.0-5.7.2.0 에서 4x Tradfri E27 white를 최신 펌웨어 버전으로 업데이트하는 것이 좋습니다. 내가 올바르게 기억한다면 이것은 여전히 첫 번째 버전입니다.

@jurriaan Tradfri E27 흰색 전구가있는 버전은 무엇입니까?

그것은 나쁜 소식입니다. 제가 올바르게 이해한다면 폴링 간격이 .60에서 덜 공격적으로 변경되었습니다.

네 기본적으로 IKEA 게이트웨이와 매우 유사합니다. 이제 남은 유일한 차이점은 메시 네트워크 라인을 표시하는 데 사용되는 이웃 테이블의 주기적 쿼리입니다.

deCONZ에서 CRE 아이콘을 클릭하고 "라우터 및 코디네이터"를 선택 취소하여 끌 수 있습니다.
시험할만한 가치가 있습니다.

Reddit에는 이론적으로 IKEA 게이트웨이가 최대 100 개의 장치를 지원해야한다는 글이 있지만 테스트가 잘되지는 않습니다. IKEA 팀이 테스트하는 일반적인 네트워크 크기를 아는 것이 흥미로울 것입니다.

https://www.reddit.com/r/tradfri/comments/96yiq4/google_home_losing_lamps_and_rooms/e4x1scz/?context=1

게이트웨이에 연결된 장치가 100 개있을 수 있습니다. 이것은 우리에 의해 제대로 테스트되지 않았기 때문에 우리는 그것을 보장하지 않습니다. 하지만 기술적 인 한계는 100 개이고, 문제가 전혀 없거나 사소한 문제 만있는 장치를 100 개 가진 사람들을 보았습니다.

게이트웨이의 새 버전은 동일한 양의 장치를 지원합니다 (공식적으로 50 개). 두 배로 늘리려면 시스템에 다른 게이트웨이를 추가 할 수 있습니다.

manup 에 2019년 03월 18일

@ JBS5 1.1.1.0-5.7.2.0 에서 4x Tradfri E27 white를 최신 펌웨어 버전으로 업데이트하는 것이 좋습니다. 내가 올바르게 기억한다면 이것은 여전히 첫 번째 버전입니다.

이전 펌웨어를 사용하는 E27 전구는 지난 6 개월 동안 실패하지 않았고 다른 전구는 실패했습니다.

JBS5 에 2019년 03월 18일

매우 흥미 롭습니다. 버전 1.2.214의 E27은 어떻습니까?

manup 에 2019년 03월 18일

매우 흥미 롭습니다. 버전 1.2.214의 E27은 어떻습니까?

그들은 지난 몇 달 동안 한 번만 연결이 끊어졌습니다.

마지막 GU10 연결이 끊어진 지 몇 주가 지났지 만 Conbee에서 deCONZ 2.05.55 및 펌웨어 262F0500을 계속 사용하고 있습니다.

JBS5 에 2019년 03월 19일

나는 또한이 문제가 있습니다. Ikea 노드 만 (43 개, 주로 조명). 나는 zigbee에 대한 지식이 없지만 언급 한 적이 없기 때문에 OTAU를 비활성화하면 네트워크가 더 안정적으로 보입니다. 다른 날에도 네트워크 환경 설정을 보안 수준이 낮은 것으로 변경했습니다. 어느 것을 기억할 수 없지만 그 후에도 나는 빛을 잃지 않았습니다.

lb1974 에 2019년 03월 20일

문제없이 며칠 후 여러 GU10이 응답하지 않습니다.
다른 문제는 관련이 없을 수 있지만 Osram 라이트도 연결이 끊어졌습니다. GUI에 여전히 표시되고 메시처럼 보였지만 더 이상 제어 할 수 없었습니다. 읽은 라이트를 삭제해야했지만 다른 라이트 번호가 지정되었지만 추가 한 직후 이전 이름을 되찾았습니다. 여기서 무슨 일이 일어나고 있는지 모르겠지만 이것은 설정에서보고 싶은 것보다 훨씬 더 많은 유지 관리입니다.

peer69 에 2019년 03월 24일

@ peer69 당신은 또한 빛의 전원을 껐다 켜려고 했습니까? 일반적으로 공장 초기화는 필요하지 않습니다.
2.05.60에 있습니까? 또한 네트워크, 조명 및 주 전원 장치 수에 대한 세부 정보를 제공 할 수 있습니까?

manup 에 2019년 03월 24일

@manup 나는 빛을 powercycled. 여러번. 전원을 껐다 켠 후 약 10 초 동안 제어 할 수 있었지만 다시 응답하지 않았습니다 (GUI에서 빨간색 표시등이 깜박임).
한편이 문제는 공장 초기화 후에도 다시 발생했으며 다른 OSRAM 표시등에도 영향을 미쳤습니다. 지금은 네트워크에서 단 두 개의 OSRAM 조명을 제거하고이를 색조 전구로 교체했습니다. ORSAM 조명으로 테스트를 제공 할 수 있지만 시간이 좀 필요합니다.

2.05.60을 실행하고 있습니다. 현재 네트워크에 연결된 57 개의 노드가 있으며 그 중 27 개의 장치가 주 전원으로 공급됩니다. IKEA GU10 13 개, IKEA FLOALT 패널 1 개, IKEA E14 2 개, OSRAM Smart + 플러그 3 개, E14 색상 전구 3 개, E27 색상 전구 5 개, 색상 조명 스트립 1 개를 사용합니다.

또한 지난 며칠 동안 일부 IKEA GU10의 전원을 껐다가 켜야했습니다. powercycle 후 모든 것이 정상으로 돌아오고 패턴이 보이지 않습니다. 나는 여러 개의 GU10이있는 램프를 가지고 있으며, 항상 그룹으로 제어되고 있음에도 불구하고 동시에 응답하지 않는 하나 이상의 GU10이 없습니다.

peer69 에 2019년 03월 28일

지금은 원점으로 돌아 왔습니다. 이제는 정기적으로 2 ~ 3 개의 조명이 반응하지 않지만 서로 다른 조명 사이에서 점프하므로 때때로 작동하고 때로는 온라인에있는 다른 조명에 의존하지 않습니다. 전원을 차단하여 물리적으로 일부 조명을 끄면 문제가 다른 조명으로 전환되기 때문에 문제가 계단식으로 나타나는 것 같습니다.

또한 Xiaomi 온도 센서 몇 개와 도어 센서 및 IKEA 켜기 / 끄기 스위치를 잃어 버렸지 만 다시 튀어 나오지 않으므로 다시 작업을 시작하려면 다시 페어링해야 할 것입니다.

앞서 언급했듯이 전체 전원을 껐다 켜 자마자 모든 것이 잘 작동했지만 며칠 후 조명이 다시 응답하지 않기 시작했고 지금은 몇 주 동안 이와 같았습니다. 게스트가 실수로 몇 시간 동안 E14의 플러그를 뽑았을 때 처음으로 발생하여 완전히 관련이 없는지 또는 예기치 않은 지그비 메시의 방해로 인해 라우팅이 미쳐 졌는지 확실하지 않습니다. 이 문제를 가진 사람이 나만은 아니라는 점을 감안할 때 우연일지도 모른다고 생각합니다.

모든 지그비 장치를 하나의 메시에 넣는 개념이 정말 마음에 들지만 이전 Hue 및 Xiaomi 게이트웨이를 부팅하고 ConBee를 서랍에 넣는 시점이 거의 다되었습니다. 몇 가지 다른 이유로. 누구든지 정확히 무슨 일이 일어나고 있는지, 그리고 그것을 해결하는 방법을 식별하는 데 도움이 될 추가 문제 해결에 대한 팁이 있습니까?

Bllstc 에 2019년 04월 04일

IKEA GU10 스팟 중 하나가 이제 반응이 없습니다.

스니퍼에서 나는 그것이 여전히 다소 "살아 있고"NWK Link Status 메시지를 보내는 것을 알지만, 분명히 그것이 네트워크에서 혼자라고 생각합니다 (Link Status Count : 0).

유니 캐스트 명령에는 응답하지 않지만 주기적으로 modelid의 ZCL 속성 보고서를 보냅니다.

~ 2 시간 이후 스니핑, 언제 응답하지 않고 관련이 있는지 확실하지 않지만 보고서 ZCL 시퀀스 번호가 낮습니다.

더 많은 테스트를 수행하고 잠시 동안 전원을 껐다 켜지 않습니다.

내 Tradri 전원 소켓은 오늘도 정말 이상하게 작동했고 재부팅 서클에서 실행되었습니다.

manup 에 2019년 04월 04일

방금 언급 한 두 번째 IKEA GU10도 걷기 주도로 다른 것과 동일한 증상입니다.

두 장치 모두 유니 캐스트, 그룹 캐스트 또는 ZCP nwk 주소 요청 (0 누름)에 응답하지 않습니다.
빈 NWK 링크 상태 명령을 보냅니다.

두 번째 GU10은 ZCL OTA Query Next Image 요청도 전송했습니다.

응답이 오지 않는 것 같습니다.

거친 추측 일 뿐이지 만 버퍼 내 조명이 차단되어 아무것도 수신 및 처리되지 않는 것입니다. 아웃 버퍼는 여전히 작동하므로 펌웨어는 보고서 및 ota 쿼리를 보낼 수 있습니다.

Mac 계층이 작동하고 (명령이 수신 됨) nwk 및 aps 계층이 침묵을 유지하는 경우 잠시 후 펌웨어가 재부팅 될 수 있도록 간단한 상태 확인과 같은 것을 구현하면 좋을 것입니다.

manup 에 2019년 04월 04일

2.05.59로 업그레이드 한 후에도이 문제가 있습니다. 오늘은 나의 세 가지 실외 조명 "사라진"중 하나였습니다.
그것의 Tradfri 전구는 모두 세 가지입니다.

주제를 벗어. 이 모든 것에서 어떻게 당신의 빛을 찾을 수 있습니까? 나는 비슷한 설정을 가지고 있었고 나는 ... 이런 시간이 없습니다.

MattL0 에 2019년 04월 04일

비슷한 의미는 +-50 개 장치를 의미합니다.

MattL0 에 2019년 04월 04일

+-50은 괜찮습니다. 우리의 테스트 네트워크 중 하나에는 Raspberry Pi 1에 deCONZ가있는 +180 개의 장치가 있습니다.

우리는 장치 찾기를 단순화하기 위해 deCONZ에 더 나은 필터 / 정렬을 추가 할 계획을 가지고 있습니다. 현재는 특정 장치 수에서 매우 번거 롭습니다.

manup 에 2019년 04월 04일

👍1

조명이 여전히 붙어 있습니다.

한 가지 흥미로운 사실은 필립스 Hue 모션 센서 (Hue Lux)의 부모 전원을 꺼서 새 부모를 검색해야한다는 것입니다. 이제 센서가 고정 된 IKEA GU10 조명 중 하나를 통해 다시 연결하려고합니다.

라이트는 나가기 (재결합 포함) 명령으로 응답합니다. 그래서 재가입 요청을 처리했습니다!

슬프게도 Hue 모션 센서는 고집스럽고 고정 된 GU10 조명에 영원히 다시 연결하려고 시도하는 대신 더 나은 부모를 찾습니다.

그러나 여기서 흥미로운 부분은 고정 된 IKEA 조명이 재가입 요청에 응답한다는 것입니다. 아마도 NWK Leave 요청을 처리 할 수도 있습니다. 이는 조명을 다시 작동 상태로 만드는 해결 방법의 기초가 될 수 있습니다.

manup 에 2019년 04월 05일

👍1

보정, Hue 모션 센서는 너무 완고하지 않습니다. 몇 분 후 센서가 다른 작동하는 상위 (양호)를 선택했습니다.

manup 에 2019년 04월 05일

그러나 여기서 흥미로운 부분은 고정 된 IKEA 조명이 재가입 요청에 응답한다는 것입니다. 아마도 NWK Leave 요청을 처리 할 수도 있습니다. 이는 조명을 다시 작동 상태로 만드는 해결 방법의 기초가 될 수 있습니다.

나는 이것을 테스트했지만 슬프게도 작동하지 않습니다. 조명이 멈춘 상태에있는 동안에는 재가입 요청으로 NWK 탈퇴를 처리하지 않습니다.

현재 나는 IKEA가 빛이 멈춘 근본 문제를 해결하거나 펌웨어의 NWK / APS 레이어에 대한 일종의 감시 + 상태 확인을 구현해야한다고 결론을 내릴 수 있습니다.

방송 폭풍, 특정 명령, 라우팅 문제 등 조명이이 상태로 정확히 들어가는 원인은 아직 밝혀지지 않았습니다.

내 발견 사항과 스니퍼 로그를 IKEA에 전달하여 문제를 추적하는 데 사용할 수 있기를 바랍니다.

manup 에 2019년 04월 06일

👍4

그래서 @manup , 멈춘 IKEA 조명에 다시 참여하는 가장 좋은 방법은 무엇입니까?

Filialen 에 2019년 04월 06일

나에게는 빛의 파워 사이클이 가장 잘 작동합니다.

djwlindenaar 에 2019년 04월 06일

@manup 환자를 더 좋게 만드는 방법을 모른다면 더 나쁘게 만들려고 노력해야한다고 생각합니다. 따라서 잠김의 잠재적 원인이있는 조명을 폭격하고 어떤 일이 발생하는지 확인하십시오.
또한이 조명은 Ember 스택을 기반으로하지 않습니까? 빛을 발할 수있는 지원 팀이나 포럼이있을 수 있습니다.

IKEA에 대한 Wrt, 그들은 이러한 지원 요청에 응답합니까? 아니면 관심을 끌기 위해 팀을 구성해야합니까?

djwlindenaar 에 2019년 04월 06일

나에게는 빛의 파워 사이클이 가장 잘 작동합니다.

나에게는별로 ...
Conbee를 다시 시작하는 것이 일시적으로 문제를 해결하는 유일한 방법입니다.
그리고 동일하거나 더 자주 다른 IKEA 조명이 잠시 후 멈 춥니 다.
항상 단 하나의 빛! 너무 이상해 ... 그리고 짜증나 ... : /

Filialen 에 2019년 04월 07일

@manup 대단해! 조사해 주셔서 감사합니다!

또한 Reddit을 통해이 스레드를 IKEA Tradfri 팀에 전달했습니다. 정보를 전달했다는 응답을 받았습니다. 이 기능을 사용하여 펌웨어를 개선하거나이 문제에 대한 해결책을 찾을 수 있기를 바랍니다. :)

jurriaan 에 2019년 04월 08일

👍4

특히 HomeKit 지원을 대상으로하는 다음날 출시 될 tradfri 게이트웨이 용 새 펌웨어가있는 것 같습니다. 전구에 대한 새로운 펌웨어도있을 수 있습니다.

peer69 에 2019년 04월 11일

@ peer69 이것은 최신 펌웨어 릴리스입니다.

version_info.json

[
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/190579-ncp572b444.ebl.ota.ota.signed",
    "fw_build_version": 444,
    "fw_file_version_LSB": 444,
    "fw_file_version_MSB": 5720,
    "fw_filesize": 166270,
    "fw_hotfix_version": 2,
    "fw_image_type": 2,
    "fw_major_version": 5,
    "fw_manufacturer_id": 4476,
    "fw_minor_version": 7,
    "fw_type": 1
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10005777-4.1-TRADFRI-control-outlet-2.0.022.ota.ota.signed",
    "fw_file_version_LSB": 9763,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 204222,
    "fw_image_type": 4353,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10005778-4.1-TRADFRI-onoff-shortcut-control-2.0.020.ota.ota.signed",
    "fw_file_version_LSB": 1571,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 182078,
    "fw_image_type": 4549,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10035514-TRADFRI-bulb-ws-1.2.221.ota.ota.signed",
    "fw_file_version_LSB": 5490,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 172734,
    "fw_image_type": 8705,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10035534-TRADFRI-bulb-ws-gu10-1.2.221.ota.ota.signed",
    "fw_file_version_LSB": 5490,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 172734,
    "fw_image_type": 8707,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed",
    "fw_file_version_LSB": 9763,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 209790,
    "fw_image_type": 16900,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/1004764-TRADFRI-bulb-cws-1.3.009.ota.ota.signed",
    "fw_file_version_LSB": 38258,
    "fw_file_version_MSB": 4864,
    "fw_filesize": 178366,
    "fw_image_type": 10241,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159495-TRADFRI-transformer-1.2.245.ota.ota.signed",
    "fw_file_version_LSB": 21874,
    "fw_file_version_MSB": 4644,
    "fw_filesize": 181118,
    "fw_image_type": 16641,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159695-TRADFRI-bulb-ws-1000lm-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 8706,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159696-TRADFRI-bulb-w-1000lm-1.2.214.ota.ota.signed",
    "fw_file_version_LSB": 17778,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 168318,
    "fw_image_type": 8449,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159697-TRADFRI-driver-hp-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 16898,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159698-TRADFRI-driver-lp-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 16897,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159699-2.1-TRADFRI-remote-control-1.2.223.ota.ota.signed",
    "fw_file_version_LSB": 13683,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 159806,
    "fw_image_type": 4545,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159700-TRADFRI-motion-sensor-1.2.214.ota.ota.signed",
    "fw_file_version_LSB": 17778,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 157822,
    "fw_image_type": 4548,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159701-TRADFRI-wireless-dimmer-1.2.248.ota.ota.signed",
    "fw_file_version_LSB": 34162,
    "fw_file_version_MSB": 4644,
    "fw_filesize": 172926,
    "fw_image_type": 4546,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10032198-2.1-TRADFRI-gateway-1.8.25.p.elf.sig.ota.signed",
    "fw_filesize": 698748,
    "fw_hotfix_version": 25,
    "fw_major_version": 1,
    "fw_minor_version": 8,
    "fw_req_hotfix_version": 26,
    "fw_req_major_version": 9,
    "fw_req_minor_version": 9,
    "fw_type": 0,
    "fw_update_prio": 5,
    "fw_weblink_relnote": "https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotesltd.html"
  }
]

업데이트 만 :

10005777-4.1-TRADFRI-control-outlet-2.0.022.ota.ota.signed
10005778-4.1-TRADFRI-onoff-shortcut-control-2.0.020.ota.ota.signed
10032198-2.1-TRADFRI-gateway-1.8.25.p.elf.sig.ota.signed
10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed
159699-2.1-TRADFRI-remote-control-1.2.223.ota.ota.signed

그래서 주로 콘센트 / 게이트웨이에 집중했습니다.

jurriaan 에 2019년 04월 11일

오늘 제 색조 전구 중 하나가 똑같은 문제를 보여주었습니다. 다시 반응하기 위해 powercycle을해야했습니다.

peer69 에 2019년 04월 20일

deCONZ와 Conbee의 펌웨어를 업데이트하는 사람에 대한 소식이 있습니까?

지금까지 1 ~ 2 개의 GU10이 2 ~ 4 주 내에 오프라인 상태가됩니다. 산발적이지만 파워 사이클링은 몇 군데에 전원 스위치가 없기 때문에 짜증이납니다.

펌웨어를 0x26330500으로 업데이트 했으니 살펴 보겠습니다.

JBS5 에 2019년 05월 05일

안타깝게도 오늘 내 GU10 중 하나를 사용할 수 없습니다 ..
Conbee에서 펌웨어 26330500과 함께 deCONZ 2.05.64 사용.

JBS5 에 2019년 05월 10일

필립스 HUE 브리지에서 똑같은 문제를 볼 수 있으므로 이것이 전구 FW 문제라고 결론 지었다고 생각합니다. 저는 Trådfri 앱, 릴리스 노트 섹션에서 CT v2 전구에 대한 언급을 발견했습니다. 전구 HW와 관련된 것일 수도 있습니다.

olemr 에 2019년 05월 10일

지금까지 2.05.65에 문제가 없었습니다.

peer69 에 2019년 05월 31일

동일, 몇 주 동안이 문제에 직면하지 않았습니다.

VincentMasselis 에 2019년 06월 02일

지금까지 최신 버전의 deconz에서 똑같은 일을했습니다. 며칠 전에 램프를 몇 개 바꿨습니다. 다시 반응하게하려면이 램프 중 하나를 수동으로 껐다가 다시 켜야했습니다.

jurriaan 에 2019년 06월 02일

몇 개의 GU10과 E27 전구가 며칠 전에 오프라인 상태였습니다. 전원을 껐다 켜면 다시 온라인 상태가됩니다.

관련이있을 수 있음 : 이것은 하루 또는 10 일 동안 조명이 켜지지 않는 휴가 기간 동안 발생했습니다.

deCONZ 2.05.64가 포함 된 펌웨어 26330500

JBS5 에 2019년 06월 09일

몇 주 전 몇 주 동안 아무런 문제가 없다고 말한 사람들에게이 문제는 어떻습니까?

여전히이 문제가 있습니다. 때때로 그들 중 어느 것도 오프라인 상태가되지 않고 갑자기 GU10이 오프라인 상태가되고 며칠 후 또 다른 하나가 ..

내가 볼 수있는 한, Tradfri GU10에 사용할 수있는 새로운 펌웨어가 아직 없습니다.

JBS5 에 2019년 08월 21일

나는 여전히이 문제가 있습니다. 나에게 그룹 명령은 단일 장치로 조명을 제어 할 수 없더라도 대부분의 시간 동안 작동하므로 벽 스위치 스크립트에서 해결 방법으로 사용합니다.

peer69 에 2019년 08월 21일

그룹 명령은 저에게도 작동하지만 몇 번만 작동합니다. 그 후에는 표시등이 계속 켜져 있거나 꺼져 있고 더 이상 반응하지 않습니다. 바인딩 된 Hue Dimmer를 사용하는 경우에도 마찬가지입니다.

JBS5 에 2019년 08월 21일

저도 마찬가지입니다. 나는 문제가 해결 된 것보다 지연되고 있다는 인상을 받는다.
또한 그룹 명령을 사용하여 문제를 해결했습니다.

나는 일부 조명이이 문제에 훨씬 더 취약한 것처럼 보입니다. 당신은 이것을 알고 있습니까?

djwlindenaar 에 2019년 08월 21일

@djwlindenaar 말하기

@ peer69 @djwlindenaar 그룹 명령이 계속 작동합니까? 오늘날 GU10은 오프라인 상태가되었고 처음에는 그룹 명령 (deCONZ의 그룹 명령 및 바인딩 된 Hue Dimmer)에 응답하지 않았습니다.

JBS5 에 2019년 08월 21일

그룹 명령은 일반적으로 계속 작동하지만 조명을 껐다가 켜야했던 경우가 기억납니다. 또한 한동안 반응이 없었고, 어떤 조치도 취하지 않고 나중에 다시 반응하기 시작한 적이 있습니다.

djwlindenaar 에 2019년 08월 21일

조만간 그룹 명령이 실패하고 조명을 다시 켜야했습니다.

잠시 동안 무슨 의미입니까? 몇 시간 또는 며칠?

JBS5 에 2019년 08월 21일

확실하지 않습니다. 아마도 몇 시간, 아마도 하루 일 것입니다. 잠시 잊어 버렸지 만 다음 번에 조명을 사용하면 다시 돌아올 것임을 알았습니다.
모션에 의해 촉발 된 규칙과 관련이있어서 ...

djwlindenaar 에 2019년 08월 21일

이번 주 초 GU10이 오프라인 상태가되었을 때 약 2 일 동안 기다렸지 만 돌아 오지 않았습니다. 파워 사이클이 필요했지만 GU10은 전혀 따뜻하지 않았습니다.

JBS5 에 2019년 08월 24일

이제 오프라인 상태가 된 GU10 조명이 하나 있지만 전원을 껐다 켜도 다시 온라인 상태가되지 않습니다. 또한 VNC에서 0을 눌러도이 문제가 해결되지 않습니다.

또한 그룹 명령 또는 바인딩 된 Hue DImmer 스위치는 더 이상 조명을 켜거나 끌 수 없습니다.

JBS5 에 2019년 09월 29일

어젯밤부터 복도에 타이머 (홈 어시스턴트)에 의해 x 시간 후에 꺼지는 이케아 라이트 4 개가 있습니다. 이제 4 개의 라이트 중 1 개가 계속 켜져 있고 홈 어시스턴트 / 디콘 즈로 끌 수 없습니다. Deconz에 따르면 오프라인 상태이며 7 시간 동안 다시 가입하지 않았습니다. powercycle을 시도하고 그것이 트릭인지 확인합니다.

조명이 작동하지 않음 : 버전 1.2.214의 TRÅDFRI 전구 E27 오팔 1000lm
작동 조명 : 버전 1.2.214의 TRÅDFRI 전구 E27 오팔 1000lm
펌웨어 : 26330500
Deconz : V2_05_69

lubbertkramer 에 2019년 09월 30일

Ikea Trafri GU10 백색 스펙트럼 전구에 하드웨어 문제가 있다고 생각합니다. 또한 내 설정 (로컬 API를 통해 홈 어시스턴트에 연결된 Ikea 게이트웨이)에서 내 17 개의 전구 중 최소 절반이 이틀마다 오프라인 상태가됩니다. 유일한 해결책은 전구의 전원을 껐다 켜는 것입니다.

이것이 Ikea가 다른 버전의 펌웨어 (1. * 대신 2. *)를 실행하는 새로운 하드웨어 버전을 출시 한 이유 일 수 있습니다.

내가 아는 한, 이전 버전에 대한 새로운 펌웨어 업데이트는 없습니다. 이것은 하드웨어와 관련된 신호일 수 있습니다.

보증 내용은 확실하지 않지만 새 버전으로 교체를 요청할 계획입니다.

ReX1983 에 2019년 09월 30일

Ikea Trafri GU10 백색 스펙트럼 전구에 하드웨어 문제가 있다고 생각합니다. 또한 내 설정 (로컬 API를 통해 홈 어시스턴트에 연결된 Ikea 게이트웨이)에서 내 17 개의 전구 중 최소 절반이 이틀마다 오프라인 상태가됩니다. 유일한 해결책은 전구의 전원을 껐다 켜는 것입니다.
이것이 Ikea가 다른 버전의 펌웨어 (1. * 대신 2. *)를 실행하는 새로운 하드웨어 버전을 출시 한 이유 일 수 있습니다.
내가 아는 한, 이전 버전에 대한 새로운 펌웨어 업데이트는 없습니다. 이것은 하드웨어와 관련된 신호일 수 있습니다.
보증 내용은 확실하지 않지만 새 버전으로 교체를 요청할 계획입니다.

화이트 스펙트럼이 아닌 웜 화이트 GU10을 사용하고 있기 때문에 한 가지 유형에만 관련이 있는지 확실하지 않습니다.

JBS5 에 2019년 09월 30일

오늘 두 IKEA GU 10 WW에서 동일한 문제가 발생했습니다. 파워 사이클링은 도움이되지 않았습니다. 전원을 껐다 켜고 deconz를 다시 시작하는 데 도움이되었습니다. 이웃 테이블 문제일까요? 두 조명 모두 두 그룹에 있으며 항상 그룹으로 제어됩니다.

peer69 에 2019년 09월 30일

요즘 몇 번의 설치에서이 문제가 발생하는 것은 우연입니다. 아니면 다른 일이 일어나고 있습니까?

헉

사용중인 deCONZ 및 conbee 펌웨어 버전은 무엇입니까?

나는 사용하고있다 :
deCONZ V2_05_66
펌웨어 26330500

JBS5 에 2019년 10월 01일

여기에도 동일한 펌웨어가 있습니다. deCONZ 버전 2.05.69.

peer69 에 2019년 10월 01일

그리고 또 다른 Tradfri GU10 따뜻한 흰색은 연결이 끊어졌습니다 ..

JBS5 에 2019년 10월 04일

테스트 브랜치에 최신 펌웨어 파일이 있지만 이것이 문제를 해결하거나 새로운 문제를 일으킬 수 있는지 여부는 알 수 없습니다.

http://fw.test.ota.homesmart.ikea.net/feed/version_info.json

10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed 10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed 10038562-TRADFRI-sy5882-bulb-ws-2.0.023.ota.ota.signed 10035514-TRADFRI-bulb-ws-2.3.007.ota.ota.signed 10035534-TRADFRI-bulb-ws-gu10-2.3.007.ota.ota.signed 159695-TRADFRI-bulb-ws-1000lm-2.3.007.ota.ota.signed

manup 에 2019년 10월 04일

@manup 이것들은 백색 스펙트럼 GU10 https://www.ikea.com/nl/nl/p/tradfri-led-lamp-gu10-400-lumen-draadloos-dimbaar-warm-wit-60420041/

JBS5 에 2019년 10월 04일

아마도 10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed 사용할 수 있습니다. IKEA E27 조광 가능 조명 중 하나에서 테스트하겠습니다. 최악의 경우는 충돌이지만 타지 않는 경우입니다. :)

manup 에 2019년 10월 04일

👍1

수동으로 파일을 할당하려고했지만 전구가 업데이트를 가져 오지 못합니다 (시작되지 않음).

manup 에 2019년 10월 04일

이것에 대해 '나도'. 집 전체가 Tradfri이고 오늘 서버를 재부팅 한 후 여러 날 동안 세 번째로 전체 네트워크를 잃었습니다. 전력 순환은 차이를 만들지 않았습니다. 우리 집에는 Tradfri 만있어 비교할 것이 없습니다. 나는 e27 흰색, e27 색상 및 GU10을 혼합했습니다. 내가 찾은 유일한 해결책은 전구를 하드 리셋하고 처음부터 모든 것을 시작하는 것입니다. 슬프게도 이것은 지속 가능하지 않습니다.

Conbee 펌웨어 : 264A0700
라이트 펌웨어 : 1.2.214

모든 진단에 도움이되어 기쁘지만 가족이 조명을 켜고 끌 수 있도록 대부분의 집을 Tradfri 게이트웨이로 되돌려 야합니다. 램프 몇 개를 남겨 두겠습니다.

kinsago 에 2019년 10월 13일

나는 방금이 문제에 흥미로운 추가 사항을 깨달았습니다.

여러 개의 객실에는 여러 개의 Tradfri GU10 스팟과 대부분의 객실에 Hue Dimmer Switch가 있으며, Phoscon 앱의 Hue Dimmer Switch 그룹에 추가하여 생성 된 방의 GU10에 직접 바인딩됩니다.

Hue Dimmer Switch가있는 직접 바인딩이있는 GU10만이 때때로 오프라인 상태가되며 다시 온라인 상태가 되려면 전원주기가 필요합니다.
Hue Dimmer Switch가있는 직접 바인딩이없는 GU10은 오프라인 상태가되지 않습니다.

JBS5 에 2019년 10월 23일

저에게는 그렇지 않은 것 같습니다. 지금까지 Hue Bulb만이 상당히 탄력적 인 것 같습니다. 내가 소유 한 모든 종류의 IKEA 장치 (GU10, E14, FLOALT 패널) 및 Osram 장치 (전구, 조명 스트립 및 정원 기둥)가 실패했습니다. 특히 Osram 장치는 완전히 실패하고 전원주기는 아무것도하지 않습니다. 그것들은 제거하고 수리해야하는데 이는 이러한 장치들에게 고통입니다.

peer69 에 2019년 10월 24일

나는 여러 장치가 실패하고 Conbee II 스틱으로의 마이그레이션이 다소 손상된 zll-db로 인해 실패한 후 너무 비싼 KNX 설치를 위해 모든 zigbee 장치를 장치로 교체하는 것에 대해 며칠을 보냈습니다. 그런 다음 모든 것을 처음부터 설정하기 위해 근본적인 접근 방식을 취했습니다. 게이트웨이를 재설정하고 모든 장치를 수리했습니다. IKEA 기기는 예전보다 훨씬 쉬웠습니다. 과거에는 게이트웨이 가까이로 이동하고, 여러 번 재설정하고, 터치 링크를 사용하여 응답하도록해야했습니다. 이번에는 아무것도 아닙니다. 전구를 재설정하고 아무 문제없이 페어링했습니다. 그래도 70 개의 장치에이 작업을 수행하는 것은 고통 스러웠고 일부 xiaomi 센서는 이케아 제품보다 조금 더 어렵게 만들었습니다. 그러나 그것은 이미 내가 더 안정적인 네트워크를 가질 수 있다고 생각하게 만듭니다. 그러나 실패한 것은 없지만 실패하면 나는 당신에게 말할 것입니다.

peer69 에 2019년 10월 28일

raspbee를 업데이트 한 지 한참 지났고, 이전 버전은 조명 온도를 읽는 데 문제가있어서 최신 펌웨어와 최신 deCONZ로 업데이트하기로 결정했습니다. 조명이 2 개뿐입니다 (OSRAM 73674). 1 개의 조명 (아마 무작위로)이 최신 deCONZ와 몇 분 후 연결이 끊어지고 수동으로 껐다가 다시 켜야합니다. 온도를 읽을 수 있고 빛을 잃지 않는 유일한 버전은 deconz-2.04.40-qt5.deb로 매우 오래되었지만 기본 용도로 작동합니다.

danielocdh 에 2019년 11월 02일

IKEA GU10 단색으로 나에게도 요즘 훨씬 더 많이 발생합니다. 엉덩이가 아파요 그러나 노드는 나를 위해 빨간색으로 표시되지 않고 회색으로 만 표시됩니다. 원격 버튼 누름에는 반응하지만 Phoscon 또는 HA를 통해서는 반응하지 않습니다.

ACrazyConcept 에 2019년 11월 03일

원격으로 제어 할 때 deCONZ가 여전히 조명 상태를 업데이트합니까?

이것은 일반적으로 deCONZ가 램프 경로를 잃었을 때 발생합니다. 램프는 여전히 네트워크에 있으며 게이트웨이에 도달 할 수 있으며 방송을 수신 할 수 있습니다. 그러나 게이트웨이는 유니 캐스트를 통해 빛에 도달 할 수 없습니다. 해결 방법으로 /lights 대신 /groups 명령을 사용할 수 있으므로 deCONZ는 대신 브로드 캐스트를 보냅니다.

Xiaomi Curtain Controller (ZigBee 라우터)에 가끔 (~ 일주일에 한 번) 동일한 문제가 여전히 발생합니다. _Device Announment_는 장치의 전원을 껐다가 켠 후 deCONZ가 경로를 다시 학습하게합니다.

이러한 라우팅 문제는 Trådfri 조명이 사용하는 라우팅 검색에 대한 지원과 함께 도입되었으므로 2.04.40은 적절하게 들립니다.

ebaauw 에 2019년 11월 03일

@ebaauw 조명을 사용할 수 없게되면 그룹 명령이 저에게 적합하지만 제한된 시간 동안 만 작동합니다. 그 후에는 표시등이 계속 켜져 있거나 꺼져 있으며 더 이상 그룹 명령에 응답하지 않습니다. 바인딩 된 Hue Dimmer Switch 사용 (Phoscon 앱에서 Hue Dimmer Switch가 페어링 될 때 기본적으로 생성 된 그룹에 조명을 추가하여 생성 된 바인딩).

JBS5 에 2019년 11월 03일

원격으로 제어 할 때 deCONZ가 여전히 조명 상태를 업데이트합니까?
이것은 일반적으로 deCONZ가 램프 경로를 잃었을 때 발생합니다. 램프는 여전히 네트워크에 있으며 게이트웨이에 도달 할 수 있으며 방송을 수신 할 수 있습니다. 그러나 게이트웨이는 유니 캐스트를 통해 빛에 도달 할 수 없습니다. 해결 방법으로 /lights 대신 /groups 명령을 사용할 수 있으므로 deCONZ는 대신 브로드 캐스트를 보냅니다.

다음에이 제안을 확인하겠습니다. 그러나 예, 그들은 일반적으로 몇 분 동안 전원을 차단했습니다. Btw IKEA "하키 퍽"리모컨을 사용합니다.

Xiaomi Curtain Controller (ZigBee 라우터)에 가끔 (~ 일주일에 한 번) 동일한 문제가 여전히 발생합니다. _Device Announment_는 장치의 전원을 껐다가 켠 후 deCONZ가 경로를 다시 학습하게합니다.
이러한 라우팅 문제는 Trådfri 조명이 사용하는 라우팅 검색에 대한 지원과 함께 도입되었으므로 2.04.40은 적절하게 들립니다.

흠 나는 그렇게 오랫동안 나에게 그렇게 나쁜 일이 아니었다. 나는 그것을 지속적으로 최신 상태로 유지했습니다.

ACrazyConcept 에 2019년 11월 03일

흠 나는 그렇게 오랫동안 나에게 그렇게 나쁜 일이 아니었다.

간헐적 인 문제입니다. 나는 그것을 마음대로 재현 할 수 없었다. # 849를 보라. 사실 조명을 제어하는 모든 규칙은 /groups 작업을 기반으로하므로 커튼 컨트롤러를 얻을 때까지 이전에는 문제를 알아 차리지 못했습니다.

조명을 사용할 수 없게되면 그룹 명령이 작동하지만 제한된 시간 동안 만 작동합니다. 그 후에는 표시등이 계속 켜져 있거나 꺼져 있으며 더 이상 그룹 명령에 응답하지 않습니다.

나는 빛이 오랜 시간 동안 속성 보고서에 대한 게이트웨이로부터 ACK를 수신하지 않을 때 네트워크를 떠나기로 결정한다고 가정합니다.

ebaauw 에 2019년 11월 03일

나는 빛이 오랜 시간 동안 속성 보고서에 대한 게이트웨이로부터 ACK를 수신하지 않을 때 네트워크를 떠나기로 결정한다고 가정합니다.

나에게 이것은 켜진 곳이나 불과 몇 분 / 시간 전에 조명으로도 발생합니다.

위에 몇 가지 답변을 게시 한 것처럼 대부분의 GU10 조명은 Hue Dimmer Switch (Hue Dimmer Switch가있는 방에서 3-8 개)에 연결되어 있습니다. 일부는 그렇지 않으며 몇 달 동안 온라인 상태입니다. 그들 중 누구도 사용할 수 없었습니다. 우연인지 아닌지 ..이 @ebaauw에 대해 어떻게 생각하세요?

JBS5 에 2019년 11월 03일

대부분의 GU10 조명은 Hue Dimmer Switch에 연결되어 있습니다.

그럴 것 같지 않습니다. deCONZ GUI의 _Bind Dropbox_ 패널에서 조광기 스위치에서 조명으로 바인딩을 만들었습니까?

ZigBee 용어에서 "바인딩"은 바인딩 된 클러스터에서 명령을 보낼 ZigBee 주소에 대한 장치의 바인딩 테이블에 항목을 만드는 것을 의미합니다. 디머 스위치의 (클라이언트!) _OnOff_ 및 _Level Control_ 클러스터가 그룹에 바인딩되어 있다고 생각합니다 (deCONZ REST API 플러그인에 의해). 이 그룹은 config.group 아래의 ZHASwitch 리소스에 나열됩니다. 다음으로 조명이이 그룹에 추가되었습니다. ZigBee 그룹은 멀티 캐스트 주소와 비슷하므로 조명이이 그룹에 대한 메시지를 구독했다고 말하는 것이 더 정확할 것입니다.

이론 상으로는 라이트 펌웨어에 버그가있어 그룹을 통해받은 명령을 처리하는 동안 중단 될 수 있다고 생각합니다. 나는 이것이 가능성이 없다고 생각합니다. 조명이 RaspBee / ConBee에 얼마나 가까운 지 (ZigBee 네트워크를 통한 홉 수) 및 / 또는 모든 조명에 동일한 하드웨어 및 펌웨어 버전이 있는지 살펴 봅니다. IKEA는 모든 장치의 새로운 ZigBee 3.0 (ZHA) 버전을 출시하는 것 같습니다.

ebaauw 에 2019년 11월 03일

대부분의 GU10 조명은 Hue Dimmer Switch에 연결되어 있습니다.
그럴 것 같지 않습니다. deCONZ GUI의 _Bind Dropbox_ 패널에서 조광기 스위치에서 조명으로 바인딩을 만들었습니까?
ZigBee 용어에서 "바인딩"은 바인딩 된 클러스터에서 명령을 보낼 ZigBee 주소에 대한 장치의 바인딩 테이블에 항목을 만드는 것을 의미합니다. 디머 스위치의 (클라이언트!) _OnOff_ 및 _Level Control_ 클러스터가 그룹에 바인딩되어 있다고 생각합니다 (deCONZ REST API 플러그인에 의해). 이 그룹은 config.group 아래의 ZHASwitch 리소스에 나열됩니다. 다음으로 조명이이 그룹에 추가되었습니다. ZigBee 그룹은 멀티 캐스트 주소와 비슷하므로 조명이이 그룹에 대한 메시지를 구독했다고 말하는 것이 더 정확할 것입니다.

아니요, deCONZ GUI의 _Bind Dropbox_ 패널에서 바인딩을 만들지 않았습니다.

Phoscon 앱에서 이러한 그룹에 조명을 추가해도 리모컨과 조명 사이에 바인딩이 생성되지 않는다는 의미입니까? deCONZ 도커 컨테이너 또는 전체 NUC가 오프라인 일 때 해당 Hue Dimmer Switch로 추가 된 조명을 전환하는 것도 가능하기 때문에 그렇게 가정했습니다.

JBS5 에 2019년 11월 03일

좋아, 지금 반응이 없네요. bth deCONZ 및 Phoscon에서 회색으로 표시되었습니다.

원격 명령과 Phoscon의 "그룹"모드에서 슬라이더를 움직일 때도 반응했습니다.

원격으로 제어 할 때 deCONZ가 여전히 조명 상태를 업데이트합니까?

회색으로 표시 되었기 때문에 처음에는 아닙니다.

그런 다음 deCONZ에서 "선택한 노드 재설정"을 시도한 다음 deCONZ에 더 이상 클러스터 라디오 버튼이 없어도 몇 분 동안 더 이상 회색으로 표시되지 않았습니다.

여전히 원격 및 그룹 명령에만 응답했지만 이제 조명 상태가 업데이트되었습니다.

잠시 후 Phoscon에서 다시 회색으로 표시되었습니다.

그런 다음 몇 분 동안 전원을 차단하려고했습니다. 도움이되지 않았습니다.

ACrazyConcept 에 2019년 11월 09일

오늘 밤 흥미로운 상황이 발생했습니다.

Tradfri 따뜻한 흰색 GU10 조명 중 하나가 몇 시간 후에 다시 오프라인 상태입니다. 현재 오프라인 상태 인 것을 포함하여 8 개의 GU10에 연결된 Hue Dimmer Switch는 deconz에 따르면 오프라인 GU10을 켜고 끕니다. 충분히 이상합니다.
다른 GU10은 바인딩 된 Hue Dimmer Switch에 응답하지 않습니다.

나머지 API로 그룹을 전환하면 오프라인 GU10을 포함한 모든 조명이 켜지거나 꺼집니다.

GU10이 이전에 오프라인이되었을 때 결합 된 Hue Dimmer Switch는 tot deconz에 따르면 오프라인 GU10을 포함하여 그룹의 모든 조명을 켜고 끕니다 (조만간 deconz에 따르면 오프라인 GU10도 그룹 명령 듣기를 중지합니다). 어느 한 쪽).

이것이 유용할까요?

\ Edit : VNC를 통한 deCONZ의 오프라인 GU10의 '이름'이 비어 있습니다.

다시 채울 때 설정되지 않습니다 (일반적으로 Phoscon 앱에서이 작업을 수행하지 않음).

여전히 노란색 :

'0'또는 'Reset selected node'를 눌러도 GU10이 다시 온라인 상태가되지 않습니다.

편집 2 : GU10이 오프라인 상태가 된 후 약 24 시간이 지나면 GU10은 이전에 설명한대로 바인딩 된 Hue Dimmer Switch에 더 이상 응답하지 않습니다. 그룹의 GU10 조명 중 어느 것도 지금 응답하지 않습니다. deCONZ GUI의 노드는 여전히 노란색이지만 이름은 회색입니다.
오프라인 GU10 라이트의 전원을 껐다 켜면 오프라인 상태였던 것을 포함하여 그룹의 모든 8 개 라이트가 바인딩 된 Hue Dimmer Switch에 다시 응답합니다.

@manup 이 동작 / 상황은 이전과는 상당히 다릅니다. 원인을 찾는 데 도움이 될 수 있습니까?

JBS5 에 2019년 11월 12일

나는 방금이 문제에 흥미로운 추가 사항을 깨달았습니다.
여러 개의 객실에는 여러 개의 Tradfri GU10 스팟과 대부분의 객실에 Hue Dimmer Switch가 있으며, Phoscon 앱의 Hue Dimmer Switch 그룹에 추가하여 생성 된 방의 GU10에 직접 바인딩됩니다.
Hue Dimmer Switch가있는 직접 바인딩이있는 GU10만이 때때로 오프라인 상태가되며 다시 온라인 상태가 되려면 전원주기가 필요합니다.
Hue Dimmer Switch가있는 직접 바인딩이없는 GU10은 오프라인 상태가되지 않습니다.

불행히도, 결합 된 Hue Dimmer Switch가없는 제 Tradfri GU10 warmwhite 중 하나가 어제부터 오프라인 상태입니다.

여전히 몇 개의 GU10 스팟 (동일한 웜 화이트)이 오프라인 상태가 아닌지 궁금합니다.
\ 편집 : 또한 몇 달 동안 온라인 상태였던 GU10도 어제부터 오프라인 상태입니다.

JBS5 에 2019년 11월 22일

지난 주말에 Tradfri Hub를 구입하여 한 방의 모든 GU10 지점을 페어링했습니다. 앞으로 몇 주 동안 무슨 일이 일어나는지 보자 ..

JBS5 에 2019년 12월 04일

내 시스템에 4 개의 IKEA 켜기 / 끄기 콘센트 스위치 (크리스마스 창 조명용)를 추가 한 후 시스템의 임의 조명이 반응하지 않기 시작했습니다. 콘센트가 집 전체에 분산되어 있습니다. 시스템에있는 조명 중 하나 이상은 하루에 전원을 껐다 켜야합니다.

문제 해결을 쉽게하기 위해 모든 유형의 로그 또는 정보를 제공 할 수 있습니까?

tubalainen 에 2019년 12월 04일

@tubalainen 무 반응 이란 무엇을 의미합니까? 전원주기가 필요합니까?

JBS5 에 2019년 12월 04일

@tubalainen 무 반응 이란 무엇을 의미합니까? 전원주기가 필요합니까?

그들은 "온라인"(회색으로 표시되지 않음)으로 나열되고 내 사진에 따르면 메시의 일부이지만 홈 어시스턴트 (또는 phoscon을 통해)에서 전환해도 아무 일도 일어나지 않습니다. 다시 작동하게하려면 전원을 껐다 켜야합니다.

tubalainen 에 2019년 12월 04일

이것에 진전이 있습니까? 내 GU10 조명이 회색으로 변하는 것이 약간 우스꽝 스럽습니다.

누군가 커튼 컨트롤러 나 켜짐 / 꺼짐 스위치를 언급 한 것 같아요. 실제로 FYRTUR 블라인드를 받았을 때 문제가 훨씬 더 악화되었다는 사실이 저에게 맞습니다. 이것은 또한 내가 네트워크에 추가 한 첫 번째 ikea 버튼이었습니다.

ACrazyConcept 에 2019년 12월 05일

여기에 Tradfri on / off 벽 스위치 나 IKEA 커튼이없고 문제가 있습니다.

JBS5 에 2019년 12월 05일

👍2

나는 여름에이 문제가 있었다. 내 GU10은 항상 중단됩니다. 모든 GU10을 최신 "테스트"소프트웨어로 업그레이드했으며 거의 2 개월 동안 문제없이 실행되었습니다.

지난 주말에 저는 두 개의 새로운 E27 전구를 추가했고 이제 몇 대의 GU10이 항상 다시 떨어집니다.

aherbjornsen 에 2019년 12월 05일

나는 여름에이 문제가 있었다. 내 GU10은 항상 중단됩니다. 모든 GU10을 최신 "테스트"소프트웨어로 업그레이드했으며 거의 2 개월 동안 문제없이 실행되었습니다.
지난 주말에 저는 두 개의 새로운 E27 전구를 추가했고 이제 몇 대의 GU10이 항상 다시 떨어집니다.

어떤 GU10 전구가 있고 어떤 펌웨어를 설치 했습니까?

ReX1983 에 2019년 12월 05일

지난 주말에 Tradfri Hub를 구입하여 한 방의 모든 GU10 지점을 페어링했습니다. 앞으로 몇 주 동안 무슨 일이 일어나는지 보자 ..

Tradfri 게이트웨이를 사용할 때 거의 매일 무응답 전구를 사용했습니다 (Tradfri GU10 백색 스펙트럼, 1 세대). 필립스 Hue 브리지로 전환했는데 문제가 사라진 것 같았지만 2 주 후에 전구 하나가 응답하지 않게되었습니다 (평소처럼 전원을 껐다 켜서 문제가 해결되었습니다).

Hue 브릿지가 Tradfri 전구와 함께 더 잘 작동하는 이유와 방법은 확실하지 않지만 실제 문제는 전구에있는 것 같습니다.

ReX1983 에 2019년 12월 05일

나는 단일 GU10을 소유하지 않지만 여전히 문제가 있습니다.

이 문제를 해결하기 위해 로그 등의 도움을받을 수있는 방법을 알려주십시오.
일부 노드가 "잠들고"처음 깨어나려고 할 때 깨어나지 않는다는 것이 (내 추측으로는) 가벼워 보입니까?

메시에 여러 노드 홉이있는 경우에만 문제가됩니까? 나에게 그것은 conbee에 하나 이상의 홉이있을 때 상당히 결과적입니다. 다시 말하지만, 그냥 느낌입니다. 확인되지 않았습니다.

tubalainen 에 2019년 12월 06일

나는 약 18 개월 된 8 GU-10을 가지고 있습니다. 그들 중 하나는 그 시간에 한 번 회색으로 변했습니다. 그들은 모두 콘비 스틱과 같은 방에 있습니다. 저는 3 년 된 980lm 전구를 가지고 있습니다. gu 10을 통해 점프하는 gw에서 가장 먼 것은 아마도 2 주에 한 번씩 회색으로 변합니다.
@tubalainen 이 뭔가에있을 수 있습니다.

회색으로 변하는 사람 옆에 나는 결코 깨어나지 않은 오스람이 있습니다.

Flurkmark 에 2019년 12월 06일

👍1

예 @tubalainen 이 단서에있을 수 있습니다. 나는 실제로 회색 GU10을 새 조명을 추가 할 때 사용하는 코드의 램프 소켓에 넣고 여러 번 다시 살아 남았습니다. 그러나 내가 그들을 제자리에 다시 놓았을 때 그들은 다시 나왔습니다. 그들이 돌아온다는 것은 100 % 일관성이 없지만 여전히 공범자 일 수 있습니다.

ACrazyConcept 에 2019년 12월 07일

👍1

여기에 또 다른 잠재적 인 단서가 있습니다. 나는 (8 개의 IKEA 램프로 1 년 넘게 가동 시간 동안) 회색으로 변하는 램프를 본 적이 없지만 Home Assistant deconz 플러그인을 3.8에서 3.9로 업데이트했고 이틀 만에 두 개의 GU10이 회색으로 변했습니다. 3.8 버전의 플러그인 백업을 복원했으며 그 이후로 문제가 없었습니다. 이상한 점은 3.8 및 3.9 플러그인이 동일한 deconz 버전을 사용한다는 것입니다 (변경 로그가 완료된 경우). 그러나 Phoscon에서도 램프에 접근 할 수 없었습니다. 이것은 모두 다소 이상하지만 플러그인의 3.9 버전이 IKEA 램프를 불안정하게 만드는 일종의 deconz 요청을한다고 가정합니다.

PremiumUsername 에 2019년 12월 19일

HA를 사용하지 않고 여전히 문제가 있습니다. 나는 ne GU10을 구입했고 이제 회색으로 변하는 모든 램프를 두 번 이상 교체합니다. 교체 한 램프는 다시 회색으로 변하지 않았습니다. 하드웨어 문제 일 수 있지만, 곧 해결 방법이 없을 것 같습니다.

peer69 에 2019년 12월 19일

비슷한 문제가 있습니다. 일부 라이트 노드는 명령에 응답하지 않고 회색이됩니다. 이상한 점은 그룹 명령을 보내면 동일한 라이트 노드가 매번 완벽하게 응답한다는 것입니다.

MikaelHoogen 에 2019년 12월 26일

비슷한 문제가 있습니다. 일부 라이트 노드는 명령에 응답하지 않고 회색이됩니다. 이상한 점은 그룹 명령을 보내면 동일한 라이트 노드가 매번 완벽하게 응답한다는 것입니다.

그룹 명령이 며칠 후 또는 일주일 이상 계속 작동합니까?
제 경우에는 조만간 조명이 그룹 명령 듣기를 중단합니다.

JBS5 에 2019년 12월 27일

비슷한 문제가 있습니다. 일부 라이트 노드는 명령에 응답하지 않고 회색이됩니다. 이상한 점은 그룹 명령을 보내면 동일한 라이트 노드가 매번 완벽하게 응답한다는 것입니다.
그룹 명령이 며칠 후 또는 일주일 이상 계속 작동합니까?
제 경우에는 조만간 조명이 그룹 명령 듣기를 중단합니다.

예, 시간이 지남에 따라 잘 작동하는 것 같습니다. 그러나 나는 무엇이 잘못되었는지에 대한 이론이 있습니다. 라이트 노드가 TRADFRI 전구 E27 WS opal 1000lm을 통해 라우팅되면 문제가 발생합니다. 그래서 어제 나는 네트워크가있는 두 개의 전원을 껐습니다. 그 이후로 모든 것이 완벽하게 작동하는 것 같습니다.

ScreenClip 4

MikaelHoogen 에 2019년 12월 28일

TRADFRI 전구 GU10 WS 400lm, TRADFRI 전구 E14 CWS 오팔 600lm 및 TRÅDFRI 전구 E27 CWS 오팔 600lm이 있습니다. 문제를 일으키지 않는 것 같습니다.

MikaelHoogen 에 2019년 12월 28일

이전 Trådfri 펌웨어와 관련이있을 수 있습니다. 최신 조명에는 최신 펌웨어가 함께 제공되지만 IKEA에서 모든 1 세대 조명에 대한 업데이트 된 펌웨어를 게시 한 것 같지 않습니다. Trådfri GU10 스팟이 없지만 CWS 전구로 펌웨어 업데이트를 받았습니다. 내 1000lm 조광 가능 전구는 그렇지 않았습니다. 나는 백색 스펙트럼 전구에 대해 잘 모르겠습니다.

ebaauw 에 2019년 12월 28일

이전 Trådfri 펌웨어와 관련이있을 수 있습니다. 최신 조명에는 최신 펌웨어가 함께 제공되지만 IKEA에서 모든 1 세대 조명에 대한 업데이트 된 펌웨어를 게시 한 것 같지 않습니다. Trådfri GU10 스팟이 없지만 CWS 전구로 펌웨어 업데이트를 받았습니다. 내 1000lm 조광 가능 전구는 그렇지 않았습니다. 나는 백색 스펙트럼 전구에 대해 잘 모르겠습니다.

내 TRADFRI 전구 GU10 WS 400lm은 동일한 펌웨어 2.0.022에 있습니다. 그들은 문제를 일으키지 않는 것 같습니다 (아직 :))

MikaelHoogen 에 2019년 12월 28일

이전 Trådfri 펌웨어와 관련이있을 수 있습니다. 최신 조명에는 최신 펌웨어가 함께 제공되지만 IKEA에서 모든 1 세대 조명에 대한 업데이트 된 펌웨어를 게시 한 것 같지 않습니다. Trådfri GU10 스팟이 없지만 CWS 전구로 펌웨어 업데이트를 받았습니다. 내 1000lm 조광 가능 전구는 그렇지 않았습니다. 나는 백색 스펙트럼 전구에 대해 잘 모르겠습니다.

나는 동의한다. Ikea 전구의 첫 번째 버전 (1. * 펌웨어)에는 두 번째 반복 (2. *)에 영향을주지 않는 일부 소프트웨어 / 하드웨어 버그가 있습니다.

슬프게도 Ikea는 더 이상 원래 버전을 지원하지 않으며 펌웨어 업데이트를 제공하지 않습니다. 동시에 전구를 반환하고 새 전구로 교체하는 것은 불가능합니다 (영국에서 시도했습니다).

ReX1983 에 2019년 12월 28일

이전 Trådfri 펌웨어와 관련이있을 수 있습니다. 최신 조명에는 최신 펌웨어가 함께 제공되지만 IKEA에서 모든 1 세대 조명에 대한 업데이트 된 펌웨어를 게시 한 것 같지 않습니다. Trådfri GU10 스팟이 없지만 CWS 전구로 펌웨어 업데이트를 받았습니다. 내 1000lm 조광 가능 전구는 그렇지 않았습니다. 나는 백색 스펙트럼 전구에 대해 잘 모르겠습니다.
나는 동의한다. Ikea 전구의 첫 번째 버전 (1. * 펌웨어)에는 두 번째 반복 (2. *)에 영향을주지 않는 일부 소프트웨어 / 하드웨어 버그가 있습니다.
슬프게도 Ikea는 더 이상 원래 버전을 지원하지 않으며 펌웨어 업데이트를 제공하지 않습니다. 동시에 전구를 반환하고 새 전구로 교체하는 것은 불가능합니다 (영국에서 시도했습니다).

1.3.009에 cws 전구가 있습니다. 그들은 문제를 일으키지 않는 것 같습니다.

MikaelHoogen 에 2019년 12월 28일

최신 정보:

다른 IKEA 전구도 문제를 일으키는 것 같습니다.

다음은 제 IKEA 전구입니다. 지금까지 문제를 일으키는 것은 TRADFRI 전구 E27 WS opal 1000lm뿐입니다. 이제 연결이 끊어지고 모든 것이 작동하는 것 같습니다. 하지만 새로운 오류가 발생하면 업데이트를 게시합니다.

Skärmklipp tradfri

MikaelHoogen 에 2019년 12월 28일

2.x 장치를 소유하고 있지 않은 것 같습니다.
일부 GU10은 제대로 작동하지만 일부는 작동하지 않습니다. 나는 결함이있는 것을 몇 달 후에 구입 한 "새"것으로 교체하기 시작했습니다. 소켓에 숫자 "1808 -S"가 인쇄되어 있지만 "최신"펌웨어에는 "1729-S"가 있지만 동일한 펌웨어를 실행하는 것 같습니다.
지금까지 전구 3 개를 교체했는데 2 주 동안 새로운 문제가 발생하지 않았습니다. GU10뿐만 아니라 교체하지 않은 FLOALT 패널에도 문제가있었습니다.

peer69 에 2019년 12월 28일

2.x 장치를 소유하고 있지 않은 것 같습니다. 일부 GU10은 제대로 작동하지만 일부는 작동하지 않습니다. 나는 결함이있는 것을 몇 달 후에 구입 한 "새"것으로 교체하기 시작했습니다. 소켓에 숫자 "1808 -S"가 인쇄되어 있지만 "최신"펌웨어에는 "1729-S"가 있지만 동일한 펌웨어를 실행하는 것 같습니다. 지금까지 전구 3 개를 교체했는데 2 주 동안 새로운 문제가 발생하지 않았습니다. GU10뿐만 아니라 교체하지 않은 FLOALT 패널에도 문제가있었습니다.

흥미 롭군요! 어떤 종류의 상관 관계가 있는지 확인하기 위해 전구를 살펴볼 것입니다.

내 노드 중 하나가 다시 문제의 영향을받는 것 같습니다. 여전히 네트워크에 IKEA 노드가 몇 개 있으므로 몇 가지 결론을 도출 할 수 있는지 확인하기 위해 몇 가지 테스트를 수행 할 것입니다.

MikaelHoogen 에 2019년 12월 28일

TRADFRI 전구 GU10 WS 400lm, TRADFRI 전구 E14 CWS 오팔 600lm 및 TRÅDFRI 전구 E27 CWS 오팔 600lm이 있습니다. 문제를 일으키지 않는 것 같습니다.

메시가 잠시 올라간 후 다른 IKEA 장치조차도 문제를 일으키고 노드가 명령에 응답하지 않는 것 같습니다. 다른 IKEA 노드도 영향을받을 수 있습니다. 나에게는 문제가 나타나기 시작한 다음 노드가 IKEA 노드를 통해 라우팅되는 것 같습니다.

이를 조사 할 계획이 있습니까? 이 문제가 해결되는 동안 모든 IKEA 장치를 색조 게이트웨이로 옮길 것입니다.

MikaelHoogen 에 2019년 12월 31일

노드는 명령에 응답하지 않습니다.

이것이 사실입니까? ZigBee 트래픽을 스니핑하여이를 확인 했습니까? 다른 노드가 게이트웨이를 통하지 않고 조명을 제어하는 무선 스위치에 더 이상 반응하지 않습니까? 더 이상 그룹 명령에 반응하지 않습니까?
내 경험상 문제는 게이트웨이가 더 이상 다른 노드에 대한 경로를 알지 못하므로 게이트웨이의 유니 캐스트 명령이 다른 노드에 도달하지 않는다는 것입니다. 노드 자체는 잘 응답하고 있으며 응답 할 항목이 없습니다.

다른 IKEA 노드도 영향을받을 수 있습니다. 나에게는 문제가 나타나기 시작한 다음 노드가 IKEA 노드를 통해 라우팅되는 것 같습니다.

(아닙니까?) 라우팅 IKEA 노드는 게이트웨이에서 다른 노드로의 경로 및 / 또는 경로 탐색을 어떻게 든 중단합니다.

이를 조사 할 계획이 있습니까?

dresden elektronik 지원을 요청해야합니다. 라우팅은 RaspBee / ConBee 펌웨어 (및 deCONZ 핵심 프로그램?)에 의해 처리됩니다. REST API 플러그인에서 이에 대해 할 수있는 일은 없습니다.

ebaauw 에 2019년 12월 31일

지난 주말에 Tradfri Hub를 구입하여 한 방의 모든 GU10 지점을 페어링했습니다. 앞으로 몇 주 동안 무슨 일이 일어나는지 보자 ..

말하기는 조금 이르지만 29 일 전에 모든 Tradfri GU10 (8x warmwhite-1.2.214)을 한 방에서 Tradfri Hub로 옮겼으며 지금까지 응답이없는 사람은 없었습니다.

JBS5 에 2019년 12월 31일

말하기는 조금 이르지만 29 일 전에 모든 Tradfri GU10 (8x warmwhite-1.2.214)을 한 방에서 Tradfri Hub로 옮겼으며 지금까지 응답이없는 사람은 없었습니다.

나는 그렇게 기대할 것이다. ZigBee 표준을 다르게 해석하는 다른 제조업체의 장치 간의 상호 작용과 같이 단일 제조업체의 장치로 인해 문제가 발생하는 것이 아닙니다. 이것이 대부분의 허브 / 게이트웨이 / 브리지가 자체 장치 만 지원하는 이유입니다. 더 흥미로운 실험은 Trådfri 지점을 Hue 브리지 또는 OSRAM 게이트웨이에 연결하는 것입니다.

또한 한 방에 8 개의 조명이 있으면 허브와 각 조명이 직접 연결됩니다 (모든 단일 홉 연결). 라우팅 문제는 인접 테이블의 항목 (일반적으로 약 20 개)보다 더 많은 장치가있는 더 큰 네트워크에서만 나타납니다. 및 / 또는 장치가 물리적으로 허브에서 범위를 벗어났습니다.

ebaauw 에 2019년 12월 31일

노드는 명령에 응답하지 않습니다.
이것이 사실입니까? ZigBee 트래픽을 스니핑하여이를 확인 했습니까? 다른 노드가 게이트웨이를 통하지 않고 조명을 제어하는 무선 스위치에 더 이상 반응하지 않습니까? 더 이상 그룹 명령에 반응하지 않습니까?
내 경험상 문제는 게이트웨이가 더 이상 다른 노드에 대한 경로를 알지 못하므로 게이트웨이의 유니 캐스트 명령이 다른 노드에 도달하지 않는다는 것입니다. 노드 자체는 잘 응답하고 있으며 응답 할 항목이 없습니다.

나는 교통을 냄새 맡을 경험이나 장비가 없습니다. 문제가 어떻게 작동하는지에 대해 정확할 수 있습니다. 내 노드는 항상 그룹 명령에 응답합니다. 문제는 유니 캐스트 명령이 목적지에 도달하지 못한다는 것입니다.

그룹 명령 만 보내는 한 모든 것이 잘 작동하는 것 같습니다.

다른 IKEA 노드도 영향을받을 수 있습니다. 나에게는 문제가 나타나기 시작한 다음 노드가 IKEA 노드를 통해 라우팅되는 것 같습니다.
(아닙니까?) 라우팅 IKEA 노드는 게이트웨이에서 다른 노드로의 경로 및 / 또는 경로 탐색을 어떻게 든 중단합니다.
이를 조사 할 계획이 있습니까?
dresden elektronik 지원을 요청해야합니다. 라우팅은 RaspBee / ConBee 펌웨어 (및 deCONZ 핵심 프로그램?)에 의해 처리됩니다. REST API 플러그인에서 이에 대해 할 수있는 일은 없습니다.

네, 이메일을 보냈지 만 체크리스트 외에는 응답을받지 못했습니다.

MikaelHoogen 에 2019년 12월 31일

말하기는 조금 이르지만 29 일 전에 모든 Tradfri GU10 (8x warmwhite-1.2.214)을 한 방에서 Tradfri Hub로 옮겼으며 지금까지 응답이없는 사람은 없었습니다.
나는 그렇게 기대할 것이다. ZigBee 표준을 다르게 해석하는 다른 제조업체의 장치 간의 상호 작용과 같이 단일 제조업체의 장치로 인해 문제가 발생하는 것이 아닙니다. 이것이 대부분의 허브 / 게이트웨이 / 브리지가 자체 장치 만 지원하는 이유입니다. 더 흥미로운 실험은 Trådfri 지점을 Hue 브리지 또는 OSRAM 게이트웨이에 연결하는 것입니다.
또한 한 방에 8 개의 조명이 있으면 허브와 각 조명이 직접 연결됩니다 (모든 단일 홉 연결). 라우팅 문제는 인접 테이블의 항목 (일반적으로 약 20 개)보다 더 많은 장치가있는 더 큰 네트워크에서만 나타납니다. 및 / 또는 장치가 물리적으로 허브에서 범위를 벗어났습니다.

여기에서 가능한 원인으로 많이 언급 된 이전 GU10의 펌웨어 1.2.214와 관련이 없는지 확인하기 위해이 작업을 수행했습니다 (그리고 GU10의 새 버전을 만드는 가능한 이유).
다른 라우터를 통해 연결된 것과 관련이있을 수 있습니다.

다른 GU10 (따뜻한 흰색 1.2.214) 조명도 Tradfri Hub (2de / 3 층에있는 조명)에 페어링하는 것을 고려할 것입니다.

JBS5 에 2019년 12월 31일

이것에 진전이 있습니까? 내 GU10 조명이 회색으로 변하는 것이 약간 우스꽝 스럽습니다.
누군가 커튼 컨트롤러 나 켜짐 / 꺼짐 스위치를 언급 한 것 같아요. 실제로 FYRTUR 블라인드를 받았을 때 문제가 훨씬 더 악화되었다는 사실이 저에게 맞습니다. 이것은 또한 내가 네트워크에 추가 한 첫 번째 ikea 버튼이었습니다.

나는 나의 마지막 포스트 이후로 네트워크에 처음 온 / 오프 스위치가 없었고 그 시간에 드롭 아웃도 없었다. 우연일지도 ...?

ACrazyConcept 에 2019년 12월 31일

이것에 진전이 있습니까? 내 GU10 조명이 회색으로 변하는 것이 약간 우스꽝 스럽습니다.
누군가 커튼 컨트롤러 나 켜짐 / 꺼짐 스위치를 언급 한 것 같아요. 실제로 FYRTUR 블라인드를 받았을 때 문제가 훨씬 더 악화되었다는 사실이 저에게 맞습니다. 이것은 또한 내가 네트워크에 추가 한 첫 번째 ikea 버튼이었습니다.
나는 나의 마지막 포스트 이후로 네트워크에 처음 온 / 오프 스위치가 없었고 그 시간에 드롭 아웃도 없었다. 우연일지도 ...?

아니요, Tradfri on / off 또는 Tradfri 커튼이 없으며이 문제가 있습니다.
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -562299982

JBS5 에 2019년 12월 31일

실수로이 문제를 종료했습니다. 재개.

JBS5 에 2019년 12월 31일

더 흥미로운 실험은 Trådfri 지점을 Hue 브리지 또는 OSRAM 게이트웨이에 연결하는 것입니다.

Trådfri 허브에 연결된 Trådfri 전구 (1 세대)에서 동일한 문제가 발생했습니다. 모든 전구를 Hue 브리지로 옮겼을 때 문제가 완전히 사라졌습니다.

BTW-나는 여전히 Trådfri 전구의 1 세대에 버그가 있다고 확신하지만 Hue 브리지는 조명을 다르게 처리합니다. ).

ReX1983 에 2019년 12월 31일

Hue 브리지는 조명을 다르게 처리합니다 (Hue에 연결할 때 조명이 몇 초 동안 동기화되지 않는 경우가 있습니다. Trådfri에서는 발생하지 않았습니다).

Hue 설정에서 조명은 Hue 브리지에 의해서만 제어됩니다. 무선 스위치와 센서는 브리지에 알림을 보내 조명을 제어하는 규칙을 트리거합니다. 브리지는 조명 상태를 예측하고 조명에 명령을 보낼 때 캐시를 미리 업데이트합니다. 주기적으로 조명을 폴링하여 캐시 된 상태를 확인 / 업데이트합니다.

Trådfri 설정에서 조명은 무선 스위치 및 센서의 명령에 의해 직접 제어됩니다. 그런 다음 표시등이 업데이트 된 상태의 보고서를 허브로 보냅니다.

(Trådfri) 무선 스위치 또는 센서에서 직접 Hue 브리지에 연결된 조명을 제어 할 때 Hue 브리지가 조명에 대한 속성보고를 설정하지 않기 때문에 지연이 발생합니다. 네트워크에 조명이 많을수록 폴링이 더 많은 조명을 순환하므로 지연이 길어집니다.

Hue 전구를 Trådfri 허브에 연결하고 (Trådfri) 무선 스위치 또는 센서에서 직접 조명을 제어 할 때 Hue 조명이 속성보고를 수행하지 않고 Trådfri 허브가 폴링을 수행하지 않기 때문에 허브 상태가 업데이트되지 않습니다.

이러한 차이점은 REST API 플러그인의 제어 범위 내에서 애플리케이션 수준에 있습니다. 라우팅은 ZigBee 스택에서 더 낮은 수준에 있습니다.

ebaauw 에 2019년 12월 31일

👍2

이제 모든 IKEA 라우터 노드가 내 색조 브리지로 이동되었습니다. 내 네트워크에 여전히 동일한 문제가 있습니다. 그래서 나는 그것이 그것을 일으키는 다른 무언가라고 생각합니다. 또한 라우팅되고 게이트웨이에 대한 직접 링크가없는 노드에 영향을줍니다.

MikaelHoogen 에 2020년 01월 01일

이제 모든 IKEA 라우터 노드가 내 색조 브리지로 이동되었습니다. 내 네트워크에 여전히 동일한 문제가 있습니다. 그래서 나는 그것이 그것을 일으키는 다른 무언가라고 생각합니다. 또한 라우팅되고 게이트웨이에 대한 직접 링크가없는 노드에 영향을줍니다.

이제 Hue 브리지와 쌍을 이루는 Tradfri 조명과 동일한 문제가 발생합니까?

@ebaauw 조명이 브리지에 직접 연결되고 라우터를 통해 연결될 때 또는 브리지에 직접 연결되지 않은 경우에만 라우팅 문제가 나타나야합니까?

JBS5 에 2020년 01월 01일

이제 모든 IKEA 라우터 노드가 내 색조 브리지로 이동되었습니다. 내 네트워크에 여전히 동일한 문제가 있습니다. 그래서 나는 그것이 그것을 일으키는 다른 무언가라고 생각합니다. 또한 라우팅되고 게이트웨이에 대한 직접 링크가없는 노드에 영향을줍니다.
이제 Hue 브리지와 쌍을 이루는 Tradfri 조명과 동일한 문제가 발생합니까?
전구가 3 개만 페어링되어 있습니다. 그러나 내가 알아 차린 문제는 없습니다.

@ebaauw 조명이 브리지에 직접 연결되고 라우터를 통해 연결될 때 또는 브리지에 직접 연결되지 않은 경우에만 라우팅 문제가 나타나야합니까?

내 네트워크에서 내 경험은 손실 된 명령 문제가 게이트웨이와 직접 연결되지 않고 다른 노드를 통해 라우팅되는 노드에 영향을 미친다는 것입니다. IKEA 전구가 연결되어 있지 않아도 같은 문제가 발생합니다.

게이트웨이에 대한 직접 링크가없는 하나의 노드 (1)가 있습니다. 유니 캐스트 명령에 응답하지 않았습니다 (또는 ebaauw가 언급했듯이 라우팅 문제로 인해 노드에 도달하지 못했을 수도 있음). 노드 (2)의 전원을 끄면 노드 (1)가 게이트웨이로 직접 경로를 가져와 완벽하게 작동하기 시작했습니다.

MikaelHoogen 에 2020년 01월 01일

조명이 라우터를 통해 브리지에 직접 연결되거나 브리지에 직접 연결되지 않은 경우에만 라우팅 문제가 나타나야합니까?

ZigBee에는 "연결"과 같은 것이 없습니다. 각 라우터는 MAC 수준에서 직접 도달 할 수있는 주변 장치의 인접 테이블을 유지합니다. deCONZ GUI의 행은 이러한 인접 테이블의 그래픽 표현에 지나지 않습니다 (deCONZ가 실제로 이러한 테이블을 읽은 한).

라우터가 인접 테이블에없는 장치에 메시지를 보내야하는 경우 해당 요청을 인접 라우터로 전송하여 전달할 수 있습니다. NWK 수준의 단일 메시지는 MAC 수준에서 여러 홉을 통해 재전송됩니다. RaspBee / ConBee (이 관점에서)는 또 다른 라우터입니다. Afaik 최종 장치는 상위 라우터에만 메시지를 보냅니다.

따라서 조명이 RaspBee / ConBee의 인접 테이블에 있으면 해당 조명이 다른 라우터의 인접 테이블인지 여부에 관계없이 경로 검색이 포함되지 않습니다. 그렇지 않은 경우 RaspBee / ConBee는 어떤 인접 라우터가 빛에 도달하는 방법을 알고 있는지 파악해야합니다. 라이트가 여러 홉 떨어져있는 경우 경로에있는 각 라우터는 반복적으로 동일한 작업을 수행해야합니다.

세부 정보가 손실 될까 두렵지 만이 경로 검색을 수행하는 방법에는 여러 가지가 있습니다. 게이트웨이와 램프 사이의 경로에있는 라우터가 다른 방식을 사용하면 상황이 잘못 될 수 있습니다. 게이트웨이는 결국 잘못된 이웃 라우터 (빛에 도달하는 방법을 알지 못함)로 메시지를 보내거나 게이트웨이가 빛에 도달하는 방법을 전혀 모르고 메시지를 전혀 보내지 않을 수 있습니다. 유니 캐스트 메시지는 일반적으로 ACK로 응답해야하므로 게이트웨이는 ACK를받지 못하면 장치를 연결할 수없는 것으로 표시합니다. 물론 원본 메시지 또는 ACT가 손실되었는지 여부를 알 수있는 방법은 없습니다 (원격 장치는 ACK를 전송하기 위해 게이트웨이에 대한 경로를 알아야 함).

그룹 명령에서 사용되는 브로드 캐스트 메시지는 라우팅을 사용하지 않습니다. 모든 라우터에 의해 MAC 수준에서 단순히 재방송됩니다. 매우 안정적이지만 많은 네트워크 대역폭을 소비합니다. 또한 ACK가 응답하지 않습니다.

내 네트워크에서 내 경험은 손실 된 명령 문제가 게이트웨이와 직접 연결되지 않고 다른 노드를 통해 라우팅되는 노드에 영향을 미친다는 것입니다. IKEA 전구가 연결되어 있지 않아도 같은 문제가 발생합니다.

따라서 라우팅 문제의 경우 장치가 RaspBee / ConBee의 라우팅 테이블에 나타나지 않을만큼 충분히 큰 네트워크가 필요합니다. 장치 수가 라우팅 테이블의 크기를 초과하거나 원격 장치가 물리적으로 RaspBee / ConBee의 범위를 벗어 났고 다른 라우터를 통해서만 도달 할 수 있기 때문입니다. 여러 홉이 문제를 악화시킬 것이라고 생각합니다.

다시 말하지만, 경로 탐색을 수행하기 위해 다소 호환되지 않는 다른 방법을 사용하는 제조업체가 다르기 때문에 IKEA의 잘못은 아닙니다. 특히 다중 홉 경로의 경우 RaspBee / ConBee 펌웨어에서 해결할 수있는 작업이 너무 많습니다.

게이트웨이에 대한 직접 링크가없는 하나의 노드 (1)가 있습니다. 유니 캐스트 명령에 응답하지 않았습니다 (또는 ebaauw가 언급했듯이 라우팅 문제로 인해 노드에 도달하지 못했을 수도 있음). 노드 (2)의 전원을 끄면 노드 (1)가 게이트웨이로 직접 경로를 가져와 완벽하게 작동하기 시작했습니다.

다시 말하지만, 세부 사항이 손실 될까 두렵지 만이 동작을 유발하는 여러 시나리오를 생각할 수 있습니다. RaspBee / ConBee는 node2 또는 node1에 메시지를 보내려고하고 ack를받지 않고 node2에 연결할 수 없다고 결론을 내리고 인접 테이블에서 제거합니다. 이제 테이블에는 node1에 사용되는 새 항목을위한 공간이 있습니다.

ebaauw 에 2020년 01월 01일

다시 말하지만, 경로 탐색을 수행하기 위해 다소 호환되지 않는 다른 방법을 사용하는 제조업체가 다르기 때문에 IKEA의 잘못은 아닙니다. 특히 다중 홉 경로의 경우 RaspBee / ConBee 펌웨어에서 해결할 수있는 작업이 너무 많습니다.

이것은 좀 더 철저한 표준이 확립되고 따를 때까지 다중 벤더 ZigBee 플랫폼의 접근 방식이 설계에 의해 결정되는 것처럼 들립니다. 어차피 내 환경에서 작동하지 않을 수도있는 여러 게이트웨이를 사용하고 싶지 않기 때문에 지금은 약간 잠겨 있습니다 (예 : 현재 작동하는 전구를 제거하면 게이트웨이에서 직접 도달 할 수없는 센서의 경우). 라우터).

peer69 에 2020년 01월 01일

이것은 멀티 벤더 ZigBee 플랫폼의 접근 방식이 운명 인 것처럼 들립니다.

나는 분명히 원하지 않지만 확실히 도전적입니다. 여기서 크기는 중요해 보입니다. 네트워크가 충분히 작 으면 이러한 라우팅 문제가 전혀 발생하지 않을 수 있습니다. 또한 네트워크의 (지리적) 중심이 호환되는 공급 업체의 라우터로 구성된 경우 네트워크 에지에있는 호환되지 않는 일부 라우터는 다른 장치에 도달하기 위해 라우팅되지 않기 때문에 문제가되지 않을 것입니다.

나는 내 OSRAM, Trådfri 및 innr 전구 (문제를 일으키는)를 Hue 전구로 교체했습니다. 이제 104 개의 노드, 51 개의 라우터 및 53 개의 최종 장치가 있습니다. 라우터의 2/3는 Hue 조명입니다. 도달 할 수없는 유일한 라우터 (하지만 여전히 보고서를 보내는 중)는 Xiaomi 커튼 컨트롤러입니다. 최종 장치 중 20 개는 Hue, 20 개의 Xiaomi, 8 개의 Eurotronic Spirit 및 5 개의 IKEA입니다. Eurotronic Spirit과 IKEA Fyrtur가 정기적으로 문제를 일으키고 있습니다 (부모가 쫓아 내지 만 새로운 부모를 찾지 못합니다. 다시 게이트웨이에서 도달 할 수 없지만 여전히 보고서를 보내는 경우). 모든 장치에서 전원 순환은 일반적으로 상황을 해결하지만 때로는 장치의 전원을 순환 할 때 네트워크를 열어야합니다.

나는 공급 업체가 아닌 내 네트워크를 분할하는 것을 고려하고 있습니다. 이것은 많은 작업이며 문제의 원인을 자세히 이해하고 어떤 설정으로 인해 문제가 발생하지 않을 수 있는지 더 잘 이해할 때까지 그렇게하기를 꺼립니다.

ebaauw 에 2020년 01월 01일

@ebaauw , 위의 게시물에서 말한 내용을 생각하면 deCONZ 라우팅 테이블에 대한 일종의 선호도를 고려하는 것이 흥미로울 것입니다. 첫 번째 홉으로 바람직하지 않은 '블랙리스트'라우터를 고려할 수 있습니까? 충분한 '좋은'라우터를 포함하도록 네트워크를 구축 할 수 있다면 첫 번째 홉은 항상이를 통과하고 두 번째 홉은 네트워크의 다른 모든 장치에 도달합니다.
이것이 확실한 해결책은 아니지만 항상 '선호하는'라우터를 통과하면서 훨씬 더 큰 (지리적 및 장치 수) 네트워크를 허용합니다.

또 다른 생각 : IKEA (Silabs EFR32, gecko 엔진)에서 어떤 칩을 사용하는지 알고 있고 (인터넷의 다양한 소스에서) Silabs에서 제공하는 zigbee 엔진을 사용한다는 것을 알고 있으므로 두 가지 조치를 고려할 수 있습니다.

우리는 silabs 엔진이 라우팅을 수행하는 방식을 분석하고 그로부터이 문제의 원인을 도출합니다.
동일한 silabs 엔진을 기반으로 사용자 정의 버전의 램프 펌웨어를 구축하고 문제를 해결하며 OTA가 해당 펌웨어를 설치하는 방법을 알아냅니다.

둘 다 Silabs SDK에 대한 액세스 권한이 필요합니다. 여기서 활동하는 사람이 ..? SDK가 포함 된 개발 키트를 위해 500 달러를내는 것을 기대하지 않습니다. 드레스덴 일렉트로닉스가 그렇게 할 수 있을까요?

내 2 캐럿 (때때로 연결이 끊어지는 것에 다소 실망 함).

djwlindenaar 에 2020년 01월 02일

👍1

첫 번째 홉으로 바람직하지 않은 '블랙리스트'라우터를 고려할 수 있습니까?

우리 : 아닙니다. RaspBee / ConBee 펌웨어에서 구현되어야한다고 생각합니다. 나쁜 생각은 아니지만 장치 EEPROM 및 NVRAM의 크기 제한을 고려할 때 이것이 얼마나 실현 가능한지 전혀 모릅니다. @manup , 이것에 대해 어떻게 생각하십니까?

동일한 silabs 엔진을 기반으로 사용자 정의 버전의 램프 펌웨어를 구축하고 문제를 해결하며 OTA가 해당 펌웨어를 설치하는 방법을 알아냅니다.

이것은 나의 현재 지식과 솔직히 내 야망을 뛰어 넘는 방법입니다. 저는 취미로 이것을합니다. 나는 ZigBee 애플리케이션을 작성할 수 있는지 확인하기 위해 XBee를 가지고 놀았지만 (내 궁극적 인 목표는 베네 시안 블라인드를 스마트 화하는 것입니다) 라우팅이 이루어지는 ZigBee 스택의 하위 수준을 살펴본 적이 없습니다. .

ebaauw 에 2020년 01월 02일

우리 : 아닙니다. RaspBee / ConBee 펌웨어에서 구현되어야한다고 생각합니다. 나쁜 생각은 아니지만 장치 EEPROM 및 NVRAM의 크기 제한을 고려할 때 이것이 얼마나 실현 가능한지 전혀 모릅니다. @manup , 이것에 대해 어떻게 생각하십니까?

나는 우리의 @manup 부분을 고려

이것은 나의 현재 지식과 솔직히 내 야망을 뛰어 넘는 방법입니다. 저는 취미로 이것을합니다. 나는 ZigBee 애플리케이션을 작성할 수 있는지 확인하기 위해 XBee를 가지고 놀았지만 (내 궁극적 인 목표는 베네 시안 블라인드를 스마트 화하는 것입니다) 라우팅이 이루어지는 ZigBee 스택의 하위 수준을 살펴본 적이 없습니다. .

나에게도 그것이 취미라는 데 동의하지만, 누군가가 이러한 세부 사항에 대해 더 잘 알고 있기를 바랍니다.

나는 스프링클러 시스템을 지그비화할 계획 인 CC2530 보드를 사용하여 비슷한 작업을 해왔습니다 (특정 스프링클러를 수동으로 켜고 끄기 위해 정원을 걸어 다니는 것을 받아 들일 수 없습니다. :)) 컴파일 할 수있었습니다. deCONZ 네트워크에 온 / 오프 표시등으로 연결되는 CC2530 보드 용 zigbee 펌웨어. 사용하려는 밸브에는 래칭 메커니즘이 있으므로 전환하려면 특정 신호가 필요하므로 자체 펌웨어를 만들어야했습니다.

djwlindenaar 에 2020년 01월 02일

우리 : 아닙니다. RaspBee / ConBee 펌웨어에서 구현되어야한다고 생각합니다. 나쁜 생각은 아니지만 장치 EEPROM 및 NVRAM의 크기 제한을 고려할 때 이것이 얼마나 실현 가능한지 전혀 모릅니다. @manup , 이것에 대해 어떻게 생각하십니까?

펌웨어의 Zigbee 스택에는 품질 (RSSI / LQI)에 따라 직접 링크 대신 경로를 사용할지 여부를 제어하는 매개 변수가 있습니다. 이것은 이미 꽤 잘 작동해야하며 수년에 걸쳐 조정되었습니다.

추가 경로는 모든 장치의 라우팅 테이블을 제어하는보다 일반적인 접근 방식 일 수 있습니다.

참고 : 라우터를 선택하고 R 키를 눌러 라우터의 라우팅 테이블을 쿼리 할 수 있습니다. 다음 홉 경로는 파란색으로 표시됩니다.

현재 Zigbee 네트워크가 열리면 Mgmt_Permit_Joining_req가 브로드 캐스트로 전송되기 때문에 모든 라우터가 상위 노드가 될 수 있습니다. 그러나이 요청을 특정 라우터에만 유니 캐스트로 보내면 새 장치는이 하나의 장치를 통해서만 참가할 수 있습니다. 이는 종종 부모에게 고정되는 Xiaomi 최종 장치에 유용 할 수 있습니다. 라우터 및 예를 들어 Philips Hue 최종 장치와 같은 다른 연결 장치의 경우 새 부모 및 경로를 자유롭게 선택할 수 있으므로 별 도움이되지 않습니다.

Zigbee R22 사양의 (신규) Mgmt_NWK_IEEE_Joining_List_req도 흥미로워 보입니다.

Mgmt_NWK_IEEE_Joining_List_req 명령은 네트워크에 연결될 것으로 예상되는 IEEE 주소 목록을 얻기위한 메커니즘으로 제공됩니다. 이를 통해 로컬 라우터는 향상된 비콘 요청을 필터링하고 참여중인 장치에만 응답 할 수 있습니다.

비콘이 없으면 장치는 특정 라우터에 연결하려고 시도조차하지 않습니다. 하지만 현재 사용 가능한 라우터가이 요청을 얼마나 잘 지원하는지 모르겠습니다.

은색 총알은 게이트웨이가 각 프레임 내에서 완전한 경로를 제공하는 소스 라우팅을 사용할 수 있지만, 소비자 제품이나 게이트웨이에서 사용되는 것을 본 적이 없으므로 현재 라우터에서 지원하지 않을 수 있습니다 (또는 제대로 지원되지 않을 수 있음). 그래도 시도해 볼 가치가 있습니다.

manup 에 2020년 01월 02일

참고 : 라우터를 선택하고 R 키를 눌러 라우터의 라우팅 테이블을 쿼리 할 수 있습니다. 다음 홉 경로는 파란색으로 표시됩니다.

멋지다, 나는 그것을 몰랐다. GUI에서 지원하는 모든 키 / 명령에 대한 개요가 있습니까? 다음 노드를 쿼리하기 전에 파란색 선을 되돌릴 수 있습니까? RaspBee / ConBee 자체에서는 작동하지 않는 것 같습니다.

라우팅 테이블이 인접 테이블과 다른가요? Sniffing, 저는 ZDP _Link Quality Request_ 및 _Link Quality Response_ 메시지 만보고 인접 테이블을보고합니다. 파란색으로 표시되지 않은 노드에 대한 선이 "수신"경로라는 의미입니까?

ebaauw 에 2020년 01월 02일

@manup , 실제로 흥미로운 시각화

은색 총알이 소스 라우팅을 사용하고있을 수 있습니다.

글쎄 ... 그럴만 한 가치가있는 것 같아요. 내 네트워크에서 가장 영향을받는 IKEA 조명은 코디네이터로부터 먼 거리에있는 조명 인 것 같습니다. @ebaauw가 언급했듯이 라우팅과 관련된 것이 문제를 일으키는 것으로 의심되었습니다.
나는 당신을 위해 이와 같은 것을 기꺼이 테스트 할 것입니다. 그러나 연결이 끊어지는 것은 그다지 신뢰할 수 없으므로 테스트가 어려울 수 있음을 인정해야합니다.

나는 코디네이터의 라인을 따라 첫 번째 홉에 대해 선택할 라우터를 선택하는 것을 더 많이 생각했습니다. IKEA 장치 (아마도 IKEA 라우터 일 수 있음)와 잘 작동하는 라우터를 찾을 수 있다면이를 통해 모든 패킷을 라우팅하면 상황이 더욱 견고해질 것입니다. 첫 번째 홉에 대해 특정 라우터를 선호하도록 경로 검색 프로세스를 속일 수 있는지 확실하지 않지만 @manup 에 대해 언급 할 수 있습니다.

djwlindenaar 에 2020년 01월 02일

참고 : 라우터를 선택하고 R 키를 눌러 라우터의 라우팅 테이블을 쿼리 할 수 있습니다. 다음 홉 경로는 파란색으로 표시됩니다.
멋지다, 나는 그것을 몰랐다. GUI에서 지원하는 모든 키 / 명령에 대한 개요가 있습니까? 다음 노드를 쿼리하기 전에 파란색 선을 되돌릴 수 있습니까? RaspBee / ConBee 자체에서는 작동하지 않는 것 같습니다.

누군가가 모든 키 콤보와 그 기능을 나열하고 싶다면 그것을 정리하고 위키 페이지를 작성하게되어 기쁩니다.

dandrzejewski 에 2020년 01월 02일

멋지다, 나는 그것을 몰랐다. GUI에서 지원하는 모든 키 / 명령에 대한 개요가 있습니까?

요청 노드 설명자 = 1
파워 설명자 요청 = 2
Nwk 주소 요청 = 0
요청 라우팅 테이블 = R
Mgmt Leave 요청 = L
활성 엔드 포인트 요청 = 7
간단한 설명자 요청 = 8
새로 고침 = F5 / Cmd-R
삭제 = Delete / Backspace
게이트웨이 장치 Annce = A (그다지 유용하지 않음)

다음 노드를 쿼리하기 전에 파란색 선을 되돌릴 수 있습니까?

아직은 경로를 보는 것이 빠르고 더러운 추가였습니다. :)
Shift-R 와 같은 다른 키를 추가하여 노드의 경로를 지우는 것이 유용할까요?

RaspBee / ConBee 자체에서는 작동하지 않는 것 같습니다.

불행히도 RaspBee I / ConBee 관련 ZDP 명령을 지원하지 않으며 ConBee II에서 작동합니다.

라우팅 테이블이 인접 테이블과 다른가요? 스니핑, ZDP 링크 품질 요청 및 링크 품질 응답 메시지 만 표시되며 인접 테이블을보고합니다.

이들은 두 개의 분리 된 테이블이며, 일반적으로 라우팅 테이블은 직접 연결할 수없고 인접 테이블 (1 홉 노드)의 대상인 노드에 대한 경로 만 보유합니다.

인접 테이블에 있고 신호가 강한 노드의 경우 경로 검색이 필요하지 않습니다. 인접 테이블 자체는 주로 1 홉 NWK 링크 상태 명령을 사용하여 빌드됩니다.

파란색으로 표시되지 않은 노드에 대한 선이 "수신"경로라는 의미입니까?

파란색이 아닌 선 (녹색 / 주황색 / 노란색)은 1 홉 인접 테이블을 나타냅니다. 파란색 선은 일부 목적지로 나가는 경로이며 현재보기에서 다음 홉 (전체 경로가 아님) 만 나타냅니다. 목적지 NWK 주소는 표시되지 않지만 디버그 인쇄가있을 가능성이 있습니다.

manup 에 2020년 01월 03일

👍2

우리 : 아닙니다. RaspBee / ConBee 펌웨어에서 구현되어야한다고 생각합니다. 나쁜 생각은 아니지만 장치 EEPROM 및 NVRAM의 크기 제한을 고려할 때 이것이 얼마나 실현 가능한지 전혀 모릅니다. @manup , 이것에 대해 어떻게 생각하십니까?
펌웨어의 Zigbee 스택에는 품질 (RSSI / LQI)에 따라 직접 링크 대신 경로를 사용할지 여부를 제어하는 매개 변수가 있습니다. 이것은 이미 꽤 잘 작동해야하며 수년에 걸쳐 조정되었습니다.
추가 경로는 모든 장치의 라우팅 테이블을 제어하는보다 일반적인 접근 방식 일 수 있습니다.
참고 : 라우터를 선택하고 R 키를 눌러 라우터의 라우팅 테이블을 쿼리 할 수 있습니다. 다음 홉 경로는 파란색으로 표시됩니다.

정말 유용한 기능! 어제 펌웨어 2.0.022로 TRÅDFRI 전구 GU10 WS 400lm (7 전구)의 전원을 켰습니다. 오늘 문제는 펌웨어 1.3.009와 함께 TRÅDFRI 전구 E27 CWS opal 600lm에 나타났습니다. 이 기능 덕분에 E27 전구가 GU10 전구를 통해 라우팅되는 것을 볼 수있었습니다. 나는 모든 GU10의 전원을 끄고 마법처럼 E27이 다시 작동하기 시작했습니다.

따라서 Innr 및 IKEA를 통한 라우팅으로 인해 문제가 발생하고 있음이 분명 해지고 있습니다. Innr och IKEA 전구를 색조 게이트웨이로 옮기기 시작했습니다. 필립스 전구는 좋은 라우터이며 문제를 일으키지 않는 것 같습니다.

MikaelHoogen 에 2020년 01월 04일

그래서 거실에서 조명의 위치를 바꾸면서 약간의 실험을했습니다. 라우터 2 개를 제거하고 조명 1 개를 재배치했습니다. Et voila, 하나의 빛이 좀비가되었지만 완전히는 아닙니다. 가끔 연결이 끊어지는 IKEA 조명에서 본 것과 똑같이 작동합니다.

IKEA 표시등은 연결할 수없는 것으로 표시되지만 그룹 명령에 여전히 응답합니다. 또한 다른 여러 라우터에서 여전히 알고 있기 때문에 빛을보고 있다고보고하는 것 같습니다 ( 0x000B57FFFEC52C7D ).

11:49:33:392 ZDP Mgmt_Lqi_rsp zdpSeq: 190 from 0x000B57FFFE9BEBC3 total: 11, startIndex: 6, listCount: 3
11:49:33:392     * neighbor: 0x00158D00017028B0 (0xA3F5), LQI: 71, relation: 0x02 rxOnWHenIdle: 1
11:49:33:392     * neighbor: 0x90FD9FFFFE054F81 (0xC7BC), LQI: 41, relation: 0x02 rxOnWHenIdle: 1
11:49:33:393     * neighbor: 0x000B57FFFEC52C7D (0xD338), LQI: 69, relation: 0x02 rxOnWHenIdle: 1

과

11:49:50:017 Node 0x000B57FFFEC52C7D is known by 7 neighbors, last seen 33 s

때로는 의사 소통이 가능해 보입니다.

11:49:44:901 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 11:49:44:902 0x0000 11:49:44:902 ]
11:49:44:902 add task 6636 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 213
11:49:44:902 Poll APS request 213 to 0x000B57FFFEC52C7D cluster: 0x0006
11:49:44:904 Idle timer triggered
11:49:44:951 Poll APS confirm 213 status: 0x00
11:49:44:951 Erase task req-id: 213, type: 19 zcl seqno: 89 send time 0, profileId: 0x0104, clusterId: 0x0006

때로는 그렇지 않습니다.

12:18:51:033 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:18:51:033 0x0000 12:18:51:033 ]
12:18:51:033 add task 4658 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 119
12:18:51:033 Poll APS request 119 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:19:02:077 Poll APS confirm 119 status: 0xA7
12:19:02:077     drop item attr/modelid
12:19:02:077     drop item attr/swversion
12:19:02:077     drop item state/bri
12:19:02:077 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task

무엇이 잘못되었는지에 대한 정보는 거의 없습니다. 0xA7 상태는 무엇을 의미합니까 ..?

무슨 일이 일어나고 있는지 알아내는 데 도움이 될 추가 정보가 있습니까?

djwlindenaar 에 2020년 01월 04일

그래서 거실에서 조명의 위치를 바꾸면서 약간의 실험을했습니다. 라우터 2 개를 제거하고 조명 1 개를 재배치했습니다. Et voila, 하나의 빛이 좀비가되었지만 완전히는 아닙니다. 가끔 연결이 끊어지는 IKEA 조명에서 본 것과 똑같이 작동합니다.
IKEA 표시등은 연결할 수없는 것으로 표시되지만 그룹 명령에 여전히 응답합니다. 또한 다른 여러 라우터에서 여전히 알고 있기 때문에 빛을보고 있다고보고하는 것 같습니다 ( 0x000B57FFFEC52C7D ).
11:49:33:392 ZDP Mgmt_Lqi_rsp zdpSeq: 190 from 0x000B57FFFE9BEBC3 total: 11, startIndex: 6, listCount: 3
11:49:33:392     * neighbor: 0x00158D00017028B0 (0xA3F5), LQI: 71, relation: 0x02 rxOnWHenIdle: 1
11:49:33:392     * neighbor: 0x90FD9FFFFE054F81 (0xC7BC), LQI: 41, relation: 0x02 rxOnWHenIdle: 1
11:49:33:393     * neighbor: 0x000B57FFFEC52C7D (0xD338), LQI: 69, relation: 0x02 rxOnWHenIdle: 1
과
11:49:50:017 Node 0x000B57FFFEC52C7D is known by 7 neighbors, last seen 33 s
때로는 의사 소통이 가능해 보입니다.
11:49:44:901 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 11:49:44:902 0x0000 11:49:44:902 ]
11:49:44:902 add task 6636 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 213
11:49:44:902 Poll APS request 213 to 0x000B57FFFEC52C7D cluster: 0x0006
11:49:44:904 Idle timer triggered
11:49:44:951 Poll APS confirm 213 status: 0x00
11:49:44:951 Erase task req-id: 213, type: 19 zcl seqno: 89 send time 0, profileId: 0x0104, clusterId: 0x0006
때로는 그렇지 않습니다.
12:18:51:033 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:18:51:033 0x0000 12:18:51:033 ]
12:18:51:033 add task 4658 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 119
12:18:51:033 Poll APS request 119 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:19:02:077 Poll APS confirm 119 status: 0xA7
12:19:02:077     drop item attr/modelid
12:19:02:077     drop item attr/swversion
12:19:02:077     drop item state/bri
12:19:02:077 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task
무엇이 잘못되었는지에 대한 정보는 거의 없습니다. 0xA7 상태는 무엇을 의미합니까 ..?
무슨 일이 일어나고 있는지 알아내는 데 도움이 될 추가 정보가 있습니까?

이것은 내 문제의 정확한 복제처럼 들립니다!

MikaelHoogen 에 2020년 01월 04일

0xA7 상태는 무엇을 의미합니까 ..?

여기를 참조하십시오 : https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

dedepene 에 2020년 01월 04일

👍2

전원 순환 조명

12:39:21:833 ZDP device announce: 0x000B57FFFEC52C7D, 0xD338, 0x8E
12:39:21:833 ZDP add fast discover for 0x000b57fffec52c7d
12:39:21:838 DeviceAnnce of LightNode: 0x000b57fffec52c7d Permit Join: 0
12:39:22:040 ZDP finished fast discover for 0x000b57fffec52c7d

그리고 그 상태를 기쁘게보고하는 것 같습니다

12:39:22:665 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:39:22:665 0x0000 12:39:22:665 ]
12:39:22:665 add task 10024 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 175
12:39:22:665 Poll APS request 175 to 0x000B57FFFEC52C7D cluster: 0x0006
12:39:22:753 Poll APS confirm 175 status: 0x00
12:39:22:753 Erase task req-id: 175, type: 19 zcl seqno: 167 send time 0, profileId: 0x0104, clusterId: 0x0006
12:39:22:920 Node 0x000B57FFFEC52C7D is known by 9 neighbors, last seen 1 s

그때:

12:39:26:760 ZDP active ep request to 0x000b57fffec52c7d
12:39:26:760 ZDP send request id: 0x07 to 0x000b57fffec52c7d
---
12:39:32:520 node 0000B57FFFEC52C7D leave wait state
12:39:32:521 ZDP active ep request to 0x000b57fffec52c7d
12:39:32:521 Incr. ZDP retry count 2 on item 7
---
12:39:44:655 add task 10125 type 21 to 0x000B57FFFEC52C7D cluster 0x0004 req.id 60
12:39:44:700 Erase task req-id: 60, type: 21 zcl seqno: 171 send time 0, profileId: 0x0104, clusterId: 0x0004
---
12:39:45:405 create binding for attribute reporting of cluster 0x0000
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0000
12:39:45:405 create binding for attribute reporting of cluster 0x0006
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0006
12:39:45:405 create binding for attribute reporting of cluster 0x0008
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0008
12:39:45:405 Force binding of attribute reporting for node HK houtlamp 2
---
12:39:50:760 Node 0x000B57FFFEC52C7D is known by 9 neighbors, last seen 28 s
---
12:40:06:904 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
12:40:08:905 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
---
12:40:11:881 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:40:11:881 0x0000 12:40:11:881 ]
12:40:11:882 add task 10241 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 205
12:40:11:882 Poll APS request 205 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:40:21:640 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:22:957 Poll APS confirm 205 status: 0xA7
12:40:22:957     drop item attr/modelid
12:40:22:957     drop item attr/swversion
12:40:22:957     drop item state/bri
12:40:22:957 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task
12:40:22:957 Erase task req-id: 205, type: 19 zcl seqno: 175 send time 11, profileId: 0x0104, clusterId: 0x0006
12:40:22:957 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 78 s
---
12:40:28:904 giveup binding srcAddr: B57FFFEC52C7D
---
12:40:30:904 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
---
12:40:32:050 giveup binding srcAddr: B57FFFEC52C7D
---
12:40:33:568 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:39:481 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:42:987 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 10 s
---
12:40:43:276 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:40:43:276 0x0000 12:40:43:276 ]
12:40:43:277 add task 10380 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 157
12:40:43:277 Poll APS request 157 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:40:54:621 Poll APS confirm 157 status: 0xA7
12:40:54:621     drop item attr/modelid
12:40:54:621     drop item attr/swversion
12:40:54:621     drop item state/bri
12:40:54:621 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task
12:40:54:621 Erase task req-id: 157, type: 19 zcl seqno: 180 send time 12, profileId: 0x0104, clusterId: 0x0006
12:40:54:621 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 22 s

작동을 멈 춥니 다. 2 분 후까지

12:42:10:529 LightNode removed 0x000b57fffec52c7d
12:42:10:530 Node zombie state changed 0x000b57fffec52c7d
---
12:42:39:361 Node 0x000B57FFFEC52C7D is known by 0 neighbors, last seen 0 s
---
12:43:06:904 add task 11002 type 21 to 0x000B57FFFEC52C7D cluster 0x0004 req.id 83
12:43:06:953 Erase task req-id: 83, type: 21 zcl seqno: 198 send time 0, profileId: 0x0104, clusterId: 0x0004
12:43:07:329 Node 0x000B57FFFEC52C7D is known by 0 neighbors, last seen 22 s
---
12:43:12:455 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:43:12:455 0x0000 12:43:12:455 ]
12:43:12:455 add task 11026 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 125
12:43:12:455 Poll APS request 125 to 0x000B57FFFEC52C7D cluster: 0x0006
12:43:12:498 ZDP status = 0x00 -> SUCCESS

나는 공중에서 무슨 일이 일어나고 있는지 알아 내기 위해 지그비 스니퍼를 구해야한다고 생각한다.

그 후 다시 작동을 멈췄습니다. 이번에는 좀 더 영구적입니다.

djwlindenaar 에 2020년 01월 04일

0xA7 상태는 무엇을 의미합니까 ..?
여기를 참조하십시오 : https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

감사합니다! 왠지 기대했던 것입니다 ...

djwlindenaar 에 2020년 01월 04일

😄1

TRÅDFRI 전구 GU10 WS 400lm (7 전구)을 필립스 Hue 브리지와 페어링하려고했습니다. 네트워크의 여러 다른 전구를 사용할 수 없게되었고 TRÅDFRI 전구 GU10 WS 400lm은 Deconz에서와 동일한 동작을 보였으며 그룹 명령에 대한 응답이지만 유니 캐스트에는 응답하지 않았습니다.

TRÅDFRI 전구 GU10 WS 400lm에 문제가있는 것 같습니다. 개별 전구이거나 작동하지 않는 모든 전구이면 몇 가지 테스트를 수행합니다.

MikaelHoogen 에 2020년 01월 07일

이제 몇 가지 테스트를 수행했습니다. 내 결론은 실제로 네트워크가 응답하지 않는 원인은 개별 전구라는 것입니다. Hue Bridge에서 즉시 almons가 나타 났고 전원을 끄 자마자 다시 작동하기 시작했습니다. 따라서 7 개의 전구 중 3 개가 영향을받습니다 . 새로운 문제가 발견되면보고하겠습니다.

MikaelHoogen 에 2020년 01월 07일

@MikaelHoogen , 어떤 버전의 전구와 펌웨어가 있습니까?

ReX1983 에 2020년 01월 07일

이 문제는 v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS 및 Ikea, HUE 및 DeCONZ 게이트웨이의 3 개 FLOALT 패널 모두에서 작년 반 동안 보았습니다.
나는 이것이 HW 문제라고 확신합니다. 노드가 죽는 것은 완전히 무작위입니다.
노르웨이에서는 모든 전자 제품의 보증 기간이 2 년 미만입니다. 티켓을 열고 그들이 말하는 것을 듣습니다.
FLOALT에 관해서. 몇 달 전, Ikea는 그들에게 정리 세일을 진행했습니다. 아마도 그것은 모든 v1을 제거하는 것이 었습니까?
FLOALT v2를 본 사람이 있습니까? (아마도 sy5882 드라이버로?)

olemr 에 2020년 01월 08일

이 문제는 v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS 및 Ikea, HUE 및 DeCONZ 게이트웨이의 3 개 FLOALT 패널 모두에서 작년 반 동안 보았습니다.
나는 이것이 HW 문제라고 확신합니다. 노드가 죽는 것은 완전히 무작위입니다.
노르웨이에서는 모든 전자 제품의 보증 기간이 2 년 미만입니다. 티켓을 열고 그들이 말하는 것을 듣습니다.
FLOALT에 관해서. 몇 달 전, Ikea는 그들에게 정리 세일을 진행했습니다. 아마도 그것은 모든 v1을 제거하는 것이 었습니까?
FLOALT v2를 본 사람이 있습니까? (아마도 sy5882 드라이버로?)

그것은 또한 내가 꽤 오랫동안 말하려고 노력한 것입니다. Trådfri v1 전구에만 문제가 있습니다. Philips Hue 브릿지는 도움이되지만 여전히 노드에 도달 할 수없는 경우가 있습니다.

ReX1983 에 2020년 01월 08일

며칠 전 저는 12 개의 IKEA GU10 전구를 모두 새 버전 (따뜻한 흰색)으로 교체하기로 결정했습니다.
이로 인해이 문제가 더욱 악화되었습니다. 이제 Hue GU10 흰색 분위기와 Hue E14 색상도 손실됩니다.

ACrazyConcept 에 2020년 01월 13일

deConz와 IKEA 조명이 나올 때부터 사용하고 있습니다. 내 네트워크에는 약 70 개의 노드가 있습니다. 대부분은 IKEA 조명입니다. 필립스 Hue (조명 4 개)가 거의없고 Osram이 하나 있습니다. 센서 Ikea 모션이 거의없고 Xiaomi 모션 센서가 많습니다.

나는이 설정으로 꽤 오랫동안 실행 해 왔으며 하루가 다른 조명이 걸리지 않고 구매하지 않으므로 전원을 껐다가 켜야합니다. 내 아내는 흥분하지 않고 나도 마찬가지입니다. 나는 모든 지그비 장치를 버리고 평범한 구식 조명으로 이동합니다. 작동하지 않습니다. 매우 실망스러운. 다른 사람들이 순수한 Philips 또는 Osram 조명을 사용하여 동일한 문제를 보는지 궁금합니다. 아니면 IKEA가 쓰레기입니까?

donnib 에 2020년 01월 16일

deConz와 IKEA 조명이 나올 때부터 사용하고 있습니다. 내 네트워크에는 약 70 개의 노드가 있습니다. 대부분은 IKEA 조명입니다. 필립스 Hue (조명 4 개)가 거의없고 Osram이 하나 있습니다. 센서 Ikea 모션이 거의없고 Xiaomi 모션 센서가 많습니다.
나는이 설정으로 꽤 오랫동안 실행 해 왔으며 하루가 다른 조명이 걸리지 않고 구매하지 않으므로 전원을 껐다가 켜야합니다. 내 아내는 흥분하지 않고 나도 마찬가지입니다. 나는 모든 지그비 장치를 버리고 평범한 구식 조명으로 이동합니다. 작동하지 않습니다. 매우 실망스러운. 다른 사람들이 순수한 Philips 또는 Osram 조명을 사용하여 동일한 문제를 보는지 궁금합니다. 아니면 IKEA가 쓰레기입니까?

이 스레드에서 똑같은 문제를 가진 모든 사람들을 살펴보면 deconz 제작자는 IKEA 조명의 냄새가 IKEA 펌웨어 문제처럼 보이는 문제를 파악할 수 없습니다.

많은 사용자가 IKEA 허브에서도 비슷한 문제를 겪고 있습니다. 그래서 이것은 deconz와 관련된 독특한 문제가 아니라고 생각합니다. 그러나 누군가이 문제를 고칠 수 있다면 "패치 / 해결 방법 찾기"는 여기에있는 사람 일 것입니다! <3

나는 가족과 설정 모두에 똑같은 문제가 있습니다.

tubalainen 에 2020년 01월 16일

👍1

안타깝습니다 :( 특히 오늘 판매하는 새 제품에도 여전히 이러한 문제가 있습니다. 이해가 안 돼요. 저는 2017 년부터 제 제품을 가지고 있으므로 지금까지 문제가 해결 될 것으로 예상합니다. 전체를 제거하는 것을 고려해야합니다. 여기에서 고칠 수 없습니다. 했으므로이 문제를 해결할 수있는 사람은 IKEA 뿐이며 아직 해결하지 않았기 때문에 아직 희망이 없습니다.

donnib 에 2020년 01월 16일

Deconz 버전 2.05.69
Conbee II 펌웨어 264A0700

100 % 완벽하지 않고 제가 눈에 띄는 드롭 아웃은 E27 Ikea (Rev1) 전구입니다.
필립스 Hue 브리지와 함께이 Ikea 조명을 사용했을 때 견고했기 때문에 아마도 Hue로 다시 옮기고이 Zigbee 메쉬를 순수하게 CC2531 (라우터 펌웨어) 및 Xiaomi 센서로 유지했습니다.
Innr 전구 (E14)와 SP120도 있지만 Deconz에서는 여전히 괜찮습니다.

jtebbens 에 2020년 01월 16일

저는 Home Assistant와 Deconz를 사용하여 약 20 개의 Ikea 전구 (및 기타 여러 센서)를 제어하고 있습니다. 전구는 주로 GU10으로 3 개 지점으로 하나의 조명으로 그룹화됩니다.

저는이 설정을 15 개월 이상 사용해 왔으며 이번 여름부터 하나 이상의 전구가 고착되어 전원을 껐다가 켜야하거나 심지어 제거하고 Zigbee 네트워크에 다시 추가하는 문제가있었습니다. 이것은 항상 HASS의 라이트 그룹에 정의 된 GU10이었습니다.

몇 주 전에 Phoscon에서 조명 그룹을 만들고 HASS에서 이러한 그룹을 참조하기 시작했습니다.

그 후 전구가 멈춰서 전원을 껐다 켜야하는 문제가 전혀 발생하지 않았습니다. 내가 보는 유일한 문제는 모든 실내 조명을 한 번에 끌 때 전체 Phoscon / Deconz 그룹이 계속 켜져 있다는 것입니다.

나에게 이것은 Deconz API의 문제로 보이며 여러 전구를 빠르게 연속적으로 처리 할 수 있습니다.

aherbjornsen 에 2020년 01월 16일

👍4

또한 Ikea 장치 (전구 및 최근 Symfonisk 리모컨)를 사용할 수 없게되어 deCONZ와 다시 페어링해야하는 문제도 있습니다. 나는 이러한 문제를 6 개월 정도 동안 봤습니다. 최근에 더 자주 발생한다고 생각하는 것보다 많이 추가하지 않습니다. 다양한 E27과 E14 (및 다양한 리모컨) 만있는 GU10 전구가 없습니다. 특정 기기는 탈락하는 경향이 더 많은 것 같습니다 (메쉬 방식 또는 유사 방식에 따라 다름). Conbee I에서 최신 FW / Phoscon / deCONZ를 사용하는 최대 범위가 5m 인 장치가 약 20 개 있습니다.

mvjt 에 2020년 02월 01일

또한 Ikea 장치 (전구 및 최근 Symfonisk 리모컨)를 사용할 수 없게되어 deCONZ와 다시 페어링해야하는 문제도 있습니다. 나는 이러한 문제를 6 개월 정도 동안 봤습니다. 최근에 더 자주 발생한다고 생각하는 것보다 많이 추가하지 않습니다. 다양한 E27과 E14 (및 다양한 리모컨) 만있는 GU10 전구가 없습니다. 특정 기기는 탈락하는 경향이 더 많은 것 같습니다 (메쉬 방식 또는 유사 방식에 따라 다름). 최신 FW / Phoscon / deCONZ를 사용하는 Conbee I에서 최대 범위가 5m 인 약 20 개의 장치가 있습니다.

Deconz 버전 2.05.69를 사용해보세요. Ikea, Innr 및 Xiaomi로 나에게 꽤 안정적입니다.

jtebbens 에 2020년 02월 01일

비슷한 문제가 있고 티켓이 https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2256#issue -543476970

2.05.67 버전으로 다운 그레이드하면 내 네트워크가 그 어느 때보 다 훨씬 안정적이라고 말할 수 있습니다. 반응하지 않는 상태가 된 전구가 몇 개 있었지만 두 개가 같고 그 전구와 함께 살 수 있습니다. 어제 모든 것이 예상대로 작동했습니다.

가능한 모든 부분이 혼합 된 문제로 보이며 물론 찾기가 어렵습니다. 그러나 deconz 버전은 안정적인 솔루션을 가지고 있는지 여부의 주요 부분으로 보입니다.

또한 Ikea 장치 (전구 및 최근 Symfonisk 리모컨)를 사용할 수 없게되어 deCONZ와 다시 페어링해야하는 문제도 있습니다. 나는 이러한 문제를 6 개월 정도 동안 봤습니다. 최근에 더 자주 발생한다고 생각하는 것보다 많이 추가하지 않습니다. 다양한 E27과 E14 (및 다양한 리모컨) 만있는 GU10 전구가 없습니다. 특정 기기는 탈락하는 경향이 더 많은 것 같습니다 (메쉬 방식 또는 유사 방식에 따라 다름). 최신 FW / Phoscon / deCONZ를 사용하는 Conbee I에서 최대 범위가 5m 인 약 20 개의 장치가 있습니다.
Deconz 버전 2.05.69를 사용해보세요. Ikea, Innr 및 Xiaomi로 나에게 꽤 안정적입니다.

뿐만 아니라 그것을 시도 할 것입니다

몇 주 전에 Phoscon에서 조명 그룹을 만들고 HASS에서 이러한 그룹을 참조하기 시작했습니다.

PeterRemnemark 에 2020년 02월 01일

그래서 마침내 스니핑 하드웨어를 얻었고 모든 ieee802.15.4 주소에 대한 이름을 표시하기 위해 Wireshark를 약간 해킹했습니다 (이는 진행중인 내용을 훨씬 쉽게 읽을 수있게 해줍니다).

어쨌든, 지그비에 대한 내 지식은 그다지 강력하지 않으므로 어리석은 질문을 던지는 것 같습니다. 그러나 나는 몇 가지 스니핑 로그를 살펴 보았고 이케아 조명의 불안정한 동작을 설명하는 것을 볼 수 있기를 바랍니다.

아래 로그를 참조하십시오. 그것이 '정상적인'행동처럼 보입니까? 관련된 두 조명 모두 Ikea ligths입니다. 먼저 DeConz는 'Zolder'를 통해 라우팅하여 'Garage'에 요청을 보냅니다. 그런 다음 'Zolder'가 'Garage'로 전송하려고 시도하지만 실패한 것처럼 보이며 (왜?) 매우 빠르게 연속해서 20 번 재 시도합니다 (대부분 3ms 이내). 마지막으로 'Zolder'는 포기하고 링크 실패를 DeConz로 다시 보냅니다.

전송을 재 시도 할 때 이렇게 공격적이어야합니까?

또한 : DeConz는 링크가 분명히 실패하더라도 Zolder를 통해 Garage에 계속해서 요청을 보내는 것을 알았습니다. DeConz는 Garage가 Zolder의 링크 상태 보고서에 더 이상 없을 때도이를 수행합니다. 또한 가끔 Garage가 Zolder의 링크 상태 보고서에있는 경우 들어오고 나가는 비용 모두 7입니다. 실제로 Garage에서 DeConz로가는 경로는 Zolder를 통하지 않습니다 ...
DeConz는 링크 실패 메시지 후에도 Zolder를 통해 계속 라우팅하는 이유는 무엇입니까?

No.          Time         Source       Transmit Dev Receive Dev  Destination  Protocol     Info         
7580         748.356336   DeConz       DeConz       Zolder       Garage       ZigBee ZDP   Link Quality Request
7582         748.360218   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7583         748.363417   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7584         748.368857   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7585         748.373337   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7587         748.419739   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7588         748.424219   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7589         748.429019   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7590         748.434460   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7591         748.481181   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7592         748.485021   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7593         748.488541   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7594         748.492702   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7595         748.541983   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7596         748.545824   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7597         748.550944   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7598         748.556384   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7599         748.594786   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7600         748.597986   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7601         748.602787   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7602         748.608226   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7603         748.640867   Zolder       Zolder       DeConz       DeConz       ZigBee       Network Status, 0x9e0c: Non-tree Link Failure

djwlindenaar 에 2020년 02월 02일

👍3

좋아, 그래서 나는 silabs ZigBee 문서를 읽는데 시간을 보냈다 (IKEA는 silabs 칩을 기반으로한다).
재시도 동작은 문서에 설명 된 것과 똑같습니다.

DeConz가이 경로를 사용하는 이유에 대한 의문이 남습니다. 링크 비용이 높고 링크 실패의 응답이 있으며 여전히 해당 경로가 사용됩니다. 왜..?
(더 나은 경로를 사용할 수 있습니다 ...)

djwlindenaar 에 2020년 02월 02일

👍5

이 수준에서는 도움을 드릴 수 없지만 @djwlindenaar에 매우 유용한 통찰력이 있습니다. 이것은 내 의심을 약간 확인합니다. 우연히 정전이 발생하고 집 전체가 정전 될 때까지 괜찮은 네트워크 (소프트웨어 다운 그레이드 포함)가있었습니다.

그 후 나는 다시 돌아 왔고 다시 잘못된 경로가 있다고 생각합니다.

한 가지 더. deconz는 실제 장치가 응답하지 않더라도 상태를 어떻게 설정합니까? 전구가 인터페이스에 켜져 있지만 물리적으로 꺼져있는 것 같습니다 (아직 전원이 공급 됨). 때때로 (소프트웨어를 통해) 다시 켜기 위해 작동하고 때로는 전원 사이클로 작동하지만 종종 전원 사이클 후에도 전혀 응답하지 않습니다. 같은 전구가 잠시 후 갑자기 다시 반응 할 수 있습니다.

PeterRemnemark 에 2020년 02월 04일

좀 더 흥미로운 동작 (동일한 조명을 보여 주지만 네트워크의 다른 곳에서도 발생합니다)

DeConz는 many-to-one route Route Request 패킷을 보냅니다. 결과적으로 모든 장치는 먼저 경로 검색을 수행합니다. 이는 집중 기 (코디네이터)에게 해당 장치에 도달하는 방법에 대한 정보를 제공하기위한 것입니다. DeConz는 라우팅을 위해이 정보를 무시하는 것 같습니다.

No.         Time        Source      Tran Dev    Recv Dev    Destination Protocol    Info
7544        747.873     DeConz      DeConz      Zolder      Garage      ZigBee ZDP  Link Quality Request
7546        747.876     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7547        747.882     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7548        747.887     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7549        747.892     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7550        747.919     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7551        747.925     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7552        747.929     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7553        747.932     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7554        747.980     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7555        747.985     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7556        747.990     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7557        747.995     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7558        748.046     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7559        748.052     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7560        748.055     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7561        748.061     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7563        748.066     Garage      Garage      Kerstver    DeConz      ZigBee      Route Record, Dst: 0x0000
7565        748.076     Garage      Kerstver    HK zoutlamp DeConz      ZigBee      Route Record, Dst: 0x0000
7567        748.084     Garage      HK zoutlamp DeConz      DeConz      ZigBee      Route Record, Dst: 0x0000

마지막 패킷에는 차고로가는 방법에 대한 정보가 있습니다.

Command Frame: Route Record
    Command Identifier: Route Record (0x05)
    Relay Count: 2
    Relay Device 1: 0x731e[Kerstverli]
    Relay Device 2: 0xa3f5[HK zoutlam]

하지만 차고에 대한 다음 요청은 Zolder를 통해 다시 전송됩니다.

No.         Time        Source      Tran Dev    Recv Dev    Destination Protocol    Info
7569        748.112847  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7570        748.117327  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7573        748.126608  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request

이 동작이 IKEA의 색다른 조명 동작과 관련이 있다는 사실에 놀라지 않을 것입니다.

@manup , 당신은 이것에 대해 언급 할 수 있습니까? 소스 라우팅이 도움이 될 것이라는 귀하의 진술은 많은 의미가 있습니다.
또는 DeConz의 라우팅 테이블을 업데이트하기 위해 Route Record의 정보를 사용하는 것이 이미 크게 개선되었을 것으로 예상합니다.
또는 DeConz가 링크 문제를보고하는 경로를 계속 사용하기를 원하거나 대안에 비해 높은 라우팅 비용이 드는 이유를 파악해야합니다.

djwlindenaar 에 2020년 02월 05일

👍1

또 다른 관찰 ... 위 패킷의 두 릴레이 장치는 모두 Xiaomi 플러그입니다. 링크 품질에 대해 쿼리되지 않습니다. 왜?
DeConz가 Link Quality Response의 정보를 사용하여 경로 테이블을 구축하고 따라서 매우 유효한 라우터를 무시할 수 있습니까? 내 불행한 IKEA 조명에 대한 좋은 링크 품질로 ...

djwlindenaar 에 2020년 02월 05일

ikea 장치에만이 동작이 표시됩니까? 아니면 최적의 경로를 무시하는 일반적인 동작 만 표시됩니까? 이케아 장치가 꽤 많을 것 같아요?

PeterRemnemark 에 2020년 02월 05일

잘 모르겠습니다. 확인해야합니다. 좋은 질문.

저는 이케아 전구를 꽤 많이 가지고 있습니다.

내 생각에 이것은 도달 할 수없는 IKEA 조명으로 본 행동의 상당 부분을 설명합니다. 지금은 가설에 불과하지만 검증해야합니다.

djwlindenaar 에 2020년 02월 05일

다른 여러 경로를 살펴보면 동일한 동작이 나타납니다.

Xiaomi 장치가 다른 모든 브랜드의 Link Quality에 대해 쿼리되지 않는다는 것만 알 수 있습니다. 이건 일종의 블랙리스트 인 것 같은데 ..?

다른 라우팅 동작의 예 :

DeConz에서 항상 :
DeConz --> WC Lamp --> Badkamer Ledstrip

다 대일 경로 요청 후 자주 경로 변경을 반환합니다. 지리적 관점에서 보면이 모든 것이 의미가 있습니다.
Badkamer Ledstrip --> WC Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> DeConz
Badkamer Ledstrip --> Zoldertrap Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> Zoldertrap Lamp --> DeConz

차고 조명의 경우 DeConz에서 볼 수 있습니다.
DeConz --> Zolder Noord Lamp --> Garage (매우 불안정한 경로 ..!)

내가 보는 귀국 경로 :
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz

이제 링크 상태 보고서의 표를 보면 Garage에서 DeConz로가는 경로 위의 경로가 의미가 있습니다.
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz 총 비용 : 4
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz 총 비용 : 4

DeConz에서 Garage로 :
DeConz --> Zolder Noord Lamp --> Garage 총 비용 : 12 (DeConz에서 Zolder Noord Lamp로 들어오는 비용 기준)

@manup , 사용중인 경로 비용 알고리즘에 대해 자세히

djwlindenaar 에 2020년 02월 06일

오늘 좀 더 분석 ...
이전 게시물에서 차고 조명이 Zolder 조명을 통해 라우팅되는 것을 보았습니다. 두 IKEA 전구. Zolder에서 Garage 로의 무선 링크는 도달 할 수있는 범위의 가장자리에 있으므로 자주 실패합니다.

오늘날 Garage 조명은 그룹 명령에 응답하지만 유니 캐스트 명령에는 응답하지 않습니다. 실제로 때로는 그렇고 때로는 그렇지 않습니다. 이것은이 스레드를 읽거나 기여한 사람들에게 익숙해야하는 동작입니다.

스니핑 로그에서 찾을 수 있습니다. 때로는 Zolder 조명이 Garage와 통신 할 수 있지만 때로는 그렇지 않습니다. Zolder 조명이 Garage와 통신 할 수 없을 때마다 다음과 같이보고합니다.

ZigBee Network Layer Command, Dst: DeConz, Src: Zolder No
    Frame Control Field: 0x1a09, Frame Type: Command, Discover Route: Suppress, Security, Destination, Extended Source Command
    Destination: 0x0000[DeConz]
    Source: 0xd6b7[Zolder Noo]
    Radius: 30
    Sequence Number: 65
    Destination: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)
    Extended Source: SiliconL_ff:fe:c3:4a:3e (00:0b:57:ff:fe:c3:4a:3e)
    ZigBee Security Header
    Command Frame: Network Status
        Command Identifier: Network Status (0x03)
        Status Code: Non-tree Link Failure (0x02)
        Destination: 0x9e0c[Garage]

이 패킷은 DeConz에게 Garage에 도달 할 다른 경로를 찾기 시작하라고 알려야하지만 그렇게되지는 않습니다. Garage로 전송 된 다음 패킷은 Zolder를 통해 다시 라우팅됩니다. 나에게 그것은 해결해야 할 버그입니다.
차고에 대한이 다음 패킷은 Zolder 라이트에 의해 수신되지만 해당 라이트는 차고로 보내려고 시도조차하지 않습니다. 아마도 이것은 좋지 않은 IKEA 펌웨어의 동작 일 수 있지만 문제의 근본 원인은 DeConz가 대체 경로를 찾는 것을 거부했기 때문입니다.
오랜 시간 동안 경로를 사용할 수없는 경우 802.15.4 프로토콜보다 높은 수준의 ACK에 대해 Garage 조명이 부족하여 펌웨어 연결이 끊어 지거나 충돌이 발생할 수 있습니다. 그리고 나는 그것이 안된다는 데 동의하지만 근본 원인은 DeConz가 차고 조명에 대한 새로운 경로를 찾는 것을 거부하는 것입니다.

오늘 저는 DeConz가 차고 조명으로가는 다른 경로를 찾기 위해 실험을했습니다. 그래서 Zolder 조명에서 주전원을 분리하고 스니핑 로그를 살펴 보았습니다. 몇 번의 시도 끝에 DeConz는 Zolder가 사라 졌다는 것을 깨닫고 Garage로가는 대체 경로를 찾기 위해 진행합니다. 다음으로 Zolder를 다시 연결하고 Zolder의 존재를 발표 한 후 새로운 경로를 찾습니다. DeConz는 (아직) Zolder를 통해 Garage를 라우팅하도록 되 돌리지 않습니다.

재미있는 점은 새로운 상황에서 DeConz가 이제 라우터없이 Garage 조명과 직접 대화한다는 것입니다.
Zolder는 이제 2 개의 다른 라우터를 통해 경로를 통해 도달하므로 (분명히 DeConz에서 직접 연결할 수 있었지만) DeConz 라우팅 펌웨어 내에서 일부 테이블 (이웃 테이블?)이 가득 찬 것처럼 보입니다.

아마도 이것은 실패한 경로에 대한 응답으로 새 경로를 만드는 것을 거부 한 것과 관련이있을 수 있습니다 ..?

@manup , 위의 게시물에 대한 의견을

저를 괴롭히기 때문에 이러한 문제에 대한 해결책을 만드는 데 도움을 드리고 싶습니다. 펌웨어 소스 코드에 대한 액세스 권한을 부여하면 직접 기여할 수 있습니다 (오픈 소스가 아니더라도). 나는 그런 식으로 Dresden Elektronik을 돕는 것에 신경 쓰지 않는다. :)

djwlindenaar 에 2020년 02월 09일

👍13 ❤5

훌륭합니다! 💪🏼
이 문제를 해결하기 위해 개발자의 관심을 끌 수 있기를 바랍니다. 설정과 프로세스가 잘되어 있으므로 수정이 "쉽게"확인 될 수 있습니다.
나는 이제 내가 본 행동을 "자기 치유"라고 부르고 왜 일부 전구가 갑자기 작동하는지 이해합니다.

PeterRemnemark 에 2020년 02월 09일

내가 @manup이 볼 수 있기를 바랍니다 @djwlindenaar 잘 했어.

Webserve 에 2020년 02월 16일

@manup 어떤 의견?

donnib 에 2020년 02월 18일

이 스레드와 작업에 감사드립니다. 저는 20 개의 ikea 전구 업데이트 펌웨어를 실행하고 있으며 1 년이되었습니다. 처음부터 낙하가 얼거나 전구가 손실되었지만 너무 자주는 아니 었습니다. 나중에 deconz 업데이트로 인해 악화되었습니다. 내 네트워크가 2.4 패키지 환경에서 최적화되었는지 확인했습니다. 여전히 전구가 매일 떨어지고 버튼이나 센서가이 전구를 통해 라우팅되어 데이터 이동을 보내지 않기 때문에 쓸모 없게 만듭니다. 전구가 다시 연결되기 시작하면 센서를 다시 사용할 수 있도록 전원을 껐다가 켜야합니다. 바라건대 이것은 많은 관심을 끌 것입니다. 실망 스럽습니다.

realwax 에 2020년 02월 23일

또 다른 관찰 ... 위 패킷의 두 릴레이 장치는 모두 Xiaomi 플러그입니다. 링크 품질에 대해 쿼리되지 않습니다. 왜?
DeConz가 Link Quality Response의 정보를 사용하여 경로 테이블을 구축하고 따라서 매우 유효한 라우터를 무시할 수 있습니까? 내 불행한 IKEA 조명에 대한 좋은 링크 품질로 ...

이웃 테이블의 쿼리 (일명 ZDP Mgmt_Lqi_req)는 Xiaomi 장치에서 잠시 후 이러한 쿼리에 응답하지 않았기 때문에 비활성화되었으며 펌웨어의 오류로 인해 잘못된 상태 또는 더 나쁜 상태가 발생할 수 있다고 의심되었습니다.

따라서 특정 요청을 제한하는 주요 동인은 최종 장치 펌웨어의 오류를 방지하고 관련 공급 업체 게이트웨이 동작을 거의 모방하는 것입니다. 일부 조사 결과는 https://github.com/dresden-elektronik/deconz-rest 에서 찾을 수 있습니다.

참고로 인접 테이블 쿼리는 시각적 메시 프레젠테이션을 작성하는 데만 사용되며 네트워크 작업이나 라우팅 테이블에 영향을주지 않습니다.

manup 에 2020년 02월 23일

그래서 마침내 스니핑 하드웨어를 얻었고 모든 ieee802.15.4 주소에 대한 이름을 표시하기 위해 Wireshark를 약간 해킹했습니다 (이는 진행중인 내용을 훨씬 쉽게 읽을 수있게 해줍니다).
어쨌든, 지그비에 대한 내 지식은 그다지 강력하지 않으므로 어리석은 질문을 던지는 것 같습니다. 그러나 나는 몇 가지 스니핑 로그를 살펴 보았고 이케아 조명의 불안정한 동작을 설명하는 것을 볼 수 있기를 바랍니다.
아래 로그를 참조하십시오. 그것이 '정상적인'행동처럼 보입니까? 관련된 두 조명 모두 Ikea ligths입니다. 먼저 DeConz는 'Zolder'를 통해 라우팅하여 'Garage'에 요청을 보냅니다. 그런 다음 'Zolder'가 'Garage'로 전송하려고 시도하지만 실패한 것처럼 보이며 (왜?) 매우 빠르게 연속해서 20 번 재 시도합니다 (대부분 3ms 이내). 마지막으로 'Zolder'는 포기하고 링크 실패를 DeConz로 다시 보냅니다.
전송을 재 시도 할 때 이렇게 공격적이어야합니까?
또한 : DeConz는 링크가 분명히 실패하더라도 Zolder를 통해 Garage에 계속해서 요청을 보내는 것을 알았습니다. DeConz는 Garage가 Zolder의 링크 상태 보고서에 더 이상 없을 때도이를 수행합니다. 또한 가끔 Garage가 Zolder의 링크 상태 보고서에있는 경우 들어오고 나가는 비용 모두 7입니다. 실제로 Garage에서 DeConz로가는 경로는 Zolder를 통하지 않습니다 ...
DeConz는 링크 실패 메시지 후에도 Zolder를 통해 계속 라우팅하는 이유는 무엇입니까?
No.          Time         Source       Transmit Dev Receive Dev  Destination  Protocol     Info         
7580         748.356336   DeConz       DeConz       Zolder       Garage       ZigBee ZDP   Link Quality Request
7582         748.360218   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7583         748.363417   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7584         748.368857   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7585         748.373337   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7587         748.419739   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7588         748.424219   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7589         748.429019   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7590         748.434460   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7591         748.481181   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7592         748.485021   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7593         748.488541   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7594         748.492702   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7595         748.541983   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7596         748.545824   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7597         748.550944   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7598         748.556384   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7599         748.594786   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7600         748.597986   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7601         748.602787   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7602         748.608226   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7603         748.640867   Zolder       Zolder       DeConz       DeConz       ZigBee       Network Status, 0x9e0c: Non-tree Link Failure

잘 잡아! 여기서 저는 deCONZ 펌웨어가이 오류를 처리해야한다고 생각하고 새로운 경로를 찾기 위해 재 시도합니다. 이 케이스가 어떻게 처리되는지 펌웨어를 확인하겠습니다. 경로가 실제로 삭제되었지만 동일한 경로를 통해 새 메시지가 수신되면 이미지를 볼 수 있습니다. 예를 들어 조명에서 ZCL 속성보고로 인해 항목은 그대로 유지됩니다.

들어오는 프레임에서 명령을 수신하는 것만으로 경로를 설정할 수 있습니다. 그러나 마지막 홉이 그 전에 홉을 유지하지 않으면 (일반적으로 수행하는 방식) 동일한 홉을 통과하는 방식은 작동하지 않습니다. 귀하의 결과는 해당 사례를 정확히 반영 할 수 있습니다.

manup 에 2020년 02월 23일

감사.

이 경우 Zolder를 통해 수신 된 Garage 조명의 메시지는 없습니다. 따라서 나는 DeConz가 경로를 계속 사용하기를 기대하지 않습니다. 내 다른 게시물보기 ...

djwlindenaar 에 2020년 02월 23일

상태 코드 : 비-트리 링크 실패 (0x02)

승자가 된 것 같습니다. Zigbee 스택 소스 (R21, ConBee II)를 확인했으며이 상태 코드는 완전히 무시됩니다. : -O AVR Zigbee 스택도 확인해야합니다. 동일한 문제 일 수 있습니다.

수정 사항으로 "No Route Available"상태가 처리되는 것과 동일한 방식으로이 코드를 처리하고 싶습니다. 이는 경로 항목을 해제하고 스택이 새 항목을 알아 내도록하는 것입니다.

manup 에 2020년 02월 23일

🎉6

코디네이터에서 IKEA 조명으로 이전에 보낸 명령의 전체 패킷도 있습니까? 탐색 경로 비트가 설정되어 있으면 흥미로울 것입니다.

manup 에 2020년 02월 23일

다음은이 특정 경우에 어떤 일이 발생해야하는지에 대한 Zigbee 사양의 섹션입니다.

명령 프레임 페이로드의 상태 코드 필드에 링크 실패를 나타내는 0x01 또는 0x02 값이있는 명령의 의도 된 대상인 라우터가 네트워크 상태 명령 프레임을 수신하면 NWK 계층은 라우팅 테이블 항목을 제거합니다. 존재하는 경우 명령 프레임 페이로드의 대상 주소 필드 값에 해당하고 동일한 상태 코드를 사용하여 NLME-NWK-STATUS.indication을 사용하여 실패의 다음 상위 계층에 알립니다.

따라서 위의 수정은 0x02에 대해 여기서 작동해야하며 0x01도 처리되지 않습니다.

0x00 No Route Available  (already handled)
0x01 Tree Link Failure
0x02 Non Tree Link Failure

manup 에 2020년 02월 23일

좋은 @manup! Conbee II를 언급하셨습니다. 이 수정 사항은 Conbee I에서도 작동합니까?

JBS5 에 2020년 02월 23일

예, ConBee I 및 RaspBee에서 사용하는 스택 소스 만 있습니다. 여기서도 같은 문제입니다. 화요일까지 테스트를 위해 새 펌웨어 버전을 요리하겠습니다. 최소한 IKEA 라우팅 문제를 해결한다면 피드백을받는 것이 좋을 것입니다.

IKEA 전구가 완전히 조용 해지고 그룹 캐스트를 듣지 않는 것과 같이 이것으로 해결되지 않는 다른 문제도 있습니다.

manup 에 2020년 02월 23일

이 문제를 실수로 종료했습니다 ... 다시 열었습니다. 우리가 이것에 대해 진전을 이루고 있다는 것이 좋습니다.

나는 @djwlindenaar가이 를 위해 스니핑 하드웨어가 필요하기 때문에 새 펌웨어를 사용할 수있게 된 후에 피드백을 줄 수있는 사람이라고 생각합니다.

JBS5 에 2020년 02월 23일

코디네이터에서 IKEA 조명으로 이전에 보낸 명령의 전체 패킷도 있습니까? 탐색 경로 비트가 설정되어 있으면 흥미로울 것입니다.

질문을 이해했는지 잘 모르겠습니다. 어떤 패킷을 찾고 있습니까? 그리고 어떤 빛 (Garage 또는 Zolder)?

djwlindenaar 에 2020년 02월 23일

예, ConBee I 및 RaspBee에서 사용하는 스택 소스 만 있습니다. 여기서도 같은 문제입니다. 화요일까지 테스트를 위해 새 펌웨어 버전을 요리하겠습니다. 최소한 IKEA 라우팅 문제를 해결한다면 피드백을받는 것이 좋을 것입니다.
IKEA 전구가 완전히 조용 해지고 그룹 캐스트를 듣지 않는 것과 같이 이것으로 해결되지 않는 다른 문제도 있습니다.

확실히 테스트하겠습니다. 때로는 오랜 시간 문제가 없기 때문에 결론에 도달하는 데 시간이 좀 걸릴 수 있지만 ...

나는 완전히 침묵하는 행동을 유발하는 무언가가 있을지도 모른다고 생각했습니다. 지난주에 이런 일이 있었지만 아직 스니퍼 로그를 살펴볼 시간이 없었습니다.

나는 Raspbee btw에 있습니다.

djwlindenaar 에 2020년 02월 23일

예, ConBee I 및 RaspBee에서 사용하는 스택 소스 만 있습니다. 여기서도 같은 문제입니다. 화요일까지 테스트를 위해 새 펌웨어 버전을 요리하겠습니다. 최소한 IKEA 라우팅 문제를 해결한다면 피드백을받는 것이 좋을 것입니다.

이 문제가 많고 테스트 할 수는 있지만 스니핑은하지 않습니다.

IKEA 전구가 완전히 조용 해지고 그룹 캐스트를 듣지 않는 것과 같이 이것으로 해결되지 않는 다른 문제도 있습니다.

소프트웨어 (디콘 즈)가 상태를보고하고 설정하지만 전구 자체가 응답하지 않거나 상태를 변경하지 않는 문제를 언급합니까? 라우팅 문제를 파악하면 문제의 심각도가 같지 않을 수 있습니다.

감사합니다, 감사합니다!

PeterRemnemark 에 2020년 02월 23일

예, ConBee I 및 RaspBee에서 사용하는 스택 소스 만 있습니다. 여기서도 같은 문제입니다. 화요일까지 테스트를 위해 새 펌웨어 버전을 요리하겠습니다. 최소한 IKEA 라우팅 문제를 해결한다면 피드백을받는 것이 좋을 것입니다.
IKEA 전구가 완전히 조용 해지고 그룹 캐스트를 듣지 않는 것과 같이 이것으로 해결되지 않는 다른 문제도 있습니다.

감사합니다! 새로운 fw가 사용 가능 해지는 즉시 업그레이드하고 업데이트를 제공 할 것입니다.

tubalainen 에 2020년 02월 23일

이 문제가 Ikea Fyrtur 블라인드 제어 문제와도 관련이있을 수 있습니까?

olemr 에 2020년 02월 23일

나에게 이상하게 보이는 또 다른 것. @manup ,

이런 종류의 시퀀스를 많이 봅니다. 나는 이것이 응답을 멈추기 전에 houtlamp의 마지막 통신이기 때문에 이것을 조사하기 시작했습니다. DeConz는 2 개의 속성보고 항목을 구성하고 거의 동시에 그룹 멤버십을 요청합니다. deConz 로그에서 이것은 아래와 같이 보입니다.

시퀀스 번호를 선택하는 데 버그가 있는지 아니면 허용되는지 (모르겠습니다)이 동작이 Tradfri 펌웨어에서 버그를 유발하는지 궁금합니다. 215 번 요청과 216 번 요청이 있습니다. tradfri 펌웨어의 요청 처리로 인해 메모리 누수가 발생하거나 두 요청으로 인해 중단되는 일종의 경쟁 조건이있을 수 있습니다. 거의 동시에 같은 번호로? Shoud DeConz에 동일한 시퀀스 번호로 두 개의 요청이 있습니까?

13:09:40:905 Force read attributes for node HK houtlamp
13:09:40:905 binding for cluster 0x0000 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:905 binding for cluster 0x0006 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:905 configure reporting rq seq 215 for 0x000B57FFFEDBFE18, attribute 0x0006/0x0000
13:09:40:906 binding for cluster 0x0008 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:906 configure reporting rq seq 216 for 0x000B57FFFEDBFE18, attribute 0x0008/0x0000
13:09:40:906 Force binding of attribute reporting for node HK houtlamp
13:09:40:908 add task 7435258 type 21 to 0x000B57FFFEDBFE18 cluster 0x0004 req.id 233
13:09:41:013 Erase task req-id: 233, type: 21 zcl seqno: 216 send time 0, profileId: 0x0104, clusterId: 0x0004
13:09:41:053 ZCL configure reporting rsp seq: 215 0x000B57FFFEDBFE18 for cluster 0x0006 attr 0x0000 status 0x00
13:09:41:077 ZCL configure reporting rsp seq: 216 0x000B57FFFEDBFE18 for cluster 0x0008 attr 0x0000 status 0x00
13:09:41:116 verified group capacity: 255 and group count: 2 of LightNode 0x000b57fffedbfe18
13:09:41:116 0x000b57fffedbfe18 found group 0x0001
13:09:41:116 0x000b57fffedbfe18 found group 0xFFF0

OTA (Over the air)는 다음과 같이 보입니다. (스니퍼가 raspbee 바로 옆에 있기 때문에 이상합니다. 스니퍼)

No.          Source       Transmit Dev Receive Dev  Destination  Protocol     Info
2196482      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL: Configure Reporting, Seq: 215
2196484      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196486      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196488      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196490      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196492      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196494      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL: Configure Reporting Response, Seq: 215
2196496      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196497      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196498      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196500      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196502      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196504      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196506      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196508      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL: Configure Reporting Response, Seq: 216
2196510      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196511      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196512      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196513      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196515      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196517      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196519      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL Groups: Get Group Membership Response, Seq: 216
2196521      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196523      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1

djwlindenaar 에 2020년 02월 24일

👍2

실제로 시퀀스 번호는이 짧은 시간에 동일하지 않아야합니다. 코드를 확인하겠습니다. 증분이 누락 된 것 같습니다.

ConBee II의 첫 번째 테스트 펌웨어입니다.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_R21_0x26520700.bin.GCF

이제 이것을 ConBee I / RaspBee 펌웨어로 다시 포팅하면 곧 온라인 상태가됩니다.

manup 에 2020년 02월 24일

👍3

그리고 ConBee I 및 RaspBee에 대한 테스트 버전은 경로 오류 수정입니다.
오류가 발생했을 때 새로운 경로를 발견하기 위해 몇 가지 개선 사항이 있기를 바랍니다.

테스트를 위해 며칠 / 주 동안 만 실행되는 것이 좋을 것이라고 생각하고 조명이 여전히 유니 캐스트에 응답하지 않는지 확인할 수 있습니다. 이 경우 조명이 여전히 그룹 명령에 반응하는지 또는 완전히 침묵하는지 시도하십시오.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

manup 에 2020년 02월 24일

👍4

테스트를 위해 며칠 / 주 동안 만 실행되는 것이 좋을 것이라고 생각하고 조명이 여전히 유니 캐스트에 응답하지 않는지 확인할 수 있습니다. 이 경우 조명이 여전히 그룹 명령에 반응하는지 또는 완전히 침묵하는지 시도하십시오.

그리고 그룹 명령에 반응 할 때 그룹 명령에 계속 반응하는지 확인하기 위해 며칠을 기다리십시오. 제 경우에는 조명이 그룹 명령에만 반응 할 때 조만간 완전히 침묵합니다.

JBS5 에 2020년 02월 24일

그리고 그룹 명령에 반응 할 때 그룹 명령에 계속 반응하는지 확인하기 위해 며칠을 기다리십시오. 제 경우에는 조명이 그룹 명령에만 반응 할 때 조만간 완전히 침묵합니다.

저도 과거에 이것을 보았습니다. 아마도 그들은 더 이상 유니 캐스트가 수신되지 않았기 때문에 이것을 할 것입니다.

manup 에 2020년 02월 24일

@manup 이 문제가 관련이 https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1657

JBS5 에 2020년 02월 24일

아마도 예, 적어도 도달 가능한 상태는 경로가 끊어지면 거짓으로 변할 것입니다. 그러나 이것은 다른 이유로 인해 발생할 수도 있습니다.

manup 에 2020년 02월 24일

👍3

일부 이케아 전구에 대한 최신 펌웨어가 있음을 확인했습니다. 변경 로그는 네트워크 / 연결성 향상 및 장애 관리를 나타냅니다. 전구 20 개를 업데이트하고 있습니다 ... 도움이되면 업데이트를 제공하겠습니다.

realwax 에 2020년 02월 24일

https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotes.html

출시 날짜가 포함되어 있지 않습니다 ...

olemr 에 2020년 02월 25일

https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotes.html
출시 날짜가 포함되어 있지 않습니다 ...

내가 회사를 다운로드 할 수 있었기 때문에 릴리스 된 것 같습니다. 릴리스 노트에 설명 된 2.3.007입니다.

1 월경 이었음에 틀림 없다 https://www.iphone-ticker.de/ikea-home-smart-homekit-und-bridge-update-verfuegbar-152574/

realwax 에 2020년 02월 25일

프로그래머가 아닙니다. conbee 2에 r21을 설치하지 않고 기다려야한다고 생각합니까? 이것은 베타 펌웨어입니까?

MattL0 에 2020년 02월 25일

약간 벗어난 주제 : Trådfri 조광 기용 새 펌웨어도 ZB3로 업그레이드합니다. 교차 참조 # 2485, 우리는 조광기에 대해 동일한 문제가있을 것입니다 ... 다음은 이전 모델 모션 센서가 될 것으로 예상합니다 ...

ebaauw 에 2020년 02월 25일

그리고 ConBee I 및 RaspBee에 대한 테스트 버전은 경로 오류 수정입니다.
오류가 발생했을 때 새로운 경로를 발견하기 위해 몇 가지 개선 사항이 있기를 바랍니다.
테스트를 위해 며칠 / 주 동안 만 실행되는 것이 좋을 것이라고 생각하고 조명이 여전히 유니 캐스트에 응답하지 않는지 확인할 수 있습니다. 이 경우 조명이 여전히 그룹 명령에 반응하는지 또는 완전히 침묵하는지 시도하십시오.
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

감사합니다, @manup , 방금 설치했습니다. 그것이 무엇을 가져올 지 봅시다.

이것이 약간의 개선을 가져올 것으로 예상하지만 DeConz 펌웨어가 기록 된 경로를 무시하는 것에 대해 어떻게 생각하십니까 (mane-to-one 라우팅으로 인해)? 일반적으로 기록 된 경로가 DeConz 펌웨어에서 사용하는 경로보다 훨씬 더 논리적이라는 것을 확인했습니다.
소스 라우팅을 활성화하는 것이 큰 일이라고 생각할 수 있지만 DeConz 펌웨어는 여전히 경로 레코드 패킷의 정보를 사용하여 장치에 대한 첫 번째 홉을 업데이트 할 수 있습니다. 코디네이터에 대한 마지막 홉이 라우팅 테이블에 저장된 것과 일치하는지 확인하고 그렇지 않은 경우 라우팅 테이블의 항목을 무효화 할 수 있습니다. 기록 된 경로의 마지막 홉으로 항목을 교체해도되는지 확실하지 않습니다. 도중에있는 장치가 정보를 무시할 가능성이 높지만 적어도 DeConz 펌웨어에 의해 해당 노드에 대한 새 경로 검색을 시작할 수 있기 때문입니다.

이것에 대해 어떻게 생각하십니까?

djwlindenaar 에 2020년 02월 25일

내 raspbee에 펌웨어를 설치했습니다 (대부분 ikea 73 개 노드가 있음). 결과를보고합니다.

donnib 에 2020년 02월 25일

실제로 시퀀스 번호는이 짧은 시간에 동일하지 않아야합니다. 코드를 확인하겠습니다. 증분이 누락 된 것 같습니다.

@manup , 문제를 정확히 파악할 수 있도록 오늘도 그 문제를 보았습니다. 2 개의 구성보고 작업과 매우 밀접한 관련이있는 것 같습니다. 이 경우 두 번째 시퀀스 : 183은 이전에보고 한 것과 다릅니다.

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
39174           DeConz          DeConz          Gang 1          Gang 1          ZigBee HA       ZCL: Configure Reporting, Seq: 182
39180           DeConz          DeConz          Gang 1          Gang 1          ZigBee HA       ZCL: Configure Reporting, Seq: 183
39227           DeConz          DeConz          On/Off light 36 Badkamer ledstr ZigBee HA       ZCL: Read Attributes, Seq: 183

djwlindenaar 에 2020년 02월 25일

시퀀스 번호 문제는 2.05.74에서 수정되어야합니다. 2.05.74는 현재 구축 중이며 몇 시간 내에 사용할 수 있습니다.

https://github.com/dresden-elektronik/deconz-rest-plugin/commit/33d8a8b349c9f4967e8b94ed2657e038406317c8

manup 에 2020년 02월 25일

그리고 ConBee I 및 RaspBee에 대한 테스트 버전은 경로 오류 수정입니다.
오류가 발생했을 때 새로운 경로를 발견하기 위해 몇 가지 개선 사항이 있기를 바랍니다.
테스트를 위해 며칠 / 주 동안 만 실행되는 것이 좋을 것이라고 생각하고 조명이 여전히 유니 캐스트에 응답하지 않는지 확인할 수 있습니다. 이 경우 조명이 여전히 그룹 명령에 반응하는지 또는 완전히 침묵하는지 시도하십시오.
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF
감사합니다, @manup , 방금 설치했습니다. 그것이 무엇을 가져올 지 봅시다.
이것이 약간의 개선을 가져올 것으로 예상하지만 DeConz 펌웨어가 기록 된 경로를 무시하는 것에 대해 어떻게 생각하십니까 (mane-to-one 라우팅으로 인해)? 일반적으로 기록 된 경로가 DeConz 펌웨어에서 사용하는 경로보다 훨씬 더 논리적이라는 것을 확인했습니다.
소스 라우팅을 활성화하는 것이 큰 일이라고 생각할 수 있지만 DeConz 펌웨어는 여전히 경로 레코드 패킷의 정보를 사용하여 장치에 대한 첫 번째 홉을 업데이트 할 수 있습니다. 코디네이터에 대한 마지막 홉이 라우팅 테이블에 저장된 것과 일치하는지 확인하고 그렇지 않은 경우 라우팅 테이블의 항목을 무효화 할 수 있습니다. 기록 된 경로의 마지막 홉으로 항목을 교체해도되는지 확실하지 않습니다. 도중에있는 장치가 정보를 무시할 가능성이 높지만 적어도 DeConz 펌웨어에 의해 해당 노드에 대한 새 경로 검색을 시작할 수 있기 때문입니다.
이것에 대해 어떻게 생각하십니까?

흠 이상하게도 펌웨어는 이미이 경로 레코드를 사용하여 새 경로를 설정해야합니다. 여기에서 코드를 확인해야합니다.하지만 내 메모리가 제대로 서비스를 제공하면 얼마 전에 활성화되었습니다.

manup 에 2020년 02월 25일

이것에 대해 어떻게 생각하십니까?
흠 이상하게도 펌웨어는 이미이 경로 레코드를 사용하여 새 경로를 설정해야합니다. 여기에서 코드를 확인해야합니다.하지만 내 메모리가 제대로 서비스를 제공하면 얼마 전에 활성화되었습니다.

글쎄, 나는 Zolder와 Garage에서 (많은 게시물에서)이 일을 진행했고 다음과 같은 행동을 얻었습니다.

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
163778          Garage          Kerstverlicht   DeConz          DeConz          ZigBee          Route Record, Dst: 0x0000
163779                                                                          IEEE 802.15.4   Ack

경로 기록은 다음과 같습니다.

Command Frame: Route Record
    Command Identifier: Route Record (0x05)
    Relay Count: 1
    Relay Device 1: 0x731e[Kerstverli]

DeConz에서 Garage 로의 다음 커뮤니케이션은 다음을 수행합니다.

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
163788          DeConz          DeConz          Zolder          Garage          ZigBee          APS: Ack, Dst Endpt: 0, Src Endpt: 0

그래서 그것은 분명히 경로 기록을 차지하지 않습니다.

이때 제가 알아 차린 것은 Zolder 전원을 끄 자마자 DeConz가 즉시 새 경로를 찾을 수 있다는 것입니다. 따라서 라우팅 관련 테이블 중 일부가 DeConz 펌웨어 내에 가득 차있을 수 있습니다. 이것이 사실일까요? 펌웨어의 인접 / 라우팅 테이블은 얼마나 큽니까? 전체 테이블이 새로운 경로 기록의 채택을 차단할 수 있습니까?

djwlindenaar 에 2020년 02월 25일

성공! 이제 비 트리 링크 실패 후 실제로 경로 검색이 시작되는 동작임을 확인할 수 있습니다.

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
173142          DeConz          Buiten - R sch  Tuin rechtsach1 Tuin rechtsach1 ZigBee ZDP      Bind Request, Basic (Cluster ID: 0x0000) Src: SiliconL_ff:fe:16:47:5f, Dst: dresden-_ff:ff:00:c4:9a
173143          Buiten - R sch  Buiten - R sch  DeConz          DeConz          ZigBee          Network Status, 0x35b7: Non-tree Link Failure
173144                                                                          IEEE 802.15.4   Ack
173206          DeConz          DeConz          Broadcast       Broadcast       ZigBee          Route Request, Dst: 0x35b7, Src: 0x0000

djwlindenaar 에 2020년 02월 25일

❤1 🎉1

시퀀스 번호 문제는 2.05.74에서 수정되어야합니다. 2.05.74는 현재 구축 중이며 몇 시간 내에 사용할 수 있습니다.
33d8a8b

"swversion": "2.5.74",

: smile : 감사합니다 @manup 훌륭한 응답 시간 : 1st_place_medal :

djwlindenaar 에 2020년 02월 25일

2.05.74로 업데이트 될 때까지 기다리거나 http://phoscon.de/app 을 사용하여 Phoscon 앱을 표시하십시오. 우리는 방금 게이트웨이 오프라인 페이지가 표시되지 않아야하는 일부 페이지에 표시되는 것을 보았습니다. 지금 재 구축 ~ 2 시간.

manup 에 2020년 02월 25일

실제로 시퀀스 번호는이 짧은 시간에 동일하지 않아야합니다. 코드를 확인하겠습니다. 증분이 누락 된 것 같습니다.
ConBee II의 첫 번째 테스트 펌웨어입니다.
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_R21_0x26520700.bin.GCF
이제 이것을 ConBee I / RaspBee 펌웨어로 다시 포팅하면 곧 온라인 상태가됩니다.

이 FW는 나를 위해 작동하지 않습니다. 모든 장치가 결합 된 것으로 표시되지만 메시가 빌드되지 않았습니다. GUI에 연결이 표시되지 않았고 Phoscon에서 전환이 작동하지 않았습니다 (2.05.74). Conbee II를 264A0700으로 다시 플래시하고 모든 것이 예상대로 다시 작동합니다 ...

cs42 에 2020년 02월 25일

😕1

얼마나 오래 달렸나요?
지금까지 문제없이 여러 설정에서이 펌웨어를 실행하고 있습니다.

manup 에 2020년 02월 25일

얼마나 오래 달렸나요?
지금까지 문제없이 여러 설정에서이 펌웨어를 실행하고 있습니다.

몇 분. 일부 장치 (파란색 점)에서 일부 활동을 보았지만 링크가 구축되지 않았습니다. 그리고 전환이 전혀 작동하지 않았습니다. 더 긴 시간 동안 테스트해야합니까?

cs42 에 2020년 02월 25일

메시가 빌드되는 데 시간이 걸릴 수 있지만 5 ~ 10 분 후에 선이 표시됩니다.

manup 에 2020년 02월 25일

이 FW는 나를 위해 작동하지 않습니다.

Rasperry Pi 4B, deCONZ 2.05.74, ConBee II도 마찬가지입니다. Trådri 리피터, Trådfri 플러그, XBee, Trådfri 디머, 2 개의 Trådfri 모션 센서 (구형 및 신형) 및 Trådri On / Off 스위치가있는 소규모 테스트 네트워크. 게이트웨이는 어떤 장치에서도 트래픽을 보내거나받지 않는 것 같습니다. syslog에서 USB 연결 끊김을 확인합니다. 4A로 돌아가서 모든 것이 다시 늠름한 도리입니다.
log.gz

ebaauw 에 2020년 02월 25일

테스트를 위해 다시 깜박입니다.

GUI에 줄 없음 (15 분 동안 실행)
USB 연결이 안정적인 것 같습니다.
UBISYS C4 및 D1 스위치는 여전히 작동합니다.
Tradfri 버튼은

cs42 에 2020년 02월 25일

@ebaauw 로그에 코디네이터가이 버전에서 두 개의 인접 항목 만 볼 수 있음을 보여줍니다.

아마도 네트워크 크기 일 것입니다. 현재 여기에는 40 개의 장치 만 있습니다. 이 펌웨어 버전에는 원인이 될 수있는 두 가지 다른 변경 사항이 있습니다. 메시지 버퍼 크기 증가 (내가 알 수있는 한 약간 초과하면 다시 축소됨)와 약간 낮은 TX 전력 설정입니다.

이 설정이 제거 된 다른 버전을 준비하여 더 잘 작동하는지 확인하겠습니다.

USB 연장 케이블을 사용합니까, 아니면 ConBee II가 직접 연결되어 있습니까?

manup 에 2020년 02월 25일

나를 위해 그것은 Raspbee에서 잘 작동합니다 ...

djwlindenaar 에 2020년 02월 25일

RaspBee 및 ConBee 1에서는 Route 수정 만 새 버전 (다른 펌웨어)에 포함됩니다.

manup 에 2020년 02월 25일

로그에는 코디네이터가이 버전을 사용하는 두 개의 인접 항목 만 표시됨이 표시됩니다.

예, 두 개의 최종 장치가 GUI에서 이웃으로 표시되었습니다. ConBee II 펌웨어를 다운 그레이드 한 후 다른 라우터에 연결된 것으로 나타났기 때문에 다소 이상합니다.

USB 연장 케이블을 사용합니까, 아니면 ConBee II가 직접 연결되어 있습니까?

내가 얻은 이후로 직접 연결되었습니다. Pi의 USB-2 포트에 XBee가 다른 USB-2 포트에 연결되어 있습니다. USB-3에는 아무것도 없습니다. ConBee II를 라우터로 구성한 경우를 제외하고는 연결이 안정적이었습니다 (# 2463 참조).

RaspBee 및 ConBee 1에서는 Route 수정 만 새 버전 (다른 펌웨어)에 포함됩니다.

아직 시도하지 않았습니다. 나중에 기다려야합니다 ...

ebaauw 에 2020년 02월 25일

구성보고 패킷이 상당히 많습니다. 약간의 검색 후 약 30 분마다 주기적으로 전송되는 것 같습니다. 이러한 구성보고 요청이 주기적으로 반복되는 이유는 무엇입니까?
@ebaauw , IKEA 코디네이터의 행동에 대해 이러한 조사를 많이하신 것을 올바르게 기억합니까? 그것도 그렇게합니까?

de_web_plugin_private.h 에서 발견했습니다.

#define IDLE_ATTR_REPORT_BIND_LIMIT 1800

djwlindenaar 에 2020년 02월 26일

다 대일 경로 기록을 무시하고 DeConz의 라우팅 동작에 관한 또 다른 증거를 찾았습니다. 이로 인해 일부 라우터는 '구식'방식으로 라우팅을 파악해야합니다.
(패킷 117130에 약간의 간섭이 있습니다. : wink :)

에 대한 경로 badkamer ledstrip , DeConz에 따르면,로 시작하는 On/Off light 36 분명히 거기에 얻을하는 방법을 알고하지 않는. 그래서 경로 탐색을 시작하고 마침내 ledstrip 자체에 도달 할 수 있다는 것을 알게됩니다. 반환 경로는 Gang 1

On/Off light 36 는 다 대일 경로 요청이 처리 될 때마다 Badkamer ledstrip 잊어 버리는 것 같습니다 ...

No.               Source            Transmit Dev      Receive Dev       Destination       Protocol          Info
177114            DeConz            DeConz            On/Off light 36   Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 55
177115                                                                                    IEEE 802.15.4     Ack
177116            On/Off light 36   On/Off light 36   Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177117            On/Off light 36   HK plafond ledstrip                 Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177118            On/Off light 36   HK zoutlamp       Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177119            On/Off light 36   Zoldertrap Lamp   Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177120            On/Off light 36   Kerstverlichting  Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177121            On/Off light 36   HK stalamp        Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177122            On/Off light 36   DeConz            Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177123            On/Off light 36   HK houtlamp 2     Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177124            On/Off light 36   Keuken links      Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177125            On/Off light 36   Keuken Rechts     Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177126            On/Off light 36   HK houtlamp       Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177127            On/Off light 36   Keuken mid        Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177128            On/Off light 36   Tuin linksvoor 2  Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177129            On/Off light 36   WC lamp           Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177130            0x6666            0x6666            0x6666            0x6666            IEEE 802.15.4     Data, Dst: 0x6666, Src: 0x6666, Bad FCS
177131            On/Off light 36   Gang 1            Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177132            On/Off light 36   Hal lamp          Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177133            DeConz            On/Off light 36   Badkamer ledstrip Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 55
177134                                                                                    IEEE 802.15.4     Ack
177135            Badkamer ledstrip Badkamer ledstrip Gang 1            DeConz            ZigBee            Command, Dst: DeConz, Src: Badkamer , Bad FCS
177136                                                                                    IEEE 802.15.4     Ack
177137            On/Off light 36   Voordeur          Broadcast         0xfcfd            ZigBee            Command, Dst: 0xfcfd, Src: On/Off li, Bad FCS
177138            Badkamer ledstrip Gang 1            DeConz            DeConz            ZigBee            Route Record, Dst: 0x0000

다음 커뮤니케이션 :

No.               Source            Transmit Dev      Receive Dev       Destination       Protocol          Info
177366            DeConz            DeConz            On/Off light 36   Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 58

djwlindenaar 에 2020년 02월 26일

ConBee II 펌웨어에 대한 또 다른 시도 :

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

이 버전의 TX 전원 설정은 0x264a0700입니다. 버퍼는 한 번에 한 가지만 확인하기 위해 여전히 큽니다 (하지만 맵에 따르면 RAM에 잘 맞아야 함).

manup 에 2020년 02월 26일

최신 펌웨어로 업데이트하려고 할 때마다이 오류가 발생했습니다. 그 이유는 무엇입니까?
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) 드레스덴 일렉트로닉 ingenieurtechnik GmbH
장치 / dev / ttyACM1 (ConBee II) 재부팅
deCONZ 펌웨어 버전 26490700
R21B18 부트 로더
Vers : 2.05
빌드 : 2019 년 3 월 22 일
161378 바이트 깜박임 : | ============================= |
검증: .
플래시 업데이트에 실패했습니다. 잘못된 CRC입니다. 다시 시도하십시오.
@ rich710 @ RichHassPc01 : ~ $

rich710se 에 2020년 02월 26일

다운로드 한 파일의 MD5 합계를 확인 했습니까? (http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF.md5)

timbru31 에 2020년 02월 26일

예, 여러 번 확인하고 다운로드했으며 이전 펌웨어로 되돌리려 고 시도했지만 지금까지 잘되었습니다. 이제이 오류가 발생하여 NUC를 여러 번 재부팅했지만 Flasher가 ConbeeII를 재부팅하려고 할 때 여전히 멈춰 있습니다.
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26490700.bin.GCF
rich710의 [sudo] 비밀번호 :
GCFFlasher V3_13 (c) 드레스덴 일렉트로닉 ingenieurtechnik GmbH
장치 / dev / ttyACM1 (ConBee II) 재부팅

2139 : 오류 : uart 재설정 실패, 재시도 확인

rich710se 에 2020년 02월 26일

사용할 때 ttyACM1을 사용하는 것으로 나타났습니다.

GCFFlasher -l

일련 번호가 표시됩니다.
이를 사용하여 명령에서보다 안정적인 장치 이름을 제공 할 수 있습니다.

GCFFlasher_internal -sn DE1948474 -f deCONZ_ConBeeII_0x26530700.bin.GCF

(장치 일련 번호로 교체)

manup 에 2020년 02월 26일

죄송합니다. 작동하지 않았습니다. Windows 컴퓨터로 옮겨서
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -l
GCFFlasher V3_13 (c) 드레스덴 일렉트로닉 ingenieurtechnik GmbH
경로 | 공급 업체 | 제품 | 직렬 | 유형
----------------- + -------- + --------- + ------------ + -------
/ dev / ttyACM1 | 0x1CF1 | 0x0030 | DE1964163 | ConBee II
/ dev / ttyUSB0 | 0x0403 | 0x6001 | A1YV35M2 | 일반 FTDI
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) 드레스덴 일렉트로닉 ingenieurtechnik GmbH
기기 재부팅 (ConBee II)

2139 : 오류 : uart 재설정 실패, 재시도 확인
@ rich710 @ RichHassPc01 : ~ $

rich710se 에 2020년 02월 26일

그 중 하나 또는 대안으로 다음을 시도 할 수 있습니다.

ConBee II 분리
GCFFlasher_internal -t 60 -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
ConBee II를 다시 플러그인

manup 에 2020년 02월 26일

-t 매개 변수를 사용하면 GCFFlasher가 1 분 동안 업데이트 처리를 시도 할 수 있습니다.

manup 에 2020년 02월 26일

Windows에서 펌웨어를 업데이트하고 우분투를 사용하여 NUC에 다시 연결하면 다시 연결되었습니다. 하지만 이제 한 시간이 지나면 내 노드 4 개에 연결되었습니다 .. : S
Annotation 2020-02-26 172624

rich710se 에 2020년 02월 26일

ConBee II 펌웨어에 대한 또 다른 시도 : http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

더 이상 USB 연결이 끊어지지는 않지만 deCONZ는 ConBee II를 자주 다시 감지하는 것 같습니다. 여전히 교통 체증이 없습니다.
log.gz

편집 유머러스하게 XBee를 분리하고 10cm USB 연장 케이블을 사용하여 ConBee II를 연결했습니다. 변경 사항은 없습니다.

ebaauw 에 2020년 02월 26일

ConBee II 펌웨어에 대한 또 다른 시도 :
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF
이 버전의 TX 전원 설정은 0x264a0700입니다. 버퍼는 한 번에 한 가지만 확인하기 위해 여전히 큽니다 (하지만 맵에 따르면 RAM에 잘 맞아야 함).

새 버전을 테스트했지만 10 분 후에도 여전히 링크가 표시되지 않습니다. 안정적인 FW를 사용하면 네트워크의 모든 양호한 (라우터) 링크가 약 2 분 후에 표시됩니다. IKEA 푸시 버튼은 즉시 작동하지만 테스트 펌웨어에서는 전혀 작동하지 않습니다.

cs42 에 2020년 02월 26일

으스 스럽네요. 테스트 해주셔서 감사합니다. 다음으로 앞서 언급 한대로 버퍼 크기를 줄 이겠습니다.
그래도 왜 내 설정에서 작동하는지 궁금합니다. 위의 스크린 샷에서 라우터보다 최종 장치가 더 많다는 것만 알 수 있습니다.

manup 에 2020년 02월 26일

@manup 은 펌웨어를 플래시 한 후에도 동일한 문제가 있었지만 deconz에서 장치 재부팅 / deconz 다시 시작을 누르면 링크가 다시 돌아옵니다.

jurriaan 에 2020년 02월 26일

그리고 ConBee I 및 RaspBee에 대한 테스트 버전은 경로 오류 수정입니다.

내 Pi 3B + 테스트 시스템에서 잘 실행되는 것 같습니다. 내 프로덕션 네트워크를 업그레이드하기 전에 이번 주말까지 기다릴 것입니다.

ebaauw 에 2020년 02월 26일

@ebaauw , IKEA 코디네이터의 행동에 대해 이러한 조사를 많이하신 것을 올바르게 기억합니까? 그것도 그렇게합니까?

대부분의 Trådfri 장치에 대한 지원을 추가했지만 Trådfri 허브와주고받는 ZigBee 트래픽을 스니핑 할 수 없었습니다. 터치 링크 페어링 만 사용하며 네트워크 키를 복구하기 위해 아직 캡처를 시도하지 않았습니다. 즉, 가능하다고 가정합니다.

ebaauw 에 2020년 02월 26일

새 펌웨어가 출시 된 이후로 ~ 40 노드 설정에서 conbee 1 스틱에서 새 FW를 실행 해 왔으며 문제없이

문제를 해결하고 코드를 업데이트 한 모든 관련자들에게 감사드립니다. 너무 감사합니다! <3

tubalainen 에 2020년 02월 27일

나를 위해 일하지 않습니다. 그리드에 연결이 거의 없습니다. 다시 시작한 후 약 20 분을 기다렸습니다.

Raspberry Pi 3 모델 B Rev 1.2
콘비 II
버전 2.05.74
버전 26530700

77 개의 노드

3 연결
1 TRÅDFRI 켜기 / 끄기 스위치
1 Xiaomi 멀티 센서
1 필립스 조광기 스위치
필립스 조광기 스위치에서 이벤트를 트리거 할 수 있습니다.
연결이있는 이들은 Conbee 스틱에 아주 가깝습니다. 막대기는 차고에 있습니다. 차고에 연결되지 않은 전구가 있습니다.

에 연결되지 않음
많은 이케아 전구, E27 및 GU10
많은 Xiaomi 멀티 센서
Ikea TRÅDFRI 많은 리모콘
그리고 다른 노드.

로그
feb 27 09:29:06 raspberrypi systemd [1] : deCONZ 시작 : ZigBee 게이트웨이-GUI / REST API.
2 월 27 일 09:29:06 raspberrypi deCONZ [7204] : libEGL 경고 : DRI2 : 인증 실패
feb 27 09:29:06 raspberrypi deCONZ [7204] : libpng 경고 : iCCP : 알려진 잘못된 sRGB 프로필

264A0700으로 다운 그레이드하면 메시 빌드가 직접 시작됩니다.

danielkihlgren 에 2020년 02월 27일

@ebaauw , IKEA 코디네이터의 행동에 대해 이러한 조사를 많이하신 것을 올바르게 기억합니까? 그것도 그렇게합니까?
대부분의 Trådfri 장치에 대한 지원을 추가했지만 Trådfri 허브와주고받는 ZigBee 트래픽을 스니핑 할 수 없었습니다. 터치 링크 페어링 만 사용하며 네트워크 키를 복구하기 위해 아직 캡처를 시도하지 않았습니다. 즉, 가능하다고 가정합니다.

네, 죄송합니다. 자식 비난을 확인해야합니다. IKEA 게이트웨이의 동작을 언급하는 코드는 실제로 @manup에 의해 48d2c39a267b5c6d025577eed7530be27932aa2c에 도입되었습니다.

@manup , IKEA 게이트웨이가 자주보고하는 속성을 재구성한다는 사실을 실제로 확인 했습니까? 재구성이 필요한 이유는 무엇입니까? 조명을 정기적으로 상기시켜야합니까?

djwlindenaar 에 2020년 02월 27일

Conbee I를 베타 FW 및 deCONZ .74로 업그레이드

메시는 즉시 빌드되고 정말 멋져 보입니다!

@djwlindenaar 에게 감사드립니다. 나는 당신이 어디에서 왔고 그런 심각한 버그를 발견한다는 것에 매우 감명을 받았습니다. 그리고 물론 @manup 에게 감사드립니다 ...

mvjt 에 2020년 02월 27일

Conbee I와 .74도 있습니다. Ikea FW를 2.3.007 (다른 일부 2.x)로 업그레이드했습니다.
대폭 개선! 아직 중퇴자가 없습니다!

이 스레드와 그 이상에서 기여하고, 개발하고, 디버깅하고, 테스트하는 모든 사람에게 큰 감사를 표합니다.

그 과정에서 내가 알아 낸 것 :
일반 그룹 ON-OFF는 빠르게 작동하지만 장면을 불러 와서 (페이드 인 시간 후) 다시 끄면 (10 초 미만) GUI에서만 조명이 꺼집니다 (이전 또는 새 GUI에 관계없이) 그런 다음 일부는 다시 켜집니다. (gui에서) 모든 물리적 전구가 여전히 켜져있는 동안 그룹에서. 두 번째 또는 세 번째 OFF를 누르면 때때로 어두워집니다.

펌웨어 업그레이드 후 장면을 복원 / 재 구축하는 것은 드문 일이 아닙니다.
하지만 새로운 장면을 만들거나 이전 장면을 수정하려고해도 동작은 동일하게 유지됩니다. 정상 온-오프는 영향을받지 않습니다.

조금 더 기다리면 평소대로 작동한다는 것을 알았습니다. 15-20 초라고합시다. 그런 다음 평소처럼 조명이 꺼집니다. deconz get은 페이드 인 할 때까지 조명을 끌 때처럼 혼란 스럽습니다.

모든 조명 상태가 다시보고되고 장면 리콜이 deconz에서 수행되거나 성공적으로보고되어 해당 그룹의 다른 작업이 원하는대로 작동 할 때까지 지연이 증가한 것 같습니다. 지금은 조금 더 오래 걸리는 것 같습니다. 이 기간 내에-당신은 (pass;))-조명을 끄지 마십시오. 이것은 중요하지 않습니다.

realwax 에 2020년 02월 27일

나는 조금 더 테스트했습니다. 우리는 행동의 변화가 있습니다. 이전에는 브리가 주어진 속도로 변경되거나 장면 전환 시간이 더 길었을 때 새로운 명령으로 중단 할 수있었습니다. 이전 작업이 여전히 수행되었지만 다음 명령이 대기열에 추가되었습니다. 이제 잃어 버렸습니다. Egmy 바닥 조명은 모션 센서로 작동됩니다. 그들이 가기 전에 나는 그들을 어둡게하고 그들을 끄기 전에 10 초 동안 기다립니다. 모션을 트리거하고 페이드하는 동안 장면을 리콜하면 명령이 손실됩니다. 그 전에는 대기열에 추가되었고 나중에 실행되었습니다. 이것은 때문입니다. 74 또는 새 펌웨어? 감사

realwax 에 2020년 02월 28일

내 Conbee II는 베타 버전에서 메시를 구축하지 않았습니다. "일반"설정과 다를 수 있다고 생각하는 유일한 것은 채널을 25로 설정하는 것입니다. 264a0700으로 돌아가서 수정했습니다.

helto4real 에 2020년 02월 28일

@realwax , Trådfri 펌웨어 버그가 발생한 것 같습니다. # 2068을 참조하십시오. GUI에서 전환 시간이 더 긴 명령을 실행 한 다음 두 번째 명령을 실행하여 쉽게 확인할 수 있습니다.

그 전에는 대기열에 추가되었고 나중에 실행되었습니다.

라이트 펌웨어를 업데이트 했습니까? 동일한 조명을 사용하고 있습니까? REST API 플러그인은 일단 라이트에 명령을 보낸 후에는 전환 시간을 추적하지 않습니다.

ebaauw 에 2020년 02월 28일

@ebaauw 올바른 방향으로 나를

realwax 에 2020년 02월 28일

이것은 큰 사용성 문제이기 때문에 IKEA가 자체 다리에서 어떻게 트릭을 수행하는지 궁금합니다.

Trådfri 허브는 deCONZ 게이트웨이 또는 Hue 브리지보다 훨씬 덜 활동적입니다. Trådfri 컨트롤러 (스위치, 조광기 및 모션 센서)는 조명을 직접 제어합니다. Trådfri 표시등은 상태 변경과 함께 푸시 알림을 허브로 보냅니다. 허브는 앱에만 필요 / 사용됩니다. 일부 알람을 실행할 수 있지만 버튼 이벤트 또는 멋진 것을 처리하는 규칙은 없습니다.

Trådfri 앱이 더 긴 전환 시간 지정을 지원하는지 확실하지 않지만 내가 본 컨트롤러는 지원하지 않습니다. 조명의 기본 전환 시간보다 빠르게 컨트롤러에서 명령을 보낼 수 없을 것입니다. 가끔 그렇게한다면 버튼을 완전히 누르지 않았다고 생각할 것입니다.

ebaauw 에 2020년 02월 28일

👍1

@ebaauw 알겠습니다 . 여전히 나를 당혹스럽게하는 것은 E14 그룹을 켜고 끌 수 있다는 것입니다 (일종의 가벼운 디스코 제공;)) 작동합니다! 하지만 deconz에서 씬 리콜 버튼을 누르 자마자 할 수없고 동작이 이상해집니다. 이것은 내가 어떻게 든 IKEA의 잘못인지 의심하는 곳입니다. 왜 정말 빨리 켜고 끌 수 있지만 장면이 떠오르면 적어도 5-10 초 동안 멈춰 있습니다.

정확하게 측정 된 시간 (20 회 시도) :
8 E14 그룹
그룹 ON-> 그룹 OFF-전환 시간 1 초
장면 리콜-> 스위치 켜기-> 끄기 10-12 초까지 응답하지 않음!

리콜을 사용하면 더 많은 트래픽이 생성되고 모든 전구가 더 많은 메시지를 수신하지만 10 초 차이가 있다는 것을 알고 있습니다. 전체 그룹에 대해 bri와 ct를 변경하더라도 잠시 후에 끌 수 있지만 다시 리콜은 동결과 같습니다. 나는 이것이 deconz 문제인 것 같지 않습니까?

비디오 녹화를 할 수 있습니다. ;) 어쩌면 나는 여기에 지식이 부족한 것 같습니다. 그럼 이해가 부족하다는 것을 실례합니다.하지만 나는 그것이 투쟁이기 때문에 어떻게 든 좌절합니다 ...

realwax 에 2020년 02월 28일

아직 장면에 대해 약간 혼란스러워하는 것 같습니다. 그룹과 마찬가지로 이들은 ZigBee에서 객체로 존재하지 않으며 장치 (조명)가 상태를 저장하는 숫자 일뿐입니다. 장면 리콜에서 번호가 전송되고 각 장치는 비 휘발성 메모리에서 상태를 복원합니다.

모호한 부분은 장면을 저장할 때 모든 장치가 상태를 올바르게 저장하는 것은 아니라는 것입니다. 색온도는이 점에서 악명이 높습니다. 조명이 전환되는 동안 장면을 저장하는 재미있는 것도 보았습니다. 이 경우 /scenes 리소스가 조명에 저장된 상태와 동기화되지 않아 API가 실제 조명 상태 대신 리소스 상태를 반영하게되며, 이는 다음에 조명이 켜질 때만 업데이트됩니다. polled. 일반적으로 장면을 리콜 할 때 전환 시간이 지정되지만 저장된 상태에도있는 것처럼 보입니다.

프로덕션 네트워크 설정 ( ph )을 스크립트로 작성 했으므로 쉽게 다시 만들 수 있습니다. 예측 가능한 방식으로 장면 생성을 스크립팅하는 데 매우 어려움을 겪었습니다. 나는 조명 상태를 설정하고, 몇 초 동안 잠자고, 상태가 안정 될 때까지 기다렸다가 장면을 저장하고, 상태가 저장 될 때까지 다시 몇 초 동안 잠을 잤습니다.

장면을 다시 만들려고 할 수 있지만 보장 할 수는 없습니다.

ebaauw 에 2020년 02월 28일

👍1

나는 첫날부터 동기화되지 않은 주제를 재현 할 수있었습니다. 나는 deconz와 때때로 장면 재구성의 필요성에 익숙했습니다. 이제 정말 더 나빠졌습니다. 현재는 deconz에서 iobroker로 소싱하여 모든 장면을 다시 빌드해야합니다. 그러나 이것은 많은 작업입니다. 이 문제가 해결되기를 바랍니다. 이슈를 생성 할 수 있습니까? 장면을 사용할 때 더 이상 조명이 신뢰할 수 없습니다 ...-나도 재현하려고합니다. 나는 이미 존재하는 것 외에 어제 "테스트"씬을했지만 다른 행동은 보이지 않았다.

realwax 에 2020년 02월 28일

관련이 있는지 확실하지 않지만 Conbee I를 베타 펌웨어로 업그레이드하고 deCONZ를 .74로 업그레이드 한 후 하루가 걸렸고 이제 deCONZ가 Conbee와의 연결이 끊어졌습니다. 몇 년 전에는 경험하지 못했습니다 ...하지만 언급하고 싶었습니다 ... 로그에 계속해서 연결을 재 시도한다고 명시되어 있습니다 ... deCONZ를 다시 시작하면 해결되었습니다 ... (도커 컨테이너 사용)

mvjt 에 2020년 02월 28일

그룹, 모든 장면을 다시 만들려고했습니다. 만드는 과정에서 너무 많은 문제가 발생합니다. Phoscon 및 "ALL"전구 선택을 사용할 때 장면 값이 제대로 저장되지 않습니다. 구성된 조명조차도 원하는 것을 표시하지만 리콜은 표시하지 않습니다. 동일한 설정을 사용하더라도 각 조명을 자체적으로 제어해야합니다. 특히 이전 GUI를 사용하여 잘못 저장된 색상의 색상 온도 오류를 수정해야합니다. 장면이 "작동"할 때까지 몇 번 반복해야합니다. 장면 구성 프로세스에서 조명을 켜고 끄면 제대로 저장 될 수 있습니다. 여기에는 기술적 인 세부 사항이 많지 않지만 스레드의 모든 분들이 장면, 생성, 저장, 리콜을 테스트하고 리콜 후 스위치를 끄도록 용기를 드리고 싶습니다. IKEA 전구가 엉망이 된 것 같고 더 나빠질 것 같습니다 ... IKEA와 함께 할 수도 있지만 다른 모든 것과 직접 그룹 제어가 deconz의 매력처럼 작동하는지 의심합니다.

이제 펌웨어를 1.x로 롤백 / 다운 그레이드하고 더 잘 작동하는지 확인합니다. 다시보고하겠습니다.

realwax 에 2020년 02월 28일

확인. 드로잉 보드로 돌아갑니다. 어제 2 개의 IKEA 조명이 휴직을했지만 전원을 껐다 켜면 다시 돌아 왔습니다. 수정 된 버그가 버그가 아니라는 말은 아닙니다. 그들은 있었다. 문제의 원인이 아닙니다.

나는 속성보고에 대해 더 깊이 조사하고 있었다. 30 분 (1800 초)마다보고하는 속성의 반복적 인 구성이 라이트 펌웨어의 중단을 유발하는지 궁금합니다.
rq.maxinterval == 0 명시 적으로 처리하지 않는 것 같은 코드를 발견했습니다. rq.maxinterval == 0 는 라이트가 변경 사항 만보고한다는 것을 의미하므로이 경우를 올바르게 처리하는 방법은 약간 어렵습니다. 따라서 해당 경우에 '좋은'시간 제한이 없습니다 ... 아마도 현재 구현은 괜찮습니다. 더 나은 아이디어가 있는지 궁금합니다.

bool DeRestPluginPrivate::sendConfigureReportingRequest(BindingTask &bt, const std::vector<ConfigureReportingRequest> &requests)
{
<hidden>
        if (val.clusterId == bt.binding.clusterId)
        {
            // value exists
            if (val.timestampLastReport.isValid() &&
                val.timestampLastReport.secsTo(now) < qMin((rq.maxInterval * 3), 1800))
            {
                DBG_Printf(DBG_INFO, "skip configure report for cluster: 0x%04X attr: 0x%04X of node 0x%016llX (seems to be active)\n",
                           bt.binding.clusterId, rq.attributeId, bt.restNode->address().ext());
            }
 ```

I Did some experiments, including asking the IKEA lights to report `ONOFF` and `LEVEL` periodically instead of only when a change is made. The lights happily report their status periodically, so that may be an acceptable way to avoid the above issue. To be verified properly of course.

Anyway, while doing these experiments, I stumbled upon an actual bug. I noticed the magical Default Response Command being returned whenever the IKEA lights now report their attributes. So I looked into what that thing is. Apparently that is supposed to conclude an ZCL/APS transaction when requested. There's a bit in the ZCL packet which dictates whether or not it should be sent `Disable Default Response`.

For attribute reports these are handled nicely by deCONZ

번호 시간 소스 전송 장치 수신 장치 대상 비활성화 기본 응답 정보
208134 10h 43m 23.151s Gang 1 Gang 1 DeConz DeConz False ZCL : 보고서 속성, 시퀀스 : 15
208136 10h 43m 23.158s DeConz DeConz Gang 1 Gang 1 APS : Ack, Dst Endpt : 1, Src Endpt : 1
208138 10h 43m 23.212s DeConz DeConz Gang 1 Gang 1 True ZCL : 기본 응답, 시퀀스 : 15

However for Configure Reporting Response command, deCONZ fails to send the Default Response. I'm not sure how the IKEA lights handle this situation, but it may be a cause for a memory leak. Remembering that the Default Response is a kind of closure of the transaction, it may be that the firmware only releases a certain amount of memory after it is received.

번호 시간 소스 전송 장치 수신 장치 대상 비활성화 기본 응답 정보
207941 10h 43m 8.422 DeConz DeConz Gang 1 Gang 1 True ZCL :보고 구성, 시퀀스 : 41
207949 10h 43m 8.481 Gang 1 Gang 1 DeConz DeConz False ZCL :보고 응답 구성, 시퀀스 : 41
207951 10h 43m 8.485 Gang 1 Gang 1 DeConz DeConz APS : Ack, Dst Endpt : 1, Src Endpt : 1
207952 10h 43m 8.487 DeConz DeConz Gang 1 Gang 1 APS : Ack, Dst Endpt : 1, Src Endpt : 1
207954 10h 43m 8.493 Gang 1 Gang 1 DeConz DeConz APS : Ack, Dst Endpt : 1, Src Endpt : 1

I'm going to test this hypothesis with this patch in place:
```diff
diff --git a/bindings.cpp b/bindings.cpp
index 9607b09..0c2b5fc 100644
--- a/bindings.cpp
+++ b/bindings.cpp
@@ -443,6 +443,12 @@ void DeRestPluginPrivate::handleZclConfigureReportingResponseIndication(const de
         allNodes.push_back(&l);
     }

+    // send DefaultResponse if not disabled
+    if (!(zclFrame.frameControl() & deCONZ::ZclFCDisableDefaultResponse))
+    {
+        sendZclDefaultResponse(ind, zclFrame, deCONZ::ZclSuccessStatus);
+    }
+
     for (RestNodeBase * restNode : allNodes)
     {
         if (restNode->address().ext() != ind.srcAddress().ext())

djwlindenaar 에 2020년 02월 29일

❤1

rq.maxinterval == 0을 명시 적으로 처리하지 않는 것 같은이 코드를 발견했습니다. 이제 rq.maxinterval == 0은 라이트가 변경 사항 만보고한다는 의미이므로이 경우에 '좋은'시간 제한이 없음을 의미하므로이 경우를 올바르게 처리하는 방법은 약간 어렵습니다 ... 아마도 현재 구현은 괜찮습니다. 더 나은 아이디어가 있는지 궁금합니다.

예, REST API 플러그인은 속성보고가 작동하는지 확인합니다. 그렇지 않은 경우 재구성을 시도하고 장치 폴링으로 돌아갑니다.

IKEA 조명이 변경된 경우에만 ONOFF 및 LEVEL을 주기적으로보고하도록 요청하는 등 몇 가지 실험을했습니다. 표시등은 주기적으로 상태를보고하므로 위의 문제를 피할 수있는 적절한 방법 일 수 있습니다. 물론 제대로 확인해야합니다.

나는 우리가 꽤 오랫동안 그 설정으로 달렸다고 생각한다. Trådfri 펌웨어 중 일부가 중단되기 때문에 (빛의 전원주기가 필요함) 인접 테이블의 폴링 빈도가 줄어들고 더 이상 상태를 폴링하지 않고 변경되었습니다. 보고 설정이 실제로 펌웨어 충돌에 기여했는지 의심합니다.

ZCL 패킷에는 Disable Default Response 보내야하는지 여부를 나타내는 비트가 있습니다.

Disable Default Response 비트가 설정되어있을 때 기본 응답을 보내는 것이 그다지 해로울 것이라고 생각하지 않습니다. 비트가 설정되지 않았을 때 기본 응답을 보내지 않으면 응답을 기다리는 장치가 코디네이터에 더 이상 연결할 수 없다고 결론을 내릴 수 있고 결국 네트워크를 벗어날 수 있으므로 해를 끼칩니다.

ebaauw 에 2020년 02월 29일

ZCL 패킷에는 Disable Default Response 보내야하는지 여부를 나타내는 비트가 있습니다.
Disable Default Response 비트가 설정되어있을 때 기본 응답을 보내는 것이 그다지 해로울 것이라고 생각하지 않습니다. 비트가 설정되지 않았을 때 기본 응답을 보내지 않으면 응답을 기다리는 장치가 코디네이터에 더 이상 연결할 수 없다고 결론을 내릴 수 있고 결국 네트워크를 벗어날 수 있으므로 해를 끼칩니다.

실제로 @ebaauw . 그게 바로 요점입니다. deCONZ는 보낼 실패 Default Response A와 응답에 Configure Reporting Response . IKEA 조명이 Configure Reporting Response Default Response 를 요청하는 경우가 있습니다.
그래서, 당신이 말했듯이, 그것이 IKEA 조명이 awol이되도록 매 30 분마다 Configure Reporting Request 와 결합 된 이유 일 수 있습니다.

djwlindenaar 에 2020년 02월 29일

알림 :
Ikea 전구 (E27 및 GU10 v1)는 때때로 연결할 수 없게되며 HUE 브리지에 연결할 때도 전원을 껐다 켜야하므로 Conbee I / II에만 해당되는 문제가 아닙니다.
내 HUE 브리지의 E27 16 개와 GU10 12 개 중 대략 1-2 주에 전구 하나가 '멈춘다'고 말할 것입니다. 때로는 더 길고 때로는 더 빠릅니다. 이 문제는 지난 1 년 반 동안 최신 HUE 펌웨어 릴리스로 개선되었습니다.

olemr 에 2020년 02월 29일

@all 어떤 Tradfri 펌웨어 버전을 사용하고 있습니까?

1.x 또는 2.x에 있습니까? 2.x에서는 zigbee 3.0을 도입했습니다. 2.x로 업그레이드했고 문제가 시작되었습니다. E14 전구. 네트워크 속도와 연결성이 향상되었습니다. 그러나 두 가지 나를 더 이상 작동하지되었다 "소프트"를 한숨 다시 20 개 전구를 출시했다. 페이드 인없이 전구가 켜졌습니다. 장면이 예전처럼 작동하지 않았습니다. 조명을 끄거나 다음 szene을 불러 오기 전에 대기 시간이 필요했습니다.

버전에 대한 귀하의 공유 경험에 감사 드리며 2.x로 '무결점'을 설명하지 않은 것 같습니다.

권장 사항이 있습니까? FW v.? 연결 끊김 문제와 Ikea의 fw 자체에 대한 연결 문제 외에도 deconz는 1.x를 더 잘 처리 할 수 있습니다.

감사!

realwax 에 2020년 03월 01일

나는 사용하고있다 :

0x26340500 펌웨어가있는 Conbee 1
Deconz 버전 2.05.73 (Debian에서 marthoc Docker 컨테이너 사용)
~ 60 개 노드, 대부분 IKEA Trådfri
Conbee 1 (코디네이터)은 200 평방 미터의 집 중앙에 설치되어 있지 않습니다. 이 시스템은 로밍과 메싱에 크게 의존합니다.
Conbee 1 스틱은 0.5m USB 연장 케이블에 설치되며 RF 신호를위한 더 많은 여유 공간을 확보하기 위해 컴퓨터가있는 선반 측면에 장착됩니다.

Conbee 1 스틱 펌웨어 deconz의 업그레이드 (출시 당일) 이후 로 매력적 으로

tubalainen 에 2020년 03월 01일

어제 프로덕션 네트워크 (RPi 3B +, stretch, RaspBee)를 2.05.74 및 0x26340500으로 업그레이드했습니다. 아래 문제를 제외하고는 안정적으로 보입니다.

관련이 있는지 확실하지 않지만 오늘 아침 lumi.curtain 커튼 컨트롤러로가는 경로가 손실되었습니다. 컨트롤러의 보고서는 여전히 게이트웨이에 도달합니다. 컨트롤러의 전원을 껐다 켜도 경로가 복원되지 않습니다. 코디네이터가 다시 연결하기 전에 네트워크를 열고 컨트롤러의 전원을 껐다가 켜야했습니다.

또한 내 Eurotronic Spirit 라디에이터 밸브 중 하나는 deCONZ를 시작한 후 여전히 보고서를 보내는 동안 deCONZ가 연결할 수 없었습니다. TRV의 전원을 껐다 켜면 평소와 같이 다시 가져 왔습니다.

이번에는 심층 조사를 할 기회가 없었지만 두 기기 모두 처음부터 문제가 발생하여 가끔씩 이러한 증상이 나타납니다. IKEA Fyrtur 블라인드도 마찬가지입니다. 계속해서 상황을 모니터링하고 더 많은 문제가 발생하면 다시보고하겠습니다.

ebaauw 에 2020년 03월 01일

뿡 빵뀨
tradfri 전구에서 어떤 펌웨어를 사용하고 있습니까? 이것은 내가 테스트 한 한 연결 끊김 문제와 관련 하여이 스레드에서도 차이를 만듭니다. 내 결과는 여기에서 취한 단계가 Conbee 1에서 1.x로 작동하는 tradfri 전구의 작동을 개선했다는 것입니다. 그러나 tradfri fw 2.3.x를 사용하는 20 e14 네트워크는 엉망입니다. 위에서보고 된대로 타이밍, 장면이 멈춤, 디콘 즈가 시작되고 표시등이 깜박이기 시작합니다 (분실?) ... 나는 이것이 좋은 경험을 위해 사용할 ikea fw의 명확한 권장 사항을 제시하기 위해 논의되고 언급되어야 할 점이라고 생각합니다. 이미 git 기사가있을 수 있습니다. 하지만 내 경험상 업그레이드하지 마십시오 😅

그래서 내 관점과 테스트 및 깜박임 시간에서. ikea fws 1.x를 개선 해주셔서 감사합니다! 2.x가 작동 할 때 현재 문제를 완화 할 수 있습니까? 그렇지 않으면 현재 ikea에서 zigbee 3으로 업그레이드 할 수 없습니다. 행동이 바뀌고 deconz에서 작동하는 것이 조정되어야하는 것 같습니다. 이것은 아마도 @ebaauw 가 판단하거나 처리하기위한

건배
좋은 일요일 되세요 😊

realwax 에 2020년 03월 01일

뿡뿡
모든 엔터티를 최신 FW로 FW 업그레이드하려고했습니다. 다음은 모든 (현재 활성) 노드 목록입니다.

동시에 모든 "움직이는 부품"의 혼란에 동의하여 문제의 근본 원인을 파악했습니다.

tubalainen 에 2020년 03월 01일

뿡 빵뀨

목록 감사합니다.

특히 라우터 (전구)를 살펴보면 E14에서 2.3.007을 작동하는 것으로 보입니다. 내 문제 목록을 재현 할 수 있습니까? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
2.3.x 로의 자동 fw 업그레이드를 알지 못했기 때문에 네트워크는 1.x와 2.x가 섞여서 좋지 않았습니다. 나는 손으로 2.3.x로 업그레이드했고 더 나 빠졌다. (네트워크 속도가 빠르지 만 사용성이 매우 높고 전구가 깜박이는 경우) e14에서 전구가 깜박이거나 scences에서 "지체"가 1.2로 다운 그레이드되는 경우 권장 할 수 있습니다. "공식"/ 이에 대한 전문적인 성명서는 여기에서 우리의 프로 개발자를 구성합니다. 나는 1.2와 비슷하게 deconz를 처리하고 개선 된 시간이 있었다고 확신합니다. 2.3.x에서도이 작업을 수행해야하거나 Ikea가 직접 엉망으로 만든 것 같습니다. 코드에 깊지 않기 때문에 말하기 어렵습니다.

realwax 에 2020년 03월 01일

👍1

뿡뿡
deconz의 otau 기능과 펌웨어 업데이트 스크립트를 사용하여 fw 파일을 다운로드하고 있습니다.
E14가 업데이트되지 않은 이유를 모르겠습니다 ... huhum.

전구를 "수동으로"업데이트 / 다운 그레이드 한 방법은 무엇입니까?

음. 모두 잘 작동하며 대부분의 라우팅은 fw 2.3.x와 Jormen 및 FLOALT 패널 주도 드라이버가있는 E27에 의해 수행됩니다.

tubalainen 에 2020년 03월 01일

뿡 빵뀨
당신이 그 문제를 경험하지 않는다는 것이 흥미 롭습니다. 메쉬 크기 때문일 수 있습니다. 2.3.007의 20 e14에서 23 개의 전구가 있습니다. 새 펌웨어로 사용성을 엉망으로 만든 자동 otau를 비활성화했습니다. Gui를 통해 업데이트 버튼으로 다운 그레이드 할 수 있습니다. 먼저 적절한 펌웨어를 선택하고 업데이트를 누른 다음 다시 누릅니다. 양식 상태가 일시 중지됨-> 대기-> 유휴-> 펌웨어 업데이트 시작 (백분율)으로 이동합니다. 때로는 중단됩니다. 때때로 재부팅이 필요합니다. 때때로 파워 사이클로 충분합니다. 때때로 전구를 코디네이터에게 더 가까이 가져와야합니다.

realwax 에 2020년 03월 01일

행동이 바뀌고 deconz에서 작동하는 것이 조정되어야하는 것 같습니다. 이것은 아마도 @ebaauw 가 판단하거나 처리하기위한

여기서 무슨 뜻인지 잘 모르겠습니다. 컨트롤러 (Trådfri 원격 및 Trådfri 무선 조광기)에 대한 ZLL 및 ZB3 펌웨어 간의 몇 가지 차이점을 처리했습니다 (# 2485 참조). 이는 ZigBee 스택의 APS 수준이며 REST API 플러그인에 의해 처리됩니다.

이 항목의 라우팅 문제는 장치 펌웨어에서 처리하는 NWK 수준입니다. 여기있는 모든 사람들과 마찬가지로 펌웨어 소스에 액세스 할 수 없습니다. 그래도 NWK 및 MAC 계층에 대한 세부 정보를 모르기 때문에 할 수있는 일이 없습니다.

ebaauw 에 2020년 03월 01일

뿡뿡
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
정확히 말하면. 여기에 20 E14 2.3.007 메시에 대한 내 결과를 포함했습니다. 일부 기능은 사라지고 씬 리콜은 해당 그룹에서 10 ~ 15 초 동안 모든 것을 엉망으로 만듭니다. 이것이 펌웨어 관련인지 아니면 deconz 관련인지 모르겠습니다. 이것이 제가 다루기 위해 변화를 의미하는 것입니다. 따라서 일상적인 작업을 위해 2.3.007을 사용하지 않는 것으로 간주합니다. 주어진 사용성 예 : phoscon에서 구성된 간단한 스위치 회전 장면은 조심스럽게 누르지 않으면 더 이상 작동하지 않습니다. 1.x에서는 2.3.x에서는 빠르고 잘 작동하지만 멈춰 있습니다.

realwax 에 2020년 03월 01일

감사합니다, @manup , 방금 설치했습니다. 그것이 무엇을 가져올 지 봅시다.
이것이 약간의 개선을 가져올 것으로 예상하지만 DeConz 펌웨어가 기록 된 경로를 무시하는 것에 대해 어떻게 생각하십니까 (mane-to-one 라우팅으로 인해)? 일반적으로 기록 된 경로가 DeConz 펌웨어에서 사용하는 경로보다 훨씬 더 논리적이라는 것을 확인했습니다.
소스 라우팅을 활성화하는 것이 큰 일이라고 생각할 수 있지만 DeConz 펌웨어는 여전히 경로 레코드 패킷의 정보를 사용하여 장치에 대한 첫 번째 홉을 업데이트 할 수 있습니다. 코디네이터에 대한 마지막 홉이 라우팅 테이블에 저장된 것과 일치하는지 확인하고 그렇지 않은 경우 라우팅 테이블의 항목을 무효화 할 수 있습니다. 기록 된 경로의 마지막 홉으로 항목을 교체해도되는지 확실하지 않습니다. 도중에있는 장치가 정보를 무시할 가능성이 높지만 적어도 DeConz 펌웨어에 의해 해당 노드에 대한 새 경로 검색을 시작할 수 있기 때문입니다.
이것에 대해 어떻게 생각하십니까?
흠 이상하게도 펌웨어는 이미이 경로 레코드를 사용하여 새 경로를 설정해야합니다. 여기에서 코드를 확인해야합니다.하지만 내 메모리가 제대로 서비스를 제공하면 얼마 전에 활성화되었습니다.

@manup , 이것을 볼 시간이 있었습니까? 오늘 아침 저는 코디네이터로부터 4 홉 떨어진 조명 (IKEA)에 전원을 공급하는 상황을 발견했습니다. 어떻게 든 사이의 라우터 (또한 IKEA)는 더 이상이 빛의 경로를 알지 못하기로 결정했습니다. 실제로 조명이 다른 조명을 라우팅하고 링크 상태를보고하며 deCONZ의 Network Address Request 응답하는 작업을 즐겁게 수행하는 것을 봅니다. 이 마지막 문제는 네트워크에서 브로드 캐스트 메시지이기 때문에 발생합니다 ..!
그러나 그 사이의 라우터는이 라이트로 라우팅해야하는 유니 캐스트 프레임을 자동으로 삭제합니다. 물론이 라우터는 자동으로 삭제해서는 안되며, deCONZ는이 나쁜 동작에 대해 견고해야합니다.
그 동안 빛은 deCONZ에 도착하여 무시되는 deCONZ에도 경로 기록 메시지를 기꺼이 보냅니다.

이 경우 deCONZ를 트리거하여 경로를 재고해야하는 논리가 있어야한다고 생각합니다. 특히 ZCL 요청에 응답하지 않는 것을 감지 한 경우. 결국 조명이 좀비로 표시됩니다. 좀비라는 표시를 따르는 발견은 실제로 ligtht의 응답으로 이어집니다. 좀비 발견이 시작되면 사용 가능한 경로 정보도 무효화해야합니다. 그러나 더 좋은 것은 이미 두 개의 ZCL 요청이 응답하지 않을 때 경로가 무효화된다는 것입니다 (아마도 이미 첫 번째 또는 두 번째 요청시).

이것에 대해 어떻게 생각하십니까?

djwlindenaar 에 2020년 03월 01일

이 새로운 펌웨어로 문제가 해결되지 않았습니다.

별도의 Pi 및 Home Assistant (NUC에서 실행)에서 Raspbee를 사용하고 appx가 있습니다. 25 개의 tradfri 조명. 대부분 GU10은 3 인 그룹으로 사용됩니다.

조명 그룹의 단일 조명이 응답하지 않고 다시 돌아 오기 위해 전원주기가 필요한 큰 문제가있었습니다. 이것은 Ikea FW v1과 전구를 2.3.007로 업그레이드 한 후에 발생했습니다.

해결책은 HASS에서 조명을 그룹화하는 것에서 Phoscon에서 조명 그룹을 정의하고 HASS에서 단일 조명으로 Phoscon 그룹을 참조하는 것으로 구성을 변경하는 것이 었습니다. 이 변경 후 몇 달 동안 문제없이 실행했습니다.

HASS에서 그룹화를 수행하고 싶기 때문에 Raspbee를 0x26340500으로, Deconz를 2.05.74로 업그레이드하고 HASS에서 라이트 그룹을 사용하도록 구성을 다시 변경했습니다. 일주일 동안이 작업을 실행 한 후 전구가 3 ~ 4 번 부실 해졌고 이제 다시 Phoscon 그룹을 사용하도록 전환하고 있습니다.

aherbjornsen 에 2020년 03월 03일

이 경우 deCONZ를 트리거하여 경로를 재고해야하는 논리가 있어야한다고 생각합니다. 특히 ZCL 요청에 응답하지 않는 것을 감지 한 경우. 결국 조명이 좀비로 표시됩니다. 좀비라는 표시를 따르는 발견은 실제로 ligtht의 응답으로 이어집니다. 좀비 발견이 시작되면 사용 가능한 경로 정보도 무효화해야합니다. 그러나 더 좋은 것은 이미 두 개의 ZCL 요청이 응답하지 않을 때 경로가 무효화된다는 것입니다 (아마도 이미 첫 번째 또는 두 번째 요청시).

나는 여전히 새로운 펌웨어를 사용하고 있으며 경로 기록을 포함하여 몇 가지를 테스트하고 있으며 이번 주에 온라인으로 연결되기를 바랍니다.

이것에 대해 어떻게 생각하십니까?

APS 레벨 ACK가 수신되지 않을 때 펌웨어가 이미 경로 "품질"을 저하시켜야한다고 생각하기 때문에 여기에서 핵심 및 REST-API 플러그인 코드를 확인해야합니다. APS ACK는 ZCL / APS 요청에서 선택적으로 설정되는 플래그이며 네트워크 트래픽을 낮추기 위해 종종 비활성화됩니다. 따라서 대략적인 아이디어는 플러그인이 유니 캐스트 요청이 시간 초과로 이어지는 것을 감지하면 APS ACK를 활성화해야한다는 것입니다.

아마도 이것의 일부는 이미 제자리에 있으며 코드를 확인해야합니다.

그러나 그 사이의 라우터는이 라이트로 라우팅해야하는 유니 캐스트 프레임을 자동으로 삭제합니다. 물론이 라우터는 자동으로 삭제해서는 안되며, deCONZ는이 나쁜 동작에 대해 견고해야합니다.

새 경로 탐색이 트리거되는 즉시 표시등이 새 경로를 선택해야합니다. 따라서 목표는 가능한 한 빨리 끊어진 경로를 감지하고 (APS ACK가 트릭을 수행하기를 바랍니다) 경로 탐색을 트리거하는 것입니다.

이에 대한 상태 머신은 이미 deCONZ 코어에 있습니다 (이것은 NWK 주소 요청 브로드 캐스트로 이어지는 것입니다). 이것은 1 홉 링크의 경우와 들어오는 명령을 기반으로 경로를 선택하는 조명 (에 대한 응답)에서 작동합니다. 방송). MAC 주소가 포함되어 있기 때문에 NWK 주소로의 변경도 존중하므로 브로드 캐스트가 좋습니다. 응답이없는 경우 다음 단계로 APS ACK가 활성화 된 유니 캐스트를 보내려고합니다.

manup 에 2020년 03월 03일

안타깝게도 어제 IKEA E27 전구 (White 1000LM, v1 펌웨어)도 전원을 껐다가 켜야했습니다. 그룹에만 반응하지만 유니 캐스트 명령에는 반응하지 않았습니다. 문제가 아직 해결되지 않은 것 같습니다.

(예, 저는 v74와 RaspBee의 베타 펌웨어를 사용하고 있습니다)

timbru31 에 2020년 03월 04일

위의 설명을 참조하십시오. 다음 변경 사항은 라우팅을 복구하는 데 도움이 될 수 있습니다.

manup 에 2020년 03월 04일

이것에 대해 어떻게 생각하십니까?
APS 레벨 ACK가 수신되지 않을 때 펌웨어가 이미 경로 "품질"을 저하시켜야한다고 생각하기 때문에 여기에서 핵심 및 REST-API 플러그인 코드를 확인해야합니다. APS ACK는 ZCL / APS 요청에서 선택적으로 설정되는 플래그이며 네트워크 트래픽을 낮추기 위해 종종 비활성화됩니다. 따라서 대략적인 아이디어는 플러그인이 유니 캐스트 요청이 시간 초과로 이어지는 것을 감지하면 APS ACK를 활성화해야한다는 것입니다.
아마도 이것의 일부는 이미 제자리에 있으며 코드를 확인해야합니다.

APS ACK 요청 비트가 설정되어 있어도 deCONZ는 누락 된 ack으로 아무 작업도하지 않는 것처럼 보입니다 (한 번만 재 시도한 다음 아무것도하지 않습니다 ...).

BTW houtlamp 2 는 Tuin linksvoor 2 향하는 패킷을 드롭하는 것입니다.

No. Time    Source  Transmit Dev    Receive Dev Destination Disable Default Response    Info
245915  10h 28m 42.108501s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2    True    ZCL: Read Attributes, Seq: 245
245922  10h 28m 46.033452s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2    True    ZCL: Read Attributes, Seq: 245

ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x40)
        .... ..00 = Frame Type: Data (0x0)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False

        .1.. .... = Acknowledgement Request: True

        0... .... = Extended Header: False
    Destination Endpoint: 1
    Cluster: On/Off (0x0006)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 107

그러나 그 사이의 라우터는이 라이트로 라우팅해야하는 유니 캐스트 프레임을 자동으로 삭제합니다. 물론이 라우터는 자동으로 삭제해서는 안되며, deCONZ는이 나쁜 동작에 대해 견고해야합니다.
새 경로 탐색이 트리거되는 즉시 표시등이 새 경로를 선택해야합니다. 따라서 목표는 가능한 한 빨리 끊어진 경로를 감지하고 (APS ACK가 트릭을 수행하기를 바랍니다) 경로 탐색을 트리거하는 것입니다.
이에 대한 상태 머신은 이미 deCONZ 코어에 있습니다 (이것은 NWK 주소 요청 브로드 캐스트로 이어지는 것입니다). 이것은 1 홉 링크의 경우와 들어오는 명령을 기반으로 경로를 선택하는 조명 (에 대한 응답)에서 작동합니다. 방송). MAC 주소가 포함되어 있기 때문에 NWK 주소로의 변경도 존중하므로 브로드 캐스트가 좋습니다. 응답이없는 경우 다음 단계로 APS ACK가 활성화 된 유니 캐스트를 보내려고합니다.

실제로 houtlamp 2 은 방송 address request 대한 응답을 보지 못합니다. deCONZ에 대한 메시지는 tuin linksvoor 3 통해 라우팅되므로 houtlamp 2 가 해당 경로를 선택하더라도 기회를 얻지 못합니다. 이것은 deCONZ가 route record 를 새 경로로 선택하지 않았기 때문에 다시 발생합니다.

ZigBee Network Layer Command, Dst: DeConz, Src: Tuin link
    Frame Control Field: 0x1a09, Frame Type: Command, Discover Route: Suppress, Security, Destination, Extended Source Command
    Destination: 0x0000[DeConz]
    Source: 0x0ea5[Tuin linksvoor 2]
    Radius: 29
    Sequence Number: 51
    Destination: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)
    Extended Source: EnergyMi_ff:fe:e9:91:86 (d0:cf:5e:ff:fe:e9:91:86)
    ZigBee Security Header
    Command Frame: Route Record
        Command Identifier: Route Record (0x05)
        Relay Count: 1
        Relay Device 1: 0xc9fa[Tuin linksvoor 3]

이제 Tuin linksvoor 2 는 network address request 브로드 캐스트에 응답을 보내고 성공하지만 deCONZ의 APS ACK는 houtlamp 2 의해 삭제되었으므로 Tuin linksvoor 2 도달하지 않습니다. 그래서 포기하기 전에 몇 번 다시 보냅니다. Tuin linksvoor 2 를 엉망으로 만들 가능성이 높습니다.

No. Time    Source  Transmit Dev    Receive Dev Destination Disable Default Response    Info
246199  10h 29m  1.496384s  Tuin linksvoor 2    Tuin linksvoor 3    DeConz  DeConz      Network Address Response, Status: Success, Address: EnergyMi_ff:fe:e9:91:86 = 0x0ea5
246201  10h 29m  1.502056s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2        APS: Ack, Dst Endpt: 0, Src Endpt: 0

djwlindenaar 에 2020년 03월 04일

👍1

Conbee 1 + 최신 fw + .74는 100 % 재생되지 않습니다.
꽤 많은 안타 / 실패가있었습니다. 저에게는 .73에서 더 잘 작동하는 것 같지만 100 %는 아닙니다.

다시 드로잉 보드로 돌아갑니다. 새로운 (베타) Conbee 1 fw에서는 여전히 100 % 괜찮지 않습니다.

tubalainen 에 2020년 03월 06일

펌웨어 1.2.221을 사용하는 Tradfir E14의 Conbee 1에서 .74 및 26340500으로 며칠 동안 작동 한 후 다음을보고 할 수 있습니다.

IKEA 조명은 4 일 만에 하나의 전구 만 잃어 버렸지 만 네트워크 이탈 측면에서 더욱 안정되었습니다. 나는 또한 당신이 E14 fw 1.2.221에서 실행되는 deconz 운영 지그비 네트워크에서 지옥을 강조한다면 발견했습니다. 매초마다 bri가 변경된 단일 요청을 보내 전구를 페이드 다운하는 스크립트를 실행했습니다. 그런 식으로 저는 4 개의 전구를 정말 빨리 잃었습니다. 그러나 어쨌든 그것을 원하는 사람;)

아직 해결되지 않음 :
내가 여전히 가지고있는 문제와 우려는 Tradfri FW 2.3.x가 제대로 실행되지 않거나 deconz와 함께 사용하기에 잘 구현되지 않는다는 것입니다. tradfri fw 1.2.x를 유지하고 zigbee 3.0을 사용하지 않는 것이 좋습니다. 그러나 피할 수없는 시점이있을 것입니다. 또는 새로 전구가 더 이상 다운 그레이드되는 것이 두렵습니다.
나는 2-3 개의 전구 그룹이 4-8 개의 전구 그룹만큼 그 문제를 너무 나쁘게 나타내지 않는다는 것을 발견했습니다.
나는 여기에 나의 발견을보고했고 그것이 발견되면 행복하고 감사합니다. 나는 여기 https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518에서 인식을 높이려고 노력했습니다.
모든 전구를 2.3.x로 플래시하여이 문제를 재현 할 수 있기 때문에 여러분도 그렇게 할 수 있기를 바랍니다.

결론-우리가 이야기하고있는 어떤 tradfri 펌웨어가 사용되는지에 대한 차이를 만듭니다. 사용성 및 문제 경험과 deconz 작동에 큰 차이가 있습니다. 1.2.x fws가 더 오래되고 알려진 드롭 아웃 외에 매력처럼 작동하지만 2.3.x는 제기 된 문제에 설명 된대로 사용성을 잃지 않았습니다. 나는 FW에서 이러한 차이를 경험하는 유일한 사람이라는 것을 상상할 수 없습니다.

@ebaauw 가 다른 스레드에서 명확하게

realwax 에 2020년 03월 06일

👍1

Conbee II 펌웨어도 수정 되었습니까? 릴리스에서 Conbee I 만 보았습니다. 당신의 노력에 감사드립니다.

helto4real 에 2020년 03월 07일

👍1

이것은 deCONZ가 경로 기록을 새로운 경로로 선택하지 않기 때문에 다시 발생합니다.

@djwlindenaar 는 여기에서 내가 책임을 져야

내 기억이 제대로 작동한다면 당시 문제는 150 개의 노드 주변에 대규모 혼합 네트워크가 있고 경로 레코드가 제대로 작동하지 않는 것 같았다는 것입니다. 새로운 경로가 제대로 작동하지 않았습니다. 그러나 코드는 NWK 상태 명령 오류 코드의 다른 수정과 함께 작동했을 수 있습니다.

이제 이것을 되돌 리므로 경로 레코드가 경로를 더 나은 경로로 업데이트해야합니다.

Zigbee 사양의 해당 단락을 좋아합니다.

ZigBee 라우터 또는 ZigBee 코디네이터는 라우팅 테이블을 유지할 수 있습니다. ZigBee 라우팅 테이블 항목에 저장되어야하는 정보는 표 3-66과 같습니다. 더 이상 사용되지 않는 항목에서 테이블 스페이스를 재 확보하기 위해 라우팅 테이블 항목의 에이징 및 폐기는 권장되는 방법입니다. 그러나 이는이 사양의 범위를 벗어납니다.

이는 기본적으로 모든 스택이 경로 노화를 다르게 처리한다는 것을 의미합니다.

그래서 우리의 경우 어떻게 작동하는지 확인했습니다. Bitcloud에서 Zigbee 스택 경로에는 처음에 1 인 경로 "속도"가 있습니다.

성공적인 NWK 전송에서 최대 값 미만인 경우 속도가 증가합니다.
(1 << 8) - 1 = 255
성공적인 NWK 전송에서 최대 255 개에 도달하면 모든 라우팅 테이블 항목이 "정규화"됩니다.
rate = (rate >> 1) + 1 (효과적으로 2로 나눈 값, 최소 1)
실패한 NWK 전송에서 관련 경로 항목의 속도는 다음과 같이 설정됩니다.
rate -= (rate / 2) > 0 ? rate / 2 : 1
실패한 전송이 너무 많으면 속도가 0이되고 경로가 제거됩니다.

이것은 상위 링크가 다음과 같이 저하됨을 의미합니다.

255  top rate
127  first failed transmission
63   ...
31
15
7
3
1
0    the record gets removed

따라서 항목이 제거되고 검색이 다시 시작될 때까지 8 개의 실패한 명령이 필요합니다.
그것은 정상적인 네트워크에서 특히 그들이 50 .. 100 노드로 성장할 때 꽤 괜찮습니다. 경로는 너무 일찍 버려서는 안됩니다.

제가 우려하는 점은 포인트 (2)입니다. 방아쇠 (2)는 대규모 네트워크의 조명 수를 꽤 자주 곱합니다. 활성 OTA 업데이트는 말할 것도 없습니다.

모든 경로 항목을 저하 (정규화)하지 않고 성공적인 전송과 관련된 255 개의 최상위 경로 만 변경 (2)하는 것이 안전하다고 생각합니다. 이것은 잘 작동했지만 자주 사용되지 않았고 첫 번째 실패한 NWK 전송에서 제거 된 잃어버린 경로를 방지해야합니다.

내일 이러한 변경 사항으로 새 펌웨어를 구축 할 예정이며 ConBee II 용 펌웨어도 동일하게 적용됩니다.

manup 에 2020년 03월 07일

👍5

이제 이것을 되돌 리므로 경로 레코드가 경로를 더 나은 경로로 업데이트해야합니다.

그래 좋아. 나는 시험을 고대하고있다!

Zigbee 사양의 해당 단락을 좋아합니다.

그래, 이런 종류의 지정은 모든 공급 업체가 잘 공존하는 데 어려움을 겪고 있다고 생각합니다. :미소:

Bitcloud에서 Zigbee 스택 경로에는 처음에 1 인 경로 "속도"가 있습니다.

저는 규칙 2의 논리를 이해하지 못합니다. 그것은 일종의 가난한 사람의 노화 버전 인 것 같습니다. 모든 노드가 비슷한 양의 트래픽을 보게되면 아주 잘 작동하지만 실제로 불균형 (제 생각에는 꽤 일반적이라고 생각합니다)이면 잘못 될 것입니다.
ZStack이 라우팅 테이블에서 status 바이트 옆에있는 실제 expiryTime 필드를 사용하고 있음을 알았습니다.

3. On a failed NWK transmission the rate of the related route entry is set as:

이것은 실제로 어떻게 작동합니까?
내가 착각하지 않았다면 NWK는 802.15.4 MAC ACK 만 확인하기 때문에 실패한 NWK 전송은 실제로 다음 홉만을 의미합니다. 따라서 종단 간 전송이 정상인지 확인하려면 APS ack에 의존해야합니다. 그 맞습니까? BitCloud에서 이런 식으로 작동합니까?
또한 : APS 계층의 ack 요청 비트가 설정되지 않은 경우, 이는 성공적인 전송으로 간주되고 (예상되는 ack가 없기 때문에) 해당 경로 항목의 "속도"를 증가시키는 것입니까? 그렇다면 우리는 항상 APS 레이어 ACK를 요청하지 않고 발을 내딛을 수 있기 때문입니다.

NWK 실패만을 기반으로하는 경우 중간 라우터가 오작동하는 상황에 도움이되지 않으며 APS 계층 ACK가 도착하지 않는 것을 고려하기 위해 추가 로직을 추가해야합니다. 아마도 '좀비'라우터를 탐지하는 유사한 로직을 기반으로하지만 먼저 해당 경로에 대한 경로 테이블 항목을 무효화합니다.

djwlindenaar 에 2020년 03월 08일

ConBee I 및 RaspBee I 용 펌웨어 버전 0x26350500을 테스트 할 수 있습니다.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26350500.bin.GCF

0x26340500과 마찬가지로 모든 NWK 상태 경로 오류가 처리됩니다.
불공정 한 경로 저하 수정 (https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-596142584의 2 번 지점 참조)
경로 레코드 수정이 경로의 다음 홉을 업데이트하지 않았습니다. 이제 작동하지만 경로 레코드가있을 때 현재 경로 비용이 더 높은 경우에만 작동합니다.
APS ACK가 활성화 된 실패한 APS 요청을 수정해도 경로가 저하되지 않았습니다.

이제 ConBee II 코드에서 이러한 수정 사항을 적용 할 수 있는지 여부와 위치를 확인하고 있습니다. 0x26520700 및 0x26530700을 해제하고이를 현재 안정된 0x264a0700을 기반으로합니다.

저는 규칙 2의 논리를 이해하지 못합니다. 그것은 일종의 가난한 사람의 노화 버전 인 것 같습니다. 모든 노드가 비슷한 양의 트래픽을 보게되면 아주 잘 작동하지만 실제로 불균형 (제 생각에는 꽤 일반적이라고 생각합니다)이면 잘못 될 것입니다.
ZStack이 라우팅 테이블의 상태 바이트 옆에있는 실제 expiryTime 필드를 사용하고 있음을 알았습니다.

전적으로 동의합니다. 속도가 최대에 도달하면 성공적인 전송 경로 만 정규화되도록이 문제가 수정되었습니다. 만료 된 타이머 처리 방법은 또 다른 옵션 일 수 있지만 규모에 따라 자체 함정이 있습니다. "속도"방식은 네트워크 크기와 시간에 의존하지 않고 잘 작동 할 것이라고 생각합니다.

NWK 실패만을 기반으로하는 경우 중간 라우터가 오작동하는 상황에 도움이되지 않으며 APS 계층 ACK가 도착하지 않는 것을 고려하기 위해 추가 로직을 추가해야합니다. 아마도 '좀비'라우터를 탐지하는 유사한 로직을 기반으로하지만 먼저 해당 경로에 대한 경로 테이블 항목을 무효화합니다.

이것이 사실 인 것처럼 보였고 실제로 경로 오류와 함께 NWK 상태 명령을 보내지 않는 오작동 라우터는 죽은 경로를 계속 유지할 수 있습니다. 이것은 이제 0x26350500에서 수정되었지만 APS ACK 활성화 명령에 의존합니다. 어느 것이 좋으며 deCONz 및 REST-API 플러그인으로 제어 할 수 있습니다.

manup 에 2020년 03월 08일

👍1

ConBee I 및 RaspBee I 용 펌웨어 버전 0x26350500을 테스트 할 수 있습니다.

플래시를 터뜨렸고 이제 테스트 중입니다.

이것은 이제 0x26350500에서 수정되었지만 APS ACK 활성화 명령에 의존합니다.

ACK 누락에 대해 어떻게합니까? 실패한 NWK 전송과 동일하거나 그 이상 / 다르게 rate 값을 절반으로 줄입니까? 누락 된 APS ACK는 실패한 NWK 전송에 비해 더 심각한 것으로 간주되어야한다고 생각하기 때문입니다. 그렇지 않으면 라우터가 잘못 작동하는 경우에도 성공적인 NWK 전송이 누락 된 APS ACK가 더 낮은 값보다 rate 더 증가 할 수 있습니다.

djwlindenaar 에 2020년 03월 08일

ACK 누락에 대해 어떻게합니까? 실패한 NWK 전송과 동일하거나 더 많거나 다른 비율 값을 절반으로 줄입니까? 누락 된 APS ACK는 실패한 NWK 전송에 비해 더 심각한 것으로 간주되어야한다고 생각하기 때문입니다. 그렇지 않으면 라우터가 잘못 작동하는 경우에도 성공적인 NWK 전송은 누락 된 APS ACK가 속도를 낮추는 것보다 속도를 더 높일 수 있습니다.

나는 똑같이 생각했다. 그 경우에 무슨 일이 일어나고 있는가 :

NWK 전송 양성 MAC ACK rate + 1
APS ACK 없음 rate = rate / 4

따라서 속도가 상당히 빨리 떨어지고 너무 공격적 일 수 있으며 rate / 2 이면 충분하지만 실제로 어떻게 작동하는지 살펴 보겠습니다.

manup 에 2020년 03월 08일

👍1

좋은. 실행하고 다시보고하겠습니다.

현재는 유니 캐스트 메시지 (OnOffwithLevel)를 메시에서 꽤 멀리 떨어진 라이트에 몇 초마다 전송하여 스트레스 테스트도 수행합니다.

Btw 나는 또한 모든 메시지에서 APS ACK를 요청하기 위해 나머지 플러그인 코드를 변경했습니다.

djwlindenaar 에 2020년 03월 08일

홈 어시스턴트를 사용하여 Rpi 3B +에서 Deconz를 실행 중입니다.
현재 Conbee I 및 26330500으로 2.05.75 실행

오늘 저녁 일부 조명이 켜지지 않았습니다.
수동으로 켜려고 시도했습니다. 아래 로그를 참조하십시오.
VNC 메시를 확인했는데 메시 네트워크의 일부이지만 아무것도 반응하지 않습니다.
이 노드는 Tradfri on / off 콘센트 스위치입니다.

여기서 이상한 점 :
_ 개별 스위치 대신 Deconz 그룹을 활성화 할 때 스위치를 켤 수 있습니다 ._

19 : 23 : 58 : 979 지연 전송 요청 57 dt 0 ms에서 0x000D6FFFFEB1C9FF, ep : 0x01 클러스터 : 0x0004 onAir : 1
19 : 24 : 15 : 744 현재 채널 25
19 : 24 : 15 : 776 장치 TTL 3920 s 플래그 : 0x7
19 : 24 : 46 : 764 0x000D6FFFFEB1C9FF 오류 APSDE-DATA. 확인 : 작업에서 0xA7
19 : 25 : 10 : 547 0x000D6FFFFEB1C9FF 오류 APSDE-DATA. 확인 : 작업에 0xA7
19 : 25 : 15 : 749 현재 채널 25
19 : 25 : 15 : 782 장치 TTL 3860 s 플래그 : 0x7
19 : 25 : 33 : 885 0x000D6FFFFEB1C9FF 오류 APSDE-DATA. 확인 : 작업에 0xA7
19 : 25 : 49 : 411 0x000D6FFFFEB1C9FF 오류 APSDE-DATA. 확인 : 작업에 0xA7
19 : 26 : 12 : 765 0x000D6FFFFEB1C9FF 오류 APSDE-DATA. 확인 : 작업에서 0xA7
19 : 26 : 12 : 765 노드 0x000D6FFFFEB1C9FF에 대한 최대 전송 오류, 이웃이 마지막으로 확인한 25 초
19 : 26 : 15 : 742 현재 채널 25
19 : 26 : 15 : 774 장치 TTL 3800s 플래그 : 0x7
19 : 26 : 48 : 221 0x000D6FFFFEB1C9FF 오류 APSDE-DATA. 확인 : 작업에서 0xA7
19 : 26 : 48 : 221 노드 0x000D6FFFFEB1C9FF에 대한 최대 전송 오류, 이웃이 마지막으로 확인한 60 초
19 : 27 : 03 : 845 9ms 내에 노드 상태 저장
19 : 27 : 33 : 634 sync () 29789ms

jan-dewit 에 2020년 03월 11일

최신 수정 사항은 26350500에 있습니다 ...

djwlindenaar 에 2020년 03월 11일

@djwlindenaar 나는 당신의 테스트 결과를 기다리고 있습니다 :-)

mvjt 에 2020년 03월 11일

여태까지는 그런대로 잘됐다. deCONZ가 즐겁게 경로를 바꾸는 것을 볼 수 있습니다. :미소:

djwlindenaar 에 2020년 03월 11일

🎉4

최신 수정 사항은 26350500에 있습니다 ...

죄송합니다. FW 버전을 잘못 읽었습니다.
공식 Home Assistant Deconz 애드온을 사용하여 테스트를 돕고 싶습니다.이 애드온을 베타 펌웨어로 업데이트하는 방법을 모르겠습니다. (공식 업데이트는 OTA입니다)

jan-dewit 에 2020년 03월 12일

@manup 님 , Conbee ii fw 업데이트에 대한 상태가 있습니까?

EGruno 에 2020년 03월 13일

👍2

@manup , Many-to-One Route Failure (0x0c) 대한 조치가없는 것 같습니다. deCONZ가 MTORR을 다시 수행하기를 기대합니다 (이미 진행중인 경우 제외). 나는 이러한 메시지를 정기적으로받습니다.

Command Frame: Network Status
    Command Identifier: Network Status (0x03)
    Status Code: Many-to-One Route Failure (0x0c)
    Destination: 0x499e[Tuin rechtsachter 2]

djwlindenaar 에 2020년 03월 14일

@manup , route record 가 여전히 deCONZ에 의해 항상 인수되는 것은 아닌 것 같습니다. 예를 들면 :

No.                Time               Source             Transmit Dev       Receive Dev        Destination        Disable Default Response              Acknowledgement Request               Info
700766             13h 27m 35.628249s Tuin linksvoor 2   Tuin linksvoor 2   DeConz             DeConz                                                   Route Record, Dst: 0x0000
700784             13h 27m 39.591343s DeConz             DeConz             WC lamp            Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162
700786             13h 27m 39.597002s DeConz             WC lamp            Tuin linksvoor 1   Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162
700788             13h 27m 39.600699s DeConz             Tuin linksvoor 1   Tuin linksvoor 2   Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162

광 Tuin linksvoor 2 직접 보내는 deCONZ 이지만에서 경로 deCONZ sevaral 홉 통해 ...
deCONZ route record 메시지의 경로를 예 / 아니오로 수락하기 위해 deCONZ 의 의사 결정 프로세스에 대한 통찰력을 줄 수 있다면 도움이 될 것입니다.

--- 내 추론에 결함이 있었기 때문에 아래 항목을 편집했습니다. 이제 희망하지 않습니다 : 윙크 : ---

하지만 deCONZ 사용하는 경로는 실제로 Tuin linksvoor 2 대한 직접 통신보다 훨씬 더 안정적입니다. 이로 인해 다 대일 라우팅이 궁금해졌습니다. 아마도 Raspbee의 전송 전력이 이상적이지 않은 것 같습니다 ...
이것이 내 추론입니다.

다 대일 라우팅은 브로드 캐스트 수신을 기반으로합니다.
일반 경로 처리와 달리 수신 및 발신 경로 비용의 최대 값을 다음 홉의 비용으로 사용합니다.
이제 라우터 또는 코디네이터가 수신 (낮은 RX 감도)보다 전송 (높은 TX 전력)이 훨씬 더 나은 경우 다 대일 라우팅이 제대로 작동하지 않을 수 있습니다.

내가 주목 한 관련 포인트는 deCONZ가 라우팅 테이블의 수신 비용에 대해 (매우) 낙관적이라는 것입니다. Tuin linksvoor 2 직접 deCONZ 메시지를 보낼 때 항상 많은 재 시도가 필요합니다. 이제 라우팅 테이블을 살펴보면 다음을 볼 수 있으며 들어오는 비용 4로 어려운 전송을 기대하지 않을 것입니다. 기본적으로 라우팅 테이블의 모든 항목은 나가는 비용보다 들어오는 비용이 훨씬 낮습니다.

Link 4
    Address: 0x0ea5[Tuin linksvoor 2]
    .... .100 = Incoming Cost: 4
    .111 .... = Outgoing Cost: 7

따라서 deCONZ가 들어오는 비용에 대해 낙관적이지 않다면 더 나은 경로 동작을 볼 수 있습니다. 또는 더 균형 잡히도록 TX 전력을 증가시킬 경우 (수신 및 발신에 대한 유사한 비용)
또는 deCONZ의 TX 전력을 낮추려면 더 많은 홉을 통해 라우팅해야하지만 (비용 7 개의 장치가 라우팅 테이블에서 빠져 나옴) 들어오는 메시지를 더 쉽게 수신 할 수 있습니다.

deCONZ 링크 상태 메시지의 전체 목록 :

Command Frame: Link Status
    Command Identifier: Link Status (0x08)
    .1.. .... = Last Frame: True
    ..1. .... = First Frame: True
    ...1 0010 = Link Status Count: 18
    Link 1
        Address: 0x0118[Buiten - R schuur]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 2
        Address: 0x0143[HK stalamp]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 3
        Address: 0x05b5[HK houtlamp 2]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 4
        Address: 0x0ea5[Tuin linksvoor 2]
        .... .100 = Incoming Cost: 4
        .111 .... = Outgoing Cost: 7
    Link 5
        Address: 0x1ad3[HK plafond ledstrip]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 6
        Address: 0x1ff6[Tuin linksvoor 1]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 7
        Address: 0x4b4d[Keuken mid]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 8
        Address: 0x5693[Keuken Rechts]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 9
        Address: 0x68c4[WC lamp]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 10
        Address: 0x6c35[Buiten - L schuur]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 11
        Address: 0x731e[Kerstverlichting]
        .... .011 = Incoming Cost: 3
        .011 .... = Outgoing Cost: 3
    Link 12
        Address: 0x7d2a[0x7d2a]
        .... .011 = Incoming Cost: 3
        .101 .... = Outgoing Cost: 5
    Link 13
        Address: 0xa3f5[HK zoutlamp]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 14
        Address: 0xc7bc[Hal lamp]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 15
        Address: 0xc9fa[Tuin linksvoor 3]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 16
        Address: 0xd6b7[Zolder Noord Lamp]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 17
        Address: 0xde81[On/Off light 36]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 18
        Address: 0xefd5[Zoldertrap Lamp]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1

djwlindenaar 에 2020년 03월 14일

지연 돼서 죄송합니다. 상태 : 우리는 여전히 새 릴리스를 위해 열심히 노력하고 있으며 생각보다 더 복잡해 보이는 펌웨어의 버그를 추적하고 있습니다. nvram 처리 중 무언가가 꺼져있는 것 같습니다. 우리는 또한 USB 열거 / 시작 문제를 해결하는 방법을 찾고 있습니다.

가능한 한 빨리 여기에 업데이트를 게시하겠습니다.

manup 에 2020년 03월 15일

👍7

업데이트 : 여전히 강세!

이렇게 안정적인 네트워크를 본 적이 없다고 생각합니다. 지금까지 그룹 대신 유니 캐스트를 사용하도록 다양한 규칙을 변경했습니다. 이제 2 주 동안 IKEA 조명 0 개가 사라졌습니다.

(지금 징크스하지 않기를 바랍니다)

모든 요청에 대해 APS ack를 요청하도록 REST 플러그인을 변경했습니다.

djwlindenaar 에 2020년 03월 20일

또한 훨씬 향상된 네트워크를 경험하고 있습니다. 하지만 100 %는 아닙니다. 가끔 전구가 반응하지 않는 경우가 있었지만 IKEA 전구를 수동으로 변경하면 반응이있었습니다. 나는 또한 전구의 상태가 이제 물리적 인 상태임을 알 수 있습니다.
그러나 내 Osram 전구 중 하나는 ikea 전구가 이전처럼 반응하지 않는 동작을 나타 냈습니다. 긍정적 인 점은 이케아처럼 심각한 행동이 아니라는 것입니다.

이것이 다른 사람이나 확인 된 결과에 의해 확인되기를 바랍니다.

PeterRemnemark 에 2020년 03월 20일

FW 26350500 및 Deconz 2.05.75로 Conbee 1을 실행하고 있습니다.
이것은 지난주 내 경험입니다.

더 잘 작동하지만 100 %는 아닙니다.
IKEA E27 TRÅDFRI 전구 E27 WS opal 980lm (fw 2.3.007 포함) 중 일부가 때때로 OFF 명령에 응답하지 않습니다.
다시 전원을 끄면 정상적으로 작동합니다 (전원을 껐다 켤 필요 없음).

tubalainen 에 2020년 03월 21일

트윗 담아 가기 REST API에 대한 APS 수정이 .75 릴리스에 포함되어 있습니까? 이전 게시물의 차이점을 설명 할 수 있는지 알고 있습니다.

mvjt 에 2020년 03월 21일

아니에요. 나는 그것에 대한 풀 리퀘스트도 만들지 않았다. 그것으로 당신은 그것을 스스로 만들 수 있습니다. 오늘이나 내일 할게요.
또한 빌드 된 나머지 API 플러그인을 공유 할 수 있지만 라즈베리 3 용 플러그인 만 있습니다.

@tubalainen , APS ack로 설명 할 수 있는지 확인하겠습니다. 또한 2.3 IKEA 조명이 없습니다.

deCONZ의 재시도 동작에 문제가있을 수 있습니다. 실험을해야하거나 이미 스 니프 로그에있을 수도 있습니다.

냄새를 맡을 수 있다면 그 현상을 냄새 맡는 것이 도움이 될 것입니다. 할 수없는 경우 분석을 도와 드릴 수 있습니다.

djwlindenaar 에 2020년 03월 21일

어제 프로덕션 네트워크 (RPi 3B +, stretch, RaspBee)를 2.05.74 및 0x26340500으로 업그레이드했습니다. 아래 문제를 제외하고는 안정적으로 보입니다.
관련이 있는지 확실하지 않지만 오늘 아침 내 lumi.curtain 커튼 컨트롤러에 대한 경로가 손실되었습니다. 컨트롤러의 보고서는 여전히 게이트웨이에 도달합니다. 컨트롤러의 전원을 껐다 켜도 경로가 복원되지 않습니다. 코디네이터가 다시 연결하기 전에 네트워크를 열고 컨트롤러의 전원을 껐다가 켜야했습니다.
또한 내 Eurotronic Spirit 라디에이터 밸브 중 하나는 deCONZ를 시작한 후 여전히 보고서를 보내는 동안 deCONZ가 연결할 수 없었습니다. TRV의 전원을 껐다 켜면 평소와 같이 다시 가져 왔습니다.
이번에는 심층 조사를 할 기회가 없었지만 두 기기 모두 처음부터 문제가 발생하여 가끔씩 이러한 증상이 나타납니다. IKEA Fyrtur 블라인드도 마찬가지입니다. 계속해서 상황을 모니터링하고 더 많은 문제가 발생하면 다시보고하겠습니다.

이러한 간헐적 문제를 객관적으로 기록하는 것은 매우 어렵지만 0x26350500이 여기에 개선을 가져 왔다는 인상을 받았습니다. 위에서 언급 한 장치 외에 내 네트워크는 매우 안정적입니다. 게이트웨이에서 연결할 수없는 일부 TRV가 있었지만 deCONZ를 다시 시작한 후에는 대부분 (오직?). FYRTUR이나 커튼 컨트롤러가 지난 3 주 동안 MIA를 밟지 않았다고 생각합니다.

모든 요청에 대해 APS ack를 요청하도록 REST 플러그인을 변경했습니다.

GUI의 _ 네트워크 설정 _에서 APS Acks를 활성화했지만 이것이 GUI에서 보낸 메시지에만 적용되는지 아니면 REST API 플러그인에도 적용되는지 잘 모르겠습니다.

ebaauw 에 2020년 03월 21일

위의 pull 요청으로 실행하려면 내 포크를 확인하고 다음을 빌드 할 수도 있습니다. djwlindenaar / deconz-rest-plugin

djwlindenaar 에 2020년 03월 21일

@ebaauw , 내가 말할 수있는 한 이것은 GUI에서 보낸 명령에만 적용됩니다.

지속적으로 스니퍼를 실행하고 있으며 문제가 발생하는 wallclock 시간이 아닙니다. 일반적으로 해당 정보를 사용하면 패킷을 매우 쉽게 찾을 수 있습니다.

BTW 저는 많은 규칙 (특히 자주 트리거되는 규칙)을 유니 캐스트로 전환했습니다. 지금까지 잘 작동합니다. 또한 지난 2 주 동안 IKEA 조명 1 개를 사용하여 밝기를 지속적으로 (약 4 초마다) 변경했습니다. 그것도 여전히 괜찮습니다.

djwlindenaar 에 2020년 03월 21일

글쎄요 ... 제 일지에서 뭔가 펑키 한 걸 발견 했어요. 나는 내가 전원을 껐다가 켰던 어떤 조명도 그들의 속성을보고하지 않는다는 것을 발견했습니다. 나는 내가 다른 버그에 있다고 생각했지만 그렇지 않았다. 어쨌든 이것은 우리가 이것을 버그라고 생각하고 싶을 수도있다.

앞서 언급했듯이 몇 초마다 조명의 레벨을 변경하는 스크립트를 실행했습니다. 이것이 IKEA 조명의 문제를 가속화 할 수 있다고 생각합니다. 이렇게하면 d->idleLastActivity 카운터가 재설정되어 유휴 작업이 실행되지 않습니다. 속성보고 구성 포함 : rofl :

djwlindenaar 에 2020년 03월 21일

전원을 껐다 켜면 IKEA 조명이 바인딩 및 속성보고 구성을 잃게된다는 말씀입니까?!

ebaauw 에 2020년 03월 21일

그런 것 같은데 ... 안 그래 ..?

djwlindenaar 에 2020년 03월 21일

내 문제는 설정을 .75 및 50500으로 업그레이드했기 때문에 도커 컨테이너가 적어도 일주일에 한 번 Conbee를 잃어버린다는 것입니다. 컨테이너를 다시 시작하면 일이 다시 진행됩니다 ... 매우 성가신

mvjt 에 2020년 03월 21일

@djwlindenaar , 아니, 나는 그들이해야한다고 생각하지 않습니다. 내가 본 대부분의 장치는 이러한 설정을 비 휘발성 메모리에 유지합니다. 나는 ZigBee 표준이 두 가지 행동을위한 여지를 남겨 둔다고 생각합니다.

ebaauw 에 2020년 03월 21일

내 IKEA 전구가 이제 더 잘 작동하지만 안타깝게도 내 Xiaomi 센서 (원형 온도 센서) 중 하나가 잠시 후 응답하지 않습니다. 다음날 냄새를 맡아 증거를 수집 해 보겠습니다.

timbru31 에 2020년 03월 22일

FW 26350500 및 Deconz 2.05.75로 Conbee 1을 실행하고 있습니다.
이것은 지난주 내 경험입니다.
더 잘 작동하지만 100 %는 아닙니다.
IKEA E27 TRÅDFRI 전구 E27 WS opal 980lm (fw 2.3.007 포함) 중 일부가 때때로 OFF 명령에 응답하지 않습니다.
다시 전원을 끄면 정상적으로 작동합니다 (전원을 껐다 켤 필요 없음).

@tubalainen 안녕하세요, 1.2.x와 비교하여 2.3.x 펌웨어를 사용하는 ikea의 다른 동작을 발견했습니다. 나는 그것을 다루려고했지만 주목을받지 못했다. 전구를 1.2.x로 다운 그레이드했는데 이제는 매력적으로 작동합니다. 2.3.x에서. 일정 시간 동안 장면 재조정 후에는 스위치를 끌 수 없습니다. 정상 켜기 끄기가 작동했습니다. 이상한 행동. 여기서 테스트하고 기여하고 싶을 수도 있습니다. 건배 https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518

realwax 에 2020년 03월 22일

👍1

전원을 껐다 켜면 IKEA 조명이 바인딩 및 속성보고 구성을 잃게된다는 말씀입니까?!

불행히도 그들은 전원을 껐다가 켜면 바인딩이 풀리지 만 코드는 얼마 전에이를 해결하기 위해 수정되었습니다. 연결 및 구성은 조명을 껐다가 켠 후 복원됩니다. 또한 잠시 동안 보고서가 수신되지 않으면 복원 프로세스가 시작됩니다.

manup 에 2020년 03월 22일

👀1

@realwax 는 모든 E27 전구에서 1.2.x로 다운 그레이드되고 다시보고합니다. (시간이 걸립니다 :)).

어제 두 개의 E27 조명 (2.3x FW)이 아침 시퀀스 동안 꺼지지 않았습니다.

tubalainen 에 2020년 03월 23일

@tubalainen 그룹 명령이나 유니 캐스트 명령을 사용합니까? (예 : REST API를 통해 / groups / 또는 / lights /를 통해 상태 설정)

조명에 도달 할 수있는 한 실제로 유니 캐스트 명령이 더 신뢰할 수 있다고 생각합니다. 그룹 브로드 캐스트 명령을 놓친 경우 재 시도되지 않습니다. 유니 캐스트 명령은 몇 번 또는 전달 될 때까지 재 시도됩니다.

djwlindenaar 에 2020년 03월 23일

@tubalainen 그룹 명령이나 유니 캐스트 명령을 사용합니까? (예 : REST API를 통해 / groups / 또는 / lights /를 통해 상태 설정)
조명에 도달 할 수있는 한 실제로 유니 캐스트 명령이 더 신뢰할 수 있다고 생각합니다. 그룹 브로드 캐스트 명령을 놓친 경우 재 시도되지 않습니다. 유니 캐스트 명령은 몇 번 또는 전달 될 때까지 재 시도됩니다.

저는 Home Assistant와 RESt API를 사용합니다. 홈 어시스턴트가 무엇을하는지 모르겠다 ...

tubalainen 에 2020년 03월 23일

제 경우에는 deconz 플러그인과 Phoscon이있는 iobroker입니다. 그래서 나머지 API입니다. igroup을 사용할 때 문제가 나타납니다. 그룹 씬 리콜은 특히 씬 리콜 후 최대 15 초 이내에 그룹을 끌 수 없거나 다른 그룹 씬 설정으로 빠르게 변경하거나 적절하게 끌 수 없음을 트리거합니다. deconz가 이전 명령으로 바쁘거나 2.3.x fw bulbs freeze (나는 의심 스럽습니다). 더 나은 이해를 위해 아직 zigbee 수준에서 디버깅 할 수 없습니다. deconz의 그룹화 기능은 유니 캐스트 명령으로 변환되거나 gui / zigbee에서 사용 가능한 그룹화 옵션을 통해 수행되는 가상 레이어입니까? 결론적으로 기본 제공 그룹 기능을 사용합니다. 그렇지 않으면 iobroker에서이 가상 계층을 구축해야하며 그룹화 기능이 좋기 때문에 이유가 없습니다. 그래서 이것이 그룹화라면 ... 2.3.x가 아닌 fw 1.2.x에서 100 %로 보이는 차이점은 무엇입니까? 무엇이 바뀌 었습니까? 그들이 다르게 행동하는 이유는 zigbee 2입니까?

@tubalainen 예, 수시로 다시 시작하거나 전구를 더 가까이 가져와야 할 수 있으므로 많은 작업입니다. 나는 20 e14 tradfri로 두 번했다. 당신은 엄청난 개선을 볼 수있을 것입니다. 2.3..x가 설치된 전구가 부드럽게 켜지지 않는 것을 알고 있습니까? (페이드 인) 더 이상 1.2.x는?

그러나 우리가 업그레이드해야 할 시점이 있기 때문에 ikeas fw 2.3.x가 deconz에서 작동 가능하게 될 것입니다. 또는 전구를 교체하십시오. zigbee 2도 좋지만.

여러분의 노력에 감사드립니다!

realwax 에 2020년 03월 24일

트윗 담아 가기

어제 밤 하나의 조명이 꺼지지 않았습니다 (fw 2.3.x가있는 IKEA E27). 나는 꺼지지 않은 그 빛의 밝기를 변경하기 위해 테스트했고 내가 선택한 밝기 설정으로 즉시 변경되었습니다. 밝기를 변경 한 직후에 빛이 갑자기 꺼지는 명령에도 잘 반응했습니다.

개인적으로 Home Assistant의 모든 자동화를 먼저 변경하여 밝기를 변경하고 2 초 동안 기다린 다음 끄기 명령을 보냅니다.

지금까지 100 % 성공률.

이것이 조사에 대한 단서가 될 수 있기를 바랍니다.

편집 : 항상 꺼지지 않는 조정 (Conbee 스틱)에서 가장 먼 조명입니다. (주파수 대역의 특성상 맞 물리는 조명)

tubalainen 에 2020년 03월 25일

👍1

안녕하세요 여러분!

내 문제에 대해 설명하고 싶었습니다.
ConBee II 스틱에 안정성 문제가 발생한 후 펌웨어 버전을 확인했습니다. 26530700이었습니다. 그런 다음 264a0700으로 다운 그레이드 한 후 응용 프로그램에서 스틱을 볼 수 없습니다. HomeAssistant와 deCONZ를 사용해 보았습니다. 호스트 OS는 스틱 OK를 식별하고 GCFFlasher가 작동합니다.

magnusoverli 에 2020년 03월 26일

안녕하세요 여러분!
내 문제에 대해 설명하고 싶었습니다.
ConBee II 스틱에 안정성 문제가 발생한 후 펌웨어 버전을 확인했습니다. 26530700이었습니다. 그런 다음 264a0700으로 다운 그레이드 한 후 응용 프로그램에서 스틱을 볼 수 없습니다. HomeAssistant와 deCONZ를 사용해 보았습니다. 호스트 OS는 스틱 OK를 식별하고 GCFFlasher가 작동합니다.

26490700으로 다운 그레이드 한 후 모든 것이 다시 작동하는 것 같습니다 ... 이제 24 시간 동안 안정적인 Zigbee 메쉬 ....

magnusoverli 에 2020년 03월 28일

업데이트가 있습니까? 집 전체를 Conbee II로 바꾸고 싶지만 현재로서는 매우 불안정합니다. 내 색조는 완벽하게 작동합니다. Conbee ii는별로 🥺

EGruno 에 2020년 04월 01일

👍1

RaspBee FW 0x26350500을 사용한 최신 deCONZ .75에 대한 나의 경험은 지금까지 매우 좋습니다.

내 장치 :
4xTradfri 980lu WS 조명-FW 2.3.007
17xTradfri 1000lu WS 조명-FW 2.0.023
3xTradfri 플러그-FW 2.0.022
3xTradfri 라운드 리모트 E1810-FW 2.3.014
4xAqara THP 센서

morfei1 에 2020년 04월 02일

IKEA 전구 펌웨어와 충돌하는 다른 하나를 찾았습니다. (그리고 deConz에서 고칠 수 있다고 생각합니다)

나는 오늘 아침에 하나의 빛이 반응하지 않는 것을 보았다. 마지막 통신은 다음과 같습니다.

deConz가 Group Membership Response를 수신 한 것처럼 보이지만, 어떻게 든 조명이 보낸 APS ACK (Get Group Membership Request를 승인)는 deConz에서 수신하지 않습니다 (MAC ACK도 표시되지 않음). 결과적으로 deConz는 요청을 다시 보냅니다. 이 요청은 ZCL에서 동일한 번호를 갖고있어 라이트 펌웨어가 충돌합니다.

deConz는 해당 응답이 도착하자마자 승인 된 요청을 고려하고 다른 요청을 넣는 것을 피할 수 있다고 생각합니다. 권리? 요청을 취소하기 위해 호출 할 수있는 플러그인 용 API가 있습니까? @남자 답게?

이 특정 버그는 현재 REST API 플러그인의 기본값 인 이러한 요청에 대해 APS ACK를 요청하지 않음으로써 해결 될 수도 있습니다.

No.               Time              Source            Transmit Dev      Receive Dev       Destination       Disable Default Response            Acknowledgement Request             Info
74174             2h 48m 12.832154s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2     True              True              ZCL Groups: Get Group Membership, Seq: 32
74176             2h 48m 12.841977s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                                                Route Record, Dst: 0x0000
74178             2h 48m 12.847098s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                                                Route Record, Dst: 0x0000
74180             2h 48m 12.890302s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz            True              True              ZCL Groups: Get Group Membership Response, Seq: 32
74182             2h 48m 12.896074s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74183             2h 48m 12.899402s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74184             2h 48m 12.902460s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                              False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74185             2h 48m 12.904330s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74190             2h 48m 14.186599s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2     True              True              ZCL Groups: Get Group Membership, Seq: 32
76346             2h 52m 41.998416s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       True              Link Quality Request
76354             2h 52m 43.668838s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       True              Link Quality Request
202171            7h 39m 10.905361s HK houtlamp 2     HK houtlamp 2     Broadcast         Broadcast                           False             Device Announcement, Nwk Addr: 0x05b5, Ext Addr: SiliconL_ff:fe:c5:2c:7d

djwlindenaar 에 2020년 04월 03일

지금 몇 주 동안 0x26350500으로 v2.05.75를 실행합니다. 이전 버전보다 조금 더 안정된 것 같지만 여전히 때때로 Eurotronic Spirit TRV, Fyrtur 블라인드 및 Xiaomi lumi.curtain 커튼 컨트롤러에 대한 경로를 잃어 버리고 있습니다. 후자는 라우터입니다. 나머지는 최종 장치입니다. 모든 TRV는 동일한 하드웨어 / 펌웨어 버전을 가지고 있지만 일부는 다른 것보다 MIA를 더 자주 사용합니다. 증상은 일관됩니다. 장치는 계속해서 코디네이터에게 보고서를 보내지 만 코디네이터의 명령은 응답하지 않은 _Route Request_ 만 발생시킵니다.

현재 가장 자주 누락되는 TRV의 트래픽을 스니핑하고 분석합니다. 보고서는 2 개의 Hue 조명을 사용하여 3 번의 홉으로 코디네이터에게 전달됩니다. 또한 TRV에서 첫 번째 조명까지 _Data Request_를 캡처했기 때문에 TRV는 이것이 부모라는 사실에 만족해 보입니다. OTAU 클러스터에 대한 TRV의 일치 설명자 요청은 응답되지 않습니다. 부모는 _Link Status_에서 다음 표시등을보고하지만 TRV는보고하지 않습니다 (최종 장치이기 때문입니까?).

_Link Quality Response_ 메시지는 20 개 항목의 인접 테이블을 표시하지만 TRV는 그 사이에 없습니다. (영원히 안정된) 샤오 미 도어 센서입니다. 이상하게도 코디네이터도 마찬가지지만 TRV에서 코디네이터로의 보고서는 다른 라우터 (이웃 테이블에도 있음)를 통해 중계되었습니다.
이제 코디네이터도 _Link Status_에 포함되고 TRV의 다음 보고서가 코디네이터에게 직접 전달됩니다.

TRV의 전원을 껐다가 켰습니다. TRV는 MAC _Data Request_를 (이전) 부모에게 보냅니다. 라우터는 TRV의 이전 NWK 주소를 새 주소로 전달하는 _Rejoin Response_로 응답합니다. 그런 다음 TRV는 _Device Announcement_ (부모에게 MAC 유니 캐스트, 부모는 MAC 브로드 캐스트로 전달)를 브로드 캐스트합니다. TRV는 부모에게 _End Device Timeout Request_를 보냅니다. 부모는 TRV가 안전하게 재가입되었음을 알리는 _Update Device_를 코디네이터에게 보냅니다. 부모는 이제 코디네이터의 _Route Request_에 _Route Reply_를 보냅니다. 다음 _Link Quality Response_ 시퀀스에는 TRV가 포함됩니다.

TRV가 다시 사라지는 순간을 포착하기 위해 스니퍼를 계속 실행하겠습니다.

관련 메모 : 내 innr SP120 스마트 플러그 중 하나가 여전히 Hue 버튼의 부모라고 생각하며 지원을 추가하면서 잠시 내 프로덕션 네트워크에 가입했습니다. 버튼은 이제 몇 주 동안 내 테스트 네트워크에 연결되었으며 플러그 전원을 여러 번 껐다가 켰습니다. 잃어버린 아이를 잊으려면 플러그를 공장 초기화해야합니까?

ebaauw 에 2020년 04월 04일

@manup , 코드와 무슨 일이 일어나고 있는지에 대한 정보가 모두 업데이트 된 지 오래되었습니다. 안정성 문제에 대한 팀 진행 상황과 예상 타임 라인도 감히 알려 주시면 감사하겠습니다.

osos 에 2020년 04월 05일

👍5

deConz의 라우팅 동작에서 또 다른 문제를 발견했습니다.

이 경우 deConz는 Hal lamp 에서 Tuin linksvoor 3 까지 메시지를 라우팅하려고합니다. 그러나 Tuin linksvoor 3 의 Link Status 보고서를 보면 Hal lamp 대해 알지 못합니다. 그리고 분명히 라우팅을 통해 도달하는 방법도 모릅니다. 물론 그 빛 (IKEA)은 스스로 작동하고 실패 메시지로 응답해야하지만 그렇지 않으며 변경할 수 없습니다.
그러나 deConz는 Hal lamp 가 그 빛에 대한 새로운 경로를 찾으려는 시도가없는 좀비라고 결론지었습니다. 그것이 (새) 라우팅 코드와 어떻게 상호 작용하는지 확실하지 않지만 어떻게 든 좀비로 플래그가 지정되는 것을 막을만큼 충분히 빠른 경로를 저하시키지 않았습니다. (진짜 그렇지 않습니다, 다음 참조 ...)

이로 인해 몇 분 후에 자체적으로 해결되는 일시적인 문제가 발생했습니다 (물론 완전히 받아 들일 수 없습니다). Hal lamp 가 APS ACK를받지 않고 Route Request 프로세스를 시작하는 속성 보고서를 보내기로 결정했기 때문입니다. 이 작업이 완료된 후 deConz는 경로를 Hal lamp 하고 통신이 정상적으로 재개됩니다.

조명이 deConz에 메시지를 보내기로 결정하지 않았다면 얼마나 걸렸을 지 궁금합니다. (내 네트워크에서 5 분마다 On / Off 및 레벨 클러스터에 대한 정기적 인 속성보고와 함께 IKEA 조명을 실행하고 있습니다.)

No.                Time               Source             Transmit Dev       Receive Dev        Destination        Disable Default R  Acknowledgement Request               Info
392213             13h 31m 26.050526s Tuin linksvoor 3   Tuin linksvoor 3   Broadcast          Broadcast                                                Link Status
392241             13h 31m 26.182875s DeConz             DeConz             Tuin linksvoor 3   Hal lamp           True               True               ZCL Level Control: Move to Level with OnOff, Seq: 252

Command Frame: Link Status
    Command Identifier: Link Status (0x08)
    .1.. .... = Last Frame: True
    ..1. .... = First Frame: True
    ...1 0000 = Link Status Count: 16
    Link 1
        Address: 0x0000[DeConz]
        .... .111 = Incoming Cost: 7
        .100 .... = Outgoing Cost: 4
    Link 2
        Address: 0x0118[Buiten - R schuur]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 3
        Address: 0x0143[HK stalamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 4
        Address: 0x05b5[HK houtlamp 2]
        .... .111 = Incoming Cost: 7
        .101 .... = Outgoing Cost: 5
    Link 5
        Address: 0x0ea5[Tuin linksvoor 2]
        .... .011 = Incoming Cost: 3
        .001 .... = Outgoing Cost: 1
    Link 6
        Address: 0x1ff6[Tuin linksvoor 1]
        .... .011 = Incoming Cost: 3
        .011 .... = Outgoing Cost: 3
    Link 7
        Address: 0x23ec[Tuin linksachter 1]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 8
        Address: 0x2b9e[Bijkeuken]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 9
        Address: 0x325d[0x325d]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 10
        Address: 0x6339[Tuin rechtsvoor 3]
        .... .101 = Incoming Cost: 5
        .101 .... = Outgoing Cost: 5
    Link 11
        Address: 0x68c4[WC lamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 12
        Address: 0x731e[Kerstverlichting]
        .... .111 = Incoming Cost: 7
        .000 .... = Outgoing Cost: 0
    Link 13
        Address: 0x7d2a[HK houtlamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 14
        Address: 0xc520[Badkamer ledstrip]
        .... .111 = Incoming Cost: 7
        .101 .... = Outgoing Cost: 5
    Link 15
        Address: 0xca27[Tuin rechtsvoor 2]
        .... .101 = Incoming Cost: 5
        .101 .... = Outgoing Cost: 5
    Link 16
        Address: 0xd6b7[Zolder Noord Lamp]
        .... .111 = Incoming Cost: 7
        .000 .... = Outgoing Cost: 0

djwlindenaar 에 2020년 04월 11일

🚀1

귀하의 설명은 내가 경험 한 것과 같습니다. 나는 최신 fw로 훨씬 더 나은 네트워크 (conbee 1)를 가지고 있습니다. 그러나 잠시 후 다시 반응하는 전구가 여전히 반응하지 않습니다.
홈 어시스턴트가 제공하는 추가 일반 명령이나 설정과 전구에 대한 일반적인 일정을 실행하지 않습니다. 그러나 내부 전구는 낮 동안 (켜짐 / 꺼짐 또는 밝기) 변경되어 외부 전구가 하루에 나무 시간 만 변경합니다. 때로는 응답하지 않는 전구가 매우 빨리 돌아오고 명령을 내리면 응답합니다. 드물게 발생하지만 훨씬 더 오래 걸리거나 전원을 껐다가 켜야합니다.

PeterRemnemark 에 2020년 04월 11일

@djwlindenaar 대단한 작업 다시. 대단히 감사합니다! IKEA FW에서 발견 한 버그를 IKEA와 공유하고 있습니까?

@djwlindenaar :

물론 그 빛 (IKEA)은 스스로 작동하고 실패 메시지로 응답해야하지만 그렇지 않으며 변경할 수 없습니다.

mvjt 에 2020년 04월 13일

글쎄요. 나는 그가 IKEA에 연락을 시도했다고 믿기 때문에 @manup 이 성공률에 대해 언급 할 수 있습니다.
또한 최신 펌웨어를 사용하고 있지 않습니다.

실리콘 연구소에 연락하는 것이 더 나은 아이디어가 될 것입니다. 버그의 원인이 Ember 코드인지 IKEA 사용자 지정인지 잘 모르겠습니다 ...

djwlindenaar 에 2020년 04월 13일

@djwlindenaar reddit을 통해 연락 할 수도 있습니다 : https://www.reddit.com/user/TRADFRI 그들은 꽤 활동적입니다.

@manup Conbee II 펌웨어에 대한 소식이 있습니까?

jurriaan 에 2020년 04월 13일

펌웨어를 다시 0x264a0700 다운 그레이드 한 후 Conbee II에 더 이상 연결할 수 없습니다. 0x264a0700 및 일부 정말 오래된 펌웨어로 다운 그레이드하려고 시도했지만 깜박임은 정상적으로 작동하지만 연결할 수 없습니다. Conbee II 스틱을 재설정하는 방법에 대한 조언이 있습니까?

Adminiuga 에 2020년 04월 21일

@manup 업데이트가 있습니까? deConz가 아닌 다른 것을 찾아야합니까? 아니면 문제를 해결하기위한 작업이 진행 중입니까? 삶의 신호를주세요 🤗

EGruno 에 2020년 04월 24일

테스트 펌웨어를 시도한 후 Conbee II를 다시 작동시키고 싶습니다.

Adminiuga 에 2020년 04월 24일

@djwlindenaar 당신 측에서 업데이트가 있습니까? 수정 사항으로 여전히 안정적인 네트워크입니까?

당신의 PR이 @manup에 의해 합쳐지는 것을

JBS5 에 2020년 05월 04일

👍2

@djwlindenaar 당신 측에서 업데이트가 있습니까? 수정 사항으로 여전히 안정적인 네트워크입니까?
당신의 PR이 @manup에 의해 합쳐지는 것을

@ JBS5 나는 상황에 중간 정도 만족합니다.

내 네트워크에 대해 분명히 개선되었습니다. 그러나 IKEA 조명의 버그로 인해 가끔 deCONZ가 혼란스러워집니다.

요점은 때때로 IKEA 라우터가 특정 경로에 대한 패킷을 자동으로 삭제한다는 것입니다. 이 조용한 낙하는 불법이지만 deCONZ는 새로운 경로를 찾아 대응해야하지만 그렇지 않습니다.

deCONZ 펌웨어의 변경으로 상황이 개선되는 것처럼 보이지만 이러한 상황에 대해 추가 할 사항이 여전히 있습니다. 확실히 APS ACK가 없으면 즉시 새로운 경로 찾기가 시작됩니다.

@manup 은 소스 라우팅이 문제를 해결할 수 있다고 언급

IKEA 조명의 버그는 일부 테이블이 원격 노드에 대한 모든 경로를 보유 할 수 없기 때문이라고 생각합니다. 따라서 경로를 알지 못하는 패킷을 조용히 삭제합니다.

djwlindenaar 에 2020년 05월 05일

감사합니다 @djwlindenaar.
@manup이 여기에 언급 한 것은

JBS5 에 2020년 05월 07일

이것은 펌웨어에서 발생해야하는 변경입니다. 저는 deCONZ 소속이 아니기 때문에 가능성에 대해서는 언급 할 수 없습니다 ...

@manup ?

그것은 _ 내 홈 네트워크를 위해 deCONZ에서 멀어지는 것을 고려하게 만듭니다.

djwlindenaar 에 2020년 05월 07일

👍3

@djwlindenaar , 어떤 대안을 고려하고 있습니까? 현재 Conbee II의 안정성에 깊은 인상을받지 못했습니다.

EGruno 에 2020년 05월 07일

이것은 펌웨어에서 발생해야하는 변경입니다. 저는 deCONZ 소속이 아니기 때문에 가능성에 대해서는 언급 할 수 없습니다 ...
@manup ?
그것은 _ 내 홈 네트워크를 위해 deCONZ에서 멀어지는 것을 고려하게 만듭니다.

Zigbee2MQTT가이 작업을 더 잘 수행합니까, 아니면 대안으로 의미하지 않았습니까?

lubbertkramer 에 2020년 05월 09일

네. 그게 다야.

나는 그것이 더 나은 일인지 실제로 모른다. 여기에서 사용되는 펌웨어는 칩 제조업체에서 제공합니다. 이러한 펌웨어는 오픈 소스가 아닙니다. 따라서 펌웨어 문제가있는 경우 deCONZ보다 지원이 적습니다.
반면에 이러한 펌웨어의 구성은 오픈 소스입니다. 또한 이미 소스 라우팅을 지원합니다.

djwlindenaar 에 2020년 05월 09일

Chip maker는 SDK 만 제공합니다. 그렇게하려는 경우 단순 스튜디오의 평가판 인 SDK를 다운로드하고 펌웨어를 직접 컴파일 할 수 있습니다. Z2M은 펌웨어에 대한 변경 사항 패치를 제공합니다.

Adminiuga 에 2020년 05월 09일

안녕하세요,

너무 오래 걸린 사과, AVR 펌웨어 0x26350500의 모든 라우팅 수정 사항을 포팅 한 ConBee II 용 새 펌웨어가 있습니다. 또한 장치가 조용해지지 않도록 시작 기능이 향상되었습니다. (우리는 여전히 부팅 문제를 해결하기 위해 다양한 사례를 테스트하고 있습니다).

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26580700.bin.GCF

이 버전은 다가오는 deCONZ 2.05.76 릴리스의 일부가 될 것입니다. ConBee I 및 RaspBee I 버전 0x26350500 펌웨어는 업데이트 버튼을 통해 설치 될 것입니다.

manup 에 2020년 05월 10일

👍8

감사합니다, @manup. 내 테스트 네트워크에이 버전을 설치했는데 작동하는 것 같습니다. 52 및 53 미만과 달리 최소한 장치를 제어 할 수 있습니다. 테스트 네트워크가 너무 작아이 버전이 라우팅을 개선하는지 확인할 수 없습니다.

ebaauw 에 2020년 05월 10일

@manup deCONZ는 새 펌웨어를 플래시 한 후에도 여전히 ConBee II에 연결되지 않습니다. 잠시 동안이 문제가있었습니다.

Adminiuga 에 2020년 05월 10일

@manup 몇 번 플래시를 시도했지만이 오류가 계속 발생합니다.

Flash update failed, invalid CRC. Please try again.

14:29:06:105 query bootloader v1 ID after 5 ms
14:29:06:122 RX 60 bytes ASCII
R21B18 Bootloader
Vers: 2.05
build: Mar 22 2019
, 14:55:05
 after 22 ms
14:29:06:122 bootloader start after 22 ms
R21B18 Bootloader
Vers: 2.05
build: Mar 22 2019
14:29:06:124 GCF_ResetDeviceDone
14:29:06:125 bootloader v1 update firmware
flashing 160930 bytes: |==============================|
verify: .
Flash update failed, invalid CRC. Please try again.

jurriaan 에 2020년 05월 10일

이 GCFFlasher 3.13입니까?

다음은 내 업데이트의 로그입니다.

GCFFlasher_internal -d /dev/ttyACM0 -f deCONZ_ConBeeII_0x26580700.bin.GCF 
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device /dev/ttyACM0 (ConBee II)
deCONZ firmware version 26570700
R21B18 Bootloader
Vers: 2.05
build: Mar 11 2019
flashing 160930 bytes: |==============================|
verify: .
SUCCESS
Wait 10 seconds until application starts

manup 에 2020년 05월 10일

예, 3.13이었습니다. 이제 전체 시스템을 재부팅했습니다. 이상하게도 ConBee II를 다시 연결해도 작동하지 않았지만 재부팅하면 작동합니다 ..

jurriaan 에 2020년 05월 10일

이상하게도 CRC 검사는 장치에서 직접 수행됩니다. 어떻게 이런 일이 발생할 수 있는지 궁금합니다.

manup 에 2020년 05월 10일

@manup 나는 심지어 오래된 펌웨어 (여러 버전)와 9600 전송 속도를 깜박이려고 시도했습니다. 모두 동일한 CRC 오류가 발생했습니다.

지금 작동하게되어 기쁩니다, 감사합니다! 네트워크에 즉시 연결되는 문제가있는 장치 하나를 이미 보았습니다. 그래서이 펌웨어가 몇 가지 문제를 해결할 수 있기를 바랍니다. :)

jurriaan 에 2020년 05월 10일

지금 작동하게되어 기쁩니다. 부트 로더에 대해 대학과 논의했습니다. 버전 2.05는 2019 년 ConBee II의 첫 번째 배치 (약 3500 개)에서 나 왔으며,이 버전은 경우에 따라 약간 거칠다. 2019 년 7 월부터 우리는 워치 독 처리에 대한 몇 가지 수정 사항과 함께 2.07을 출시합니다.

이미 RaspBee II의 일부인 새로운 부트 로더 3.x가 개발 중이며, 2.x 버전의 문제를 해결하기위한 더 강력한 설계 및 프로토콜이 있습니다.

현재는 GCFFlasher로 ConBee II 부트 로더를 업데이트하지 않습니다. 시작 벡터 테이블이 수정되는 순간 부트 로더 업데이트가 중단되는 경우 장치를 브릭 할 수있는 미묘한 기회가 있기 때문에이를 출시하지 않았습니다. 그러나 저는 ARM 하드 폴트 핸들러를 사용하여 이것을 알아낼 수 있다고 생각합니다. 아이디어는 부트 로더 업데이트가 실패하고 하드 오류 처리기가 트리거되면 부트 로더가 유효한지 확인할 수 있으며 실패하면 부트 로더 업데이트를 다시 시도 할 수있는 응용 프로그램으로 이동합니다. 우리는 유망 해 보이는 하드 폴트 핸들러로 몇 가지 테스트를 해봤지만 공개 할 준비가 될 때까지 시간이 좀 걸릴 것입니다.

manup 에 2020년 05월 11일

👍4

안녕하세요

오늘 새 펌웨어로 플래시했지만 여전히 다음과 같은 로그가 표시됩니다.

0x000D6FFFFE540E7C 오류 APSDE-DATA. 확인 : 작업에서 0xA7

진행 업데이트

(다음 릴리스에 대한 미리보기)

저는 소스 라우팅으로 많은 테스트를 해왔고이 문제와 다양한 스니퍼 로그의 결과를 실험했습니다. 들어오는 경로 기록 명령을 기반으로 "자동"소스 라우팅이 안정적으로 작동하도록 많은 시간을 할애하십시오. 기본적으로 zigbee2mqtt 용 소스 라우팅 펌웨어와 같이 소싱 라우팅을 사용하는 대부분의 구현이 수행하는 작업입니다. 때때로 작동하지만 경로 레코드 홉이 이웃에서 보는 LQI / RSSI 값을 기반으로 소스 경로를 선택 (및 유지)하는 방법 / 유지 여부에 대한 더 큰 역학이있는 것 같습니다. 혼합 네트워크에서는 까다 롭습니다. 스택과 하드웨어의 차이 때문입니다. 사람들이 노드 사이를 이동하고 문이 열리고 닫히는 경우 링크 품질은 매우 동적 일 수 있으며, 이는 불행히도 라우팅에도 영향을 미칩니다.

따라서 대상 노드를 향한 고정 소스 경로를 구성하는 아이디어를 실험했습니다. 대부분의 경우 네트워크의 일부에만 라우팅 문제가 있습니다. 여기서 다음과 같은 고정 소스 경로를 지정하는 것이 좋습니다.

소스 경로는 노드별로 선택적으로 지정할 수 있습니다.
모든 홉은 항상 전원이 공급되어야합니다.
경로를 통한 홉 위치는 합리적이어야합니다. 경우에 따라 사용자는 자동 알고리즘이 알아낼 수있는 것보다 패킷이 라우팅되어야하는 더 나은 계획을 가지고있을 수 있습니다.

이를 위해 펌웨어 프로토콜이 확장되어 APS 요청 당 소스 경로를 선택적으로 제공합니다. 구성 할 수있는 소스 경로의 수에는 제한이 없으며 펌웨어는 요청 및 ACK를 위해 메모리에 몇 개만 유지하면됩니다.

deCONZ는 경로의 각 홉에 도달 할 수 있는지 자동으로 파악하고이 경우에만 소스 경로를 사용합니다.
이면 소스 경로는 노드의 MAC 주소로 구성되어 NWK 주소 변경에 저항합니다.

고정 소스 경로 만들기

deCONZ GUI에서 코디네이터 (소스)에서 시작하여 대상 노드까지 CTRL (다중 선택)을 누른 상태에서 모든 홉을 선택합니다. 중요 소스와 대상 사이에 적어도 하나의 홉이 있어야합니다.
대상 노드를 마우스 오른쪽 버튼으로 클릭하여 컨텍스트 메뉴를 엽니 다.
"소스 경로 추가"를 선택합니다.

그러면 파란색 선으로 시각화 된 새 소스 경로가 생성되고 빨간색 끝은 대상 노드에 표시됩니다.

(나중 릴리스에서는 대체 대체 경로를 지정할 수 있지만 이에 대한 좋은 UI를 찾아야합니다.)

소스 경로를 제거하려면 : 대상 노드 컨텍스트 메뉴에서 "소스 경로 제거"를 선택합니다.

경로는 바로 다음 요청에 사용됩니다.

이것은 꽤 잘 작동하고 필요한 경우 라우팅을 수동으로 덮어 쓸 수 있으며 테스트에도 유용합니다.
현재 이것은 GUI를 통해 구성된 경우에만 작동하지만 나중에 REST-API를 통해 사용할 수도 있습니다.

이것이 모든 것을 고칠까요?

가능성은 낮지 만 목적지에 대한 라우팅을 개선해야합니다 (노드 자체의 라우팅은 구성 할 수 없음). 최종 장치가 상위를 변경하는 경향이 있고 소스 경로가 더 이상 작동하지 않을 수 있으므로 고정 소스 경로는 라우터에만 적합합니다.이 경우 자동 소스 라우팅이 더 잘 작동 할 수 있습니다.

언제 출시 되나요?

곧 다음 2.05.81 릴리스에서 릴리스의 할 일 목록에 다음과 같은 (약간 가벼운) 항목이 있습니다.

데이터베이스에 소스 경로를 저장 / 복원합니다.
NWK 보안 카운터 처리를 수정하여 다른 ConBee / RaspBee 간의 백업을 수정하고 아무것도 재부팅하지 않으면 버그가 작동하지 않습니다.
업데이트 후 GCFFlasher가 펌웨어가 실행 중인지 확인하도록합니다.

manup 에 2020년 09월 06일

❤10

그래서 @manup 그의 응답으로 대답이 주어졌습니다. 주제와 주제에 대해 유지하십시오.

Mimiix 에 2020년 09월 07일

안녕하세요, 문제에 대한 업데이트 시간 이상이라고 생각합니다.
진행 업데이트
(다음 릴리스에 대한 미리보기)
저는 소스 라우팅으로 많은 테스트를 해왔고이 문제와 다양한 스니퍼 로그의 결과를 실험했습니다. 들어오는 경로 기록 명령을 기반으로 "자동"소스 라우팅이 안정적으로 작동하도록 많은 시간을 할애하십시오. 기본적으로 zigbee2mqtt 용 소스 라우팅 펌웨어와 같이 소싱 라우팅을 사용하는 대부분의 구현이 수행하는 작업입니다. 때때로 작동하지만 경로 레코드 홉이 이웃에서 보는 LQI / RSSI 값을 기반으로 소스 경로를 선택 (및 유지)하는 방법 / 유지 여부에 대한 더 큰 역학이있는 것 같습니다. 혼합 네트워크에서는 까다 롭습니다. 스택과 하드웨어의 차이 때문입니다. 사람들이 노드 사이를 이동하고 문이 열리고 닫히는 경우 링크 품질은 매우 동적 일 수 있으며, 이는 불행히도 라우팅에도 영향을 미칩니다.
따라서 대상 노드를 향한 고정 소스 경로를 구성하는 아이디어를 실험했습니다. 대부분의 경우 네트워크의 일부에만 라우팅 문제가 있습니다. 여기서 다음과 같은 고정 소스 경로를 지정하는 것이 좋습니다.
소스 경로는 노드별로 선택적으로 지정할 수 있습니다.
모든 홉은 항상 전원이 공급되어야합니다.
경로를 통한 홉 위치는 합리적이어야합니다. 경우에 따라 사용자는 자동 알고리즘이 알아낼 수있는 것보다 패킷이 라우팅되어야하는 더 나은 계획을 가지고있을 수 있습니다.
이를 위해 펌웨어 프로토콜이 확장되어 APS 요청 당 소스 경로를 선택적으로 제공합니다. 구성 할 수있는 소스 경로의 수에는 제한이 없으며 펌웨어는 요청 및 ACK를 위해 메모리에 몇 개만 유지하면됩니다.
deCONZ는 경로의 각 홉에 도달 할 수 있는지 자동으로 파악하고이 경우에만 소스 경로를 사용합니다.
이면 소스 경로는 노드의 MAC 주소로 구성되어 NWK 주소 변경에 저항합니다.
고정 소스 경로 만들기
deCONZ GUI에서 코디네이터 (소스)에서 시작하여 대상 노드까지 CTRL (다중 선택)을 누른 상태에서 모든 홉을 선택합니다. 중요 소스와 대상 사이에 적어도 하나의 홉이 있어야합니다.
대상 노드를 마우스 오른쪽 버튼으로 클릭하여 컨텍스트 메뉴를 엽니 다.
"소스 경로 추가"를 선택합니다.
그러면 파란색 선으로 시각화 된 새 소스 경로가 생성되고 빨간색 끝은 대상 노드에 표시됩니다.
(나중 릴리스에서는 대체 대체 경로를 지정할 수 있지만 이에 대한 좋은 UI를 찾아야합니다.)
소스 경로를 제거하려면 : 대상 노드 컨텍스트 메뉴에서 "소스 경로 제거"를 선택합니다.
경로는 바로 다음 요청에 사용됩니다.
이것은 꽤 잘 작동하고 필요한 경우 라우팅을 수동으로 덮어 쓸 수 있으며 테스트에도 유용합니다.
현재 이것은 GUI를 통해 구성된 경우에만 작동하지만 나중에 REST-API를 통해 사용할 수도 있습니다.
이것이 모든 것을 고칠까요?
가능성은 낮지 만 목적지에 대한 라우팅을 개선해야합니다 (노드 자체의 라우팅은 구성 할 수 없음). 최종 장치가 상위를 변경하는 경향이 있고 소스 경로가 더 이상 작동하지 않을 수 있으므로 고정 소스 경로는 라우터에만 적합합니다.이 경우 자동 소스 라우팅이 더 잘 작동 할 수 있습니다.
언제 출시 되나요?
곧 다음 2.05.81 릴리스에서 릴리스의 할 일 목록에 다음과 같은 (약간 가벼운) 항목이 있습니다.
데이터베이스에 소스 경로를 저장 / 복원합니다.
NWK 보안 카운터 처리를 수정하여 다른 ConBee / RaspBee 간의 백업을 수정하고 아무것도 재부팅하지 않으면 버그가 작동하지 않습니다.
업데이트 후 GCFFlasher가 펌웨어가 실행 중인지 확인하도록합니다.

자세한 답변에 감사 드리며, 커뮤니티가이 문제를 위해 열심히 노력하고 개발자로서하고있는 모든 노력으로 인해 위와 같은 답변을 기다리고있는 것 같습니다.

내가 가지고있는 몇 가지 후속 질문 :

위의 베타 / 안정 업데이트는 언제 제공 되나요?
conbee 1/2 및 Raspbee와 관련하여 위의 작동 방식에 차이가 있습니까, 아니면 모두 동일합니까?
업데이트 2.05.81의 경우 할 일 목록에 다소 (가벼운) 항목이 있다고 언급했습니다. 언제 해당 업데이트를 기대할 수 있습니까? (아마도이 자식에 로드맵을 추가하는 아이디어일까요?)

lubbertkramer 에 2020년 09월 07일

안녕하세요 @lubbertkramer

1 번에 답할 수 있습니다. 버전 2.05.81은 월 15 일에 출시 될 것으로 예상됩니다 (Windows 빌드는 며칠 후). 나는 Discord의 초기 발표에 그것을 놓았지만 Github의 경우가 아니라고 생각했습니다. 읽어보기에 추가하겠습니다! 내 잘못이야!

편집 : readme.md 파일의 풀 요청 을 했습니까? 좀 더 명확히해야 할 안정적인 채널이 어떻게 실행되고 있는지 잘 모르겠습니다.

Mimiix 에 2020년 09월 07일

👍3

conbee 1/2 및 Raspbee와 관련하여 위의 작동 방식에 차이가 있습니까, 아니면 모두 동일합니까?

동일하게 작동해야합니다. 이제 코드를 RaspBee I / ConBee I로 이식했으며 소스 경로가 동일한 방식으로 사용됩니다.

나는 현재 IKEA 중계기 플러그가 살아 있지만 나머지 네트워크와 함께 플레이하고 싶지 않은 궁금한 경우가 있습니다.
소스 경로를 사용하거나 사용하지 않고 보내는 명령은 자동으로 무시됩니다.

repeater는 NWK 링크 상태 프레임을 보내지 만보고하고 이웃 목록을 비 웁니다.

코디네이터의 명령과 repeater가 상위 인 OSRAM 센서는 무시됩니다. 많은 Xiaomi 장치와 마찬가지로 센서는 새 부모를 자동으로 찾으려고 시도하지 않습니다. 나쁜 상황 :

이 시나리오는 지금 이틀 동안 실행되지만 repeater를 복구 할 방법을 찾지 못했습니다. 중계기의 전원을 껐다 켜면 문제가 해결 될 수 있지만 지금은 이렇게 유지하여 어떻게 든 공기를 통해 해결할 수 있는지 확인하겠습니다.

manup 에 2020년 09월 11일

👍2

Tradfri USB 중계기 또는 Tradfri 플러그에 문제가 있습니까?

morfei1 에 2020년 09월 11일

이 경우는 플러그 였는데 최신 버전인지 잘 모르겠습니다. 나중에 확인해야합니다.

manup 에 2020년 09월 11일

확인할 수 있습니까? 약 1.5 년 동안 최신 FW 록 솔리드를 실행하는 3 개의 Tradfri 플러그가 있습니다. 새 베타로 인해 문제가 생기면 업데이트를 연기해야합니다.

감사!

morfei1 에 2020년 09월 11일

다음은 기본 클러스터의 데이터입니다. 문제는 당시 새 펌웨어가 없었던 내 홈 네트워크에서 이틀 전에 처음 발생했습니다.

manup 에 2020년 09월 11일

내 플러그로 최신 FW를 사용하는 것 같습니다. Ikea의 오래된 FW 때문에 그렇게되기를 바랍니다.

최신 FW가 수정 한 내용을 확인하기 위해 tradfri 변경 로그가있는 웹 페이지가 다운되었습니다.

morfei1 에 2020년 09월 11일

최신 펌웨어 파일은 현재 온라인 상태입니다.

이들은 최대로 활성화 된 소스 라우팅을 가지고 있습니다. 32 개의 소스 경로, 가장 오래된 항목이 최신 항목으로 자동 대체됩니다. 양은 이후 릴리스에서 증가 할 가능성이 있지만 이미 잘 작동합니다.
소스 경로와 "일반"경로 항목이 있으면 소스 경로가 선호됩니다. 이것은 비표준이지만 더 잘 작동하는 것 같습니다.
펌웨어는 직렬 프로토콜 견고성을 위해 일반적으로 개선되었습니다.
ConBee II 및 RaspBee II는 전원 사이클 후 프레임 카운터가 이전 값에 다시 도달 할 때까지 네트워크가 손실 된 것처럼 보일 수있는 문제를 완화하기 위해 프레임 카운터 처리 기능을 개선했습니다.

manup 에 2020년 09월 14일

❤7 🚀3 👍2

@manup했다 ConBee I 펌웨어가 떨어 version 명령 ID 0x0D ? 이 명령에 더 이상 응답이 없습니다.

Adminiuga 에 2020년 09월 15일

@Adminiuga @manup 펌웨어

Mimiix 에 2020년 09월 15일

최신 펌웨어 파일은 현재 온라인 상태입니다.
ConBee II
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26650700.bin.GCF
RaspBee II
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_RaspBeeII_0x26650700.bin.GCF
RaspBee I 및 ConBee I
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26370500.bin.GCF
이들은 최대로 활성화 된 소스 라우팅을 가지고 있습니다. 32 개의 소스 경로, 가장 오래된 항목이 최신 항목으로 자동 대체됩니다. 양은 이후 릴리스에서 증가 할 가능성이 있지만 이미 잘 작동합니다.
소스 경로와 "일반"경로 항목이 있으면 소스 경로가 선호됩니다. 이것은 비표준이지만 더 잘 작동하는 것 같습니다.
펌웨어는 직렬 프로토콜 견고성을 위해 일반적으로 개선되었습니다.
ConBee II 및 RaspBee II는 전원 사이클 후 프레임 카운터가 이전 값에 다시 도달 할 때까지 네트워크가 손실 된 것처럼 보일 수있는 문제를 완화하기 위해 프레임 카운터 처리 기능을 개선했습니다.

이 펌웨어를 어떻게 플래시합니까 (marthoc의 deCONZ Docker 이미지를 사용합니다)?

파일 (ConBee II)을 다운로드했지만 수동 업데이트 지침은 marthoc의 deCONZ Docker 이미지에 적용되지 않으며 marthoc의 deCONZ 가이드는 이미지에 포함되지 않은 펌웨어 사용을 허용하지 않습니다 (이 파일은 나열되지 않음). 가능한 경우).

ReX1983 에 2020년 09월 18일

이 펌웨어를 어떻게 플래시합니까 (marthoc의 deCONZ Docker 이미지를 사용합니다)?

USB 동글을 Windows 랩톱에 꽂고 거기에서 연결 한 다음 완료되면 내 Synology NAS에 다시 연결합니다.

frlarsendeloitte 에 2020년 09월 19일

👍1

이 펌웨어를 어떻게 플래시합니까 (marthoc의 deCONZ Docker 이미지를 사용합니다)?
USB 동글을 Windows 랩톱에 꽂고 거기에서 연결 한 다음 완료되면 내 Synology NAS에 다시 연결합니다.

펌웨어를 플래시하는 Windows 유틸리티가 있습니까? 그렇다면 링크를 공유 할 수 있습니까?

ReX1983 에 2020년 09월 19일

이 펌웨어를 어떻게 플래시합니까 (marthoc의 deCONZ Docker 이미지를 사용합니다)?
USB 동글을 Windows 랩톱에 꽂고 거기에서 연결 한 다음 완료되면 내 Synology NAS에 다시 연결합니다.
펌웨어를 플래시하는 Windows 유틸리티가 있습니까? 그렇다면 링크를 공유 할 수 있습니까?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update -in-windows

salopette 에 2020년 09월 19일

👍1

따라서 대상 노드를 향한 고정 소스 경로를 구성하는 아이디어를 실험했습니다. 대부분의 경우 네트워크의 일부에만 라우팅 문제가 있습니다. 여기서 다음과 같은 고정 소스 경로를 지정하는 것이 좋습니다.
소스 경로는 노드별로 선택적으로 지정할 수 있습니다.
모든 홉은 항상 전원이 공급되어야합니다.
경로를 통한 홉 위치는 합리적이어야합니다. 경우에 따라 사용자는 자동 알고리즘이 알아낼 수있는 것보다 패킷이 라우팅되어야하는 더 나은 계획을 가지고있을 수 있습니다.

이것이 모든 것을 고칠까요?
가능성은 낮지 만 목적지에 대한 라우팅을 개선해야합니다 (노드 자체의 라우팅은 구성 할 수 없음). 최종 장치가 상위를 변경하는 경향이 있고 소스 경로가 더 이상 작동하지 않을 수 있으므로 고정 소스 경로는 라우터에만 적합합니다.이 경우 자동 소스 라우팅이 더 잘 작동 할 수 있습니다.

명확히하기 위해 ...이 새로운 펌웨어가 새로운 정적 소스 경로를 수동으로 구성하지 않으면 Ikea 장치의 임의 연결 끊김을 수정 (또는 적어도 개선) 할 것입니까? 아니면이 업데이트의 이점을 누릴 수있는 유일한 방법은 연결이 끊어지는 경향이있는 장치의 경로를 수동으로 설정하는 것입니까?

ReX1983 에 2020년 09월 19일

수동 설정 경로가 없으면 IKEA 장치처럼 장치가이를 홍보하면 자동 소스 라우팅이 수행됩니다.
따라서 이전 펌웨어 소스 라우팅과 비교할 때 이러한 경로가 알려진 경우 이러한 장치에 대해 라우팅이 사용됩니다.

정말 도움이된다면 이전 펌웨어에 정기적으로 문제가있는 사람이 변경된 사항이 있으면보고 할 수 있다면 좋을 것입니다.

내 테스트 네트워크에서 펌웨어는 매우 잘 작동하며 스니퍼 로그에 표시된대로 소스 경로가 자주 사용됩니다. 그것은 소스 라우팅이 없어도 네트워크가 꽤 견고했기 때문에 그다지 의미가 없습니다.

manup 에 2020년 09월 20일

나는 21 개의 조명 (4-980lu WS, 17-1000lu WS), 3 개의 플러그와 3 개의 (5 개의 버튼) Ikea의 둥근 리모컨을 가지고 있습니다. 모두 최신 Ikea FW에 있습니다. 나는 지난 약 1.5 년 동안 그들과 함께 불안정한 경험을 한 적이 없습니다. 이전 deCONZ 버전 또는 FW 릴리스 또는 현재 버전의 Nighter. 최신 RaspBee FW 0x26370500으로 안정적인 .81을 실행하고 있으며 사용 마지막 주 동안 문제가 발생하지 않습니다.

아마 .... (아마도 옳지 않을 수도 있습니다) Ikea는 일반적인 문제가 없지만 특정 설정입니다. deCONZ 및 일반적으로 그들의 행동과 성능에 영향을 미칠 수있는 다양한 요인이 있습니다.

morfei1 에 2020년 09월 21일

👍1

Ikea GU10 램프에서 대부분의 문제가 발생했다고 생각합니다. 안정성은 시간이 지남에 따라 크게 향상되었지만 2018 년 후반에 시작했을 때 엉망이었습니다. 지난 3 개월의 릴리스 / 펌웨어 동안 평균적으로 2 주마다 30 개의 GU10 중 하나의 전원을 껐다가 켜야했습니다.

peer69 에 2020년 09월 21일

👍2

Ikea GU10 램프에서 대부분의 문제가 발생했다고 생각합니다. 안정성은 시간이 지남에 따라 크게 향상되었지만 2018 년 후반에 시작했을 때 엉망이었습니다. 지난 3 개월의 릴리스 / 펌웨어 동안 평균적으로 2 주마다 30 개의 GU10 중 하나의 전원을 껐다가 켜야했습니다.

그럴 수 있습니다. 내가 아는 한 GU10은 Ikea의 다른 조명처럼 FW 업데이트를받지 못했습니다. 최근에는 Discord 채널에서 논의했습니다. GU10 Ikea 조명을 실행하는 사용자는 이러한 동작을 경험합니다. 우리가 무엇을 시도하든 그의 문제를 해결할 수있는 것은 없습니다. 그는 심지어 Ikea Tradfri Hub를 구입했으며 Ikea Hub와 GU10 light / s를 사용해도 똑같은 나쁜 경험을했습니다.

따라서 Ikea가 이러한 유형의 조명에 대한 새로운 FW를 출시하여이 문제를 해결 / 해결하는 것은 시간 문제라고 생각합니다 ....

morfei1 에 2020년 09월 21일

@djwlindenaar 가 이미 최신 deCONZ 및 펌웨어로 업데이트했으며 그의 경험을 공유 할 수 있는지 궁금합니다. :)

JBS5 에 2020년 09월 21일

😄1

사실 아직은 ... 아직 업그레이드 할 시간을 찾지 못했습니다. 또한 z2mqtt로 전환 할 시간이 없었기 때문에 좋은 소식은 새 펌웨어로 업그레이드하고보고 할 것이 있으면 그렇게 할 것입니다.

djwlindenaar 에 2020년 09월 21일

정말 도움이된다면 이전 펌웨어에 정기적으로 문제가있는 사람이 변경된 사항이 있으면보고 할 수 있다면 좋을 것입니다.

2 일 전에 최신 펌웨어로 업데이트 한 후 내 Xiaomi 벽 스위치 (ctrl_neutral2, 11-25-2017) 하나가 자체적으로 3 번 토글되었습니다. 나는 전에 그런 문제가 없었습니다.

1.3.009의 Tradfri 전구 E27 CWS를 통해 코디네이터에 연결됩니다.

또한이 문제와 엄격하게 관련되지는 않았지만 Deconz (커뮤니티 컨테이너)로 OTA 업데이트를받지 못했습니다.

Tradfri 전구가 있습니다.

1.3.009의 E27 CWS
1.2.214의 E14W
1.2.248의 무선 조광기
17 * 1.2.221의 GU10 WS

다운로드 된 Trafri OTA 파일을 볼 수 있지만 아무 일도 일어나지 않습니다. 어떻게해야합니까?

참고로 컨테이너가 시작되는 방법은 다음과 같습니다.

docker run -d --name=deconz --net=host --restart=always -v /etc/localtime:/etc/localtime:ro -v /opt/otau:/root/otau -v /opt/deconz:/root/.local/share/dresden-elektronik/deCONZ --device=/dev/ttyACM0 -e DECONZ_WEB_PORT=801 -e DECONZ_WS_PORT=445 -e DECONZ_VNC_PORT=5930 -e DECONZ_VNC_PASSWORD=... -e DECONZ_VNC_MODE=1 -e DEBUG_INFO=1 marthoc/deconz

ReX1983 에 2020년 09월 21일

@ ReX1983 여기서는이 문제와 관련이 없습니다. 별도의 문제를여십시오. Docker 버전 저장소에 게시해야한다고 생각합니다. https://github.com/marthoc/docker-deconz

Mimiix 에 2020년 09월 21일

검토 참고 :

여기에서 모든 것이 뒤섞이기 전에 여기에 범위를 설정하고 싶습니다.

원래 문제와 관련된 모든 것 : IKEA 조명이 가끔 연결이 끊어지는 것은 이번 문제에서 허용됩니다.

펌웨어와 관련된 다른 문제는 여기에 게시 할 수 있습니다

Mimiix 에 2020년 09월 21일

👍1

사실 아직은 ... 아직 업그레이드 할 시간을 찾지 못했습니다. 또한 z2mqtt로 전환 할 시간이 없었기 때문에 좋은 소식은 새 펌웨어로 업그레이드하고보고 할 것이 있으면 그렇게 할 것입니다.

@ JBS5 , 귀하의 방아쇠가 도움이되었습니다.)

방금 펌웨어와 최신 deCONZ .deb를 설치했습니다. 지금까지 소스 라우팅이 작동하는지 확인할 수 있지만 안정성에 대한 결론은 아직 없습니다. 계속 게시하겠습니다

ZigBee Network Layer Data, Dst: 0x0ea4, Src: DeConz
    Frame Control Field: 0x0608, Frame Type: Data, Discover Route: Suppress, Security, Source Route Data
    Destination: 0x0ea4[0x0ea4]
    Source: 0x0000[DeConz]
    Radius: 10
    Sequence Number: 190
    [Extended Source: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)]
    [Origin: 366]
    Source Route, Length: 2
        Relay Count: 2
        Relay Index: 1
        Relay 1: 0xc803[0xc803]
        Relay 2: 0xf1e5[0xf1e5]
    ZigBee Security Header

djwlindenaar 에 2020년 09월 21일

👍2 😄1

@ ReX1983 OTA 플러그인이 https://github.com/dresden-elektronik/deconz-ota-plugin 작동하고 장치를 업데이트하는 방법을 확인하십시오.
죄송하지만 IKEA 장치 통신 문제가 하나 있습니다.

MattWestb 에 2020년 09월 21일

트윗 담아 가기
GU10 전구 때문 만이 아니라는 것을 확인할 수 있습니다. 시스템에 GU10이없는 상태에서 오랫동안 라우팅 및 연결 끊김 문제가있었습니다.

내 conbee 1의 새 펌웨어로 .82 릴리스 후 몇 가지 초기 문제가있었습니다.
그러나 이제 네트워크 메시가 안정되고 몇 번의 전원 사이클이 지난 며칠 동안 견고 해졌습니다.

멍청한 나는 모든 전구의 최신 펌웨어 (OTAU)로 업데이트하여 미래의 문제가있을 때 시작하는 더 나은 기준을 마련하기로 결정했습니다. 행운을 빌어 요. 진행 상황에 대해 계속 알려드립니다.

tubalainen 에 2020년 09월 21일

👍2 🎉1

@tubalainen HA 애드온을 사용하고 있습니까?

morfei1 에 2020년 09월 21일

@tubalainen HA 애드온을 사용하고 있습니까?

아니요, Docker의 Debian에서 HA Core를 사용하므로 https://github.com/marthoc/docker-deconz stand-a-lone docker 패키지도 사용합니다. 둘 다 dresten에서 제공하는 .deb 파일을 사용하므로 동일하게 작동합니다. OTAU 플러그인이 deconz HA 애드온에 포함되어 있는지 잘 모르겠습니다 ....

tubalainen 에 2020년 09월 21일

👍1

지금까지 관찰 한 내용을 잘 이해했습니다.

Ikea GU-10 (23 개)에만 문제가 있으며 나머지 API를 통해 deconz (docker)에 연결하는 Home Assistant를 사용하며 HA가 이벤트를 성공적으로 deconz하는 것을 볼 수 있습니다.

HA를 사용하여 켜면 17 개의 전구가 하나씩 (서로 뒤따라) 17 개 중 3 개가 켜지지 만 HA는 켜진 것으로 인식합니다.
하지만 deconz에서 그룹을 만들면. 해당 그룹에 모든 조명을 넣고 HA에게 해당 그룹을 켜라고 지시합니다. 아직 문제가 없었으며 모든 조명이 켜집니다.

펌웨어 사용 : 0x26650700 나는 어떤 개선도 보지 못했습니다.

rest-api에 대한 제한일까요?

MartinTerp 에 2020년 09월 21일

😕1 👍1

@MartinTerp , 그룹에 1 개의 명령이 아닌 한 번에 각 장치에 대해 단일 명령을 사용하면 실패 할 것입니다. 매번은 아니지만 대부분의 경우 무언가를 수행해야하는 임의의 장치는 그렇게하지 않습니다.

이에 대한 해결 방법은 명령 간 5 초 지연입니다. 예를 들면
23:00에 bri : 127 및 ct : 454에 침실 조명을 전환하고 복도에서도 방 중 하나에 5 초 지연을줍니다. 지연을 두지 않으면 방 중 하나 또는 둘 다에 대한 전체 명령을 무작위로 완료하지 못합니다. 나는 이것을 많이 실험합니다. Ikea 버그와 비슷한 것은 스위치 색상과 밝기를 동시에 처리 할 수 없습니다.

나는 이것이 정확히 무엇인지, deconz 버그, 일반적으로 zigbee 제한 또는 Ikea FW 버그가 무엇인지 모릅니다. 아마도 zigbee가 어떻게 작동하는지에 대한 지식이 부족할 수도 있지만 5 초 지연은 항상 저에게 효과적입니다.

일반적으로 저는 항상 사용합니다 : 한 번에 가능한 한 적은 명령을 사용하거나 지연을 사용합니다. 따라서 채널을 깨끗하게 유지합니다.

한 번에 여러 그룹 / 조명을 전환해야하는 경우에는 항상 새 phoscon 그룹을 만들고 이러한 조명 그룹을 포함하고 단일 그룹 명령을 보내는 것이 좋습니다. 동일한 조명을 포함하여 여러 다른 그룹을 가질 수 있습니다. 조명 당 하나의 그룹 만 사용하는 것에 국한되지 않습니다. phoscon에 많은 그룹을 갖고 싶지 않다면 지연이 가장 좋은 친구입니다.

morfei1 에 2020년 09월 21일

👍1

@ morfei1 비슷한 해결 방법을 사용하고 있으며 대부분의 경우 모든 명령 사이에 5 초 지연이 있습니다.
@MartinTerp IKEA-Tradfri 조명 이외의 다른 장치 (예 : OSRAM 스마트 플러그 및 조명 스트립)에서도이 문제가 발생했습니다. 나는 문제가 명령을 전달하지 않는 일부 버그가 많은 Tradfri-Lights로 인해 발생했지만 가능하다고 생각합니다.

githtz 에 2020년 09월 21일

👍1

하지만 이렇다고 생각하지 않습니까?
스크립트가 1 초 지연으로 1x1을 켭니다. 처리 할 수 있을까요?

MartinTerp 에 2020년 09월 21일

😕1

트윗 담아 가기

또한 트리거 된 자동화 당 두 번 가정 비서에서 명령을 켜고 끄는 지연을 사용했습니다.

.82 이후 지연 및 반복 명령을 제거했습니다.

tubalainen 에 2020년 09월 21일

5 초 지연이 필요하지 않다고 확신합니다. 나는 이것이 이전 버전에서는 필요하지 않다고 생각하지만 그 이후로 네트워크가 성장했기 때문에 내기하지 않을 것입니다. 82 (아직 지연을 줄인 상태로 시도하지 않았 음) 또는 향후 버전이이 동작을 개선 할 것입니다.

githtz 에 2020년 09월 22일

@ morfei1 @githtz @tubalainen @martinterp

장치 펌웨어를 업데이트하는 방법에 대해 논의 할 수 있습니까?

Mimiix 에 2020년 09월 22일

👍2

펌웨어 업데이트를하지 않습니까?

MartinTerp 에 2020년 09월 22일

내가 올바르게 읽으면 모든 것이 다른 것은 아니지만 여러 명령을 보내는 문제가 있습니다. 이것은 작업 스케줄러의 문제 일 가능성이 높습니다.

"유니 캐스트 명령을 여러 조명에 보낼 때 모든 조명이 반응하는 것은 아닙니다"와 같은 별도의 문제를 여는 것이 좋습니다.

여기서 문제는 조명이 완전히 손실되고 전혀 도달 할 수없는 경우에 관한 것입니다. 이는 라우팅과 관련 될 수 있습니다.

manup 에 2020년 09월 22일

👍5

Mimiix에 의해 수정 됨

inconsx 에 2020년 09월 22일

Mimiix에 의해 수정 됨

ReX1983 에 2020년 09월 22일

@inconsx @ ReX1983 나는 https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -696541484 및 https://github.com/dresden-elektronik/deconz- 에서 명확하다고 생각했습니다. rest-plugin / issues / 1261 # issuecomment -696046160

이 규칙을 지키십시오. 원하는 경우 별도의 문제를 엽니 다.

Mimiix 에 2020년 09월 23일

그래서 여기 내 의견이 있습니다. 최신 펌웨어와 deconz api로 업그레이드했습니다. HA에서 네트워크를 실행합니다.

약 72 개의 노드가 있는데 대부분은 IKEA GU10 조명입니다. 업그레이드 후 두 개의 다른 GU10이 이틀 동안 "죽은"것을 발견했습니다. 다시 되돌릴 수있는 유일한 방법은 전원을 껐다 켜는 것입니다. GU10은 1.2.217 및 1.2.221의 고정 장치를 사용합니다. 모두 같은 버전으로 업그레이드 해 보겠습니다.

donnib 에 2020년 09월 23일

나는 단지 4 개의 GU10을 가지고 있는데, 나는 이것이 최신 ota 버전에서 실행되는 첫 번째 릴리스 버전에서 나온 것이라고 생각합니다. 도달 가능성 측면에서 문제가 없었습니다. 라이트 펌웨어 업데이트 후 내 장면이 엉망이었습니다.

manup 에 2020년 09월 23일

IKEA TRADFRI 전구 E14 W op / ch 400lm 버전 1.2.214 중 하나가 응답을 멈췄습니다. 이 램프는 여러 번 다른 deconz 펌웨어에서이 작업을 수행했습니다. 지금은 deconz 26370500과 2.05.82를 사용하고 있습니다.
Skärmavbild 2020-09-27 kl 22 35 47

cappadanna 에 2020년 09월 27일

나는 단지 4 개의 GU10을 가지고 있는데, 나는 이것이 최신 ota 버전에서 실행되는 첫 번째 릴리스 버전에서 나온 것이라고 생각합니다. 도달 가능성 측면에서 문제가 없었습니다. 라이트 펌웨어 업데이트 후 내 장면이 엉망이었습니다.

2.3.050으로 업데이트 한 후이 GU10 전구의 안정성 향상을 보셨습니까? 나는 현재 0x26650700에 있으며 2.3.050 (17 전구 중)으로 업데이트 한 이후로 네트워크가 훨씬 더 안정적인 것 같습니다. 장치가 밤새 오프라인으로 전환되지 않고 Aqara 버튼 / 스위치가 첫 번째 시도에서 작동합니다. 지금은 4 일이라 말하기가 이르다.

ReX1983 에 2020년 10월 01일

GU10이 4 개 밖에 없는데, 처음 출시 된 버전 인 것 같아요

실제로 더 저렴한 IKEA GU10 버전 (W 만 해당)이 있습니다. 2.x 소프트웨어로 업데이트되지 않았으며 여전히 1.2.214에서 실행 중입니다. 그리고 이것들은 가장 문제가있는 것들이었습니다. 저는 개인적으로 포기하고 이제는 IKEA 허브로 원활하게 작동합니다.

antonbo 에 2020년 10월 01일

@antonbo 가 문제의 과정에 가까워지고 있다고 생각합니다.
IKEA는 다른 하드웨어 (PSU / LED 드라이브)에서 동일한 펌웨어 이미지를 사용하고 있으며 다른 하드웨어에 대해 "사용자 데이터"에 다른 설정을 가지고 있습니다 (모델 ID가 저장 됨). 따라서 하나의 펌웨어는 한 하드웨어 (E14)에서 정상적으로 작동하고 다른 펌웨어 (GU10 / E27)에서는 문제가 발생할 수 있습니다.
한 가지 차이점은 IKEA GW가 ZLL 모드 (Zigbee PRO에서)에서 실행되고 장치 상태를 가져 오지 않고 장치가 네트워크에서 전송하는 상태 변경 (Zigbee PRO / ZB3 표준) 만 듣고 HUE 및 기타와 혼합한다는 것입니다. 코디네이터가 장치 (ZB3 동작이 아님)에서 상태를 가져 오는 공급 업체는 네트워크를 엉망으로 만들 수 있습니다.
나는 가장 오래된 IKEA RGBW와 하나의 E27 Opal WW를 가지고 있습니다. 내 백본은 네트워크 통신을 안정적으로 유지하는 약 10 개의 IKEA 플러그이며 내 Xioami 센서도 모두 정상적으로 작동합니다.
내 느낌은 네트워크 레이아웃과 결합하여 하드웨어 및 아마도 FW와 결합하여 하나의 일반적인 문제가 아니라는 것입니다 (패키지를 손상시키고 항상 아이들을 잃는 OSRAM Outdoor Plug와 같은).

MattWestb 에 2020년 10월 01일

@manup 내 시스템의 경우 새 펌웨어가 이전보다 훨씬 더 나 빠졌다고 말할 수 있습니다. 그것이 소스 라우팅이든 그것이 무엇이든간에 나는 이제 매일 하나 또는 두 개의 전구가 붙어 있고 전원 사이클이 필요합니다. 필립스 휴 전구 중 하나가 고착 된 것을 보았지만 전원을 껐다가 켤 필요가 없습니다. 문제가 지금 실행중인 이전 펌웨어로 인해 발생하는지 모르겠지만 문제가 발생하여 업그레이드 할 수 없습니다. :(

donnib 에 2020년 10월 06일

새로운 GU10에 여전히 문제가 있는지 또는 문제가 없는지 아는 사람이 있는지 궁금합니다. 최신 장치가 zigbee 3.0을 실행한다고 들었는데 아내가 이러한 문제에 만족하지 않아 도움이된다면 모두 변경할 수 있습니까?

donnib 에 2020년 10월 08일

👀1

나는 오늘 아침에 매달려있는 빛을 가지고 있었다. 나는 그것이 새로운 것 중 하나라고 생각합니다.

빛은 어떤 명령에도 반응하지 않고 오프라인으로 표시되었습니다. 파워 사이클로 문제가 해결되지 않았습니다. 재설정하고 네트워크에 다시 추가해야했습니다.

githtz 에 2020년 10월 08일

@ JBS5 @djwlindenaar @lubbertkramer 이 문제와 비교하여 최신 펌웨어에 대한 피드백이 있습니까?

Mimiix 에 2020년 10월 12일

48 시간 동안이 주제에서 다루는 내용과 이전에 경험 한 내용에 대한 문제가 없었 음을 추가 할 수 있습니다.

그러나 다음을 추가해야합니다.

매일 밤 deconz로 컨테이너를 다시 시작하십시오.
그룹을 가정 도우미에서 deconz / phoscon으로 이동하여 처리했습니다.

나는 더 나은 경험이지만 지금은 그렇지 않지만 위의 변경 전에 반응이 덜한 전구를 가졌습니다.

PeterRemnemark 에 2020년 10월 12일

@Mimiix , 글쎄, 말하기가 조금 이르다.

나를 괴롭히는 것은 네트워크가 훨씬 느려진다는 것입니다. 버튼을 누른 후 조명이 켜지는 시간 (규칙에 따라)은 이전보다 더 깁니다. 또한 조명을 켜고 밝기를 변경하는 것은 약간의 시간이 걸리는 2 단계 과정입니다. 이 문제의 원인을 확인하기 위해 여전히 스 니프 로그를 조사해야합니다. 아마도 이것은 소스 라우팅의 변경과 관련이 없지만 거기에 있습니다.

응답하지 않는 조명이 하나 있었지만 그 상황도 분석하지 않았기 때문에 무슨 일이 일어 났는지 말하기가 어렵습니다.

djwlindenaar 에 2020년 10월 17일

👍2

내 E27 Ikea 전구는 협력을 위해 일괄 적으로 멈췄습니다.
지금까지 파워 사이클링은 이들 중 일부에 효과적이었습니다. 3은 아직 돌아 오지 않았습니다. 다시 추가해야 할 것 같아요 ... :(

펌웨어 : 26610700
버전 : 2.05.84 / 14.9.2020
(Raspbee2)

umrath 에 2020년 10월 23일

@umrath 이 문제에서 해결 된 문제와 관련이없는 것 같습니다. 별도의 문제를여세요 :)

Mimiix 에 2020년 10월 23일

증상은 나에게 매우 똑같이 보입니다. 명백한 이유없이 램프가 반응하지 않습니다.

umrath 에 2020년 10월 23일

👍1

내가 방금 말했듯이 : 이것은 관련이없는 것 같습니다. 별도의 문제를여십시오. 나중에 항상 이것이 관련이 있는지 확인할 수 있습니다. 나는이 문제에 대해 타이트한 배를 유지한다.

Mimiix 에 2020년 10월 23일

네, 관련이 있다고 생각합니다. 버그없이 몇 달 후, 어제 두 장치, (매우 오래된) IKEA E27과 최신 IKEA 콘센트 모두 최신 펌웨어에서 문제가 다시 발생했습니다.

그 당시 내가 한 유일한 일은 KADRILJ 블라인드를 범위를 벗어난 후 다시 운반하는 것이었지만 이것은 완전히 관련이 없을 수 있습니다.

스니퍼를 발사하면 동일한 문제가 나타납니다.

장치는 여전히 주기적으로 NWK 링크 상태 명령을 보냅니다.
그러나 항상 빈 목록이 있으면 주변의 모든 라우터를 무시하는 것 같습니다.
MAC 수준에서 들어오는 명령을 ACK합니다.
그들은 비콘 요청에 반응하고 비콘을 보내지 만 이것이 그들이주는 유일한 "응답"입니다.

어떻게 든 IKEA 장치의 Zigbee 스택이 NWK 및 APS 레이어 이상에서 부분적으로 충돌하거나 들어오는 NWK 버퍼가 가득 차서 해제되지 않는 것처럼 보입니다.

다음을 전송하여 장치를 다시 활성화하려고했습니다.

재가입과 함께 ZDP 탈퇴;
NWK 탈퇴 (하위 수준).

둘 다 MAC 수준에서 ACK되지만 그렇지 않으면 무시됩니다.

그런 다음 장치가 인접 테이블에서 코디네이터를 선택하기를 바라면서 장치에 수신 및 발신 링크 비용 (3/3)이 작동 함을 나타내는 유효한 항목을 사용하여 코디네이터 NWK 링크 상태 명령을 가짜로 시도했습니다. ...도 작동하지 않았습니다.

불행히도 상황이 발생한 후 상황을 해결할 수있는 방법이없는 것 같으며 IKEA 장치는 대부분이 죽은 상태로 들어갑니다. 일부 포럼을 살펴보면 모든 종류의 게이트웨이와 기본 Zigbee 스택에서 동작을 볼 수 있습니다. 예를 들어 Hue 브리지는 이웃 테이블 쿼리 또는 바인딩 및보고와 같은 멋진 Zigbee 작업을 수행하지 않고 여전히 버그가 발생하기 때문에 흥미 롭습니다.

IKEA가해야 할 일은 적어도 NWK 및 APS 구성 요소가 여전히 작동 중인지 확인하고 장치가 워치 독을 재부팅하도록하는 Watchdog을 구현하는 것입니다. 이것은 버그를 수정하지는 않지만 적어도 그것이 발생했을 때 장치의 기능을 유지합니다.

manup 에 2020년 10월 24일

👀1 👍1

@manup 진단 클러스터가있는 오래된 E27 하나 LL입니까?
아마도 몇 주 사이에 카운터에서 뭔가가 일어나고 있는지 보는 것이 흥미로울 수 있습니다.
문제를 해결할 수는 없지만 펌웨어가 잠기지 않는 한 가지 힌트를 제공합니다.
좋은 관찰과 결론 만드 !!

나는 Silabs가 가장 큰 고객 중 한 명을 위해 더 많은 버그 사냥을하고 있다고 생각합니다 ;-)

MattWestb 에 2020년 10월 24일

안녕하세요, 몇 달 전에 ZZH를 사용하여 Z2M으로 이전 한 이후로이 문제를 보지 못했기 때문에 혼란 스럽습니다. 방정식에 다른 변수가있을 수 있습니다. 같은 행동을 한 다른 사람이 확인할 수 있다면 좋을 것입니다.

mvjt 에 2020년 10월 24일

👍1

@mvjt Z2M 또는 다른 코디네이터와 함께 Rasp / CornBee를 사용하고 있습니까?
서로 다른 지그비 스택은 서로 다른 방식으로 작동하며 서로 다른 문제를 가지고 있거나 만들 수 있습니다.

편집 : 죄송합니다. ZZH = 새로운 TI 코디네이터가 보입니다.
deCONZ NCP = Atmel / Microchip
IKEA 기기 / NCP = Sirlabs EFR32 / EZSP

HA / ZHA / Zigpy / Bellows가 "Billy EZSP"= IKEA ICC-1-A 모듈과 IKEA 및 Xiaomi의 IKEA 라우터 및 최종 장치와 코디네이터로 잘 작동하고 OSRAM 또는 Xiaomi 라우터가 없음을 확인할 수 있습니다.

MattWestb 에 2020년 10월 24일

@MattWestb 예 E27에는 진단 클러스터가 있지만 오류 상태로 유지하기 위해 아직 전원을 껐다가 껐다가

적어도 과거에 내가보고있는 문제는 TI CC253X에서도 발생했으며 문제의 마지막에는 CC26X2R1이 언급되었지만 1 월에 개선되었을 수도 있습니다. https://github.com/Koenkk/zigbee2mqtt/issues/2032#issuecomment -547483373

일반적으로 Silabs 버그가 아닐 수 있으며 응용 프로그램 계층의 일부 사용자 지정 항목 일 수도 있습니다. 최근의 Hue 기기도 Silabs를 사용한다고 생각합니다. Hue 브리지에는 최소한 TI 및 Microchip 버전이 있습니다.

정말 불쾌한 일입니다. 많은 경우 버그가 전혀 발생하지 않거나 몇 달 후에야 발생하며 다른 네트워크에서는 훨씬 더 작은 간격으로 발생합니다. 네트워크 운영 방식과 정기적으로 전원이 꺼지는 조명이 영향을 덜받는 것도 중요하다고 생각합니다.

manup 에 2020년 10월 24일

@manup "IKEA 문제"에 대해 매우 잘 전달하는 시나리오가 하나 있습니다.
네트워크를 설정 한 경우 하나의 네트워크 키로 시작되고 보안 프레임 카운터가 시작됩니다. 네트워크를 재구성하지 않거나 네트워크 키를 매우 오랫동안 롤링하지 않으면 카운터가 최대 0xFFFFFFFF (32 비트)에 도달하고 증가 할 수 없기 때문에 카운터가 정지됩니다.
그런 다음 장치는 프레임 카운터가 잘못되었지만 네트워크 아래 계층이 여전히 정상적으로 작동하기 때문에 지그비 계층으로 들어오는 모든 데이터를 던집니다.
장치의 보안 프레임 카운터의 순위를 얻는 한 가지 방법을 모르는 문제. Wireshark에서 볼 수 없다고 생각합니다 (생각 = 알지 못함).

이를 가리키는 것은 재설정되지 않은 초기 페어링 된 장치가 더 빨리 멈춘다는 것입니다.
카운터가 멈추기 전에 최신 페어링 / 리셋 된 장치가 더 오래 실행됩니다.
하나의 장치에 대한 Mutch 명령은 또한 "커뮤니케이션"이 아닌 장치보다 더 빨리 멈 춥니 다.

보안을 유지하기 위해 ZB3 네트워크에서 정기적으로 네트워크 키를 롤링 한 다음 보안 프레임 카운터를 재설정하여 중단되지 않도록하는 것이 좋습니다.
일부 정보 AN1233 : Zigbee Security 2.1.6 네트워크 보안 프레임 카운터.

하나의 거친 브레인 스토밍이지만 오랜 시간 동안 네트워크를 실행 한 후에 문제가 발생할 수 있습니다.

한 테스트는 네트워크 키를 롤링하고 "살아있는"장치가 꽤 오랫동안 정상으로 실행되고 있지만 0에서 보안 프레임 카운터를 시작하려면 지연된 장치를 재설정 / 재결합해야합니다.

MattWestb 에 2020년 10월 25일

흠, 네트워크 키를 롤링하면 모든 xiaomis가 삭제됩니다.

Adminiuga 에 2020년 10월 25일

그들이 업데이트하지 않고 네트워크를 떠나지 않는다는 잘못된 200 % 보안 (이전 ZB3 없음) !!!

@Adminiuga EZSP 에서 네트워크 키를 롤링하려고하십니까?
결과가 흥미로워 요 !!!

MattWestb 에 2020년 10월 25일

네트워크 키 롤링을 시도하지 않았습니다. 실제로 얼마나 많은 구현이 정기적으로 키를 롤링하는지 아는 것이 흥미로울 것입니다.
그러나 나는 pan-id 변화가 xiaomis가 떨어질 가능성이 매우 높다는 것을 확인할 수 있습니다.

Adminiuga 에 2020년 10월 25일

나는 거리에서 pan-ID를 스니핑하고 대규모 조명 공급 업체 (여기에 이름이 지정되지 않음)가 1 년 후에 네트워크 키를 롤링하지 않는 사이 몇 달 동안 여러 번 되돌아가는 보안 침투 테스트를 보았습니다 (Wien의 Mariahilferstraße ) 그래서 당신은 권리를 가질 가능성이 더 높습니다 (agen).

MattWestb 에 2020년 10월 25일

보안 프레임 카운터가 문제를 일으키는 경우에만 모든 실제 zigbee 3 장치에 대해 동일한 작업을 수행하는 경우 "Base-Device-Behavior-Specification"에 정의되고 이전 LL에서 권장되지만 그렇지 않을 가능성이 큽니다. zigbee PRO (이전 HA 및 LL) 장치 또는 인증되지 않은 장치 (이름 없음 .... mi).
그런 다음 1 년에 두 번 네트워크 키를 "수동"으로 롤링하는 것이 더 좋으며 입안에서 빌드를 더 많이 재설정하기 위해 집을 철거 할 필요가 없으며 일반적으로 작동하지 않는 오래된 Xiaomi 센서를 멈춰서 재설정 / 재결합합니다. 집 구조에 통합되고 재설정이 더 쉽습니다 (일반적으로 연결을 열고 버튼을 누르면 연결됩니다).
Menny "chinese Zigbee 3"는 전원 재설정 후 "이전"보안 프레임 카운터를 던지고 이웃에서 처음으로 도착한 패키지의 새 하나를 사용합니다 (그런 다음 tasmotas zigbee 3 문제를 테스트 한 다음 다시 시작할 때 NCP 카운터가 잘못 재설정 됨). 그래서 그들은 repower 일 뿐이고 그들은 다시 들어 왔습니다.

MattWestb 에 2020년 10월 26일

작년에 몇 가지 테스트를 수행했지만 게이트웨이가 네트워크 키를 교체하지 않았습니다. 사양에 설명 된대로 네트워크 키 번호를 늘릴 때 NWK 보안 프레임 카운터를 재설정하는 유일한 방법입니다. 나는 또한 이것이 모든 장치에서 지원된다는 우려를 공유하며 일반적으로 거의 사용되지 않는 기능은 제대로 테스트되지 않았습니다. 나는 여기에서 내가 틀렸기를 진정으로 희망하며 대부분의 장치에서 작동합니다.

어쨌든 프레임 카운터를 재설정하는 것은 나가는 명령, 조명 및 센서의 수가 가장 많기 때문에 게이트웨이에 가장 중요합니다. 현재 이것은 문제가되지 않지만 더 큰 네트워크에서 게이트웨이 카운터에 도달하면 2 ~ 3 년 내에 하나가됩니다. 이를 위해 이미 네트워크 키의 회전과 키 번호 및 프레임 카운터 재설정이 작동하는지 확인할 계획이 있습니다.

어쨌든 여기서 문제는 다릅니다. 게이트웨이의 프레임 카운터와 오류 상태의 표시등은 여전히 양호하고 매우 낮습니다.

manup 에 2020년 10월 26일

👀1 👍1

@djwlindenaar 제가 할 수있는 것처럼 램프가 다시 오프라인 상태가되었다고보고하는 것 외에도 검색 결과를 기술적으로 분석 할 수 있기 때문에 새로운 결과가 있는지 궁금합니다. 귀하의 발견과 통찰력은 대단히 감사합니다. :)

JBS5 에 2020년 11월 08일

감사합니다. 솔직히 말하자면 현재의 네트워크 안정성에 전적으로 만족하지 않습니다. 최신 deconz 펌웨어로 업데이트 한 이후로 다운되었습니다. 일부 조명은 지난 몇 주 동안 오프라인 상태가되었지만 업그레이드 전에 오랫동안 발생하지 않았습니다. IKEA 조명에 대한 정기적 인 속성보고를 가능하게하는 패치로 실행했지만 현재 상황에서는 아직 적용하지 않았습니다.

이것을 분석하는 것은 재미 있지만, 저에게는 취미이며, 이제는 집을 리모델링하는 데 시간이 많이 걸립니다. 시간을 좀 낼 수 있는지 볼게요 ...

djwlindenaar 에 2020년 11월 08일

👍3 👀1

감사합니다. 솔직히 말하자면 현재의 네트워크 안정성에 전적으로 만족하지 않습니다. 최신 deconz 펌웨어로 업데이트 한 이후로 다운되었습니다.

나는 똑같은 부정적인 경험을하고있다. 이제 대부분의 Xiaomi 장치 (주로 Aqara 벽 스위치)가 낮 동안 자주 오프라인 상태가되고 몇 분 후에 다시 작동합니다 (샤오 미 장치가 코디네이터의 시간 클러스터 속성).

ReX1983 에 2020년 11월 11일

새로운 v2.5.88 릴리스는 상황을 개선 할 수 있습니다. 여기서 IKEA보고 구성이 매끄러 워 져서 상태 전환이 보고서로 네트워크를 공격하지 않습니다. 이전에는 상태 전환 동안 모든 속성이 매우 빠른 속도로보고되었습니다.

manup 에 2020년 11월 13일

👍4

새로운 v2.5.88 릴리스는 상황을 개선 할 수 있습니다. 여기서 IKEA보고 구성이 매끄러 워 져서 상태 전환이 보고서로 네트워크를 공격하지 않습니다. 이전에는 상태 전환 동안 모든 속성이 매우 빠른 속도로보고되었습니다.

유망한 소리 :) 또한 켜짐 / 꺼짐은 내가 추측하는 상태 전환입니까? 아니면 대부분 밝기 또는 색상 모드 변경?
이 변경에 필요한 최소 펌웨어 버전이 있습니까 / 권장됩니까?

JBS5 에 2020년 11월 13일

밝기 및 colorX, colorY 및 색온도와 같은 모든 색상 관련 속성.
펌웨어의 경우 항상 최신 0x26660700 (ConBee II 및 RaspBee II의 경우)을 권장합니다.

manup 에 2020년 11월 13일

새로운 v2.5.88 릴리스는 상황을 개선 할 수 있습니다. 여기서 IKEA보고 구성이 매끄러 워 져서 상태 전환이 보고서로 네트워크를 공격하지 않습니다. 이전에는 상태 전환 동안 모든 속성이 매우 빠른 속도로보고되었습니다.

@manup ,이 업데이트는 Aqara 장치의 안정성 문제도 해결했다고 생각합니다. 감사

ReX1983 에 2020년 11월 14일

🎉1 👍1

새로운 v2.5.88 릴리스는 상황을 개선 할 수 있습니다. 여기서 IKEA보고 구성이 매끄러 워 져서 상태 전환이 보고서로 네트워크를 공격하지 않습니다. 이전에는 상태 전환 동안 모든 속성이 매우 빠른 속도로보고되었습니다.
@manup ,이 업데이트는 Aqara 장치의 안정성 문제도 해결했다고 생각합니다. 감사

불행히도 문제 (# 3605)는 아직 여기에 있습니다. 너무 일찍 결론에 도달했습니다.

ReX1983 에 2020년 11월 15일

Deconz-rest-plugin: IKEA 조명이 때때로 연결이 끊어짐

가장 유용한 댓글

모든 493 댓글

다른 IKEA 전구도 문제를 일으키는 것 같습니다.

진행 업데이트

고정 소스 경로 만들기

이것이 모든 것을 고칠까요?

언제 출시 되나요?

진행 업데이트

고정 소스 경로 만들기

이것이 모든 것을 고칠까요?

언제 출시 되나요?

ConBee II

RaspBee II

RaspBee I 및 ConBee I

ConBee II

RaspBee II

RaspBee I 및 ConBee I

이것이 모든 것을 고칠까요?

관련 문제