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

[SOYER]

Piszesz:
„ Taki kanał superuniwersalny do wszystkiego, z przesyłaniem danych w obie strony i w pełni konfigurowalny po stronie urządzeń, serwera, apek, to temat dużo bardziej złożony.”
ja bym z tego zdania wyciął:
„konfigurowalny po stronie urządzeń”, to zrobi user a nie Wy

[klew]

Ale jak pewnie wiesz zostało zaimplementowane bo teza została przedstawiona i udowodniona bez świadków

Chętnie wyjaśnię co stoi za każdym punktem KPOP i KLOP. Temat nie jest jeszcze skończony i mamy jeszcze chwilę na to, aby wprowadzić jakieś zmiany.

Z tym zapisem to uważam że przesadzacie twierdząc że to spowoduje kosmiczny przyrost danych ,jeśli to było by tymczasowe.

Odnośnie 10 min - temat jest wieloaspektowy
1. Cloud, apki, serwer - wszędzie gdzieś jest po cichu zaszyte, że historia powinna być co 10 min. Zakładają to wykresy, metody do wypełniania brakujących danych na wykresach itp.
2. Ilość danych - problemem jest skala. Korzystanie z infrastruktury Supli jest darmowe. A sama infrastruktura oczywiście darmowa nie jest. Przechowywanie danych też kosztuje. Temat wygląda inaczej przy 1 użytkowniku, inaczej przy 1000, a inaczej przy 100 000.
3. Większości osób pomiar co 10 min wystarcza. Zarykuję stwierdzeniem, że dla 99% przypadków to jest ok
4. Analiza danych historycznych, kasowanie starych itp - to wszystko obciąża serwery.
5. Takie szybsze zapisywanie w celach debugowych to dość kosztowna funkcja, z której korzystałoby niewiele osób. Jak zwykle mamy długą kolejkę i jest dużo więcej tematów, które są pilniejsze. Z ankiety zdradzę, że w odpowiedziach dotyczących "jakiej funkcji mi brakuje w Supli?", zapis danych częściej niż co 10 min pojawił się aż 1 raz. To daje nam około 0,25 %

BTW pokażecie te wyniki ankiety ?

Nie rozmawialiśmy o tym. Myślę, że część wniosków/wykresów/danych będzie się pojawiać

A co do odpowiedzi na pytanie , zdanie moje i to co gdzieś widziałem na forum a nikt tu nie wspomniał :
Przedstawienie wartości pomiarowych których bezpośrednio nie przedstawiają istniejące kanały: ,napięcie baterii ,wartości zanieczyszczenia powietrza , kierunek wiatru , poziom cieczy/węgla w zbiorniku, ciśnienie atmosferyczne , oczywiście z historia.

Dzięki

To co podpowiada SOYER, możliwość pobrania wartości też była by fajna sprawa

Tak, ale to poza zakresem "kanałów pomiarowych".

A swoją drogą to fajnie by było w aplikacji móc ułożyć sobie obok siebie kanały jak temperatura z wilgotności a nie tylko pod sobą lub jeszcze nadać im zgrupowana nazwę

Też bym takie coś chciał :P

[SOYER]

Ktoś się ewidentnie zafiksował na temacie przymiotnika”pomiarowy” w kpop. Śmiem twierdzić, że wszystko wzięło się od tryliona próśb o inne sufiksy. I trzeba było wprowadzić możliwość dowolnych sufiksów. Temat byłby załatwiony, a tak latami ciągnie się kpop.

[klew]

Nie chcę być złośliwy, ale ile trwa implementacja kpop?

Raczej niedługo. Temat na serio ruszył gdzieś w grudniu. Ale w międzyczasie było też dużo innych rzeczy robionych.

Jak już wejdzie ten super konfigurowalny kpop to i tak się okaże, że wielu rzeczy nie potrafi, bo ktoś tam coś sobie wymyślił.Tu nie chodzi o to by ten kanał potrafił skalować, skakać , tańczyć i w środę robić loda, sorry za wulgarność. Robisz ten kanał dla diy, daj nam tylko możliwości o których piszę. Wystarczy.
Dajcie nam klucz francuski zamiast wypasionego zestawu narzędzi, z których używać będziemy kilku sztuk.
Nie narzekam. Uważam tylko, że obrana droga dla diy jest błędna.

