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

[kurus]

Może chodziło o historię dla kanału ciśnienia?

[Maciek663]

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?

Mierzyć można cokolwiek, co da się zmierzyć . Pomiar napięcia ADC będzie jedną z gotowych opcji. Poza tym można tam wstawić implementację dowolnych czujników (np. dodałem już do biblioteki pomiar natężenia światła z BH1750 oraz MAX44009).

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.

Czy tutaj nadal będzie potrzebny ten min/max?

1. Implementacja czujników np po I2c to oczywiście osobny temat, myślę, że podstawa powinien być pomiar napięcia i licznik impulsów.

2. Tak, określenie zakresu ułatwia diagnostykę i wykrywanie błędów całej instalacji, jak i samego czujnika

[Maciek663]

Właśnie to jest idealny przykład, że to urządzenie powinno wiedzieć co się do niego podłączyło i wysyłać poprawne wartości do cloud, w GG właśnie dla takiego pomiaru określam min max i wszystko nie z tego zakresu jest uznawane za błąd.

Ale ten min/max powinien być wg Ciebie ustawiany w GG (lub w sofcie na urządzeniu), czy w Cloud? Dodać KPOP z pomiarem analogowym napięcia, który można skonfigurować w Cloud, czy tego nie robić i całą konfigurację zostawić w sofcie na urządzeniu?

Bo możemy:
1. Dodawać kanały dedykowane do każdego urządzenia podłączanego do GPIO i wtedy mamy kanał "natężęnia dźwięku", "natężenia światła", etc. (wtedy min/max w Cloud nie trzeba podawać) lub
2. Dodać kanał "pomiar ADC" i resztę user sobie wyklika w Cloud, aby mV skonwertować do faktycznej wartości, której te pomiary odpowiadają (wtedy min/max w cloud się przyda)
3. Można też robić wariant mieszany, czyli dodać "pomiar ADC", ale też dodawać ile się da konkretnych czujników, które korzystają z pomiaru ADC
?

2.

Wg mnie również 2 - ma to być kanał diy, więc jak najbardziej uniwersalny i konfigurowany bez zmiany softu urządzenia.

[SOYER]

Ja dalej twierdzę, że brniemy w kolejny ślepy zaułek. Po kiego grzyba, pomiar: tego, tamtego, owego, czegoś i jeszcze czegoś tam i kolejnego typu czujnika których rodzajów są tysiące.
Przecież to kanał do diy, chcę tylko możliwość przesłania wartości w prosty sposób do aplikacji i tam jej dowolnego opisania. To jest DIY!
Dajcie nam wreszcie proste narzędzie do wysłania jakiejś liczby i dowolnego jej opisania w apk. Prostego przesłania, bez korzystania z fafnastu innych kanałów które mają coś zastąpić.
Dajcie nam to na już.
Jeśli uważacie, że nie tędy droga to skoro macie zasoby to potem możecie to sobie uszczegóławiać, precyzować i specjalizować.
Na początek prosta funkcja wysyłająca int na aplikację i kanał w cloud gdzie tego inta dowolnie opiszemy.
Potem taka sama funkcja wysyłająca int z apk do device.
Tylko tyle po tylu latach czekania.
Potem możecie kombinować dalej.

[SOYER]

Ja dalej twierdzę, że brniemy w kolejny ślepy zaułek. Po kiego grzyba, pomiar: tego, tamtego, owego, czegoś i jeszcze czegoś tam i kolejnego typu czujnika których rodzajów są tysiące.
Przecież to kanał do diy, chcę tylko możliwość przesłania wartości w prosty sposób do aplikacji i tam jej dowolnego opisania. To jest DIY!
Dajcie nam wreszcie proste narzędzie do wysłania jakiejś liczby i dowolnego jej opisania w apk. Prostego przesłania, bez korzystania z fafnastu innych kanałów które mają coś zastąpić.
Dajcie nam to na już.
Jeśli uważacie, że nie tędy droga to skoro macie zasoby to potem możecie to sobie uszczegóławiać, precyzować i specjalizować.
Na początek prosta funkcja wysyłająca int na aplikację i kanał w cloud gdzie tego inta dowolnie opiszemy.
Potem taka sama funkcja wysyłająca int z apk do device.
Tylko tyle po tylu latach czekania.
Potem możecie kombinować dalej.

int, double, float… co tam wybierzecie, ale tylko jeden rodzaj zmiennej, w miarę uniwersalnej. Nic nie udziwniajcie, nie komplikujcie, bo się tego nigdy nie doczekamy.

[YoMan]

Zgodnie zatem z oczekiwaniami .... do pomiaru:
1. ilość soli w zmiękczaczu
2. poziom nieczystości w zbiorniku (tutaj w zasadzie jest odległość ale brakuje opcji przeliczenia cm na objetość i % w cloudzie i historii, przydatne byłoby uśrednianie ale to chyba się w cloud "nie zmieści")

