Propozycja nowego podejścia do alarmów, zdarzeń itp. na urządzeniach

[klew]

W SUPLI sposób zgłaszania alarmów i różnych problemów trochę się już wyczerpał. Szczególnie to widać na termostatach, gdzie powoli brakuje "bitów" do oznaczania problmeów zgłaszanych przez urządzenia.
Dotychczas dla każdego kanału trzeba było tego typu sygnalizację implementować osobno i upychać po bitach lub innych miejscach w "channel value".
Przez to chcąc dodać alarm do kanału ("otwarta pokrywa baterii", "wymień baterię", "błąd kalibracji"), trzeba było to implemnetować od nowa w termostatach, roletach i innych kanałach.

Niedługo pojawi się u nas urządzenie, które tych alarmów jeszcze trochę więcej dorzuca. Więc szala się przelała i naszykowałem propozycję nowego mechanizmu zgłaszania alarmów.

Temat dopiero zaczynamy dyskutotować wewnętrznie w zespole, ale chciałbym też dać każdemu możliwość dorzucenia swoich uwag i trzech groszy . Proponowana lista alarmów w tym PR jest raczej aby pokazać koncepcję. Trzeba to jeszcze przemyśleć i można tam dorzucać więcej kodów alarmów (w zasadzie sky is the limit ).

Zapraszam do dyskusji.

Szczegóły, trochę opisu i propozycja zmian na poziomie SUPLA proto:
https://github.com/SUPLA/supla-core/pull/612

[klew]

Widzę, że wszyscy są nieśmiali, więc wywołam;)
@vajera czy nie myślisz że "tamper" powinien być alarmem na kanale/subdevice a nie osobnym kanałem? Pewnie w ZigBee jest więcej komunikatów alarmowych. Te low battery, albo "wymień baterię" również

[zzrr]

W SUPLI sposób zgłaszania alarmów i różnych problemów trochę się już wyczerpał. Szczególnie to widać na termostatach, gdzie powoli brakuje "bitów" do oznaczania problmeów zgłaszanych przez urządzenia.
Dotychczas dla każdego kanału trzeba było tego typu sygnalizację implementować osobno i upychać po bitach lub innych miejscach w "channel value".
Przez to chcąc dodać alarm do kanału ("otwarta pokrywa baterii", "wymień baterię", "błąd kalibracji"), trzeba było to implemnetować od nowa w termostatach, roletach i innych kanałach.

Niedługo pojawi się u nas urządzenie, które tych alarmów jeszcze trochę więcej dorzuca. Więc szala się przelała i naszykowałem propozycję nowego mechanizmu zgłaszania alarmów.

Temat dopiero zaczynamy dyskutotować wewnętrznie w zespole, ale chciałbym też dać każdemu możliwość dorzucenia swoich uwag i trzech groszy . Proponowana lista alarmów w tym PR jest raczej aby pokazać koncepcję. Trzeba to jeszcze przemyśleć i można tam dorzucać więcej kodów alarmów (w zasadzie sky is the limit ).

Zapraszam do dyskusji.

Szczegóły, trochę opisu i propozycja zmian na poziomie SUPLA proto:
https://github.com/SUPLA/supla-core/pull/612

