Głowice termostatyczne i termostaty ścienne - [bramka ZigBee]

[LukiSpajder]

Ver. 0.7.47
Głowica ME 167 zauważyłem że jeśli głowicę grzeje w apce pokazuje poprawnie . To po wyłączeni i włączeniu bramki w kanale termostatu w Supli ikona zmienia się że nie grzeje . Po włączeniu bramki po jakimś czasie pojawiają się pomiary temperatury z głowicy ale nie odświeży już info o tym że głowica aktualnie grzeje . Czy można jakoś odczytaj w takiej sytuacji ?

[lukasz06]

Super pomysł, fajnie, że udało Ci się ją zamontować na grzejniku

Chciałeś prezent od zająca, ale dostaniesz ode mnie

Wersja 0.7.46 zawiera testową obsługę głowicy SONOFF TRVZB:

• dodałem obsługę klastra termostat zgodnego ze standardem Zigbee - może w przyszłości dojdą nowe modele głowic zgodne z tym klastrem,
• dodałem obsługę głowicy SONOFF TRVZB - w przypadku wewnętrznego czujnika temperatury działa analogiczne jak głowice z serii TS0601,
• przewaga pojawia się, gdy wybierzemy w termostacie Supla zewnętrzny czujnik temperatury - wtedy bramka korzysta z interfejsu głowicy i wysyła temperaturę 1 - 99 st, C z precyzją 0,1 st. C przy każdej zmianie temperatury czujnika termostatu oraz co 30 minut nawet, gdy temperatura nie uległa zmianie, bo SONOFF przełącza się na wewnętrzny czujnik po 2h od ostatniego komunikatu z czujnika zewnętrznego,
• ta głowica ma jeszcze wiele innych udogodnień, ale potrzebuję na to czasu,
• przy okazji polecenie update-device-timings nr_kanału_termostatu timeout czas_w_sekundach włącza mechanizm timeoutu dla wszystkich głowic TRV - to nie jest taki sam timeout jak np. przy gniazdku - tutaj jest liczony od ostatniego rozkazu do odpowiedzi - przyznam, że nie testowałem jeszcze tej funkcji, zawsze można ją zdezaktywować poleceniem update-device-timings nr_kanału_termostatu timeout 0

@Vajera dziękuję za prezent
Znajdę trochę czasu to potestuję, jesteś Gość

[Kwicol]

Głowica pokazuje że się połączyła ale nie widoczna w w cloud,fragment logu po podłączeniu.