Ja nie rozumiem jak ten Twój pomysł mógłby być zrealizowany.
Zacznijmy od pierwszego uproszczenia, czyli komunikacja ma być tylko z urządzenia na serwer. Czyli "kanał pomiarowy", a nie "kanał do sterowania urządzeniem".
Już nawet obecnie kanał temperatury pozwala wysłać dowolną liczbę. Jedyne czego tutaj nie ma, to wysyłania tekstu. No i zmiany jednoski w apce/cloud.
Po stronie urządzenia możesz sobie dowolnie tą liczbę przekształcać i przeliczać, zanim poleci na serwer. Więc wydaje mi się, że to spełnia większość Twoich oczekiwań odnośnie tego typu kanału.

W KPOP/KLOP też możesz sobie tą liczbę dowolnie przetworzyć po stronie softu na urządzeniu.

Te opcje do "skalowania, skania" itp. są po to, aby nie-programista mógł sobie inaczej taki kanał skonfigurować.

Przykład:
1. Programista robi urządzenie i kanał, który przesyła ilość wolnej pamięci RAM w bajtach (jednostka B).
2. Taki kanał jest dodawany np. do GG, albo do jakiegoś innego softu na jakieś urządzenie, które ktoś postanawia sprzedawać
3. Użytkownik dostaje urządzenie, które raportuje ilość wolnej pamięciw B. Ale on by chciał mieć to w KB, więc dodaje sobie w cloud dzielnik 1024 i zmienia jednosktę na KB.
4. Inny user będzie chciał mieć kB, więc doda dzielnik 1000 i jednostkę kB.

Przy wielu pomiarach można powyższe zastosować, np. zamiast lx, wyświetlać klx. Zamiast V, pokazać mV.
J przeliczyć na kcal, lub na kWh.

Inny przykład:
Jak wystarczy mi czasu, to dodam kanał, który wysyłą częstotliowść impulsów z GPIO (w Hz).
Tego typu kanał można użyć do anemometrów. Wystarczy, że ktoś sobie podstawi odpowiedni mnożnik/dzielnik i przeliczy częstotliowść na prędkość wiatru.

Może podaj jakieś konkretne przykłady, jakie masz na myśli, to będzie mi łatwiej zrozumieć Twój punkt widzenia.

[klew]

Ktoś się ewidentnie zafiksował na temacie przymiotnika”pomiarowy” w kpop. Śmiem twierdzić, że wszystko wzięło się od tryliona próśb o inne sufiksy. I trzeba było wprowadzić możliwość dowolnych sufiksów. Temat byłby załatwiony, a tak latami ciągnie się kpop.

Od zawsze to miał być "kanał pomiarowy". W zamyśle chodziło o przesyłanie danych z urządzenia do serwera.
Ja wiem, że kanał komunikacyjny do przesłania dowolnych danych w drugą stornę też jest potrzebny, ale od samego początku była mowa i było to wiele razy powtarzane, że najpierw będzie dodany "ogólny kanał, który wysyła dane z urządzenia na serwer" (a nie w drugą stronę).
Tak, też chciałbym mieć kanał do przesyłania dowolnych danych na urządzenie. Nikt nie kwestionuje tego, że to by było przydatne, dałoby wiele nowych możliwości itd.

Możemy używać nazwy "ogólny kanał, który wysyła dane z urządzenia na serwer", ale jest ona zbyt długa, dlatego wolę pisać "kanał pomiarowy", bo oddaje sens, a jest krócej i prościej.

Tu jest chyba pierwszy post na ten temat:
viewtopic.php?t=5225

[SOYER]