To ja tak nieśmiało coś nie tyle zaproponuję ale powiem. Nie wiem czy to ma w ogóle znaczenie jak finalnie będzie rozwiązana kwestia odrganizacji ewentualnych kanałów jeśli chodzi o konfigurowanie alarmów. Wydaje mi się że najlepiej jak będzie to dobrze zoptymalizowane i nie będzie zaśmiecało listy często sporych ilości kanałów. Użytkownikowi też można by nie odbierać wyboru. Czyli czasami lepiej mieć kanał a sobie go ukryć jeśli to by się wiązało z wprowadzeniem nowych metod o których myślę. Mając na względzie ten cytat z założeń cyt. "Aplikacje klienckie powinny móc wyświetlać aktywne alerty, historię alertów (? to się jeszcze nie stało) i dostępne wyzwalacze automatyzacji na podstawie alertów bez konieczności posiadania wiedzy na temat konkretnego urządzenia. " to użytkownik i tak będzie miał to czego potrzebuje. Przecież w przypadku samego alarmu to nie musi być kanał w stanie czuwania cały czas widoczny na liście. Osobiście wolałbym gdyby go nie było dla czytelności ale w razie alarmu np. pokazywała się o tym w aplikacji wyraźna informacja. Jeśli to jest czujnik alarmowy, tamper, itp to może mieć tylko dwa stany. Szkoda na niego miejsca w aplikacji. Ale warunek jest oczywisty... jeśli zadziała jasna widoczna informacja o tym w aplikacji a nie tylko powiadomienie. Tak mi się wydaje o ile dobrze zrozumiałem czy to o to chodzi w temacie. Mogła by też być w jakimś oddzielnym oknie lita wszystkich kanałów bez grafik tylko z informacją czy kanał jest widoczny w głównym oknie czy nie lub może nawet z możliwościa przełączenia bezpośrednio w aplikacji. @klew czy się trochę nie rozpędziłem?
EDIT:
Tamper nie powinien być alarmem na kanale. Jeśli mamy np PIR gdzie jest oddzielnie IAS a oddzielnie OCCUPANCY a jest też TAMPER to jak go przypisać do kanału. Raczej chyba musi być oddzielnie

[klew]

@zzrr bardziej chodzi o to, że różne alarmy nie będą wymagały tworzenia dla nich dedykowanych kanałów (patrz tamper).
Drugi problem, to wspólne błędy dla różnych urządzeń, np obecnie głowica Auraton potrafi zgłosić "błąd kalibracji" a także sterowniki rolet zgłaszają "błąd kalibracji" - te błędy nie mają osobnych kanałów, ale są modelowane w kanale rolety i termostatu.

Te nowe alarmy by miały osobny mechanizm i wtedy "tamper" można zgłosić na czujniku otwarcia, czujniku ruchu, czy nawet na sterowniku rolet (jeśli by to miało sens). Także nie dodajemy nowych kanałów, tylko zgłaszany alarm na istniejący kanał, który reprezentuje dane urządzenie.

Soft urządzenia by określał jakie alarmy może zgłaszać (do wyboru ze zdefiniowanych kodów alarmu, a także jakaś pula "vendor specific", gdzie byłby widoczny tylko kod błędu).

W apce alarm miałby swoją ikonkę na liście kanałów (analogicznie jak obecne czarowne i żółte wykrzykniki).

[zzrr]

@zzrr bardziej chodzi o to, że różne alarmy nie będą wymagały tworzenia dla nich dedykowanych kanałów (patrz tamper).
Drugi problem, to wspólne błędy dla różnych urządzeń, np obecnie głowica Auraton potrafi zgłosić "błąd kalibracji" a także sterowniki rolet zgłaszają "błąd kalibracji" - te błędy nie mają osobnych kanałów, ale są modelowane w kanale rolety i termostatu.

Te nowe alarmy by miały osobny mechanizm i wtedy "tamper" można zgłosić na czujniku otwarcia, czujniku ruchu, czy nawet na sterowniku rolet (jeśli by to miało sens). Także nie dodajemy nowych kanałów, tylko zgłaszany alarm na istniejący kanał, który reprezentuje dane urządzenie.

Soft urządzenia by określał jakie alarmy może zgłaszać (do wyboru ze zdefiniowanych kodów alarmu, a także jakaś pula "vendor specific", gdzie byłby widoczny tylko kod błędu).

W apce alarm miałby swoją ikonkę na liście kanałów (analogicznie jak obecne czarowne i żółte wykrzykniki).

