Plany

[Robert Błaszczak]

@dobo, wszystko co potrzebujesz, i wiele, wiele więcej otrzymasz (właściwie to kupisz) w systemie KNX.

[klew]

Niedługo rok od ankiety, a co z jej priorytetu zostało.

Rozumiem, że jedyna rzecz, którą dostrzegasz w tej ankiecie to "Kanał pomiarowy ogólnego przeznaczania".

Natomaist odpowiadając na Twoje pytanie, z ankiety "Cloud" zostało zrobione:
1. powiadomienia push - w dużo szerszym zakresie, niż było pierwodnie zakładane (miało być tylko dla kanałów binarnych, on/off itp)
2. Uruchamianie scen/akcji na podstawie czujników (też w dużo szerszym zakresie, niż plan w anakiecie j/w)
4. Można częściowo zrealizować używając reakcji i powiadomień
7. Korekty energii dla każdej fazy osobno
9. Włącznik schodowy w HA
10. włączanie i wyłączenie harmonogramów ze sceny
11. ukrwanie kanałów przed integracjami - zrobione częściowo dla Alexy, GH. Dla MQTT nadal czeka

W kategorii aplikacji, jest dużo słabiej, bo tam zaległości były/są duże, do tego wysypał się człowiek zatrudniony do tego celu i potem było dość długie szukanie nowej osoby, ale mimo wszystko, zostało zrobione:
4. Countdown timer

Ten punkt 4. był też traktowany od storny implementacjnej jako wymagany krok do termostatu i KPOP, dlatego został zrobiony wcześniej.

[pzygmunt]

@dobo wbrew Twoim przypuszczeniom KPOP będzie miał wykresy, a moja odpowiedź dla kolegi @pirat dotyczyła czujników odległości/ głębokości.

Uzupełniając wypowiedź @klew. Wiele funkcji wymaga gruntownej przebudowy aplikacji i to się od kilku miesięcy dzieje. Dotyczy to również KPOP.

[dobo]

Szanowni Panowie mówię to co wszyscy inni myślą ale obawiają się głośno powiedzieć bo zaraz nastąpi na taką osobę atak bardziej lub mniej subtelny.
Robert trzeba było to powiedzieć 4 lata temu, a nie teraz. Bo teraz to wszyscy są mądrzy. Bez urazy

Pewnie jestem głupi ale KPOP również może obsługiwać czujniki odległości/ głębokości - sam akurat na to właśnie czekam.

I teraz pytanie bo może ja czegoś nie kumam. Po co osobne kanały dla temperatury, ciśnienia, wilgotności, odległości, głębokości, nasłonecznienia i innych dupereli gdy powstanie KPOP (chyba, że nie powstanie i dlatego są), w którym po wybraniu jednostki miary mamy tak naprawdę wszystko co napisałem powyżej.

Nie twierdzę, że nic nie jest robione ale głosy były jednoznaczne czego ludzie oczekują w pierwszej kolejności.

[klew]

I teraz pytanie bo może ja czegoś nie kumam. Po co osobne kanały dla temperatury, ciśnienia, wilgotności, odległości, głębokości, nasłonecznienia i innych dupereli gdy powstanie KPOP (chyba, że nie powstanie i dlatego są), w którym po wybraniu jednostki miary mamy tak naprawdę wszystko co napisałem powyżej.

1. Wszystkie te osobne kanały powstały dawno temu.
2. KPOP jest mało przydatny do tzw. komercyjnych urządzeń. W przypadku gotowych urządzeń, powinno się podłączyć urządzenie i wszystko powinno działać bez konieczności ustawiania parametrów, jednostek itp. Dlatego kanały dedykowane do różnych pomiarów będą nadal istnieć. Jeśli coś jest termometrem, to jest termometrem i nie powinno dać się zmienić tego na coś innego.

Nie twierdzę, że nic nie jest robione ale głosy były jednoznaczne czego ludzie oczekują w pierwszej kolejności.

Nie twierdzę, że wiem, czego ludzie oczekują w pierwszej kolejności, ale na pewno ankieta nie oddaje tego "czego ludzie chcą w pierwszej kolejności". Ankieta z grubsza oddaje to czego forumowicze chcą w pierwszej kolejności i to nie wszyscy - zauważ, że "tylko" niecałe 20% osób głosowało na KPOP.

Nie możemy np. nie robić dalszych rzeczy z kategorii "Cloud", bo mamy zaległości w apkach.

[[email protected]]

...

2. KPOP jest mało przydatny do tzw. komercyjnych urządzeń. W przypadku gotowych urządzeń, powinno się podłączyć urządzenie i wszystko powinno działać bez konieczności ustawiania parametrów, jednostek itp. Dlatego kanały dedykowane do różnych pomiarów będą nadal istnieć. Jeśli coś jest termometrem, to jest termometrem i nie powinno dać się zmienić tego na coś innego.

