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

[klew]

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ł .

W KLOP można określić typ danych na "tylko rosnące" (w HA "always increment"). W sumie obecne IC i EM już to mają. Spadki pomiarów poniżej 10% wartości są ignorowane. Większe spadki są traktowane jak reset licznika.

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 .

Tak, to temat bardziej ogólny i w ramach KPOP i KLOP na penwo nie będzie robiony.

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 .

Zapisu co 10 min na pewno nie będziemy zmieniać. W celach debugowych można sobie to na wiele innych sposobów ogarnąć: logi z urządzenia, odczyt danych po MQTT/API i pobieranie ich np. do Grafany.

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

Też takie coś proponowałem, aby wprowdzić "etykiety tekstowe" do różnych wartości, ale ten temat wylądował w poczekalni z etykietą "nie na pierwsze wydanie"

[QLQ]

Szanuję za sposób jaki podchodzicie do tematu ale czy nie za bardzo chcecie zrobić to za dobrze ? aktualnie wszystkie rozwiązania są zrobione na kanale temperatury i to się sprawdza.Brakuje najbardziej wyświetlania jednostki w której wysyła urządzenie dane do cloud. Może to za bardzo upraszam ale strzelam, że jest to 90% przypadków.

Już dawno o tym pisałem, że można było dla 99 %przypadków tak zrobić.

[klew]

Już dawno o tym pisałem, że można było dla 99 %przypadków tak zrobić.

Ja mam wrażenie, że nam się często wydaje, że wiemy co chcą inni.
Podam przykład z ostatniej urodzinowej ankiety. Jak było około 400 odpowiedzi to na pytanie "jakieś funkcjonalności najbardziej brakuje w Supli" było około 200 różnych odpowiedzi, z czego ponad 90 występowała tylko 1 raz, a kolejne 30-40 miało po 2-3 głosy.
Jak widać pomysłów i potrzeb jest tyle ilu ludzi
Także z tym zgadywaniem ile % potrzeb taki prosty kanał by zaspokoił byłbym bardziej powściągliwy.

[klew]

Dodam może jeszcze, że to co opisałem wcześniej odnośnie planowanych funkcji tych kanałów to w większości jest już zaimplementowane.
Także nie ma co wyrzucać teraz tego co jest zrobione, na rzecz prostszego i mniej uniwersalnego kanału

Dużo bardziej pomocne by było, gdyby pojawiło się tutaj więcej informacji o tym, do czego chcesz używać ogólnych kanałów pomiarowych?

[SOYER]

Już dawno o tym pisałem, że można było dla 99 %przypadków tak zrobić.

Ja mam wrażenie, że nam się często wydaje, że wiemy co chcą inni.
Podam przykład z ostatniej urodzinowej ankiety. Jak było około 400 odpowiedzi to na pytanie "jakieś funkcjonalności najbardziej brakuje w Supli" było około 200 różnych odpowiedzi, z czego ponad 90 występowała tylko 1 raz, a kolejne 30-40 miało po 2-3 głosy.
Jak widać pomysłów i potrzeb jest tyle ilu ludzi
Także z tym zgadywaniem ile % potrzeb taki prosty kanał by zaspokoił byłbym bardziej powściągliwy.

Właśnie odwrotnie, prosty kanał do diy powinien być już dawno. Mielibyście o 95% mniej próśb o kolejne pierdółki. Gdyby dało się przesyłać w dwie strony w prosty sposób jakieś dane i je dowolnie opisywać to, userzy diy mieli by może problemy z implementacją własnych pomysłów w kodzie, jeśli raczkują w programowaniu, ale nie mieli by żadnych by te swoje dane wysłać na aplikację albo odwrotnie.
Taki przykład, jeśli miałbym możliwość wysłania 0 lub 1 z apk do device, to umiem na urządzeniu zrobić mnóstwo rzeczy z tą informacją, np. dowolnie sterować przekaźnikami. Jasne , że teraz ustawianie tego w cloud może jest łatwiejsze dla użytkowników gotowych urządzeń. Jednak tu rozmawiamy o diy, potrzebujemy prostych narzędzi, z resztą sobie poradzimy.

[SOYER]

Pamiętacie moje termostaty tutaj? Ile kombinacji by zmienić, przy pomocy aplikacji, stan zmiennej w urządzeniu o 1. Masakra jakaś.

[krycha88]

Pamiętacie moje termostaty tutaj? Ile kombinacji by zmienić, przy pomocy aplikacji, stan zmiennej w urządzeniu o 1. Masakra jakaś.

Od tego przecież jest kanał przekaźnika

[[email protected]]

Dodam może jeszcze, że to co opisałem wcześniej odnośnie planowanych funkcji tych kanałów to w większości jest już zaimplementowane.
Także nie ma co wyrzucać teraz tego co jest zrobione, na rzecz prostszego i mniej uniwersalnego kanału

Dużo bardziej pomocne by było, gdyby pojawiło się tutaj więcej informacji o tym, do czego chcesz używać ogólnych kanałów pomiarowych?

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

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

BTW pokażecie te wyniki ankiety ?

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.

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

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ę

[klew]

Właśnie odwrotnie, prosty kanał do diy powinien być już dawno. Mielibyście o 95% mniej próśb o kolejne pierdółki. Gdyby dało się przesyłać w

Ale tego nie było i nie ma. Możemy rozmawiać o tym co jest, a nie o tym, co kilka lat temu można było zrobić?

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.
To, że finalnie w Blynku to jest proste dla użytkownika, wcale nie oznacza, że implementacja tego była prosta.

[SOYER]

Właśnie odwrotnie, prosty kanał do diy powinien być już dawno. Mielibyście o 95% mniej próśb o kolejne pierdółki. Gdyby dało się przesyłać w

Ale tego nie było i nie ma. Możemy rozmawiać o tym co jest, a nie o tym, co kilka lat temu można było zrobić?

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.
To, że finalnie w Blynku to jest proste dla użytkownika, wcale nie oznacza, że implementacja tego była prosta.

Nie chcę być złośliwy, ale ile trwa implementacja kpop? 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.