To jeszcze napisze tutaj bo edytowałem powyższą swoją wiadomość w tym samym momencie co napisałeś.
Tamper nie powinien być alarmem na kanale. Jeśli mamy np PIR gdzie jest oddzielnie IAS a oddzielnie OCCUPANCY a jest też TAMPER to jak go przypisać do kanału. Raczej chyba musi być oddzielnie
EDIT:
Chyba wiem o czym mówisz. Czyli jedno widoczne urządzenie np PIR i w nim przypisane kanały alarmowe. No koncepcja dobra. Tylko OCCUPANCY nie koniecznie jest alarmowym. Hmm. Ale czy jest potrzebny jako widoczny oddzielny, chyba nie... No ciekawy pomysł
EDIT:
Czytam i stwierdzam że ja to chyba źle zrozumiałem. Czyli "alarmy' zostały by na liście tylko przypisywało by się je do ustalonych zasad a nie każdy miałby swoje oddzielne. Tak? Czyli tak naprawdę dla użytkownika nic się nie zmieni w sumie tylko zostanie zoptymalizowany sposób obsługi tych kanałów, tak?

[klew]

To że urządzenie może mieć dwa kanały, nie oznacza, że powinniśmy dodawać trzeci, bo nie wiemy na którym zgłosić alarm

Ogólnie w SUPLI jest niejako taki problem, że apki nie znają urządzeń, a tylko kanały. Także alarmy z urządzeń trzeba też zgłaszać na kanałach.

Przy ias+occupancy programista urządzenia musi zdecydować, który z tych kanałów będzie główny i na niego raz ma zgłaszać alarmy. Można też na oba kanały.

Zmiana pozwoli na lepsze modelowanie takich sytuacji. Użytkownik z apce będzie miał dostęp do alarmów na kanale użytkowym bez konieczności dodawania sztucznych kanałów.
Programista będzie miał do dyspozycji kilkadziesiąt różnych alarmów, które będzie mógł zgłosić na dowolnym kanale, co powinno mocno uelastycznić ten obszar i pozwolić na zaniechanie robienia sztucznych workaroundów.

[lukasz06]

W SUPLI sposób zgłaszania alarmów i różnych problemów trochę się już wyczerpał. Szczególnie to widać na termostatach, gdzie powoli brakuje "bitów" do oznaczania problmeów zgłaszanych przez urządzenia.
Dotychczas dla każdego kanału trzeba było tego typu sygnalizację implementować osobno i upychać po bitach lub innych miejscach w "channel value".
Przez to chcąc dodać alarm do kanału ("otwarta pokrywa baterii", "wymień baterię", "błąd kalibracji"), trzeba było to implemnetować od nowa w termostatach, roletach i innych kanałach.

Niedługo pojawi się u nas urządzenie, które tych alarmów jeszcze trochę więcej dorzuca. Więc szala się przelała i naszykowałem propozycję nowego mechanizmu zgłaszania alarmów.

Temat dopiero zaczynamy dyskutotować wewnętrznie w zespole, ale chciałbym też dać każdemu możliwość dorzucenia swoich uwag i trzech groszy . Proponowana lista alarmów w tym PR jest raczej aby pokazać koncepcję. Trzeba to jeszcze przemyśleć i można tam dorzucać więcej kodów alarmów (w zasadzie sky is the limit ).

Zapraszam do dyskusji.

Szczegóły, trochę opisu i propozycja zmian na poziomie SUPLA proto:
https://github.com/SUPLA/supla-core/pull/612

I to jest słuszna koncepcja
Tamper i jemu podobne nie powinien być kanałem.

[QBA-dev]

Popieram to rozwiązanie w całej rozciągłości. Bardzo dobra decyzja robić coś jako ogólne a nie szczególne.
Trochę spędziłem z rozkminianiem kodu supla-core i jest tam kilka rzeczy które powinny być zaimplementowane inaczej lata temu, a teraz się ciągną ale nie chcę tego jakoś bardzo krytykować bo kto lata temu wiedział co będzie w przyszłości?
Naprawdę doceniam dbałość o kompatybilność wsteczną i to że nawet dziś można wgrać buildy Przemka sprzed 10 lat z tego repo: https://github.com/SUPLA/ESP8266 i wciąż działają z najnowszym serwerem