Yhmm a w czym problem, żeby KPOP był by default skonfigurowany jako temperatura jeśli urządzenie wspiera czujnik temp? Z tego co rozumiem to i tak oprogramowanie urządzenia wie czym jest urządzenie, więc i tak ustawia funkcję kanału? Wydaje mi się, że tu by się warto nad tym pochylić i pozbyć się innych kanałów pomiarowy zamiast brnąć w istniejące rozwiązanie.

[Goral64]

Yhmm a w czym problem, żeby KPOP był by default skonfigurowany jako temperatura jeśli urządzenie wspiera czujnik temp? Z tego co rozumiem to i tak oprogramowanie urządzenia wie czym jest urządzenie, więc i tak ustawia funkcję kanału? Wydaje mi się, że tu by się warto nad tym pochylić i pozbyć się innych kanałów pomiarowy zamiast brnąć w istniejące rozwiązanie.

Nie należy zapominać, że pomimo swojej otwartości Supla skierowana jest także do producentów gotowych modułów z konkretnym przeznaczeniem i stąd dedykowane kanały pomiarowe, zamiast ogólnego, który jest potrzebny głównie w rozwiązaniach DYI lub przeróbek innych modułów z dalekiego kraju.
Dlatego ja nie mam nic przeciwko temu, żeby KPOP był obok dedykowanych kanałów pomiarowych.

[klew]

...

2. KPOP jest mało przydatny do tzw. komercyjnych urządzeń. W przypadku gotowych urządzeń, powinno się podłączyć urządzenie i wszystko powinno działać bez konieczności ustawiania parametrów, jednostek itp. Dlatego kanały dedykowane do różnych pomiarów będą nadal istnieć. Jeśli coś jest termometrem, to jest termometrem i nie powinno dać się zmienić tego na coś innego.

Yhmm a w czym problem, żeby KPOP był by default skonfigurowany jako temperatura jeśli urządzenie wspiera czujnik temp? Z tego co rozumiem to i tak oprogramowanie urządzenia wie czym jest urządzenie, więc i tak ustawia funkcję kanału? Wydaje mi się, że tu by się warto nad tym pochylić i pozbyć się innych kanałów pomiarowy zamiast brnąć w istniejące rozwiązanie.

Ale w co tu ktoś "brnie"? Kanał termometru istnieje od dawna i raczej zmian jakichś nie ma
Te istniejące kanały pomiarowe nie konkurują w żaden sposób z KPOP.
Nie pozbędziemy się też tych kanałów, bo nie zmusisz tysięcy użytkowników do aktualizacji softu na urządzeniach i do migracji danych do jakiegoś innego formatu, który w wielu sytuacjach nic nie zmienia.