MOES TRV Tuya ZigBee [url][https://pl.aliexpress.com/item/10050072 ... lo2pol/url]

Twoja dostała całkowicie nowy zestaw rozkazów - będzie do przetestowania w 0.7.45.

Code: Select all

[1371581][I][z2s_device_tuya_custom_cluster.cpp:897] processTuyaCustomCluster(): TUYA_MCU_SYNC_TIME failed - no Supla channel for that device
Send: [53 55 50 4C 41 17 45 00 00 00 28 00 00 00 10 00 00 00 CA 21 06 68 00 00 00 00 7D 7A 0E 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Recv: [53 55 50 4C 41 17 46 00 00 00 32 00 00 00 10 00 00 00 AB 05 06 68 00 00 00 00 E0 E0 00 00 00 00 00 00 53 55 50 4C 41 ]
[1390197][I][Z2S_Gateway.ino:858] loop(): getZbgDeviceUnitLastSeenMs 0, current millis 1390197
[1390197][I][Z2S_Gateway.ino:858] loop(): getZbgDeviceUnitLastSeenMs 1371579, current millis 1390197
[1402444][I][ZigbeeHandlers.cpp:36] zb_action_handler(): Receive Zigbee action(0x1040) callback
[1402445][I][ZigbeeHandlers.cpp:369] zb_cmd_custom_cluster_req_handler(): Receive custom command: 36 from address 0xf446
[1402445][I][ZigbeeHandlers.cpp:371] zb_cmd_custom_cluster_req_handler(): Payload size: 2
[1402446][I][ZigbeeHandlers.cpp:373] zb_cmd_custom_cluster_req_handler(): Payload [0x0] = 0x9f
[1402446][I][ZigbeeHandlers.cpp:373] zb_cmd_custom_cluster_req_handler(): Payload [0x1] = 0x0
[1402447][I][z2s_device_tuya_custom_cluster.cpp:882] processTuyaCustomCluster(): processing Tuya custom cluster 0xEF00, command id 0x24
[1402447][I][z2s_devices_table.cpp:96] Z2S_findChannelNumberSlot(): Z2S_findChannelNumberSlot 0xa4:0xc1:0x38:0x93:0xbf:0x85:0x8a:0x46, endpoint 0x1, channel type 0xffffffff
[1402448][I][z2s_device_tuya_custom_cluster.cpp:897] processTuyaCustomCluster(): TUYA_MCU_SYNC_TIME failed - no Supla channel for that device
Send: [53 55 50 4C 41 17 46 00 00 00 28 00 00 00 10 00 00 00 E3 21 06 68 00 00 00 00 14 8A 0E 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Recv: [53 55 50 4C 41 17 47 00 00 00 32 00 00 00 10 00 00 00 C4 05 06 68 00 00 00 00 29 D3 01 00 00 00 00 00 53 55 50 4C 41 ]
Send: [53 55 50 4C 41 17 47 00 00 00 28 00 00 00 10 00 00 00 FC 21 06 68 00 00 00 00 D4 95 0E 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Recv: [53 55 50 4C 41 17 48 00 00 00 32 00 00 00 10 00 00 00 DD 05 06 68 00 00 00 00 58 A3 01 00 00 00 00 00 53 55 50 4C 41 ]
[1433297][I][ZigbeeHandlers.cpp:36] zb_action_handler(): Receive Zigbee action(0x1040) callback
[1433297][I][ZigbeeHandlers.cpp:369] zb_cmd_custom_cluster_req_handler(): Receive custom command: 36 from address 0xf446
[1433298][I][ZigbeeHandlers.cpp:371] zb_cmd_custom_cluster_req_handler(): Payload size: 2
[1433298][I][ZigbeeHandlers.cpp:373] zb_cmd_custom_cluster_req_handler(): Payload [0x0] = 0xa0
[1433299][I][ZigbeeHandlers.cpp:373] zb_cmd_custom_cluster_req_handler(): Payload [0x1] = 0x0
[1433299][I][z2s_device_tuya_custom_cluster.cpp:882] processTuyaCustomCluster(): processing Tuya custom cluster 0xEF00, command id 0x24
[1433300][I][z2s_devices_table.cpp:96] Z2S_findChannelNumberSlot(): Z2S_findChannelNumberSlot 0xa4:0xc1:0x38:0x93:0xbf:0x85:0x8a:0x46, endpoint 0x1, channel type 0xffffffff
[1433301][I][z2s_device_tuya_custom_cluster.cpp:897] processTuyaCustomCluster(): TUYA_MCU_SYNC_TIME failed - no Supla channel for that device
[1450204][I][Z2S_Gateway.ino:853] loop(): Device on endpoint(0x1), short address(0x5670), model id(0x0), cluster id(0xef00), rejoined(NO)
[1450205][I][Z2S_Gateway.ino:855] loop(): Gateway version: 0.7.47-20/04/2025
[1450205][I][Z2S_Gateway.ino:858] loop(): getZbgDeviceUnitLastSeenMs 0, current millis 1450205
[1450206][I][Z2S_Gateway.ino:853] loop(): Device on endpoint(0x1), short address(0xf446), model id(0x0), cluster id(0xef00), rejoined(YES)
[1450206][I][Z2S_Gateway.ino:855] loop(): Gateway version: 0.7.47-20/04/2025
[1450207][I][Z2S_Gateway.ino:858] loop(): getZbgDeviceUnitLastSeenMs 1433299, current millis 1450207
Send: [53 55 50 4C 41 17 48 00 00 00 28 00 00 00 10 00 00 00 15 22 06 68 00 00 00 00 89 A1 0E 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Recv: [53 55 50 4C 41 17 49 00 00 00 32 00 00 00 10 00 00 00 F6 05 06 68 00 00 00 00 33 65 01 00 00 00 00 00 53 55 50 4C 41 ]
[1464096][I][ZigbeeHandlers.cpp:36] zb_action_handler(): Receive Zigbee action(0x1040) callback
[1464097][I][ZigbeeHandlers.cpp:369] zb_cmd_custom_cluster_req_handler(): Receive custom command: 36 from address 0xf446
[1464097][I][ZigbeeHandlers.cpp:371] zb_cmd_custom_cluster_req_handler(): Payload size: 2
[1464098][I][ZigbeeHandlers.cpp:373] zb_cmd_custom_cluster_req_handler(): Payload [0x0] = 0xa1
[1464098][I][ZigbeeHandlers.cpp:373] zb_cmd_custom_cluster_req_handler(): Payload [0x1] = 0x0
[1464099][I][z2s_device_tuya_custom_cluster.cpp:882] processTuyaCustomCluster(): processing Tuya custom cluster 0xEF00, command id 0x24
[1464100][I][z2s_devices_table.cpp:96] Z2S_findChannelNumberSlot(): Z2S_findChannelNumberSlot 0xa4:0xc1:0x38:0x93:0xbf:0x85:0x8a:0x46, endpoint 0x1, channel type 0xffffffff
[1464100][I][z2s_device_tuya_custom_cluster.cpp:897] processTuyaCustomCluster(): TUYA_MCU_SYNC_TIME failed - no Supla channel for that device
Send: [53 55 50 4C 41 17 49 00 00 00 28 00 00 00 10 00 00 00 2E 22 06 68 00 00 00 00 45 AD 0E 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Recv: [53 55 50 4C 41 17 4A 00 00 00 32 00 00 00 10 00 00 00 0F 06 06 68 00 00 00 00 CE 2F 01 00 00 00 00 00 53 55 50 4C 41 ]

[Zibi_007]

Masz na myśli korektę temperatury dostępną z poziomu Cloud? Bramka nie przesyła tej wartości do głowicy.

Tak mam na myśli ustawienia w cloud (a dokładnie "Dostosowanie temperatur"). I jak najbardziej bramka przesyła je do głowicy. I robi to w pętli. Pętli śmierci Sprawdź sobie w wolnej chwili. Bo u mnie się tak dzieje na różnych głowicach z opisanym wcześniej efektem.

Czy raczej masz na myśli ręczną korektę temperatury poleceniem custom-cmd z konsoli? Sprawdzałeś, że to rzeczywiście generuje taką pętlę śmierci ? Z tego, co kojarzę to nawet po ręcznym wysłaniu korekty głowica odbierze komunikat o ustawionej korekcie I powinna to uwzględnić.

O custom-cmd bym nie pisał (ale też sprawdzę w wolnej chwili, choć ostatnio nie generowało to takiej sytuacji), bo przeciętny użytkownik nie będzie raczej grzebał tak głęboko w konsoli

Ten mechanizm, o którym piszesz, jest już w wersji 0.7.46 - tam służy do sprawdzenia czy SONOFF ma wybrany zewnętrzny czujnik temperatury.

To bardzo dobrze. Będzie go można wykorzystać do innych głowic

W SD jest/był taki objekt jak termometr oparty o link bezpośredni?

No jest. I pewnie można by było go wykorzystać, ale obsługę linków bezpośrednich musiałbyś zaszyć w kodzie bramki. Nie wiem, czy to już kiedyś robiłeś. Mam w tym odrobinę doświadczenia, ale ekspertem nie jestem. Sam poległem na Virtual GPIO przy customowym termostacie (GG nie pozwala na prawidłowe/działające) wygenerowanie takiego kodu, w końcu (za radą @krycha 88 i @robertklepacki94) oparłem go na reakcjach, ale link bezpośredni do temperatury jak najbardziej działa. W każdym razie chętnie pomogę, możemy się z tym pobawić, a to już (obsługa w zasadzie dowolnego termometru w domu) byłaby kolejna bomba!

Dokumentacja to pięta Achillesa wszystkich takich projektów, ale masz rację - muszę uzupełnić instrukcję.

Na spokojnie. Napisz mi tylko w wolnej chwili, jaką komendą mogę zmusić głowicę do wysłania info o baterii. Próbowałem z configure-reporting nr_kanału_czujnika 0x1 0x20 U8 0 30 1 i read-attribute nr_kanału_czujnika 0x1 0x20 async ale bez widocznego efektu.

[vajera]

Głowica pokazuje że się połączyła ale nie widoczna w w cloud,fragment logu po podłączeniu.

Code: Select all

 Z2S_findChannelNumberSlot(): Z2S_findChannelNumberSlot 0xa4:0xc1:0x38:0x93:0xbf:0x85:0x8a:0x46, endpoint 0x1, channel type 0xffffffff
[1464100][z2s_device_tuya_custom_cluster.cpp:897] processTuyaCustomCluster(): TUYA_MCU_SYNC_TIME failed - no Supla channel for that device
Send: [53 55 50 4C 41 17 49 00 00 00 28 00 00 00 10 00 00 00 2E 22 06 68 00 00 00 00 45 AD 0E 00 00 00 00 00

Wygląda tak, jakby się jednak nie połączyła -:parowałeś ją od nowa na czystej bramce z aktualnym kodem?

Wejdź w konsolę i sprawdź:
list-zb-devices
a później
list-devices

[vajera]

Tak mam na myśli ustawienia w cloud (a dokładnie "Dostosowanie temperatur"). I jak najbardziej bramka przesyła je do głowicy. I robi to w pętli. Pętli śmierci Sprawdź sobie w wolnej chwili. Bo u mnie się tak dzieje na różnych głowicach z opisanym wcześniej efektem.

Faktycznie może tak być bo ta korekta Supla zmienia wartość kanału temperatury...no widzisz, co ja bym bez Ciebie zrobił Mógłbyś pracować dla jakiejś megakorporacji i znajdować błędy...chyba, że pracujesz...

To bardzo dobrze. Będzie go można wykorzystać do innych głowic

Włączę ten mechanizm dla wszystkich głowic, tylko zrobię dwa tryby - {kalibracja} i {pomiar_zewnętrzny}.

No jest. I pewnie można by było go wykorzystać, ale obsługę linków bezpośrednich musiałbyś zaszyć w kodzie bramki. Nie wiem, czy to już kiedyś robiłeś. Mam w tym odrobinę doświadczenia, ale ekspertem nie jestem. Sam poległem na Virtual GPIO przy customowym termostacie (GG nie pozwala na prawidłowe/działające) wygenerowanie takiego kodu, w końcu (za radą @krycha 88 i @robertklepacki94) oparłem go na reakcjach, ale link bezpośredni do temperatury jak najbardziej działa. W każdym razie chętnie pomogę, możemy się z tym pobawić, a to już (obsługa w zasadzie dowolnego termometru w domu) byłaby kolejna bomba!

Jeden z moich pierwszych termostatów był oparty o linki zewnętrzne, wiec jakieś tam doświadczenie mam. Pytanie tylko na ile ma sens sterowanie termostatem na II piętrze termometrem z piwnicy? Chociaż jak Ciebie znam to na pewno wymyślisz jakiś dobry przykład

Na spokojnie. Napisz mi tylko w wolnej chwili, jaką komendą mogę zmusić głowicę do wysłania info o baterii. Próbowałem z configure-reporting nr_kanału_czujnika 0x1 0x20 U8 0 30 1 i read-attribute nr_kanału_czujnika 0x1 0x20 async ale bez widocznego efektu.

Tu jest problem - glowice Tuya działają na klastrze 0xEF00 i chyba nikt do tej pory nie znalazł sposóbu żeby zmusić je do przesłania czegokolwiek na życzenie
Głowica zechce to głowica wyśle...w teorii jest taka komenda custom-cmd nr_kanału_termostatu 0xEF00 3 0 00, po której urządzenia z klastrem 0xEF00 powinny wysłać komplet danych, ale u mnie to raz działa a raz nie...
Napisz, który model jest taki oporny.

[vajera]

Ver. 0.7.47
Głowica ME 167 zauważyłem że jeśli głowicę grzeje w apce pokazuje poprawnie . To po wyłączeni i włączeniu bramki w kanale termostatu w Supli ikona zmienia się że nie grzeje . Po włączeniu bramki po jakimś czasie pojawiają się pomiary temperatury z głowicy ale nie odświeży już info o tym że głowica aktualnie grzeje . Czy można jakoś odczytaj w takiej sytuacji ?

Glowica wysyła parametr running state = {idle, heat} przy zmianie tego stanu...i tylko przy zmianie. Nie ma niestety prostego sposobu żeby zmusić ją do wysłania jakichkolwiek danych na życzenie - zobacz mój post powyżej - odpowiedź na pytanie Zbyszka o baterię.

Można rozważyć protezę: jeżeli {HeatingSetpoint} > {Current Temperature} to głowica grzeje, ale to nie będzie odzwierciedlać rzeczywistego stanu głowicy.

[lukasz06]

@Vajera mam pytanie, może 2
W tej głowicy sonoff pomiar jest od 4 stopni. Jeśli tak ustawimy, to w suplowym termostacie mamy off. Można to zmienić jakoś?
Tak samo w apce jest 40 stopni max, a na wyświetlaczu 35. Czy to oznacza, że teoretycznie termostat będzie grzał do 40, czy 35?
Edit: U mnie głowica nie pokazuje przeskoku co 0,1 stopnia tylko 0,5, a pisałeś, że od 1-99, coś nie zrozumiałem

[Zibi_007]

Faktycznie może tak być bo ta korekta Supla zmienia wartość kanału temperatury...no widzisz, co ja bym bez Ciebie zrobił Mógłbyś pracować dla jakiejś megakorporacji i znajdować błędy...chyba, że pracujesz...

Nie, nie pracuję. Zawodowo robię coś dalece innego, to tylko hobby

Włączę ten mechanizm dla wszystkich głowic, tylko zrobię dwa tryby - {kalibracja} i {pomiar_zewnętrzny}.

Super!

Jeden z moich pierwszych termostatów był oparty o linki zewnętrzne, wiec jakieś tam doświadczenie mam. Pytanie tylko na ile ma sens sterowanie termostatem na II piętrze termometrem z piwnicy? Chociaż jak Ciebie znam to na pewno wymyślisz jakiś dobry przykład

Może nie z II piętra w piwnicy, ale.. sam musiałem wczoraj na nowo "przepinać" jeden termometr do innej bramki, aby go powiązać z termostatem. Ktoś powie, że to chwila. Może i tak, ale później trzeba go usunąć z tej pierwszej, albo ukryć, a tu już może się zrobić mały bałagan. Kolejna rzecz, która może być dla kogoś istotna. Wybierając sobie jakiś czujnik (temp. i wilg.) jako termometr zewnętrzny "pozbywamy" się go niejako z Supli. Jest on wtedy widoczny pod termostatem, a żeby sprawdzić wilgotność to już musimy w ten termostat kliknąć. Używając termometru wirtualnego zawsze w Supli będziemy widzieć ten oryginalny (tak jak dotychczas).

Tu jest problem - glowice Tuya działają na klastrze 0xEF00 i chyba nikt do tej pory nie znalazł sposóbu żeby zmusić je do przesłania czegokolwiek na życzenie
Głowica zechce to głowica wyśle...w teorii jest taka komenda custom-cmd nr_kanału_termostatu 0xEF00 3 0 00, po której urządzenia z klastrem 0xEF00 powinny wysłać komplet danych, ale u mnie to raz działa a raz nie...
Napisz, który model jest taki oporny.

W obecnej wersji softu (0.7.46) bateria nie pokazuje mi się na żadnym kanale. A sparowałem wczoraj pięć głowic (dwie ME i trzy HY). A próbowałem już chyba wszystkiego. Łącznie z resetem głowic, bramki, kilkukrotnym parowaniem itd. Wiem, że ta HY pod Tuyą raportowała raz przy parowaniu, a później dopiero jak baterie były na wykończeniu. Mam jeszcze jeden pomysł, aby sprowokować raportowanie stanu baterii. Muszę znaleźć tylko jakieś zużyte i zobaczymy, czy coś to da. Z Twojej komendy dostaję takie coś, jak poniżej, nie wiem co powinna odpowiedzieć głowica, ale chyba przynajmniej wyświetlić swój numer... Próbowałem na dwóch różnych (u mnie są na kanale 9 i 14).

Code: Select all

custom-cmd 9 0xEF00 3 0 00
custom-cmd channel cluster command data_type data_size value
custom-cmd 14 0xEF00 3 0 00
custom-cmd channel cluster command data_type data_size value

[Zibi_007]

Ver. 0.7.47
Głowica ME 167 zauważyłem że jeśli głowicę grzeje w apce pokazuje poprawnie . To po wyłączeni i włączeniu bramki w kanale termostatu w Supli ikona zmienia się że nie grzeje . Po włączeniu bramki po jakimś czasie pojawiają się pomiary temperatury z głowicy ale nie odświeży już info o tym że głowica aktualnie grzeje . Czy można jakoś odczytaj w takiej sytuacji ?

Glowica wysyła parametr running state = {idle, heat} przy zmianie tego stanu...i tylko przy zmianie. Nie ma niestety prostego sposobu żeby zmusić ją do wysłania jakichkolwiek danych na życzenie - zobacz mój post powyżej - odpowiedź na pytanie Zbyszka o baterię.

Można rozważyć protezę: jeżeli {HeatingSetpoint} > {Current Temperature} to głowica grzeje, ale to nie będzie odzwierciedlać rzeczywistego stanu głowicy.

Też to zauważyłem, ale wiedziałem z czego to wynika i to jest tylko kwestia ikonki. Ważne, że wszystko działa. Na szybko można zrobić off i włączyć ponownie. Powinno pomóc. Ten problem jest szerszy i nie dotyczy tylko głowic. Pod Tuyą jest dokładnie to samo. Jak głowica "wypadnie" z bramki Zigbee, to możesz i przez kilka (kilkanaście) godzin nie mieć o tym informacji, a jak wróci, to też nie widać co w danej chwili tak naprawdę robi. Taka ciekawostka. Wczoraj przepisałem trzy głowice do bramki na C6. Wg SmartLife dalej je mam pod bramką Zigbee, a w jednej mogę nawet zmieniać nastawy (oczywiście zmieniają się tylko w apce).
Rozwiązanie wydaje się być stosunkowo proste, ale musiałoby leżeć po stronie producenta głowic. Wystarczyłoby zrobić warunek, że po utracie połączenia z bramką i ponownym jego nawiązaniu głowica wysyła komplet swoich danych (wszystko co ma). Wtedy po stronie softu bramki wiadomo już co się stało i co trzeba z tym zrobić. Robiłem kiedyś podobny projekt (oparty o transmisje radiową na duże odległości) i tak to właśnie działało...