Głowice termostatyczne i termostaty ścienne - [bramka ZigBee]

[zzrr]

SuplaDevice też emituje zdarzenia, np device status change

O tym w pierwszej chwili pomyślałem, ale wtedy tak czy inaczej potrzebujemy zdarzenia akcji SEND_STATE.

W sumie może to byłoby najprostsze rozwiązanie:

Supla zdarzenie ON_REGISTERED_AND_READY
kanał docelowy - przekaźnik Zigbee (źródło ciepła)
akcja SEND_STATE

wtedy przekaźnik Zigbee w handleAction() na akcję SEND_STATE generuje zdarzenie ON_TURN_ON, które trafia do VR?

Przyznaje się że nie do końca rozumiem. Czemu kanał docelowy - przekaźnik Zigbee (źródło ciepła)? Docelowym miał być VirtualBinary i SET nie TURN_ON. Hmm Jakimiś szyframi rozmawiacie

[Robert Błaszczak]

A ja tylko mam prośbę. Aby być ostrożnym z pisaniem funkcjonalności pod potrzeby jednego użytkownika. Które to potrzeby będą obsługiwane przez dodatkowy(e) kanał(y) w Supli.

[zzrr]

A ja tylko mam prośbę. Aby być ostrożnym z pisaniem funkcjonalności pod potrzeby jednego użytkownika. Które to potrzeby będą obsługiwane przez dodatkowy(e) kanał(y) w Supli.

Ale to nie ma być pod potrzeby jednego użytkownika. To będzie użyteczne w przypadku każdego kto zechce tego używać. Bo będzie mógł a teraz nie.

[vajera]

SuplaDevice też emituje zdarzenia, np device status change

O tym w pierwszej chwili pomyślałem, ale wtedy tak czy inaczej potrzebujemy zdarzenia akcji SEND_STATE.

W sumie może to byłoby najprostsze rozwiązanie:

Supla zdarzenie ON_REGISTERED_AND_READY
kanał docelowy - przekaźnik Zigbee (źródło ciepła)
akcja SEND_STATE

wtedy przekaźnik Zigbee w handleAction() na akcję SEND_STATE generuje zdarzenie ON_TURN_ON, które trafia do VR?

Przyznaje się że nie do końca rozumiem. Czemu kanał docelowy - przekaźnik Zigbee (źródło ciepła)? Docelowym miał być VirtualBinary i SET nie TURN_ON. Hmm Jakimiś szyframi rozmawiacie

Pojedyncza akcja Supla ma kanał źródłowy, zdarzenie z kanału źródłowego, kanał docelowy i akcję na kanale docelowym.

Tutaj potrzebne będą 2 akcje:

1. Gdy SuplaDevice (kanał źródłowy) zmieni stan (zdarzenie = zmiana stanu), to na kanale docelowym (źródło ciepła) wykonaj akcję SEND_STATE.

2. Teraz źródło ciepła jest kanałem źródłowym i w odpowiedzi na akcję SEND_STATE generuje akcję SET na docelowym VB (sorry wcześniej pomyliłem VR z VB) lub CLEAR - w zależności od swojego stanu.

[vajera]

A ja tylko mam prośbę. Aby być ostrożnym z pisaniem funkcjonalności pod potrzeby jednego użytkownika. Które to potrzeby będą obsługiwane przez dodatkowy(e) kanał(y) w Supli.

Zgadzam się z Tobą Robercie w 100%. Niemniej kolega @zzrr trochę przypadkiem podsunął funkcjonalność, której czasami brakuje. Ja od razu pomyślałem, żeby oprócz reakcji na zmianę stanu SuplaDevice dołożyć też kilka akcji czasowych, np. ON_EVERY_30_SECONDS.

[Robert Błaszczak]

Ja jestem zdania, że jeśli nie ma takiej funkcjonalności zaprojektowanej dla wszystkich termostatów Supla, to termostaty z bramki Z2S nie powinny jej wprowadzać. Bo zaraz zacznie się z jednej strony narzekanie, że "ja bym chciał coś takiego w Auratonie" / "po co mi się w bramce Z2S pojawiają jakieś dodatkowe kanały - ja tego nie chcę".

W tym temacie powinien się wypowiedzieć zespół Supli i dać ewentualne "zielone światło".

[vajera]

