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

[klew]

Sytuacja jest taka. Mamy tu dwa termostaty na channel #1 i #4. Jest przekaźnik z funkcją "heat or cold switch".
Bramka startuje, rejestrują się poprawnie termostaty w przekaźniku. Przekaźnik zostaje wyłączony:

Code: Select all

RelayHvacAggregator[2] hvac[1 @ 4087EC14] registered
RelayHvacAggregator[2] hvac[4 @ 4083357C] registered
RelayHvacAggregator[2] turn off
Relay[2] turn OFF (duration 0 ms)

Potem bramka odczytuje stan z gniazdka, jest "on", więc ustawia na kanale 1 (nie na klasie przekaźnika):

Code: Select all

[  6008][I][z2s_devices_table.cpp:3259] Z2S_onOnOffReceive(): A4:C1:38:CB:C9:C7:EE:96, endpoint 0x1, state 0x1
[  6008][I][z2s_devices_table.cpp:161] Z2S_findChannelNumberSlot(): A4:C1:38:CB:C9:C7:EE:96, endpoint 0x1, channel type 0xb54
[  6009][I][Z2S_virtual_relay.cpp:497] Z2S_setOnOff(): durationMs = 0, storedTurnOnDurationMs = 0, durationTimestamp = 0, keepTurnOnDurationMs = 0
Channel(2) value changed to 1

Nie wiem jakiej klasy "relaya" używa bramka, ale ogólnie Relay (oparty o GPIO) czyta stan GPIO, aby ocenić czy przekaźnik jest włączony. Natomiast VirtualRelay czyta wartość zmiennej "state", które się przestawia tylko metodami "turnOn" i "turnOff".
No i ten RelayHvacAggregator (który zarządza tym całym interesem) czyta "isOn()" i cału czas dostaje, że jest "off", więc wg niego jest wszystko ok .
Bramka tutaj dobiera się do kanałów i przestawia stan na kanale, zamiast użyć metody turnOn/turnOff.

Ogólnie interfejsy klas w Supli nie są najlepiej zrobione i jest tam trochę błędnych decyzji z przeszłości. Pewnie najlepiej by było gdyby Channel jako taki był schowany, aby się do niego nie dobierać bezpośrednio (chyba, że pisze się implementację klasy zarządzającej tym kanałem ).

Ten sam problem by wyszedł, jeśli np. podłączycie sobie lokalnie czujnik binarny (albo przycisk?) i na zmianę stanu wywołacie lokalną akcję TOGGLE. Wtedy pierwsza reakcja nie zadziała poprawnie (sprawdz isOn, wyjdzie, że jest off, więc zrobi turnOn i spróbuje włączyć włączone gniazdko ). Druga próba oczywiście zadziała.

Także moja propozycja jest taka, aby obsługa przekaźnika na bramce nie grzebała samodzielnie w Channel, tylko użyła metody "turnOn/Off" na instancji VirtualRelay.

A ja się zastanowię jak tą lukę w bibliotece załatać .

[zzrr]

viewtopic.php?p=216195#p216195
viewtopic.php?p=216200#p216200

Ta flaga dostępna jest tylko dla kanałów T i T/H - nie powinna dać się włączyć dla kanału THERMOSTAT. Włączasz tę flagę tym termometrom, które mają wysyłać dane do zdalnego termometru.

No zgadza się na termostatcie się nie da. Ale muszę te linki przeczytać jeszcze ze dwa razy. Bo próbowałem też tym wysłać temperaturę z ZWT198 na TRV06. Próbowałem numery kanałów tych z bramki. Nie osiągnąłem niczego z czego bym mógł wydedukować o co chodzi

[zzrr]

Sytuacja jest taka. Mamy tu dwa termostaty na channel #1 i #4. Jest przekaźnik z funkcją "heat or cold switch".
.........
.........

Także moja propozycja jest taka, aby obsługa przekaźnika na bramce nie grzebała samodzielnie w Channel, tylko użyła metody "turnOn/Off" na instancji VirtualRelay.

A ja się zastanowię jak tą lukę w bibliotece załatać .

@klew wielkie dzięki. Nie będę udawał że zrozumiałem wszystko co napisałeś no powiedzmy trochę, ale @vajera już pewnie będzie wiedział co i jak. Dzięki

[zzrr]

Wiesz co @klew. Troche mnie zastanawia z tego opisu jedna rzecz. ja na tym przekaźniku mam przyciski. I jak np przełączam przekaźnik tym przyciskiem to jego stan za pierwszym też razem przenosi do clouda i apki. Zmienia się ikonka pieca na włączony. Jak się uruchamia bramka to na termostacie też właściwie odczytuje stan tego przełącznika. A mimo to go nie przełącza zgodnie z tym co pokazuje termostat. A mówiłeś że on jest cyklicznie sprawdzany.

[klew]

