KLOP, KPOP..... KTOP ?

[pzygmunt]

Zapisywanie tego stringa w historii jest problematyczne z uwagi na RODO. Wystarczy, że ktoś zacznie wyświetlać tam dane wrażliwe i mamy problem.

[klew]

Zapisywanie tego stringa w historii jest problematyczne z uwagi na RODO. Wystarczy, że ktoś zacznie wyświetlać tam dane wrażliwe i mamy problem.

Domyślnie historia jest wyłączona. Także może to można załatawić odpwiedznim komunikatem dla użytkownika, gdy włącza tą opcję w Cloud?

[pzygmunt]

To nas nie zwalnia z odpowiedzialności za te dane.

[[email protected]]

serio dowolne pole tekstowe wymusza podleganie pod RODO bo można tam coś wpisać identyfikującego osobę?
to np. taka lokalizacja też jest powiązana z emailem i też można wpisać dane wrażliwe, i by dyskwalifikowało samą wartość, bo można tam przesłać dowolny tekst, a to, że jest historia chyba niczego nie zmienia

ale Twoja decyzja, zrobię jak uważasz.

[pzygmunt]

Do wszystkich danych musimy się prawnie przygotować. Regulaminy, wewnętrzna dokumentacja, procedury, retencja. backupy itd. Tak samo jak do lokalizacji, która była dyskutowana/weryfikowana z prawnikami. To nie jest "od tak" moja decyzja. Ja za to odpowiadam głową. Dla mnie tam mogłoby być wszystko. Dla decydentów UE niekoniecznie.

[[email protected]]

@klew pozwolę sobie tutaj kontynuować dywagacje a na GitHuba wkleję podsumowanie jak coś ustalimy, bo tu wszyscy będą widzieć i mogą się wypowiedzieć:

Czy kanał GPT powinien być dwukierunkowy?
Niekoniecznie, ale jeśli już to albo w jedną, albo w drugą, ale nie oba na raz.
W sumie zacząłem od opcji naturalnej Urządzenie->Serwer, i to była by jakaś opcja minimum działająca End-to-end. Nie widzę też problemów w jej rozszerzenia w drugim kierunku, np. jak mówisz przez funkcję.

Jeśli tak to w jaki sposób?
Dwie funkcje, to pewnie najprostszy sposób, bo... patrz niżej.

Czy może dwa kanały?
Dwa kanały pewnie by miały sens, jak by kanał Server -> urządzenie miał mieć dostępne jakieś większe możliwości niż przesłanie stringa, i tu pytanie w sumie do was, czy macie taką potrzebę na rzecz komercyjnych urządzeń, czy one mają po prostu swoje komunikaty?
Z drugiej strony, dwa kanały wymuszają kierunek.

Czy użytkownik może zmienić funkcję?
Uważam, że nie, rejestruje kanał z daną funkcją (upload/download) i albo przesyła dane albo je odbiera. Nie widzę przypadku użycia na zmianę w trakcie.

Jak ograniczyć zmianę?
wydaje mi się, że trzeba zablokować to po stronie cloud/server

[klew]

KTXT był rozważany wcześniej w obu wariantach. Argumenty za tymi dwoma rozwiązaniami są zasadne.
Pytanie tylko czy ktoś widzi jakieś use case'y na zmianę funkcji między tymi dwoma?

Jeśli nie ma potrzeby zmiany, to oba te kanały mogą mieć inne typy i inne funkcje. Jeśli dopuszczamy możliwość zmiany funkcji przez użytkownika w cloud, to trzeba to zupełnie inaczej zaprojektować i trzeba to uwzględnić przy dodawaniu obecnego zakresu

Ja roboczo ten Twój nazywam read only (RO). Kanał którym można przesłać tekst do urządzenia to read write RW. Może zasadne jest tam tylko write - do ustalenia.

RO raczej nie widzę opcji zastosowania w komercyjnych urządzeniach. Tam z definicji potrzebujemy praktycznie wszystko tłumaczyć, więc jeśli zajdzie tego typu potrzeba, to byłby to bardziej sztywny kanał z określonymi tekstami i tłumaczeniami po stronie cloud i apek.

Kanał RW/W ma potencjał na urządzenie komercyjne - ja tu widzę np możliwość wrzucenia tekstu na wyświetlacz.
Tutaj dodatkowo trzeba by umożliwić wysyłanie extended value z serwera do urządzenia (chyba tego wcale nie ma obecnie).

Jeszcze pytanie czy RO potrzebuje pamiętać stan? Tak aby po resecie zasilania przywrócił stan. 255 znaków to trochę dużo się zapisu w pamięci trwałej.

Potrzebujemy też koncepcję tego jak to pokazywać w aplikacji.

Serwer też pamięta ostatni stan.
Jak traktować wartość pustą? (0 znaków) Czy to będzie --- w cloud I apce? W reakcjach trzeba by ten stan też uwzględnić.

