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

User avatar
lukfud
Posts: 2123
Joined: Thu Nov 23, 2017 11:33 pm
Location: Warszawa

Post

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.
You do not have the required permissions to view the files attached to this post.
https://www.facebook.com/groups/supladiy/
User avatar
klew
Posts: 8798
Joined: Thu Jun 27, 2019 12:16 pm
Location: Wrocław

Post

lukfud wrote: Tue Mar 12, 2024 11:29 am 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.
lukfud wrote: Tue Mar 12, 2024 11:29 am 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ł.
lukfud wrote: Tue Mar 12, 2024 11:29 am 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 ...")
Widzimy się na Supla Offline Party vol. 2 :!:
rafalekkalwak@wp.pl
Posts: 527
Joined: Mon Feb 06, 2023 8:56 am

Post

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 ()
User avatar
lukfud
Posts: 2123
Joined: Thu Nov 23, 2017 11:33 pm
Location: Warszawa

Post

klew wrote: Tue Mar 12, 2024 12:12 pm 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ć? ;)
klew wrote: Tue Mar 12, 2024 12:12 pm 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.
klew wrote: Tue Mar 12, 2024 12:12 pm 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.
https://www.facebook.com/groups/supladiy/
User avatar
klew
Posts: 8798
Joined: Thu Jun 27, 2019 12:16 pm
Location: Wrocław

Post

lukfud wrote: Tue Mar 12, 2024 12:45 pm 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 ;)
lukfud wrote: Tue Mar 12, 2024 12:45 pm Funkcjonalność przecież już jest, jak jeszcze inaczej mogę ją przedstawić? ;)
Do mnie przemawiają struktury danych, wiadomości, bity, rozmiary pól, algorytmy itp :P
Jak dane mają być przechowywane? Tylko na urządzeniu? Tylko na serwerze? W obu miejscach? Jak mają być synchronizowane?
lukfud wrote: Tue Mar 12, 2024 12:45 pm 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 :P. 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?
lukfud wrote: Tue Mar 12, 2024 12:45 pm 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?
Widzimy się na Supla Offline Party vol. 2 :!:
User avatar
YoMan
Posts: 2358
Joined: Thu Apr 30, 2020 5:18 pm
Location: Częstochowa

Post

klew wrote: Tue Mar 12, 2024 1:11 pm
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ć.
YoMan
________________________________________
Wziąłem udział w Supla Offline Party 2023 ;)
User avatar
klew
Posts: 8798
Joined: Thu Jun 27, 2019 12:16 pm
Location: Wrocław

Post

YoMan wrote: Tue Mar 12, 2024 1:27 pm 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ł :)
Widzimy się na Supla Offline Party vol. 2 :!:
SOYER
Posts: 844
Joined: Wed Aug 10, 2022 12:29 pm
Location: Kryry

Post

lukfud wrote: Tue Mar 12, 2024 11:29 am 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?
🙏🙏🙏🍻
User avatar
lukfud
Posts: 2123
Joined: Thu Nov 23, 2017 11:33 pm
Location: Warszawa

Post

klew wrote: Tue Mar 12, 2024 1:11 pm 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
klew wrote: Tue Mar 12, 2024 1:11 pm Do mnie przemawiają struktury danych, wiadomości, bity, rozmiary pól, algorytmy itp :P
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ę :P
(użytkownik, być może zaawansowany, nie programista)
klew wrote: Tue Mar 12, 2024 1:11 pm 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 :P. 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())
klew wrote: Tue Mar 12, 2024 1:11 pm 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.
https://www.facebook.com/groups/supladiy/
User avatar
lukfud
Posts: 2123
Joined: Thu Nov 23, 2017 11:33 pm
Location: Warszawa

Post

SOYER wrote: Tue Mar 12, 2024 3:08 pm Możesz się podzielić kluczowymi kawałkami kodu które czynią tą wspaniałą rzecz?
🙏🙏🙏🍻
Którą rzecz?
https://www.facebook.com/groups/supladiy/

Return to “Zagadnienia ogólne”