Deconz-rest-plugin: Elko 온도 조절기가 바닥 센서의 온도를 표시하도록 하세요.

상태/작업도 누락되었습니다. 홈 어시스턴트는 항상 꺼져 있다고 말합니다.

@olekenneth 같은 문제가 있습니다. 당신은 API를 사용하고 있습니까? 광산은 HA에 방금 나타났지만 잠시 후 사라졌습니다. 그런 다음 VNC에 들어가야하고 다시 나타납니다....

여기에 2개의 도전 과제가 있기 때문에 깨닫는 데 약간의 시간이 걸릴 수 있습니다. 하나는 API의 확장이고, 다른 하나는 동일한 ID를 가진 제조업체별 속성이 둘 이상 있는 경우 deconz가 현재 오작동하는 경우입니다. 먼저 오는 것이 우선권을 갖습니다(그렇지 않아야 함).

읽을 속성만 있으면 되겠죠?

네 맞습니다. 온도 조절기는 공기 또는 바닥 센서를 기반으로 난방으로 설정됩니다. 이것을 읽을 수 있다면 현재 상태를 제대로 읽을 수 있습니다. 어떤 센서를 선택하든 타겟 설정은 작동합니다.

이 장치에는 많은 공급업체별 속성이 있습니다. smartthings 앱 개발자가 여기에 나열했습니다.
https://github.com/nilskaa/Smartthings/blob/master/devicetypes/Elko%20Super%20Thermostat%20-%20vendor%20specific%20attributes.txt