Wiesz co @klew. Troche mnie zastanawia z tego opisu jedna rzecz. ja na tym przekaźniku mam przyciski. I jak np przełączam przekaźnik tym przyciskiem to jego stan za pierwszym też razem przenosi do clouda i apki. Zmienia się ikonka pieca na włączony. Jak się uruchamia bramka to na termostacie też właściwie odczytuje stan tego przełącznika. A mimo to go nie przełącza zgodnie z tym co pokazuje termostat. A mówiłeś że on jest cyklicznie sprawdzany.

(zakładam, że tam jest VirtualRelay)
Supla sprawdza stan zmiennej w klasie VirtualRelay, a nie stan kanału. Natomiast bramka nadpisuje bezpośrednio stan kanału, więc tak jakby nie informuje klasy VirtualRelay o zmianie stanu. Więc VR myśli, że jest wyłączony i dlatego to nie działa.

[zzrr]

Wiesz co @klew. Troche mnie zastanawia z tego opisu jedna rzecz. ja na tym przekaźniku mam przyciski. I jak np przełączam przekaźnik tym przyciskiem to jego stan za pierwszym też razem przenosi do clouda i apki. Zmienia się ikonka pieca na włączony. Jak się uruchamia bramka to na termostacie też właściwie odczytuje stan tego przełącznika. A mimo to go nie przełącza zgodnie z tym co pokazuje termostat. A mówiłeś że on jest cyklicznie sprawdzany.

(zakładam, że tam jest VirtualRelay)
Supla sprawdza stan zmiennej w klasie VirtualRelay, a nie stan kanału. Natomiast bramka nadpisuje bezpośrednio stan kanału, więc tak jakby nie informuje klasy VirtualRelay o zmianie stanu. Więc VR myśli, że jest wyłączony i dlatego to nie działa.

Hmm... @vajera no to musi być upgrade na bramce nie ma wyjścia. Obsługę tego przekaźnika umieszczam w swojej analizie ryzyka jako priorytet

[vajera]

Wiesz co @klew. Troche mnie zastanawia z tego opisu jedna rzecz. ja na tym przekaźniku mam przyciski. I jak np przełączam przekaźnik tym przyciskiem to jego stan za pierwszym też razem przenosi do clouda i apki. Zmienia się ikonka pieca na włączony. Jak się uruchamia bramka to na termostacie też właściwie odczytuje stan tego przełącznika. A mimo to go nie przełącza zgodnie z tym co pokazuje termostat. A mówiłeś że on jest cyklicznie sprawdzany.

(zakładam, że tam jest VirtualRelay)
Supla sprawdza stan zmiennej w klasie VirtualRelay, a nie stan kanału. Natomiast bramka nadpisuje bezpośrednio stan kanału, więc tak jakby nie informuje klasy VirtualRelay o zmianie stanu. Więc VR myśli, że jest wyłączony i dlatego to nie działa.

Nie do końca tak jest - klasa Z2S_VirtualRelay jest klasą pochodną po Relay, która ma zaimplementowane metody turnOn(), turnOff() i isOn() - oprócz modyfikowania stanu kanału uaktualniana jest też zmienna state (na wzór VirtualRelay).

[klew]

Nie do końca tak jest - klasa Z2S_VirtualRelay jest klasą pochodną po Relay, która ma zaimplementowane metody turnOn(), turnOff() i isOn() - oprócz modyfikowania stanu kanału uaktualniana jest też zmienna state (na wzór VirtualRelay).

Ok.
W takim razie coś jest w bibliotece tutaj nie tak. Przyjrzałem się jeszcze raz jak to zaimplementowałem i tam chyba ignoruję zmiany stanu przekaźnika. Ten odczyt "isOn" jest robiony tylko przy startcie (5s po uruchomieniu). W logach zmiana stanu była chyba 6s po uruchomieniu.

Także temat do głębszego przeanalizowanie i poprawienia w bibliotece. Ale takie rzeczy to już w poniedziałek

[vajera]

Nie do końca tak jest - klasa Z2S_VirtualRelay jest klasą pochodną po Relay, która ma zaimplementowane metody turnOn(), turnOff() i isOn() - oprócz modyfikowania stanu kanału uaktualniana jest też zmienna state (na wzór VirtualRelay).

Ok.
W takim razie coś jest w bibliotece tutaj nie tak. Przyjrzałem się jeszcze raz jak to zaimplementowałem i tam chyba ignoruję zmiany stanu przekaźnika. Ten odczyt "isOn" jest robiony tylko przy startcie (5s po uruchomieniu). W logach zmiana stanu była chyba 6s po uruchomieniu.

Także temat do głębszego przeanalizowanie i poprawienia w bibliotece. Ale takie rzeczy to już w poniedziałek

To raptem 23h

[zzrr]

Także temat do głębszego przeanalizowanie i poprawienia w bibliotece. Ale takie rzeczy to już w poniedziałek

To raptem 23h

Moje zdanie w temacie to