Co do tych naleciałości(szczególne zamiast ogólne) to mam na myśli na przykład te typy kanałów(widzę oznaczenie depractated i słusznie):

Code: Select all

#define SUPLA_CHANNELTYPE_RELAYHFD4 2000       // DEPRECATED
#define SUPLA_CHANNELTYPE_RELAYG5LA1A 2010     // DEPRECATED
#define SUPLA_CHANNELTYPE_2XRELAYG5LA1A 2020   // DEPRECATED
#define SUPLA_CHANNELTYPE_THERMOMETERDS18B20 3000  // DEPRECATED
#define SUPLA_CHANNELTYPE_DHT11 3010               // ver. >= 4  DEPRECATED
#define SUPLA_CHANNELTYPE_DHT22 3020               // ver. >= 4  DEPRECATED
#define SUPLA_CHANNELTYPE_DHT21 3022               // ver. >= 5  DEPRECATED
#define SUPLA_CHANNELTYPE_AM2302 3030              // ver. >= 4  DEPRECATED
#define SUPLA_CHANNELTYPE_AM2301 3032              // ver. >= 5  DEPRECATED

Wiem że wiszą w kodzie tylko dla zachowania kompatybilności wstecz

Odchodzę od meritum czyli alarmów, ale dokończę myśl:
Nie zbyt podoba mi się też to że w proto jest za dużo szczególnych detali związanych z GKW-01, podobnie z grzałkami HEATPOL
W sensie te definicje i powiązane struktury:

Code: Select all

#define SUPLA_DEVCFG_HOME_SCREEN_CONTENT_NONE (1ULL << 0)
#define SUPLA_DEVCFG_HOME_SCREEN_CONTENT_TEMPERATURE (1ULL << 1)
#define SUPLA_DEVCFG_HOME_SCREEN_CONTENT_TEMPERATURE_AND_HUMIDITY (1ULL << 2)
#define SUPLA_DEVCFG_HOME_SCREEN_CONTENT_TIME (1ULL << 3)
#define SUPLA_DEVCFG_HOME_SCREEN_CONTENT_TIME_DATE (1ULL << 4)
#define SUPLA_DEVCFG_HOME_SCREEN_CONTENT_TEMPERATURE_TIME (1ULL << 5)
#define SUPLA_DEVCFG_HOME_SCREEN_CONTENT_MAIN_AND_AUX_TEMPERATURE (1ULL << 6)
#define SUPLA_DEVCFG_HOME_SCREEN_CONTENT_MODE_OR_TEMPERATURE (1ULL << 7)

Do przemyślenia byłoby coś w stylu zaproponowania jakiegoś ogólnego formatu przesyłania konfiguracji urządzenia aplikacja/serwer/urządzenie w taki sposób żeby mieć zestaw opcji w stylu:

label:nazwa opcji
type: bool/num/oneof/text/color/player(PLAY/STOP/NEXT/PREV)
range: zakres dla danego parametru

I taki GKW-01 by mógł rejestrować się z czymś w stylu:

Code: Select all

"{
{"label":"TEMP_DISPLAY","type":"oneof","range":"NONE/TEMPERATURE/TEMPERATURE_AND_HUMIDITY"},
itd...
}"

Urządzenie zgłaszałoby serwerowi ten zestaw nastaw i zakresów przy rejestracji, a serwer zwracałby te nastawy aplikacji która by to renderowała i zwrotnie wysyłała do urządzenia. Serwer nie musiałby nawet znać zawartości takiej paczki danych tylko przerzucać je od urządzenia do aplikacji i odwrotnie.
Takie rozwiązanie byłoby podobne do propozycji z alarmami gdzie urządzenie będzie mieć zestaw swoich alarmów z ogólnego zbioru wszystkich możliwych alarmów