Własne pola w "Ustawia urządzenia" [cloud/supla-device/app]

[lukfud]

Odnosząc się do mojego pytania w tym wątku: viewtopic.php?p=175165#p175165

Budując cfg urządzenia wykorzystujemy klasy html poprzez które przekazujemy do programu odpowiednie parametry.
Część tych parametrów tj. ustawienia termostatu, ustawienia diody statusu czy czasu możemy także zmieniać w Cloud.

Czy jest cień szansy, aby w tym miejscu

Zrzut ekranu 2024-03-12 111451.png

pojawiły się własne parametry konfiguracyjne?
Mowa oczywiście o polach / checkboxach ze strony konfiguracyjnej 192.168.4.1.
W swoich szkicach np. używam checkboxów, które w zależności od stanu zmieniają logikę działania programu.

Innym przykładem są inputy numeryczne służące do przekazywania wartości dla mapowania czujnika analogowego

Zrzut ekranu 2024-03-12 113600.png

Oczywiście, mapowanie wykonuje się tylko raz na początku przy konfiguracji, ale zapewne znajdą się jeszcze inne zastosowania tej możliwości (możliwości ustawienia z Cloud)

Przy okazji wspomnę o funkcjonalności KTOP w połączeniu z KPOP
Czy w tym miejscu byłaby możliwość wyświetlenia tekstu/wartości liczbowej ?

Screenshot_20240312_114743_org.supla.android.jpg

Wyświetliłbym wartość RAW czujnika, która byłaby pomocna przy mapowaniu/kalibracji.

[klew]

Budując cfg urządzenia wykorzystujemy klasy html poprzez które przekazujemy do programu odpowiednie parametry.
Część tych parametrów tj. ustawienia termostatu, ustawienia diody statusu czy czasu możemy także zmieniać w Cloud.

Podaj przykłady. Same "checkboxy", czy inne pola? Z walidacją wartości? Skąd brane nazwy? Co z tłumaczeniami nazw na inne języki?
Przedstaw jakiś zarys całej funkcjonalności.

Innym przykładem są inputy numeryczne służące do przekazywania wartości dla mapowania czujnika analogowego

Tu by trzeba było rozbudować KPOP o dodatkowe pola. Była propozycja wcześniej wprowadzenia określania minimalnej i maksymalnej wartości (tak aby po przekroczeniu był NaN), ale reakcja forumowiczów była taka, że zbytnio komplikujemy prosty kanał.

Wyświetliłbym wartość RAW czujnika, która byłaby pomocna przy mapowaniu/kalibracji.

W tym miejscu są wyświetlane daty i wybierajki dat (jak wybierzesz inne okresy niż "Ostatenie ...")

[rafalekkalwak@wp.pl]

Mega pomysł
Ja bym zaczął prosto ,bez walidacji innej niż długość tekstu ,pozwolił na zdefiniowanie dowolnych parametrów o określonej ilości ,które potem po nazwie lub pozycji można odebrać na urzadzeniu, zapisać jeśli ich nie ma, i wykorzystać w logice ,np wysokość n.p.m. wykorzystywana do obliczania ciśnienia atmosferycznego , czy ustawienia nasłuchu pilota Rf 433, czy odczytu po wbus . Generalnie wszystko co teraz się robi na stronie 192.168.4.1 , można by wyeliminować ,oczywiście po za wifi ,z możliwością zapisu do pliku aby nie musieć tego klikać .

Problem z językiem ?
Znane klucze można tłumaczyć, pozostałe nazwać Właściwość 1,2 ,... I niech każdy sobie nazywa jak chce bo to i tak będzie specyficzne dla użytkownika ,więc po co komu tłumaczenie .

Nie wiązał bym tego z Kpop ,oczywiście można by tego użyć dla dowolnych zmiennych

Pobranie np po supla.begin ()

[lukfud]

Podaj przykłady. Same "checkboxy", czy inne pola? Z walidacją wartości? Skąd brane nazwy? Co z tłumaczeniami nazw na inne języki?
Przedstaw jakiś zarys całej funkcjonalności.

I tu zaczynają się schody z walidacją wartości, w takim razie same checkboxy.
Nazwy mogłyby być wysyłane z urządzenia (jak nazwy kanałów?), tłumaczenia są zbędne, cfg nie jest tłumaczony.

Funkcjonalność przecież już jest, jak jeszcze inaczej mogę ją przedstawić?

Tu by trzeba było rozbudować KPOP o dodatkowe pola. Była propozycja wcześniej wprowadzenia określania minimalnej i maksymalnej wartości (tak aby po przekroczeniu był NaN), ale reakcja forumowiczów była taka, że zbytnio komplikujemy prosty kanał.

Jeśli KPOP ma tylko wyświetlać sformatowaną na urządzeniu wartość, to pola ustawień (w tym */+) w Cloud nie są potrzebne.
Ale jeśli, użytkownik miałby modyfikować wyświetlaną wartość po swojemu, to tych ustawień (jak mieliśmy okazję testować) jest za mało.

