Szablony powiadomień

[klew]

@zzrr nie da się obecnie. Natomiast rozmawiamy i zbieramy pomysły. To jest trochę eksperymentalny feature.

@vajera czego dokładnie serwer nie aktualizuje? Lub co by się tam przydało, aby było sprawniej?

[zzrr]

...

Kolega @zzrr jest znany tutaj z tworzenia podobnych problemów (XY)
Aby jednak oddać sprawiedliwość, to muszę napisać, że jak już dokładnie wytłumaczy (zdefiniuje) problem, to można na tej podstawie zaproponować nowe, ciekawe rozwiązania
To chyba osoba z największa liczbą "Edit:" w treściach wiadomości

To nie był problem X,Y ponieważ dobrze wytłumaczyłem najpierw do czego mi to potrzebne a nie prosiłem o Y

[Zibi_007]

@vajera to może nawiązując do tego co mówiłeś faktycznie warto by odblokować to pole tekstu? Można by w sumie wyłączyć domyślne ON/OFF a dać jako domyślny tekst " {% if true %} ON {% else %} OFF {% endif %} " Jak by ktoś nie był zapoznany z tymi komendami to mu będzie domyślnie przychodzić ON/OFF a zawsze będzie można w razie czego wstawić dłuższy blok. Jak myślisz?

Tak się nie da - w przypadku tych powiadomień DIY musisz zdecydować, kto ustawia treść powiadomienia - bramka czy użytkownik w Cloud - nie ma możliwości zdefiniowania domyślnego tekstu w przypadku tej drugiej opcji.
Dodatkowo serwer zapamiętuje to ustawienie przy pierwszej rejestracji kanału i nie reaguje na późniejsze zmiany - musisz usunąć i dodać ponownie urządzenie podwykonawcze w Cloud.
Osoby, które obecnie korzystają z tego rozwiązania nie zauważyłyby różnicy do momentu dodania urządzenia ponownie/dodania nowej bramki i na pewno pojawiłyby się zgłoszenia błędu i skargi. Jedyna opcja to dodać przełącznik, który domyślnie będzie rejestrować powiadomienia "po staremu".

Kolejny "przełącznik"? Też będą pytania. Ale chyba nie ma innej opcji.
Tutaj @klew miał kiedyś rację pisząc o "wyprzedzaniu" rozwiązań z SD i możliwych konsekwencjach.
Wiem, to nie jest dokładnie tak, ale coś trzeba będzie na to poradzić i mieć na uwadze kolejne nowości wprowadzane w bramce...

[zzrr]

...
Kolejny "przełącznik"? Też będą pytania. Ale chyba nie ma innej opcji.
Tutaj @klew miał kiedyś rację pisząc o "wyprzedzaniu" rozwiązań z SD i możliwych konsekwencjach.
Wiem, to nie jest dokładnie tak, ale coś trzeba będzie na to poradzić i mieć na uwadze kolejne nowości wprowadzane w bramce...

Nie. Chyba nie. Nie wiem czy to chodziło vajerze o kolejny przełącznik. Ja fakt wcześniej pisałem o przełączniku ale nie w kontekście tworzenia jakiegoś nowego kanału tylko że sobie można dodać po prostu z bramki VR żeby go wykorzystywać jako warunek wysłania lub niewysłania wiadomości.

[vajera]

@zzrr nie da się obecnie. Natomiast rozmawiamy i zbieramy pomysły. To jest trochę eksperymentalny feature.

@vajera czego dokładnie serwer nie aktualizuje? Lub co by się tam przydało, aby było sprawniej?

Pisałem już kiedyś o tym - z mojej analizy kodu serwera Supla wynika, że są dwie funkcje - add channel I update channel - tylko ta pierwsza pozwala na ustawienie np. device sub_id albo właśnie tych powiadomień.
Widziałem również, że dostępna jest funkcja update channel functions, której SD używa właśnie do zmiany funkcji kanału. Pytanie, czy wchodzi w grę dodanie funkcji, które mogłyby zmienić np. te ustawienia powiadomień bez usuwania i dodawania kanału - chodzi mi o te ustawienia, które definiują kto ustala treść powiadomienia i tytuł powiadomienia.

[Zibi_007]