Dobra, przyjmuję tłumaczenie, bo i tak się zdalnie nie dogadamy, trzeba by usiąść przy stole ze szklankami i mlekiem i obgadać. Pewnie i tak byś mnie zbił argumentami, bo ja rookie jestem, zachwycony tylko prostotą wysyłania i odbierania apk/device w Blynku i zrażony komplikacją zagadnień w Supli. Supla z kolei zyskuje właśnie na cloudzie i multum prostych ustawień, ostatnie reakcje to perełka, ile by się było trzeba kodu napisać, żeby włączać światło po otwarciu bramy i zapadnięciu zmroku. Teraz kilka klików i zrobione.
Także czekam na kejpopa na klopie. Zobaczymy z czym to się je, jak się to będzie na apk wyświetlać, co da się z tego zrobić. Pewnie zawiedziony nie będę.
Wy już myślcie nad tym jak łatwo przekazywać dane z apki do urządzenia. Na wczoraj

[klew]

- dzielnik i mnożnik jako jedno: wpisujemy 0.1 mamy dzielnik, wpisujemy 10 mamy mnożnik, albo wg jeśli to możliwe to wpisywanie prostych funkcji np 2x + 4, x kwadrat, ln x itp.

W pierwszej wersji mieliśmy tylko "dzielnik", bo mnożenie, to odwrotność dzielenia itd. Te parametry będą przesyłane między serwerem, cloudem a urządzeniem, więc zdecydowaliśmy się na format danych typu "int" z jakąś zafiksowaną precyzją (np. 0.001). Początkowo był tam int32, ale to dawało nam zakres dzielnika od -2 000 000.000 do +2 000 000.000. Tylko taka wartość dzielnika pozwlała na mnożenie co najwyżej przz 1000. Więc jedną z opcji była zmiana tej zafiksowanej precyzji na -20 000.00000, ale wtedy znowu maksymalna wartość dzielnika i mnożnika jest na poziomie 10^5. No i tutaj zaczęliśmy rozważać zmianę na int64 (wtedy te zakresy już nie mają większego znaczenia), lub wprowadzenie osobno dzielnika i mnożnika z 0.001 i int32. Ja byłem za osobnymi wartościami, bo dla niektórych jest oczywiste, że aby coś pomnożyć przez 1000, to wystarczy to podzielić przez 0.001, ale dla innych nie jest to tak oczywiste, więc osobne "mnożniki" i "dzielniki" wg mnie są prostsze.

Wpisywania funkcji nie rozważaliśmy. Zastosowanie pewnie znikome, a poziom skomplikowania implementacji raczej większy.

- możliwość przypisania jednego wejścia do obu kanałów, na jednym wartość chwilowa, na drugim "zużycie" - np przepływ wody i zużycie wody

To raczej jest po prostu do ogarnięcia po stronie oprogramowania urządzenia. Czyli dodajesz sobie dwa kanały na urządzeniu, bierzesz pomiar i odpowiednio go przekształcasz i wrzucasz do jednego i drugiego kanału.

- możliwość określenia górnego i dolnego limitu - sporo czujników przy końcach zakresów jest nieliniowe, żeby nie wyświetlać głupot mogłoby się coś takiego przydać, do tego można tym wykrywać błąd czujnika

Podasz jakieś przykłady? Zastanawiałem się nad wprowadzeniem min/max, ale nie miałem co do tego przekonania .

[Maciek663]

Dziękuje za wyjaśnienia!

To raczej jest po prostu do ogarnięcia po stronie oprogramowania urządzenia. Czyli dodajesz sobie dwa kanały na urządzeniu, bierzesz pomiar i odpowiednio go przekształcasz i wrzucasz do jednego i drugiego kanału.

Racja - tutaj pewnie docelowo po stronie GG pozwalanie na wybranie już użytego GPIO.

Podasz jakieś przykłady? Zastanawiałem się nad wprowadzeniem min/max, ale nie miałem co do tego przekonania .

Np. sporo "przemysłowych" czujników ciśnienia (4-20mA lub 0-10) odjeżdża od liniowości przy dolnych granicach pomiarów, do tego samo ESP na analog input też traci liniowość.

Oprócz tego dla czujnika 4-20mA możemy prąd poniżej 4mA traktować jako błąd (np. uszkodzenie przewodów).

[klew]

Racja - tutaj pewnie docelowo po stronie GG pozwalanie na wybranie już użytego GPIO.