W tym miejscu są wyświetlane daty i wybierajki dat (jak wybierzesz inne okresy niż "Ostatenie ...")

Moje niedopatrzenie. To gdziekolwiek indziej w obrębie kanału.

[klew]

I tu zaczynają się schody z walidacją wartości, w takim razie same checkboxy.
Nazwy mogłyby być wysyłane z urządzenia (jak nazwy kanałów?), tłumaczenia są zbędne, cfg nie jest tłumaczony.

Osobiście same checkboxy to dość ograniczone pole do popisu. Już to co Rafał napisał powyżej byłoby bardziej elastryczne, czyli pola tekstowe z maksymalną długością i bez walidacji po stronie Clouda.

Cfg jest tłumaczony po stronie Clouda. Wszystko co masz w Cloud i w Apkach jest tłumaczone.

Poza tym argument "to tylko do DIY jest i każdy sobie ustawi co chce" do mnie nie trafia. Potem ludzie po internetach sprzedają takie urządzenia i w Cloud będą się pojawiały pola bez tłumaczeń i "kowalski" będzie nam błędy w braku tłumaczeń zgłaszał ;P.
Oczywiście kwestia tłumaczeń nie koniecznie jest "must have" i jest to raczej temat otwarty, ale chciałbym zwrócić uwagę na potencjalne problemy i chciałbym widzieć propozycje ich rozwiązania

Funkcjonalność przecież już jest, jak jeszcze inaczej mogę ją przedstawić?

Do mnie przemawiają struktury danych, wiadomości, bity, rozmiary pól, algorytmy itp
Jak dane mają być przechowywane? Tylko na urządzeniu? Tylko na serwerze? W obu miejscach? Jak mają być synchronizowane?

Jeśli KPOP ma tylko wyświetlać sformatowaną na urządzeniu wartość, to pola ustawień (w tym */+) w Cloud nie są potrzebne.
Ale jeśli, użytkownik miałby modyfikować wyświetlaną wartość po swojemu, to tych ustawień (jak mieliśmy okazję testować) jest za mało.

Dlatego na etapie "konsultacji" pytaliśmy czy czegoś potrzeba, czy to co jest zaproponowane wystarczy. Ale temat jest otwarty, jeśli coś znajdzie poparcie, to może być wprowadzone. Tylko konkrety . Jakie pola? jakie wartości? itd
No i jak te min/max/in/out mają się mieć do mnożnika/dzielnika itp?
Dodatkowo czy te parametry miałyby zastosowanie do KPOP, które nie są pod spodem czujnikiem analogowym?

Moje niedopatrzenie. To gdziekolwiek indziej w obrębie kanału.

Wartość "raw" się wyświetli, jak ustawisz mnożnik i dzielnik na 1. Czy to nie wystarczy?

[YoMan]

Poza tym argument "to tylko do DIY jest i każdy sobie ustawi co chce" do mnie nie trafia. Potem ludzie po internetach sprzedają takie urządzenia i w Cloud będą się pojawiały pola bez tłumaczeń i "kowalski" będzie nam błędy w braku tłumaczeń zgłaszał ;P.
Oczywiście kwestia tłumaczeń nie koniecznie jest "must have" i jest to raczej temat otwarty, ale chciałbym zwrócić uwagę na potencjalne problemy i chciałbym widzieć propozycje ich rozwiązania

Mój głos tutaj za wiele nie powinien znaczyć z racji nieumiejętności programowania ale ...z punktu widzenia usera wydaje mi się, że mogło by być akceptowalne wydzielenie ramki pod tytułem "Ustawienia własne modułu" lub coś podobnego, taki cudzysłów, gdzie jest wyraźnie widoczne, że to nie jest część clouda. Trochę to będzie daleka analogia ale scripts niby suplowy ale jednak osobny serwis i rzadko kto ma pretensje, że supla nie działa bo mu skrypty nie chodzą (zwłaszcza że chodzą prawie zawsze:) )
Dlatego jako user, gdybyście się decydowali na takie funkcjonalności) widziałbym to w ten sposób. To nawet mógłby być popup z informacją w nagłówku o braku autoryzacji przez supla cloud zawartych tam ustawień i ich poprawności, żeby to podkreślić.

[klew]

Mój głos tutaj za wiele nie powinien znaczyć z racji nieumiejętności programowania ale ...z punktu widzenia usera wydaje mi się, że mogło by być akceptowalne wydzielenie ramki pod tytułem "Ustawienia własne modułu" lub coś podobnego, taki cudzysłów, gdzie jest wyraźnie widoczne, że to nie jest część clouda. Trochę to będzie daleka analogia ale scripts niby suplowy ale jednak osobny serwis i rzadko kto ma pretensje, że supla nie działa bo mu skrypty nie chodzą (zwłaszcza że chodzą prawie zawsze:) )
Dlatego jako user, gdybyście się decydowali na takie funkcjonalności) widziałbym to w ten sposób. To nawet mógłby być popup z informacją w nagłówku o braku autoryzacji przez supla cloud zawartych tam ustawień i ich poprawności, żeby to podkreślić.

