Pytania techniczne dotyczące kodu [bramka ZigBee]

[vajera]

@klew - zauważyłem też następującą różnicę:

Code: Select all

case MOVE_UP: {
      moveUp();
      break;
    }
 

ale

Code: Select all

case INTERNAL_BUTTON_MOVE_UP: {
      if (rsConfig.buttonsUpsideDown == 2) {
        moveDown();
      } else {
        moveUp();
      }
      break;
    }
  

To jest by design? Czy ten MOVE_UP nie powinien uwzględniać warunku rsConfig.buttonsUpsideDown == 2?

@klew Podbijam pytanie, bo chyba schowało się w gąszczu innych

[klew]

@klew - zauważyłem też następującą różnicę:

Code: Select all

case MOVE_UP: {
      moveUp();
      break;
    }
 

ale

Code: Select all

case INTERNAL_BUTTON_MOVE_UP: {
      if (rsConfig.buttonsUpsideDown == 2) {
        moveDown();
      } else {
        moveUp();
      }
      break;
    }
  

To jest by design? Czy ten MOVE_UP nie powinien uwzględniać warunku rsConfig.buttonsUpsideDown == 2?

@klew Podbijam pytanie, bo chyba schowało się w gąszczu innych

MOVE_UP jest starszy i był zanim pojawiło się "odwaracanie sterowania przyciskiem".
To rozróżnienie wynika też trochę z jednego urządzenia "gotowego", które ma przyciski góra/dół na panelu frontowym (więc nie da się zrobić odwrotnie), a jednocześnie ma wejścia przewodowe pod tradycyjne przyciski (które da się pomylić). Stąd MOVE_UP zawsze robi to samo, a ten drugi obraca się zależnie od ustawienia.
Inny use case - masz sterownik z wejściami na przyciski oraz na sterowanie centralne. Centralne jest bez obracania (zakładamy zawsze poprawne), a przyciski można obrócić.

[vajera]

MOVE_UP jest starszy i był zanim pojawiło się "odwaracanie sterowania przyciskiem".
To rozróżnienie wynika też trochę z jednego urządzenia "gotowego", które ma przyciski góra/dół na panelu frontowym (więc nie da się zrobić odwrotnie), a jednocześnie ma wejścia przewodowe pod tradycyjne przyciski (które da się pomylić). Stąd MOVE_UP zawsze robi to samo, a ten drugi obraca się zależnie od ustawienia.
Inny use case - masz sterownik z wejściami na przyciski oraz na sterowanie centralne. Centralne jest bez obracania (zakładamy zawsze poprawne), a przyciski można obrócić.

OK, rozumiem i dziękuję!

To jeszcze zamykając temat parowania - rozumiem, że na ten moment nie ma możliwości powiadomienia Cloud, że użytkownik uruchomił parowanie lokalnie?

[klew]

To jeszcze zamykając temat parowania - rozumiem, że na ten moment nie ma możliwości powiadomienia Cloud, że użytkownik uruchomił parowanie lokalnie?

Wiadomość powinno dać się wysłać, ale nie było to robione pod taki use case, także nie wiem czy serwer to zaakceptuje.
Założenie było takie, że jak odpalasz lokalnie to jesteś przy bramce i widzisz odpowiedni stan diodek sygnalizacyjnych.
Do tego parowanie z przycisku działa, gdy nie ma połączenia z siecią itd.

Rozumiem że przy z2s przydałaby się informacja o nieudanym parowaniu nieznanego urządzenia? Czy jeszcze jakieś użyteczne scenariusze widzisz?

[vajera]

To jeszcze zamykając temat parowania - rozumiem, że na ten moment nie ma możliwości powiadomienia Cloud, że użytkownik uruchomił parowanie lokalnie?

Wiadomość powinno dać się wysłać, ale nie było to robione pod taki use case, także nie wiem czy serwer to zaakceptuje.
Założenie było takie, że jak odpalasz lokalnie to jesteś przy bramce i widzisz odpowiedni stan diodek sygnalizacyjnych.
Do tego parowanie z przycisku działa, gdy nie ma połączenia z siecią itd.

Rozumiem że przy z2s przydałaby się informacja o nieudanym parowaniu nieznanego urządzenia? Czy jeszcze jakieś użyteczne scenariusze widzisz?

Właściwie to jedyny użyteczny scenariusz - użytkownik mógłby wtedy pozyskać dane o nieznanym urządzeniu bez zbierania logów i bez uruchamiania/wchodzenia w GUI.

[vajera]

@klew Skoro jesteśmy przy temacie akcji i zdarzeń - rozumiem, że nie jesteś w stanie zagwarantować, że nowe elementy zawsze będą dodawane na koniec listy?

[klew]

@klew Skoro jesteśmy przy temacie akcji i zdarzeń - rozumiem, że nie jesteś w stanie zagwarantować, że nowe elementy zawsze będą dodawane na koniec listy?

Elementy są dodawane zawsze na koniec listy. Nie planuję tego zmieniać.
Co kombinujesz, bo źle to pachnie?

[vajera]

@klew Skoro jesteśmy przy temacie akcji i zdarzeń - rozumiem, że nie jesteś w stanie zagwarantować, że nowe elementy zawsze będą dodawane na koniec listy?

Elementy są dodawane zawsze na koniec listy. Nie planuję tego zmieniać.
Co kombinujesz, bo źle to pachnie?

No wiesz...używam dobrych perfum
Mówiąc poważnie, jak zapewne wiesz, bramka pozwala na zapis/edycję/kopiowanie akcji, tak żeby po ponownym uruchomieniu można było je odtworzyć. Zapisuję identyfikator zdarzenia i akcji (jako liczby całkowite), w SD to są typy enum, jak dodasz coś w środku, to akcje się rozjadą

[klew]

No wiesz...używam dobrych perfum
Mówiąc poważnie, jak zapewne wiesz, bramka pozwala na zapis/edycję/kopiowanie akcji, tak żeby po ponownym uruchomieniu można było je odtworzyć. Zapisuję identyfikator zdarzenia i akcji (jako liczby całkowite), w SD to są typy enum, jak dodasz coś w środku, to akcje się rozjadą

Heh
Gdzieś to już słyszałem... GG miało ten sam problem
Osobiście mogę zagwarantować, że plik events.h i actions.h BĘDZIE się zmieniał. Nie polegaj na jego wartościach.

Proste obejście:
Tworzysz własny enum z gwarantowanym ID, który zapisujesz na flashu.
Przy zapisie i odczycie, konwertujesz swoje ID na enuma z Supli.
10 min roboty i masz problem z głowy

[vajera]

No wiesz...używam dobrych perfum
Mówiąc poważnie, jak zapewne wiesz, bramka pozwala na zapis/edycję/kopiowanie akcji, tak żeby po ponownym uruchomieniu można było je odtworzyć. Zapisuję identyfikator zdarzenia i akcji (jako liczby całkowite), w SD to są typy enum, jak dodasz coś w środku, to akcje się rozjadą

Heh
Gdzieś to już słyszałem... GG miało ten sam problem
Osobiście mogę zagwarantować, że plik events.h i actions.h BĘDZIE się zmieniał. Nie polegaj na jego wartościach.

Proste obejście:
Tworzysz własny enum z gwarantowanym ID, który zapisujesz na flashu.
Przy zapisie i odczycie, konwertujesz swoje ID na enuma z Supli.
10 min roboty i masz problem z głowy

Taki mam plan