Pytania techniczne dotyczące kodu [bramka ZigBee]

[vajera]

Planuję pewną poprawkę w HvacBase, która dotknie termostatów na bramce Z2S.
Do tej pory obsługa czujnika binarnego (np.otwarcie okna) na urządzeniach z "wyjściem nie kontrolowanym wewnętrznie" (isOutputControlledInternally) była robiona przez ustawienie trybu "OFF" i potem przywracane przez "TURN_ON".
Ale to nie działa poprawnie. Np.
1. mam włączony termostat
2. otwieram okno
3. termostat robi się "off"
4. nic w Supli nie mogę zmienić: ani nastawy temperatury, ani trybu ręczny/program/off

No i tak nie może być .

Poprawka będzie polegała na tym, że sensor nie będzie przestawiał trybu pracy. W integracjach w stylu "bramek", tam gdzie sprawdza się tryb "getMode" trzeba będzie też dodać sprawdzenie stanu sensora (metoda HvacBase::isHvacFlagForcedOffBySensor() - dorzucę ją).
No i jak jest "forced off", to bramka powinna wyłączyć termostat ZigBee i jednocześnie nie przestawiać swojego "mode".

Kod pewnie jutro wrzucę, także ostrożnie z zaciąganiem z githuba

OK, dzięki za ostrzeżenie - to dosyć istotna zmiana i muszę pomyśleć nad jej implementacją.

[vajera]

@klew Wracam do tematu AT z następującym pytaniem:

przycisk 3x (on press, on double press, on long press)

1. stan na teraz - dodają się 3x VR z nazwami odpowiadającymi tym stanom, każde naciśnięcie powoduje toggle() na konkretnym VR - czyli lecą lokalne akcje ON_TURN_ON/OFF, ON_CHANGE.

Dzięki temu mogę zbudować lokalną akcję wykorzystując jako source channel VR(ON_DOUBLE_PRESS), zdarzenie ON_CHANGE, destination channel XX, akcja XX.

2. Wersja z AT - utworzę AT (przycisk) i dodam mu te action caps SHORT_PRESS_1, SHORT_PRESS_2, HOLD.

Pytanie brzmi - jak odtworzyć lokalną akcję z pkt. 1 w tym scenariuszu?

[klew]

Pytanie brzmi - jak odtworzyć lokalną akcję z pkt. 1 w tym scenariuszu?

Klasa AT to opakowanie wysyłające AT do serwera.
Obiektem generującym normlanie te AT w SD są Buttony. I normlanie to button generuje zdarzenie (press_2x), które coś robi oraz powiadamia o tym AT.

Także jeśli chcesz robić lokalne powiązania, to w sumie najprościej byłoby opakować te Twoje urządzenia w klasę typu "VirtualButton" .
Wtedy możesz korzystać z całego dobrodziejstwa tego co dają przyciski (choć nie wiem czy te rzeczy będą potrzebne).
No i możesz też używać "addAction" na buttonie.
Tylko tam wiele mechanizmów jest dopasowanych do dotychczasowych zastosowań i nie mam pewności, czy to się dobrze da pożenić z Z2S.

[vajera]

Pytanie brzmi - jak odtworzyć lokalną akcję z pkt. 1 w tym scenariuszu?

Klasa AT to opakowanie wysyłające AT do serwera.
Obiektem generującym normlanie te AT w SD są Buttony. I normlanie to button generuje zdarzenie (press_2x), które coś robi oraz powiadamia o tym AT.

Także jeśli chcesz robić lokalne powiązania, to w sumie najprościej byłoby opakować te Twoje urządzenia w klasę typu "VirtualButton" .
Wtedy możesz korzystać z całego dobrodziejstwa tego co dają przyciski (choć nie wiem czy te rzeczy będą potrzebne).
No i możesz też używać "addAction" na buttonie.
Tylko tam wiele mechanizmów jest dopasowanych do dotychczasowych zastosowań i nie mam pewności, czy to się dobrze da pożenić z Z2S.

Ha! Wiedziałem!

itsatrap.jpg

Mówiąc poważnie to zmiana z tych VR na AT wycięłaby całą logikę lokalną A gdyby do każdego VR wygenerował oddzielnie AT - to coś zmieni? Poza podwojeniem liczby kanałów?

[klew]

Ha! Wiedziałem!

