Kanały pomiarowe ogólnego przeznaczenia - konsultacje społeczne

[krycha88]

Czy te dane będą zapisywane w configu urządzenia? Bo jeżeli nie to już widzę ten lament przy konflikcie kanału jak ktoś będzie musiał go usunąć

[klew]

Skoro tylko do diy, to co stało na przeszkodzie by zrobić to tak jak napisałem? Było by to multum razy bardziej praktyczne i przydatne. Twórca urządzenia diy i tak sam kombinuje nad kodem, wie co wysyła, więc wie jak to zinterpretować z drugiej strony.

Ja nie do końca rozumiem co opisałeś wcześniej.
Kanały pomiarowe służą głównie temu, aby można było przygotować implementację prawie dowolnego kanału pomiarowego i ustawić mu jednostkę.
W zasadzie dużo więcej tu nie ma.
W supla-device są już trzy przykłady użycia kpop (klasy do obsługi bh1750, max44009 oraz do ilości wolnego RAMu na ESP). Są też przykłady ino przygotowane.
Ogólnie osoba tworząca soft na jakieś urządzenie, może przesłać dowolny pomiar, a ewentualne korekty, przeliczania, zmiany jednostki, to może sobie już użytkownik w cloud ustawić.

[SOYER]

Robert nie narzekam. Naprawdę tylko pytam. Śmiem twierdzić, że sposób który opisałem pozwolił by nie tylko na kpop i klop w jednym ale to byłby kop, kanał ogólnego przeznaczenia. W prosty sposób przesłałbyś nim dowolną zmienną z albo do urządzenia/apk. Przecież to dzielenie, dodawanie, zerowanie, cokolwiek…, taki user diy zrobi sobie w kodzie przed wysłaniem zmiennej, albo po jej odebraniu, albo cokolwiek tam sobie tylko wymyśli. Brakuje tylko opcji wysłania/odebrania na cloud/apk i odpowiedniego opisania.
Takie dwa kanały zamknęły by buzie użytkownikom diy na długo, a tak za chwilę zaczną się kolejne prośby.
Dziękuję za pracę Twórców tylko chcę poznać powody takiego utrudniania sobie pracy. Takie moje zdanie.

[SOYER]

Skoro tylko do diy, to co stało na przeszkodzie by zrobić to tak jak napisałem? Było by to multum razy bardziej praktyczne i przydatne. Twórca urządzenia diy i tak sam kombinuje nad kodem, wie co wysyła, więc wie jak to zinterpretować z drugiej strony.

Ja nie do końca rozumiem co opisałeś wcześniej.
Kanały pomiarowe służą głównie temu, aby można było przygotować implementację prawie dowolnego kanału pomiarowego i ustawić mu jednostkę.
W zasadzie dużo więcej tu nie ma.
W supla-device są już trzy przykłady użycia kpop (klasy do obsługi bh1750, max44009 oraz do ilości wolnego RAMu na ESP). Są też przykłady ino przygotowane.
Ogólnie osoba tworząca soft na jakieś urządzenie, może przesłać dowolny pomiar, a ewentualne korekty, przeliczania, zmiany jednostki, to może sobie już użytkownik w cloud ustawić.

No i o to mi chodzi, by można wysłać cokolwiek z device do apk, nie tylko double, a w apk dowolnie to opisać.


W następnej kolejności zrobilibyście okno dialogowe w apk z którego device by to mogło odebrać i zrobić z tym co dusza zapragnie. Głupi przykład, mam wyświetlacz led witający klienta, wchodzę w suplę, w oknie dialogowym wpisuję dzisiejszą promocję, leci to do esp które wyświetla to na mojej tablicy led.

[lukfud]

W następnej kolejności zrobilibyście okno dialogowe w apk z którego device by to mogło odebrać i zrobić z tym co dusza zapragnie. Głupi przykład, mam wyświetlacz led witający klienta, wchodzę w suplę, w oknie dialogowym wpisuję dzisiejszą promocję, leci to do esp które wyświetla to na mojej tablicy led.

Jak związek mają kanały pomiarowe z "info tablicą ledową"?

[SOYER]

Taki, że jeśli byłby jeden kanał do przesyłania dowolnej zmiennej do aplikacji, a drugi w drugą stronę, to nie byłby potrzebny ani kpop, ani klop, ani multum kolejnych kanałów które będą robić wycinek roboty KOP.
Jeśli zrobienie takiego kanału jak piszę kosztowało by znacznie więcej pracy i czasu niż zrobienie kpop i klop, to ok, zgadzam się, jeśli nie, to gdzie sens?
Poważnie pytam, Was programistów, czy taki kanał o którym piszę, przesyłający dowolną zmienną do apk, z możliwością jej dowolnego tam opisania, to aż takie wyzwanie?

[klew]

Czy te dane będą zapisywane w configu urządzenia? Bo jeżeli nie to już widzę ten lament przy konflikcie kanału jak ktoś będzie musiał go usunąć

Tylko wybór między kpop i klop będzie generował konflikt, bo to różne typy kanałów.
Konfiguracja z wartościami domyślnymi nie jest przechowywana przez kanał, tylko określona przez soft. Jeśli chciałbyś pozwolić w swoim sofcie, aby użytkownik określał wartość domyślną, to trzeba by samemu zadbać o jej zapis i odczyt.
Natomiast cała konfiguracja, która jest też dostępna z cloud, jest normalnie zapisywana.
Na urządzeniu możesz odczytać wartość po przeliczeniu a także będzie metoda na pobranie gotowego tekstu z jednostkami i ustaloną precyzją - głównie pod kątem lokalnych wyświetlaczy.

[SOYER]

Ok, będzie gotowe to będziemy testować. Może będzie tak, że wystarczy na 99% przypadków. Jak na razie się nie zawiodłem na Supli, wszędzie polecam. Będzie dobrze.
Tylko zróbcie fajne przykłady i dobry opis gdzieś na githubie chociaż.
Przykład dobrze opisanych funkcji:
https://docs.blynk.io/en/blynk-library- ... rtual-pins

[[email protected]]

Do Klop dodał bym możliwość ignorowania wartości mniejszych niż poprzednia - liczniki wody czasem stają w niejasnej pozycji pomiędzy jedna wartością a druga i zdarza się że odczyt jest mniejszy ,a to nie znaczy że licznik się resetował .

Druga rzecz to możliwość edycji danych ,jak to w dyi zdarza się wysłać jakaś wartość z kosmosu a nie chcemy tracic całej historii - chociaż to pewnie bardziej ogólny temat .

Dla obu kanałów tymczasowy zapis danych częściej niż co 10 min -w celach typowo debugu , z jakimś ograniczeniem jak max doba po której dane zostaną usunięte, oraz nie częściej niż co 10 sek .

W Kpop możliwość interpretacji wartości na tekst - przykład z kierunkiem wiatru

[SOYER]