No i co z formatowaniem?

[[email protected]]

Przykład z wyświetlaczem jest ciekawy, ale wg mnie też pokazuje kierunek, co trochę implikuje Serwer -> Urządzenie w tym przypadku a nie dwukierunkowo.
Skłaniał bym się do tego co powiedziałeś, że w przypadku komercyjnych urządzeń to nawet taki Write, to może być po prostu mało - jak np. zachowanie bramki dla Auraton.
Dla mnie dobrym przykładem użycia tego nowego kanału jest chęć pokazania trybu pracy urządzenia, czytelna forma wartości "Północny" zamiast 180' odczytanej z czujnika obrotów.
Uważam więc, że dwa kierunki - czemu nie - , ale brak możliwości zmiany po zarejestrowaniu.

Co do trzymania stanu:
mnie się wydaje, że przy Read niekoniecznie, od tego jest serwer.

Co do pokazywania wartości:
W aplikacji chyba jak i w Cloud po prostu tekst bez udziwnień. Zależnie od długości albo go trzeba będzie przełamać na dwie linie albo nie. Patrz screenshot z Cloud.

Jeśli chodzi o długość 255 bajtów to sobie strzeliłem kompletnie z kapelusza, pewnie 50 znaków to już jest dużo od urządzenia do serwera.
W drugą stronę, myślę, że już gorsza sprawa bo pewnie sam bym przesyłał sobie jakąś konfigurację zakodowaną w dłuższym tekście

Co masz na myśli mówiąc formatowanie? Chciałeś powiedzieć Kodowanie znaków? Pchałbym w UTF-8, a to też implikuje, trochę rozmiar w bajtach

Wartość pustą pokazywał bym zawsze jako "- - -" powinno być raczej czytelne, bo chyba tak teraz jest zrobiony brak wartości w Supli. Pusty string nie daje pewności czy tak przyszło czy coś jest nie tak.
Reakcje - ok, sprawdzić czy nie pusty przed wykrywaniem różnic

[klew]

Przykład z wyświetlaczem jest ciekawy, ale wg mnie też pokazuje kierunek, co trochę implikuje Serwer -> Urządzenie w tym przypadku a nie dwukierunkowo.

Możliwe. Nie przeczę. Liczę na głosy i opinie innych osób. Czasem są use-case'y, o których nie pomyślimy

Dla mnie dobrym przykładem użycia tego nowego kanału jest chęć pokazania trybu pracy urządzenia, czytelna forma wartości "Północny" zamiast 180' odczytanej z czujnika obrotów.

Tu akruat uważam, że powinniśmy wprowadzić kanał typu "wyliczeniowego". Gdzie urządzenie rejestruje dostępne wartości, a w Cloud poza etykietami (i możliwymi tłumaczeniami) można by dodać wielostanowe ikonki.
Oczywiście GPT jest tutaj dobrym workaroundem na brak takiego kanału, ale to nadal jest tylko do zastosowań DIY (nie mówię, że to źle ).

Co do trzymania stanu:
mnie się wydaje, że przy Read niekoniecznie, od tego jest serwer.

Urządzenie zawzse przy rejestracji musi przesłać aktualny stan. Chociaż ten wymóg dotyczy tylko "channel value", a nie "extended channel value". Tutaj tekst leci w extended, więc w zasadzie da się zarejestrować kanał bez przesyłania stanu tekstu. Tylko to tworzy pewien rozjazd - na serwerze mamy "stary stan", a na urządzeniu możemy mieć pusty stan.

Co do pokazywania wartości:
W aplikacji chyba jak i w Cloud po prostu tekst bez udziwnień. Zależnie od długości albo go trzeba będzie przełamać na dwie linie albo nie. Patrz screenshot z Cloud.

W apce mamy stan na belce w widoku listy kanałów. Tam mamy pewnie dostępne kilkanaście znaków maks. W detalach (po wejściu w kanał) możemy już pokazać całość.

Co masz na myśli mówiąc formatowanie? Chciałeś powiedzieć Kodowanie znaków? Pchałbym w UTF-8, a to też implikuje, trochę rozmiar w bajtach

Mam na myśli bold, cursywa, justowanie, kolor, header, itd.

[Bania]

Moim zdaniem jeśli chodzi o KTXT:
a) jednostronny:
- wyświetlanie statusu urządzenia
- wyświetlanie logów krytycznych
b) dwustronny:
- dowolność nastaw: zadana wilgotność, zadana wartość procentowa (lub inne jednostki)
- bardzo przyszłościowo można wykorzystać ten kanał do "suwaka" trybów pracy np. AUTO - MANUAL - STOP, aktualnie mamy pozycję tylko włącz i wyłącz
- wpisywanie kodów IR, np. chce mieć zdalny włącz / wyłącz klimatyzacji, więc bez sensu za każdym razem resetować urządzenie, wchodzić w tryb konfiguracji, wprowadzać kod, sprawdzać czy działa...