Do tego do niedawna założenie KPOP było takie, że urządzenie nic nie wie o tym kanale. Ma po prostu pomiar w postaci jakiejś liczby i to wysyła do serwera (gotowa implemnetacja po stronie urządzenia to kilka linijek https://github.com/SUPLA/supla-device/b ... ent_base.h ) . Cała konfiguracja miała być robiona przez użytkownika po stronie Clouda.
Oczywiście robiąc soft na urządzeniu możesz mieć wiedzę, że to jest temperatura, ale w ogólności tak być nie musi.
Raczej nie było też zakładane, że KPOP może mieć zmienaine funkcje (np. termometr, czujnik ciśnienia). KPOP ma funkcję "kanał pomiarowy ogólny" i w jego konfiguracji się wszystko ustawia.

Dopiero funkcjonalności dodane przy termostacie trochę wpływają na tą koncepcję, bo na "dużą skalę" dodaliśmy możliowśc wymiany konfiguracji między urządzeniem a serwerem (w obie strony). Także pewnie ten kawał wykonanej pracy pozwoli na to, aby urządzenie mogło odczytać config KPOP z serwera i dzięki temu na jakimś wyświetlaczu lokalnym pojawi się dobrze sformatowany pomiar z jednostką.
Gdybyśmy wprowadzili KPOP zanim usiedliśmy do termostatów, to by tego na pewno nie było w "pierwszym wydaniu KPOP".

[dobo]

Ankieta z grubsza oddaje to czego forumowicze chcą w pierwszej kolejności i to nie wszyscy - zauważ, że "tylko" niecałe 20% osób głosowało na KPOP.

Ale zajęło 1 miejsce

Jeżeli takie jest podejście do ankiety to jest tak jak mi się ulało i kolejna ankieta z dupy przy takim podejściu

Yhmm a w czym problem, żeby KPOP był by default skonfigurowany jako temperatura jeśli urządzenie wspiera czujnik temp? Z tego co rozumiem to i tak oprogramowanie urządzenia wie czym jest urządzenie, więc i tak ustawia funkcję kanału? Wydaje mi się, że tu by się warto nad tym pochylić i pozbyć się innych kanałów pomiarowy zamiast brnąć w istniejące rozwiązanie.

Nie należy zapominać, że pomimo swojej otwartości Supla skierowana jest także do producentów gotowych modułów z konkretnym przeznaczeniem i stąd dedykowane kanały pomiarowe, zamiast ogólnego, który jest potrzebny głównie w rozwiązaniach DYI lub przeróbek innych modułów z dalekiego kraju.
Dlatego ja nie mam nic przeciwko temu, żeby KPOP był obok dedykowanych kanałów pomiarowych.

[email protected] jestem tego samego zdania.

Goral64 KPOP można oprogramować tak aby jednostkę ustawiać w urządzeniach DIY, a w komercyjnym urządzeniu było to już zrobione przez docelowego producenta w sofcie bez możliwości edycji przez użyszkodnika informacja z urządzenia wędrowała by do CLOUD, które wiedziało by co się z czym je.

Ale w co tu ktoś "brnie"? Kanał termometru istnieje od dawna i raczej zmian jakichś nie ma
Te istniejące kanały pomiarowe nie konkurują w żaden sposób z KPOP.
Nie pozbędziemy się też tych kanałów, bo nie zmusisz tysięcy użytkowników do aktualizacji softu na urządzeniach i do migracji danych do jakiegoś innego formatu, który w wielu sytuacjach nic nie zmienia.

To SUPLA się rozwija czy zostaje z zaszłościami w pewnym momencie może się ich za dużo nazbierać i co wtedy?
Niech wybór jest po stronie użytkownika kiedyś zrobi tą aktualizację.

[[email protected]]

Ale w co tu ktoś "brnie"? Kanał termometru istnieje od dawna i raczej zmian jakichś nie ma
Te istniejące kanały pomiarowe nie konkurują w żaden sposób z KPOP.
Nie pozbędziemy się też tych kanałów, bo nie zmusisz tysięcy użytkowników do aktualizacji softu na urządzeniach i do migracji danych do jakiegoś innego formatu, który w wielu sytuacjach nic nie zmienia.

Do tego do niedawna założenie KPOP było takie, że urządzenie nic nie wie o tym kanale. Ma po prostu pomiar w postaci jakiejś liczby i to wysyła do serwera (gotowa implemnetacja po stronie urządzenia to kilka linijek https://github.com/SUPLA/supla-device/b ... ent_base.h ) . Cała konfiguracja miała być robiona przez użytkownika po stronie Clouda.
Oczywiście robiąc soft na urządzeniu możesz mieć wiedzę, że to jest temperatura, ale w ogólności tak być nie musi.
Raczej nie było też zakładane, że KPOP może mieć zmienaine funkcje (np. termometr, czujnik ciśnienia). KPOP ma funkcję "kanał pomiarowy ogólny" i w jego konfiguracji się wszystko ustawia.

Dopiero funkcjonalności dodane przy termostacie trochę wpływają na tą koncepcję, bo na "dużą skalę" dodaliśmy możliowśc wymiany konfiguracji między urządzeniem a serwerem (w obie strony). Także pewnie ten kawał wykonanej pracy pozwoli na to, aby urządzenie mogło odczytać config KPOP z serwera i dzięki temu na jakimś wyświetlaczu lokalnym pojawi się dobrze sformatowany pomiar z jednostką.
Gdybyśmy wprowadzili KPOP zanim usiedliśmy do termostatów, to by tego na pewno nie było w "pierwszym wydaniu KPOP".

Czysto teoretycznie bo podoba mi się niesamowicie temat KPOP od strony technicznej, gdyż piszę w pracy aplikację typu https://en.wikipedia.org/wiki/Andon_(manufacturing) która na podstawie takiego KPOP prezentuje dane:

Istniejące kanały pomiarowe konkurują o zasoby jak wasz czas a jak widać tego się nie da kupić Z perspektywy programisty - kręcenie bata na siebie, bo skoro teraz to taki wielki problem zrobić KPOP z istniejącego kanału temperatury, to znaczy, że utrzymując KPOP i pozostałe kanały trzeba będzie podwójnej roboty, gdzie KPOP to jest i tak uogólnienie np. temperatury.

Co do wymuszania aktualizacji - no niekoniecznie, wystarczy ze Cloud potrafi interpretować co do niego przychodzi pije do wzorca projektowego Adapter.

A co do konkretów i konfiguracji KPOP - proponowałbym, że urządzenie może zgłosić funkcje kanału (jak teraz każde DIY) oraz jednostkę przesyłanej wartości, ale jak tego nie zrobi to można ustawić w Cloud - czemu tak? Bo elastyczność jest super, ale po zmianach na urządzeniu pojawiają się konflikty, których pewnie można by w ten sposób uniknąć i nie trzeba by konfigurować kanałów wiele razy przy zmianach kodu.