itsatrap.jpg

Mówiąc poważnie to zmiana z tych VR na AT wycięłaby całą logikę lokalną A gdyby do każdego VR wygenerował oddzielnie AT - to coś zmieni? Poza podwojeniem liczby kanałów?

Jak już pisałem: ja bym dodał wirtualny przycisk. Czyli klasę "vb", na której z z2s robisz:

Code: Select all

  vb->generate(ON_CLICK_2);

No i vb powiązać akcjami z AT.
Wtedy lokalne reakcje robisz na bazie vb i tego co normalnie obsługuje przycisk.

Z tym, że zrobienie tego ładnie i fajnie wymaga sporo pracy i będzie jednak skomplikowane (np. AT potrafi raportować, że jakieś akcje są używane lokalnie i je wyłaczać, gdy ktoś w Cloud coś na nich ustawi). Ale to nie zadziała tak po prostu. AT rozumie przyciski (Button) w tym zakresie, że przycisk może być mono/bistabilny i ma do tego zdefiniowane zdarzenia itd.

Jeśli ma nie być wyłączania lokalnych reakcji i bez informowania o tym, że są jakieś używane, to powinno to być relatywnie proste.

[robertklepacki94]

Ten post można uznać za offtop.
Ale może to rozwiązać tak jak @krycha88 w bramce RF ?
Tzn. Jeden przycisk to kanał przekaźnika a w nim zaszyte AT, i zawsze funkcja x1 ustawiona na lokalne sterowanie?
To umożliwia w pilotach zigbee ustawić wszystkie 3 akcje a w urządzeniach typu plug do gniazdka powiązać lokalny przycisk z lokalnym przekaźnikiem.

[vajera]

Ten post można uznać za offtop.
Ale może to rozwiązać tak jak @krycha88 w bramce RF ?
Tzn. Jeden przycisk to kanał przekaźnika a w nim zaszyte AT, i zawsze funkcja x1 ustawiona na lokalne sterowanie?
To umożliwia w pilotach zigbee ustawić wszystkie 3 akcje a w urządzeniach typu plug do gniazdka powiązać lokalny przycisk z lokalnym przekaźnikiem.

Chyba się zgubiłem?

Mamy przycisk Zigbee z 3 funkcjami (single, double, long) - proponujesz 3 przekaźniki I w każdym AT x1 czy jeden przekaźnik z 3 AT?

Co do wtyczek - tutaj nie masz kontroli nad przyciskiem - on jest połączony z przekaźnikiem na poziomie kodu urządzenia Zigbee.

[klew]

Ja bym się trzymał modelu, jeśli model na to pozwala. Tutaj mamy dedykowane klasy i kanały do odpowiednich funkcji.
Przekaźnik, to przekaźnik.
Zdarzenia z przycisków to Wyzwalacz akcji (jeden kanał na przycisk).

Nie róbmy bałaganu z przekaźnikami udającymi zdarzenia z przycisków.
Wg mnie wszystkie obecne funkcje da się ogarnąć na AT.

[vajera]

Ja bym się trzymał modelu, jeśli model na to pozwala. Tutaj mamy dedykowane klasy i kanały do odpowiednich funkcji.
Przekaźnik, to przekaźnik.
Zdarzenia z przycisków to Wyzwalacz akcji (jeden kanał na przycisk).

Nie róbmy bałaganu z przekaźnikami udającymi zdarzenia z przycisków.
Wg mnie wszystkie obecne funkcje da się ogarnąć na AT.

Myślę nad tym i mam już jakąś wizję...tylko czasu wiecznie za mało

[vajera]

@klew Krzysztof - spójrz na ten kod:

Code: Select all

void LocalAction::runAction(uint16_t event) const {

  auto ptr = ActionHandlerClient::begin;
  
  while (ptr) {
  
    if (ptr->client && ptr->trigger == this && ptr->onEvent == event &&
        ptr->isEnabled()) {
      ptr->client->handleAction(event, ptr->action);
    }
    ptr = ptr->next;
  }
}

Myślisz, że wystarczyłoby:

Code: Select all

.....

      ptr->client->handleAction(event, ptr->action, this);
....

a w definicji handleAction:

Code: Select all

virtual void handleAction(int event, int action, LocalAction *local_action_ptr = nullptr) = 0;

żeby zachować wsteczną kompatybilność?