Ja jestem zdania, że jeśli nie ma takiej funkcjonalności zaprojektowanej dla wszystkich termostatów Supla, to termostaty z bramki Z2S nie powinny jej wprowadzać. Bo zaraz zacznie się z jednej strony narzekanie, że "ja bym chciał coś takiego w Auratonie" / "po co mi się w bramce Z2S pojawiają jakieś dodatkowe kanały - ja tego nie chcę".

W tym temacie powinien się wypowiedzieć zespół Supli i dać ewentualne "zielone światło".

1. Nie będzie dodatkowych kanałów, co najwyżej na liście akcji pojawi się SD.

2. To nie będzie w żadnym wypadku rozszerzenie funkcji termostatów, tylko dostęp do akcji, które i tak generuje SD.

3. Zwróć uwagę na to, że bramka Z2S jest chyba jedynym projektem z ekosystemu Supla (DIY i komercyjne), który daje użytkownikowi dostęp do akcji Supla z poziomu interface-u (Telnet, GUI), pozwalając na ich samodzielne budowanie.

[Robert Błaszczak]

1. Nie będzie dodatkowych kanałów, co najwyżej na liście akcji pojawi się SD.

2. To nie będzie w żadnym wypadku rozszerzenie funkcji termostatów, tylko dostęp do akcji, które i tak generuje SD.

3. Zwróć uwagę na to, że bramka Z2S jest chyba jedynym projektem z ekosystemu Supla (DIY i komercyjne), który daje użytkownikowi dostęp do akcji Supla z poziomu interface-u (Telnet, GUI), pozwalając na ich samodzielne budowanie.

Ok, to ja trochę źle zrozumiałem, bo wydawało mi się, że mają to być dodatkowe kanały. Jeśli ma to być tak jak opisujesz, to oczywiście nie ma tematu.

Odnośnie pkt. 3, to jest to funkcjonalność bramce Z2S konfigurowana z poziomu GUI bramki i w żaden sposób nie ingeruje w aplikację / Cloud. Sam zresztą z tej funkcjonalności chętnie i mocno korzystam.

Łukasz (@vajera), wiem że doskonale rozumiesz o co mi chodzi (aby nie robić jakiś niestandardowych funkcjonalności) i wiem że masz podobne podejście w tym zakresie, więc z mojej strony po Twoich wyjaśnieniach jest zamknięty.

[zzrr]

Ok, to ja trochę źle zrozumiałem, bo wydawało mi się, że mają to być dodatkowe kanały. Jeśli ma to być tak jak opisujesz, to oczywiście nie ma tematu.

Odnośnie pkt. 3, to jest to funkcjonalność bramce Z2S konfigurowana z poziomu GUI bramki i w żaden sposób nie ingeruje w aplikację / Cloud. Sam zresztą z tej funkcjonalności chętnie i mocno korzystam.

Łukasz (@vajera), wiem że doskonale rozumiesz o co mi chodzi (aby nie robić jakiś niestandardowych funkcjonalności) i wiem że masz podobne podejście w tym zakresie, więc z mojej strony po Twoich wyjaśnieniach jest zamknięty.

Robert wszystko przez to że w cloud nie działa przełącznik pokazywania stanu źródła ciepła.
To co @vajera zdecyduje i jeśli finalnie wdroży to nie ma być bezpośrednio to o czym ja napisałem i tylko i wyłącznie żeby sobie belkę włączyć bo akurat mam taki kaprys Ja taką belkę dzięki akcjom w bramce mam zrobioną już w tej chwili i działa. To ma być funkcjonalność dzięki której wskazanie ustawionego VB a może to być i VR i fizyczny inny RELAY który ma przyjąć po restarcie bramki zawsze właściwy stan zgodny z założeniem a nie zrobić buga bo się nie zsynchronizuje właściwie ze stanem źródła ustawionego w akcjach.
Więc to będzie tylko kolejna udoskonalona rzecz w bramce z korzyścią dla każdego kto sobie ustawi jakieś akcje w bramce. Jeśli się w którymś miejscu mylę niech mnie @vajera poprawi bo może też to widzę inaczej niż jest w planach.

[Robert Błaszczak]

@zzrr, już załapałem temat. Ja zrozumiałem początkowo, że do każdego termostatu pojawi się dodatkowy kanał ze stanem źródła ciepła.