이러한 속성이 가장 중요하며 구현되어야 한다고 생각합니다.
0x403 ( 인코딩:30 , 값:
0x409( 인코딩:29 값:
0x415(부동 인코딩:10 , 값:00=유휴 01=난방

이 문제는 최근 활동이 없었기 때문에 자동으로 오래된 것으로 표시되었습니다. 더 이상 활동이 없으면 폐쇄됩니다. 귀하의 기여에 감사드립니다.

이 문제를 계속 공개하고 싶습니다. 아직도 많이 원합니다!

이 문제를 계속 공개하고 싶습니다. 아직도 많이 원합니다!

나는 더 동의할 수 없었다. 문제가 해결될 때까지 이 문제를 열어 두십시오.

이것을 살려주세요.
이것은 우리에게 필요한 것입니다 👍

@SwoopX 이게 추가되나요?

아니요, 제가 설명했듯이 이것은 약간 복잡합니다. 클러스터가 general.xml에 추가되었으며 기본적으로 사용 가능합니다. 그러나 이것은 현재 온도 조절기 클러스터에 대한 다른 모든 제조업체별 속성 위에 Elko 특정 속성을 수동으로 배치하는 경우에만 작동합니다.

필요한 곳에서 API 확장이 아직 열려 있습니다...

나는 이것을 열어두기 위해 이미 백로그 라벨을 붙였습니다.

general.xml에서 Elko 제조사별 속성을 이동하고 deCONZ 서비스를 다시 시작했습니다.

속성이 deCONZ에서 모두 회색이므로 속성을 읽을 수 없습니다. 누구든지 ELKO 특정 속성을 읽는 데 성공합니까? 특히 "난방 활성/비활성" 속성에 관심이 있습니다.

https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3123#issuecomment -670978296의 텍스트 파일에 따르면 속성은 예를 들어 0x403이고 general.xml에서는 0x4003에 추가되었습니다. 이것은 의도에 의한 것입니까?/ 맞습니까?

마지막으로 최신 general.xml을 수정하여 deCONZ가 ELKO 특정 속성을 읽도록 했습니다.

1. 이 문제의 추가 리소스에 지정된 대로 속성을 0x400x에서 0x040x로 변경합니다. 4000 시리즈 속성이 아니므로 더 위로 이동할 필요도 없습니다.
2. 각 _attribute_에서 mfcode="0x1002"를 제거했지만 속성 집합에는 유지했습니다. 그렇게하지 않고 deCONZ는 "지원되지 않는 속성"으로 응답했습니다.

난방 상태에 대한 풀 요청을 했습니다: https://github.com/dresden-elektronik/deconz-rest-plugin/pull/3311.

공기 센서를 사용하는지 바닥 센서를 사용하는지 여부에 따라 일부 논리를 확인해야 하므로 바닥 센서를 포함하지 않았습니다.

흠, 제조사별 속성이 0x4000부터 시작하고 그 이전의 속성이 표준화되어 있기 때문에 공급업체가 사양을 더 엄격하게 준수했으면 합니다(또는 최소한 그렇게 되어야 함)...

PR을 올려주셔서 감사합니다. 하지만 아직 내 브랜치로 푸시되지 않은 장치에 대해 더 많은 변경 사항을 준비했습니다. 내가 당신의 속성 보고를 인계받는 동안 PR을 닫아도 될까요?

물론, PR을 올리는 것이 변경 사항을 공유하는 가장 쉬운 방법이라고 생각했습니다!

알겠습니다. 거의 다 된 것 같습니다. 그러나 0x0415를 on 상태로 매핑해야 하는지 궁금합니다. 내가 보기에 이 속성은 장치가 현재 가열되고 있는지 여부를 나타내므로 heating 상태를 호출하는 것이 더 적절할 것입니다. 또한 0x0406(장치 켜짐)이 있는데 이 특정 경우에 state: on 에 더 적합할 수 있습니다.

어떻게 생각하나요?

0x0403을 상태로 보고해야 하는지도 잘 모르겠습니다. 주어진 상황에 따라 구성해야 할 것 같습니다.

나는 당신의 제안이 훨씬 낫다고 생각합니다. 발열 특성을 몰랐습니다.

나는 0x0406 속성을 확인했고 그것은 온도 조절기를 껐다 켤 때 사용할 수 있습니다.

이 특정 github 문제는 바닥 센서 측정을 포함하는 것입니다. 바닥 센서가 없습니다. 나는 공기 센서를 사용하고 온도는 이미 나머지 API에서 사용할 수 있습니다. 바닥 센서가 활성화된 경우(0x0403 = 1), 속성 0x409가 로컬 온도 측정을 대체할 수 있습니까? 바닥 센서를 사용하는 사람들은 여기에 의견이 있어야한다고 생각합니다.

API에 추가 속성을 추가하는 것이 얼마나 쉬운가요? 어쩌면 바닥 센서 온도를 추가 속성으로 포함하는 것이 더 쉬울까요? 이 맥락에서 나는 또한 0x0408을 평균 전력 소비로 포함할 것을 제안할 것입니다.

나는 또한 0x0406이 켜짐/꺼짐에 매핑되어야 하고 0x0415가 난방/유휴에 매핑되어야 한다는 데 동의합니다.

0x0408 속성은 직접적으로 전력 소모가 아니라 지난 10분 동안 "가열" 상태(0x0415)에서 보낸 시간이라고 생각합니다. 0에서 2000 사이의 숫자로 보이며 10분마다 변경됩니다. 따라서 지난 10분 간격으로 온도 조절기가 5분 동안 켜져(난방) 있었다면 이 속성은 1000이 됩니다. 그러면 난방 상태에서 보낸 시간은 (1000 / 2000) * 600초가 되며 소비 전력은 다음을 기반으로 계산할 수 있습니다. 히팅 케이블의 kW 등급.

지금까지 피드백에 감사드립니다. 이제 매핑된 장치 켜기/끄기 -> state 및 난방 켜기/끄기 -> heating 있습니다. 나는 온도가 실제로 측정되는 위치(공기 또는 바닥)에 따라 온도를 "재사용"한다는 아이디어를 매우 좋아합니다. 그러나 이것이 두 값을 모두 사용할 수 없는 문제를 일으키지 않기를 바랍니다...

그런 다음 아직 보류 중인 것은 API를 통해 구성 가능한 0x0403을 통한 온도 감지를 만드는 것입니다. 이를 위해 설정 가능한 값이 이 장치에 대해 고유하지만 mode 를 재사용하는 것을 선호합니다.

@arnerek API에 추가하기 위해 얼마나 많은 노력을 기울이는지 속성에 따라 다릅니다.

장치에는 공기 또는 바닥 센서 중에서 선택할 수 있는 LCD 화면이 있습니다. 나는 이것이 당신이 한 번 하는 일이라고 예상하지만 물론 나머지 API를 통해 구성할 수 있는 가능성이 있다는 것은 좋은 일입니다.

예를 들어 모드: 열, 바닥 센서 및 모드: 열, 공기 센서 또는 이와 유사한 것을 사용하는 것이 좋습니다. 예를 들어 HA 통합에 어떤 영향을 미칩니까?

어떤 사람들은 두 가지 측정을 모두 원할 수도 있습니다. 내가 말했듯이, 나는 공기 센서만 가지고 있으므로 필요한 측정값을 이미 가지고 있습니다.

예를 들어 모드: 열, 바닥 센서 및 모드: 열, 공기 센서 또는 이와 유사한 것을 사용하는 것이 좋습니다. 예를 들어 HA 통합에 어떤 영향을 미칩니까?

좀. 모드: air sensor, floor sensor or floor protection 입니다. 나는 그것에 대한 적절한 이름이 부족합니다. 아마도 temperaturemeasurement 라고 부르겠습니까?
여기에서 "전형적인" 지그비 값을 기대하는지 알 수 없기 때문에 이것이 HA에 영향을 미칠 것인지에 대한 단서가 없습니다.

API를 통해 0x0409와 0x0000의 온도 측정을 모두 보고할 수 있습니까?

내가 이해하는 한 온도 상태는 0x0403의 값에 따라 달라집니다. 02이면 온도 측정값은 0x0409부터 시작해야 하고, 01 또는 03이면 속성 0x0000에서 측정해야 합니다. 그래도 api를 통해 두 온도 측정을 모두 사용할 수 있기를 바랍니다.

예, 두 온도 값을 모두 가질 수도 있습니다. 따라서 air는 temperature 이고 floor는 floortemperature 됩니다. 더 안전한 변종인 것 같습니다.

엄청난! 다음편도 기대해주세요👍

여기에 수정 사항이 포함된 풀 요청이 있습니다.
https://github.com/dresden-elektronik/deconz-rest-plugin/blob/2baf9573f18035fc182fa67fa8c4662e2fa50bd2/general.xml

위에서 언급한 풀 리퀘스트가 보통 매월 15일, 즉 이틀 후에 출시되는 deconz의 베타 릴리스에 포함되기를 바랍니다!

@arnerek 내가 볼 수 있는 한 "ELKO 특정 온도 조절 장치 속성"( #3213 )이라는 섹션이 deCONZ 2.05.84에 추가되었지만 여전히 이러한 모든 속성은 0201 온도 조절 장치 클러스터에서 회색으로 표시됩니다.
내가 뭔가를 놓치고 있습니까?

예, 추가된 Elko 속성은 올바르지 않은(0x4000) 반면 pull 요청의 general.xml은 올바른(0x0400) 속성을 사용합니다.

물론! general.xml을 pull 요청의 것으로 교체하면 차이가 생겼습니다. 이제 몇 가지 추가 속성을 볼 수 있습니다. 하지만 그럼? HA가 공기 온도가 아닌 바닥 온도를 표시하도록 하려면 어떻게 해야 합니까?

디버깅을 좀 더 했습니다. 추가 속성은 RestAPI에서 끝나지 않았습니다. 내가 thermostat.cpp이 시험에 아래로 추적 : https://github.com/dresden-elektronik/deconz-rest-plugin/blob/5d8aa096242dd69977ccf105cc22c3f816644a31/thermostat.cpp#L600

zclFrame.manufacturerCode() == VENDOR_EMBER

이것은 어떤 이유로 사실이 아닙니다. Elko 속성 "floortemperature", "heating" 및 "on" 상태 속성에 대해 이를 제거하면 API에서 올바르게 보고됩니다.

@SwoopX

멋진 작품 @arnerek !! 귀하의 발견을 어떻게 구현할 수 있습니까? 15일 새 PR이 나올 때까지 기다려야 하나요?

열심히 하는 @SwoopX 입니다. 정말 감사합니다!

이제 다음과 같은 문제가 남아 있습니다.
1) "on", "locked"의 구성은 아무 것도 하지 않습니다. Rest API의 config 섹션은 변경되지만 장치는 변경되지 않으며 "state"("on" 속성)도 변경되지 않습니다.
2) "mode" 속성이 보이지 않습니다. 있어야 하는지 잘 모르겠습니다.

{
"구성": {
"열 설정점": 500,
"잠김": 사실,
"오프셋": 0,
"켜기": 참,
"도달 가능한": 사실,
"일정": {},
"schedule_on": null,
"온도 측정": null
},
"엡": 1,
"etag": "8a4a56e949ae694ace65cd58ceb2d17e",
"마지막으로 본": "2020-10-29T20:28Z",
"제조업체 이름": "ELKO",
"modelid": "슈퍼 TR",
"이름": "슈퍼 TR",
"상태": {
"바닥 온도": -9990,
"난방": 거짓,
"최종 업데이트": "2020-10-29T20:28:04.875",
"켜기": 참,
"온도": 1840
},
"유형": "ZHA온도 조절 장치",
"고유 ID": "00:0d:6f:00:15:55:29:4f-01-0201"
}

나는 더 발전했다:
1) "잠김" 구성이 이제 작동합니다. 속성 ID는 https://github.com/dresden-elektronik/deconz-rest-plugin/blob/5d8aa096242dd69977ccf105cc22c3f816644a31/thermostat.cpp#L668 및 https: //dresgithub.cpp#L668에서 0x0413이어야 합니다.

"on" 속성이 여전히 작동하지 않습니다...

마지막 커밋에서 했던 것처럼 모든 4개 또는 5개의 Super TR 속성에 대해 https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3123#issuecomment -718922994에서 수행한 작업을 제거하십시오.

로컬에서 하위 잠금에 대한 속성 변경을 이미 준비했습니다.

감사 해요. 이미 모든 Elko 속성에 대한 검사를 제거했지만 문제가 해결되지 않았습니다.

나는 오늘 저녁에 더 많은 디버깅을 계속할 것입니다. "config" 섹션에 "mode"가 표시되어야 합니까? 로그에서 이 속성에 대한 보고를 확인했으며 문자열도 올바르게 설정되었습니다.

"config"/"on" 속성에 대한 PUT 요청으로 ZclWriteAttribute의 로그가 표시되지 않습니다. 어린이 잠금의 경우 API가 해당 기능을 입력하고 어린이 잠금을 올바르게 설정합니다.

그것이 "모드" temperaturemeasurement , 그렇지 않습니까?

온/오프에 관해서는 살펴보겠습니다. "평소" 동작을 변경했습니다.

나는 시스템 모드에 생각했다 : 특성 0x001C https://github.com/dresden-elektronik/deconz-rest-plugin/blob/5d8aa096242dd69977ccf105cc22c3f816644a31/thermostat.cpp#L13

저건 노출이 안되네요 🤷‍♂️ 그럼 갖고싶은거겠죠?

알았어 고마워. 나는 그것이 모든 온도 조절기에 있어야 한다고 생각했지만 나에게는 중요하지 않습니다. 어쩌면 Home Assistant / 다른 통합이 이것에 의존합니까?

남아 있는 유일한 문제는 "config"/"on" 요청입니다. 그렇지 않으면 장치가 지금 완벽하게 작동합니다.

글쎄, "모드"는 거의 당신에게 달려 있습니다. 쓸만하고 갖고싶다고 하면 별거아닌데...

Btw, "켜기/끄기"는 구성을 통해 작동하지 않으므로 무시할 수 있습니다. 상태가 되지만 그것도 될지는 잘 모르겠습니다.

다른 온도 조절 장치와 호환되도록 노출될 수 있습니까? 보고는 이미 시행 중이며 작동 중입니다.

우리는 일반적으로 온도 조절기의 작동 기능을 공개합니다. 예를 들어 Danfoss의 경우 모드 속성이 있지만 작동하지 않으므로 노출되지 않습니다. 불행히도 온도와 열점 노출을 제외하고는 그런 의미에서 온도 조절기에 대한 "표준"이 없습니다.

그렇다면 노출하지 않는 것이 합리적이라고 생각합니다. 이 온도 조절기는 켜기/끄기 기능만 있으며 "구성"/"켜기"가 작동하면 모든 것이 정상입니다!

편집: 이전 게시물에서 귀하의 편집을 확인했습니다. "config"/"on"이 작동하지 않는 경우 온도 조절기를 켜고 끄는 가장 좋은 방법은 무엇입니까? "시스템 모드"를 사용할 수 있습니까?

몰라, 그게 당신이 알아야 할 것입니다. 한편, state/on으로 이것이 가능하고 우리가 원하는지 확인하겠습니다.

네, 오늘 저녁에 확인하겠습니다. 나는 당신이 옳다고 생각합니다. 즉, 장치가 시스템 모드를 끄더라도 "자동"으로 유지됩니다. 오늘 나중에 확인하겠습니다.

Deconz Home Assistant 통합은 모드 매개변수를 사용하여 장치를 켜고 끕니다.
pydeconz.errors.RequestError: /sensors/49/config/mode 매개변수, 모드, 사용할 수 없음

@arnerek , DM을 보낼 수 있습니까?

나는 몇 가지 더 테스트했습니다. 장치가 꺼져도 시스템 모드는 변경되지 않습니다. Deconz Home Assistant는 "mode" 매개변수에 의존하므로 속성 0x0406(Device on)이 "on" 및 "mode"("heat" / "off" 포함) 모두에 매핑됨을 제안합니다.

감사 해요. 이제 변경을 수행하기 전에 다른 방법으로 어떻게 보입니까? 따라서 0x001C를 off 및 heat 로 설정하면 온도 조절기 클러스터의 속성 0x0406이 변경됩니까?

config/mode 가 노출되지 않았지만 코드에서 필요한 다른 모든 준비를 사용할 수 있음을 확인했습니다.

나는 그것을 시도했지만 deconz에서 값을 변경할 수 없습니다. 속성을 읽은 후 deconz의 열거 목록이 비활성화됩니다.

Deconz를 사용하여 0x001C 속성을 변경할 수는 없지만 수정된 Rest API를 사용하여 속성을 변경할 수 있습니다(Deconz의 판독값으로 다시 확인됨).

그것은 당신이 가정 한 것입니다. 속성 0x001C는 장치에서 단순히 무시됩니다. 0x00과 0x01을 시도했지만 변경 사항이 없습니다. 0x0406이 "mode" 매개변수에 매핑되어야 한다고 말하는 것이 안전하다고 생각합니다.

하지만 0x0406을 설정하면 온도 조절 장치가 켜지거나 꺼지나요?

mode 가 장치에 대해 노출되고 이전 수정 사항이 포함된 내 지점으로 시도해 볼 수 있습니다.

git clone --branch enhancements https://github.com/SwoopX/deconz-rest-plugin.git enhancements

예, 0x0406을 설정하면 온도 조절기가 켜지거나 꺼집니다.

Deconz로 이것을 변경할 수 없었기 때문에 실제로 0x001C 속성을 테스트하기 위해 이미 귀하의 분기를 시도했습니다. 테스트 목적으로 "Super TR"을 여기에 포함했습니다. https://github.com/dresden-elektronik/deconz-rest-plugin/blob/b059f4baf87338df0000daba4706700425a3cad4/rest_sensors.cpp#L1229

좋아, 그럼. 추가 테스트를 위해 코드를 업데이트할 수 있는지 확인하겠습니다. 준비되면 알려드립니다.

@arnerek 코드가 준비

@SwoopX 잘 작동합니다! 이것을 구현하는 훌륭한 작업에 감사드립니다 👍

방금 이것을 발견했습니다. https://github.com/SwoopX/deconz-rest-plugin/blob/c3ce518b176b9103fb3ff322bd47615999c09cfc/thermostat.cpp#L479 보고가 제거되었으므로 제거해야 합니까?

해를 끼치면 안되지만 예, 아마도 더 좋을 것입니다. 완료.

아무런 해가 없지만 모드 매개변수는 5분마다 자동과 가열 사이에서 변경되므로 불필요합니다. 감사 해요!

fubar 보고하는 것 같군요 😂

여러분은 영웅입니다 @SwoopX 와 @arnerek ! 훌륭한 작업에 감사드립니다. 테스트할 수 있기를 기대합니다. :D