...
Kolejny "przełącznik"? Też będą pytania. Ale chyba nie ma innej opcji.
Tutaj @klew miał kiedyś rację pisząc o "wyprzedzaniu" rozwiązań z SD i możliwych konsekwencjach.
Wiem, to nie jest dokładnie tak, ale coś trzeba będzie na to poradzić i mieć na uwadze kolejne nowości wprowadzane w bramce...

Nie. Chyba nie. Nie wiem czy to chodziło vajerze o kolejny przełącznik. Ja fakt wcześniej pisałem o przełączniku ale nie w kontekście tworzenia jakiegoś nowego kanału tylko że sobie można dodać po prostu z bramki VR żeby go wykorzystywać jako warunek wysłania lub niewysłania wiadomości.

Znowu nie czytasz całości konwersacji, tylko skupiasz się na ostatnim poście.

Osoby, które obecnie korzystają z tego rozwiązania nie zauważyłyby różnicy do momentu dodania urządzenia ponownie/dodania nowej bramki i na pewno pojawiłyby się zgłoszenia błędu i skargi. Jedyna opcja to dodać przełącznik, który domyślnie będzie rejestrować powiadomienia "po staremu".

[vajera]

...
Kolejny "przełącznik"? Też będą pytania. Ale chyba nie ma innej opcji.
Tutaj @klew miał kiedyś rację pisząc o "wyprzedzaniu" rozwiązań z SD i możliwych konsekwencjach.
Wiem, to nie jest dokładnie tak, ale coś trzeba będzie na to poradzić i mieć na uwadze kolejne nowości wprowadzane w bramce...

Nie. Chyba nie. Nie wiem czy to chodziło vajerze o kolejny przełącznik. Ja fakt wcześniej pisałem o przełączniku ale nie w kontekście tworzenia jakiegoś nowego kanału tylko że sobie można dodać po prostu z bramki VR żeby go wykorzystywać jako warunek wysłania lub niewysłania wiadomości.

Sprawa jest następująca - rejestrując takie powiadomienie DIY bramka musi zdecydować:
a) kto ustala treść powiadomienia,
b) kto ustala tytuł powiadomienia.

Jest to operacja jednorazowa, przy pierwszej rejestracji kanału, późniejsze zmiany nie dają efektu - musisz usunąć i dodać kanał ponownie.

Przełącznik działałby jak ten od AT, z tym, że domyślnie byłby wyłączony, więc powiadomienia dodawałyby się na dotychczasowych zasadach. Po włączeniu dodając nowy kanał bramka zostawiałaby opcję ustawiana treści dla Coud.

[zzrr]

Wystarczyło powiedzieć "przełącznik o którym mówiłem wczoraj"
EDIT:
@vajera a coś się dzieje w temacie pushover czy wypadło?

[vajera]

Wystarczyło powiedzieć "przełącznik o którym mówiłem wczoraj"
EDIT:
@vajera a coś się dzieje w temacie pushover czy wypadło?

Pushover czekał na nowe powiadomienia w Supla - pytanie, jak ta nowa funkcjonalność powiadomień ma się do potrzeby implementowania Pushover. Nie mam doświadczenia z Pushover, ale na pierwszy rzut oka nowe możliwości powiadomień Supla wydają się bardziej atrakcyjne z punktu widzenia użytkownika tego systemu?

[zzrr]

...
Pushover czekał na nowe powiadomienia w Supla - pytanie, jak ta nowa funkcjonalność powiadomień ma się do potrzeby implementowania Pushover. Nie mam doświadczenia z Pushover, ale na pierwszy rzut oka nowe możliwości powiadomień Supla wydają się bardziej atrakcyjne z punktu widzenia użytkownika tego systemu?

Jak najbardziej nowa możliwość spersonalizowania powiadomień w SUPLA to bardzo fajny krok do przodu w temacie konstruowania powiadomień. Jednak uważam że powiadomienia pushover i ta nowość w SUPLA to dwie różne rzeczy. Przynajmniej na ten moment. Pushover to różny sposób powiadomienia o różnych zdarzeniach. A obecne nowe w supli to różny, bardziej profesionalny sposób ich konstruowania. Takie jest moje zdanie. Nie zastępuje jedno drugim. Ale to moje zdanie. Jeśli zechcę syrenę przy wykryciu wody na piętrze to mi tego inja nie załatwi. I tak samo pushover jeśli zechcę mieć jakiś raport stanów z rożnych kanałów przy jakimś zdarzeniu. Nawet bym powiedział że jedno z drugim może być mega.