To raczej nie jest coś, co łatwo wdrożyć do takich "gotowców" jak GG. Na GPIO możesz liczyć stany wysokie/niskie, albo robić jakiś pomiar napięcia. Ale żadna z tych wartości bezpośrednio nie nadaje się do użycia jako "licznik" i coś co pokazuje tempo zmian tego licznika.
Raczej myślałem tutaj o tym, że osoba implementujaca takie kanały i urządzenie, sama sobie to odpowiednio przetworzy i policzy.
Jeśli miałeś coś innego na myśli, to podaj konkretny przykład. Bo sam odczyt GPIO wg mnie do tego się nie nadaje.

Np. sporo "przemysłowych" czujników ciśnienia (4-20mA lub 0-10) odjeżdża od liniowości przy dolnych granicach pomiarów, do tego samo ESP na analog input też traci liniowość.

Oprócz tego dla czujnika 4-20mA możemy prąd poniżej 4mA traktować jako błąd (np. uszkodzenie przewodów).

Na ESP raczej nie ma pomiaru prądu. Jedyne co jest dostępne wprost, to albo stan cyfrowy 0/1, albo analogowy pomiar napięcia. Tutaj rzeczywiście można traktować niskie wartości jako błąd. Ale to można zaimplementować w ramach kanału "KPOP do pomiaru analogowego na GPIO". W sensie taka implementacja KPOP powinna wiedzieć na jakim sprzęcie pracuje i zbyt niskie lub zbyt wysokie pomiary traktować jako błąd.

Jeśli chcielibyśmy mieć jakieś czujniki z pomiarem 4-20 mA, to one nie będą wprost podłączone do ESP, tylko pewnie przez jakis dodatkowy układ. To z kolei oznacza, że pewnie tego typu czujnik wymaga dedykowanej implementacji po stronie softu na urządzeniu, więc znów: dozwolone zakresy i błędy powinny być obsłużone w sofcie na urządzeniu.

[Maciek663]

To raczej nie jest coś, co łatwo wdrożyć do takich "gotowców" jak GG. Na GPIO możesz liczyć stany wysokie/niskie, albo robić jakiś pomiar napięcia. Ale żadna z tych wartości bezpośrednio nie nadaje się do użycia jako "licznik" i coś co pokazuje tempo zmian tego licznika.
Raczej myślałem tutaj o tym, że osoba implementujaca takie kanały i urządzenie, sama sobie to odpowiednio przetworzy i policzy.
Jeśli miałeś coś innego na myśli, to podaj konkretny przykład. Bo sam odczyt GPIO wg mnie do tego się nie nadaje.

Założyłem, że uniwersalny kanał pomiarowy będzie używany najczęściej we współpracy z pomiarem napięcia na ADC lub jako "licznik impulsów". Czy nie o to chodzi?

Na ESP raczej nie ma pomiaru prądu. Jedyne co jest dostępne wprost, to albo stan cyfrowy 0/1, albo analogowy pomiar napięcia. Tutaj rzeczywiście można traktować niskie wartości jako błąd. Ale to można zaimplementować w ramach kanału "KPOP do pomiaru analogowego na GPIO". W sensie taka implementacja KPOP powinna wiedzieć na jakim sprzęcie pracuje i zbyt niskie lub zbyt wysokie pomiary traktować jako błąd.

Jeśli chcielibyśmy mieć jakieś czujniki z pomiarem 4-20 mA, to one nie będą wprost podłączone do ESP, tylko pewnie przez jakis dodatkowy układ. To z kolei oznacza, że pewnie tego typu czujnik wymaga dedykowanej implementacji po stronie softu na urządzeniu, więc znów: dozwolone zakresy i błędy powinny być obsłużone w sofcie na urządzeniu.

Pętlę 4-20mA można łatwo przełożyć na pomiar napięcia, można też stosować czujniki np. 0-10V i dzielnik napięcia. Jak dla mnie to taki kanał pomiarowy będzie przydatny wtedy jak będę mógł go wygenerować w GG np. jako pomiar napięcia + określenie dzielnika/mnożnika + jednostka + historia jak obecnie dla pomiaru temperatury.