Dobry pomysł

[SOYER]

Odnosząc się do mojego pytania w tym wątku: viewtopic.php?p=175165#p175165

Budując cfg urządzenia wykorzystujemy klasy html poprzez które przekazujemy do programu odpowiednie parametry.
Część tych parametrów tj. ustawienia termostatu, ustawienia diody statusu czy czasu możemy także zmieniać w Cloud.

Czy jest cień szansy, aby w tym miejscu


Zrzut ekranu 2024-03-12 111451.png

pojawiły się własne parametry konfiguracyjne?
Mowa oczywiście o polach / checkboxach ze strony konfiguracyjnej 192.168.4.1.
W swoich szkicach np. używam checkboxów, które w zależności od stanu zmieniają logikę działania programu.

Innym przykładem są inputy numeryczne służące do przekazywania wartości dla mapowania czujnika analogowego


Zrzut ekranu 2024-03-12 113600.png

Oczywiście, mapowanie wykonuje się tylko raz na początku przy konfiguracji, ale zapewne znajdą się jeszcze inne zastosowania tej możliwości (możliwości ustawienia z Cloud)

Przy okazji wspomnę o funkcjonalności KTOP w połączeniu z KPOP
Czy w tym miejscu byłaby możliwość wyświetlenia tekstu/wartości liczbowej ?


Screenshot_20240312_114743_org.supla.android.jpg

Wyświetliłbym wartość RAW czujnika, która byłaby pomocna przy mapowaniu/kalibracji.

Mega pomysł chłopie, sto lat bym myślał i bym nie
wymyślił.
Możesz się podzielić kluczowymi kawałkami kodu które czynią tą wspaniałą rzecz?

[lukfud]

Osobiście same checkboxy to dość ograniczone pole do popisu. Już to co Rafał napisał powyżej byłoby bardziej elastryczne, czyli pola tekstowe z maksymalną długością i bez walidacji po stronie Clouda.
Cfg jest tłumaczony po stronie Clouda. Wszystko co masz w Cloud i w Apkach jest tłumaczone.
Poza tym argument "to tylko do DIY jest i każdy sobie ustawi co chce" do mnie nie trafia. Potem ludzie po internetach sprzedają takie urządzenia i w Cloud będą się pojawiały pola bez tłumaczeń i "kowalski" będzie nam błędy w braku tłumaczeń zgłaszał ;P.
Oczywiście kwestia tłumaczeń nie koniecznie jest "must have" i jest to raczej temat otwarty, ale chciałbym zwrócić uwagę na potencjalne problemy i chciałbym widzieć propozycje ich rozwiązania

Biorąc pod uwagę propozycję @YoMan, tłumaczenia będą zbędne.
Wracając do walidacji, w sumie też jest zbędna, więc pola numeryczne także wchodziły by do gry (ograniczenie do int, jak w przypadku mnożnika i dzielnika w GPM) + pole tekstowe, które zaproponował @rafalekkalwak@wp.pl

Do mnie przemawiają struktury danych, wiadomości, bity, rozmiary pól, algorytmy itp
Jak dane mają być przechowywane? Tylko na urządzeniu? Tylko na serwerze? W obu miejscach? Jak mają być synchronizowane?

To nie ja, ja Ci tego nie w ten sposób nie rozrysuję
(użytkownik, być może zaawansowany, nie programista)

Dlatego na etapie "konsultacji" pytaliśmy czy czegoś potrzeba, czy to co jest zaproponowane wystarczy. Ale temat jest otwarty, jeśli coś znajdzie poparcie, to może być wprowadzone. Tylko konkrety . Jakie pola? jakie wartości? itd
No i jak te min/max/in/out mają się mieć do mnożnika/dzielnika itp?
Dodatkowo czy te parametry miałyby zastosowanie do KPOP, które nie są pod spodem czujnikiem analogowym?

Nie łączmy tych min/max/in/out z */+ (mnożnik, dzielnik, wartość dodana), wcześniej wspomniałem tylko, że ciężko skalibrować czujnik analogowy używając tylko */+.
Zazwyczaj do wyliczenia wartości dla KPOP nie będą potrzebne wartości z "zewnątrz", dlatego rozbudowywanie KPOP o dodatkowe pola nie jest konieczne.
KPOP użyłem jako przykładu, na wykorzystanie własnych pól numerycznych z konfiguracji urządzenia (przekazanie wartości do klasy GPM, do funkcji map())

Wartość "raw" się wyświetli, jak ustawisz mnożnik i dzielnik na 1. Czy to nie wystarczy?

Nie, jeśli z urządzenia będzie wysyłana wartość już przetworzona i */+ nie będzie używany.

[lukfud]

Możesz się podzielić kluczowymi kawałkami kodu które czynią tą wspaniałą rzecz?

Którą rzecz?