Właśnie te dwie opcje mnie trochę martwią .
To są przykłady pomiarów typu "measurement" (np. odległość, waga), która fajnie by było móc przełączyć na "meter" (czyli zużycie godzinowe, dobowe itp.)
Natomiast wydaje mi się, że w postaci "measurement" (czyli takiej jak obecnie termometr), będą nadal użyteczne.

Owszem ... tak zakładałem, że to leży u podstaw tworzenia dwóch rodzajów kanałów. Mam nadzieję, że nie potraktujesz tego negatywnie ale bez KLOPa (a tak rozumiem ideę - że będzie "zużycie") to w sumie nie potrzebuję nic (albo niewiele) - pozwolić na zmianę jednostek na kanałach

cm na objętość można przeliczyć używając mnożnika/dzielnika oraz wartości dodanej.

Przykładowo: mamy pomiar odległości, który nam daje ilość cm pustej przestrzni. Jeśli wiemy, że zbiornik ma 100 cm i każdy 1 cm, to np. 10 l, to wtedy przeliczamy: (pomiar * 10) -> ilość "pustych litrów".
Teraz możemy dodać korektę. Cały zbiornik ma 1000 l pojemności (100 cm * 10 l), więc (pomiar * (-10)) + 1000 -> da nam pozostałą ilość opału/soli etc.

można tylko miejmy na uwadze, że suplożytkownicy są na różnych stopniach zaawansowania a z rozkładu statystycznego większość jest na moim, czyli niewysokim. Stąd umiejętność kodowania raczej nie wchodzi w grę dla ponad 90%. Natomiast widziałbym to w ten sposób, że urządzenie przekazuje wartości do cloud (np. z czujnika odległości) a w cloud ustawiamy co to jest, jaką ma jednostkę i ewentualnie jak ma przeliczać. Druga opcja jak rozumiem, to umieszczenie takich algorytmów w sofcie urządzenia. Wadą jest to, że zanim ZAMEL coś takiego wypuści to ja już będę na emeryturze, alterntywnie @krycha88 się wkurzy od ciągłego narzekania i wniosków o zmiany w GG

Wykresy będą wyglądać jak pomiar temperatury, więc wartość będzie spadać od 1000 l w dół do 0 l, a potem wzrosną (wsypanie soli).
Tylko nie będzie tam "przyrostów", więc nie będzie na wykresach widać ile zużywamy na godzinę/dobę/miesiąc/rok.

Tak naprawdę wtedy przydałyby się obie wersje wykresu: stan bieżący jak temperatura i zużycia jak przy licznikach energii/wody/gazu.

Tu pewnie też by się przydały te parametry ograniczające wartości min/max, aby nam przy błędnych pomiarach nie wskakiwało < 0 lub > 1000

... i uśrednianie (niektóre czujniki mają wahnięcia)
... i jakiś filtr - jak uzupełniam sól lub jest opróżnianie szamba to wskazania skaczą ponieważ przy czujnikach pojawiają się inne przeszkody (np. wąż od szambiarki) - ja akurat mam czujniki ultradźwiękowe i dzisiaj otrzymałem 20 powiadomień bo wskazówka skakała co chwilę do maksa. Potem cloud mnie wyciął

[YoMan]

Nie masz ciśnienia?

mam ... ale bez historii ...

... i bez prognozy

[klew]

... i uśrednianie (niektóre czujniki mają wahnięcia)
... i jakiś filtr - jak uzupełniam sól lub jest opróżnianie szamba to wskazania skaczą ponieważ przy czujnikach pojawiają się inne przeszkody (np. wąż od szambiarki) - ja akurat mam czujniki ultradźwiękowe i dzisiaj otrzymałem 20 powiadomień bo wskazówka skakała co chwilę do maksa. Potem cloud mnie wyciął

Cytując klasyka: a może frytki do tego?

[SOYER]

Nie masz ciśnienia?

mam ... ale bez historii ...

... i bez prognozy

Uwaga, teraz będę złośliwy.
Historia i wykresy dla kanału ciśnienia będą po kolejnej ankiecie, jej przeanalizowaniu, upłynięciu 397 dni. Potem prace pójdą jak z płatka, będą wykresy dla ciśnienia, kanały i cloud będą obsługiwać wszystkie dostępne czujniki ciśnienia, wykresy pokazywać w kolorach tęczy, a pod wykresami będzie ankieta co robimy dalej.

Wybaczcie, nie mogłem się powstrzymać.

[Robert Błaszczak]

No i podniosłeś sobie niepotrzebnie ciśnienie, a tu nie ma wykresów