Sonoff Bridge RF 433

[rollieT]

Mam pytanie czy ktoś sprawdzał możliwość sterowania za pomocą tej bramki roletami a w zasadzie silnikami firmy Yooda?
W RF-Linku działają ciekawi mnie czy i tutaj by działały?

[kpisiek]

Ucieszyłem się gdy zobaczyłem, że RF wspierany przez supla. Ale po zaprogramowaniu i zobaczeniu funkcjonalności to totalna lipa.

Nie ukrywam, że widziałbym obsługę MQTT, czy np Domoticza - RF odczytuje kody z pilota i np domoticz wykonuje komendy dla niego.

A tu tylko kopiujemy i możemy wyzwalać z RFa kody szkoda.

Pomyśleć,że przeleżał 2 lata w garażu i chyba dalej poleży.

[klew]

Ucieszyłem się gdy zobaczyłem, że RF wspierany przez supla. Ale po zaprogramowaniu i zobaczeniu funkcjonalności to totalna lipa.

Nie ukrywam, że widziałbym obsługę MQTT, czy np Domoticza - RF odczytuje kody z pilota i np domoticz wykonuje komendy dla niego.

A tu tylko kopiujemy i możemy wyzwalać z RFa kody szkoda.

Pomyśleć,że przeleżał 2 lata w garażu i chyba dalej poleży.

Pokaż swój soft, ocenimy czy to lipa, totalna lipa, czy może dąb.

[kpisiek]

wyraziłem swoje zdanie, że programowanie przekaźnika i tylko z poziomu jego aktywowanie funkcji jest przydatne tylko stacjonarnie

a skoro w nazwie jest Bridge "most", to chciałbym np przypisywać komendy pod dany kod, gdzie w punkcie A naciskam guzik RF z pilota - most wyłapuje - przesyła do przekaźnika daną komendę

Tasmota daje takie możliwości, ale jest nie Polska - my Polacy powinni mieć bardziej rozbudowane(uniwersalne) wersje by pokazać kto tu rządzi - a tymczasem skupiamy się tylko na jednej platformie , brooker by sie przydał

byłbym skłonny nawet zapłacić za funkcję która by mi umożliwiła takie funkcje = skanera który przesyła do brokera, a ha wykonuje komendy

[pzygmunt]

Problem w tym, że oczekiwań jest bardzo dużo i my również chcielibyśmy aby było więcej, lepiej i szybciej. Projekty, które tutaj się pojawiają to często wynik pracy, którą ktoś wykonał w ramach swojego prywatnego czasu realizując hobby. Nie są to kompleksowe rozwiązania, ale i tak chwała im za to, że cokolwiek udostępnili. Z 6000 forumowiczów zaledwie kilkanaście osób aktywnie dzieli się wiedzą i tym co uda im się stworzyć, za co wszystkim im dziękuję. "my Polacy" nie lubimy się dzielić swoją pracą co już wielokrotnie tutaj zauważyłem. Najchętniej opatentować, schować i sprzedać. Co więcej są tacy, którzy wykorzystują pracę innych, pakują w pudełko ukrywając co jest w środku i sprzedają olewając klienta jak trzeba mu pomóc. Proporcjonalnie do tego jak projekt się rozrasta rośnie liczba osób, które są z czegoś niezadowolone. Te osoby są zwykle najgłośniejsze. Niestety poza pretensjami nic nie wnoszą. Nominalnie będzie to już całkiem spora grupa. Procentowo to zaledwie 1-3%.

Mój wywód nie ma na celu "odbicia piłeczki", a bardziej uświadomienie gdzie jesteśmy i z czym się borykamy. Nie jesteśmy Tuya w którą ktoś zainwestował 200 mln USD. Jesteśmy grupą ludzi, która rozwija projekt skromnymi zasobami jak na realia IT w Polskiej rzeczywistości.
Konstruktywna krytyka, sugestie co zmienić, jak poprawić, w jakich kierunkach pójść itd itp. są zawsze mile widziane. Bezrefleksyjne punktowanie nas z każdej strony patrząc tylko na fragment obrazka jest zwyczajnie nie fair. Tym bardziej jeśli obrywa się komuś, kto zbudował na własne potrzeby oprogramowanie do bramki RF, które z założenia nie miało być kombajnem i się tym po prostu podzielił. Mógł przecież wyjść z założenia, że "my Polacy" się nie dzielimy i nas olać.

[klew]

wyraziłem swoje zdanie, że programowanie przekaźnika i tylko z poziomu jego aktywowanie funkcji jest przydatne tylko stacjonarnie

a skoro w nazwie jest Bridge "most", to chciałbym np przypisywać komendy pod dany kod, gdzie w punkcie A naciskam guzik RF z pilota - most wyłapuje - przesyła do przekaźnika daną komendę

Tasmota daje takie możliwości, ale jest nie Polska - my Polacy powinni mieć bardziej rozbudowane(uniwersalne) wersje by pokazać kto tu rządzi - a tymczasem skupiamy się tylko na jednej platformie , brooker by sie przydał

byłbym skłonny nawet zapłacić za funkcję która by mi umożliwiła takie funkcje = skanera który przesyła do brokera, a ha wykonuje komendy

Mogę podjąć się przygotowania dowolnego programu. Podeślij proszę w miarę dokładną specyfikację (na jakim sprzęcie ma to działać, jakie funkcjonalności byś tam chciał mieć). W zależności od zakresu prac, koszt wahałby się pewnie między 3500 a 12000 zł (z VAT) (dokładną kwotę mogę podać po ustaleniu bardziej szczegółowego zakresu prac). Jeśli aplikacja ma współpracować z Suplą, to robimy to na oprogramowaniu open source, więc dostaniesz kod źródłowy z aplikacją i jeśli chciałbyś to komuś udostępnić/sprzedać w jakiejkowliek formie, to musiałbyś również udostępniać kod źródłowy. Ewentualnie możemy to od razu opublikować jako open source i byłbys po prostu "sposorem projektu". W tej kwocie dostałbyś gotową aplikację wraz z ewentualnymi poprawkami błędów jeśli takie by się znalazły. Ewentualna dalsza rozbudowa jest do ustalenia osobno.

[dude]

Trochę się pobawiłem tym softem
1. Sensory całkowicie nie działają - nie zmieniają stanów po odebraniu poprawnych kodów.
2. Przekaźnik z podwójnym kodem RF (inny kod dla stanu ON oraz OFF) umożliwia wysyłanie i odbieranie kodów dla obu stanów "ON" oraz "OFF". Ta funkcjonalność działa w zasadzie chyba tak jak trzeba.
3. Przekaźnik z pojedynczym kodem RF (jeden kod dla stanu ON oraz OFF) umożliwia tylko odbieranie kodu stanu "ON". Drugie odebranie tego samego kodu nie powoduje przejścia kanału w stan "OFF", a powinno. Nie działa tutaj również wysyłanie kodów.


Podczas kompilacji błędy dotyczą właśnie sensorów. Dwie linie kodu wywalają kompilację. Próbowałem dodawać tam ten drugi oczekiwany argument typu bool, kompilacja przechodzi, ale po wgraniu na moduł nic to nie zmienia pod kątem funkcjonowania sensorów - nie działają.

Linie które wywalają kompilację: vSensor[channel] = new Supla::Sensor::Binary(vPin);
Tak dokładniej chodzi o to:

Code: Select all

		int vPin = 0;
		for (uint8_t channel = 0; channel < CHANNELS; channel++) {
			vPin = channel + VPIN_OFFSET;
			if(rfChannel[channel].channelType == CHANNEL_TYPE_RELAY) {
				vRelay[channel] = new Supla::Control::Relay(vPin);
			}
			else if(rfChannel[channel].channelType == CHANNEL_TYPE_SENSOR) {
				vSensor[channel] = new Supla::Sensor::Binary(vPin);
			}
			else if(rfChannel[channel].channelType == CHANNEL_TYPE_RELAY1) {
				vRelay[channel] = new Supla::Control::Relay(vPin);
			}
			else if(rfChannel[channel].channelType == CHANNEL_TYPE_SENSOR1) {
				vSensor[channel] = new Supla::Sensor::Binary(vPin);
			}
		}

Konsola:

Code: Select all

In function 'void setup()':
error: no matching function for call to 'Supla::Sensor::Binary::Binary(int&)'
vSensor[channel] = new Supla::Sensor::Binary(vPin);
                                                      ^
supla-arduino-master\src/supla/sensor/binary.h:28:3: note: Supla::Sensor::Binary::Binary(int, bool)
   Binary(int pin, bool pullUp);
   ^
supla-arduino-master\src/supla/sensor/binary.h:28:3: note:   candidate expects 2 arguments, 1 provided
supla-arduino-master\src/supla/sensor/binary.h:26:7: note: constexpr Supla::Sensor::Binary::Binary(const Supla::Sensor::Binary&)
 class Binary : public ChannelElement {
       ^

A teraz coś użytecznego. Skoro działa odczyt kodów RF dla przekaźników, można zrealizować zapalanie światła na określony czas po odebraniu takiego kodu (na przykład z czujnika PIR). Co prawda cały czas wykorzystuję po stronie Supli kanał przekaźnika zamiast sensora, ale ważne, że działa.


1. Kanał oświetlenia zmieniamy na funkcję automatu schodowego. Po jego włączeniu i ustawionym czasie nastąpi powrót do stanu OFF.



2. Na Sonoff Bridge ustawiamy kod dla przekaźnika ON/OFF.



3. W cloud ustawiamy funkcję dodanego przekaźnika jako włącznik zasilania.



4. Za pomocą skryptów tworzymy scenę, która będzie przywracała stan "OFF" kanału z RF Bridge. Warunkiem wywołania sceny jest ID kanału przekaźnika z poprzedniego kroku, tak samo na tym kanale podejmowana jest akcja po upłynięciu ustawionego czasu.



5. Za pomocą skryptów tworzymy scenę, która po włączeniu kanału PIR powoduje włączenie kanału z oświetleniem. Warunkiem wywołania sceny jest ID kanału z PIR (z korku 3), natomiast akcję wywołujemy na kanale z oświetleniem - z kroku 1.



Oczywiście sceny z kroków 4 i 5 można połączyć w jedną. Opóźnienie między zadziałaniem czujnika PIR, a włączeniem oświetlenia to około 3 sekundy. Generalnie na tym sofcie mimo błędów da się ogarnąć całkiem sporo np. powiadomienia push z czujników zalania. Trzeba tylko trochę pokombinować Dzięki za kawał pracy @Goral64

[plnuker]

Trochę się pobawiłem tym softem
1. Sensory całkowicie nie działają - nie zmieniają stanów po odebraniu poprawnych kodów.
2. Przekaźnik z podwójnym kodem RF (inny kod dla stanu ON oraz OFF) umożliwia wysyłanie i odbieranie kodów dla obu stanów "ON" oraz "OFF". Ta funkcjonalność działa w zasadzie chyba tak jak trzeba.
3. Przekaźnik z pojedynczym kodem RF (jeden kod dla stanu ON oraz OFF) umożliwia tylko odbieranie kodu stanu "ON". Drugie odebranie tego samego kodu nie powoduje przejścia kanału w stan "OFF", a powinno. Nie działa tutaj również wysyłanie kodów.


Podczas kompilacji błędy dotyczą właśnie sensorów. Dwie linie kodu wywalają kompilację. Próbowałem dodawać tam ten drugi oczekiwany argument typu bool, kompilacja przechodzi, ale po wgraniu na moduł nic to nie zmienia pod kątem funkcjonowania sensorów - nie działają.

Linie które wywalają kompilację: vSensor[channel] = new Supla::Sensor::Binary(vPin);
Tak dokładniej chodzi o to:

Code: Select all

		int vPin = 0;
		for (uint8_t channel = 0; channel < CHANNELS; channel++) {
			vPin = channel + VPIN_OFFSET;
			if(rfChannel[channel].channelType == CHANNEL_TYPE_RELAY) {
				vRelay[channel] = new Supla::Control::Relay(vPin);
			}
			else if(rfChannel[channel].channelType == CHANNEL_TYPE_SENSOR) {
				vSensor[channel] = new Supla::Sensor::Binary(vPin);
			}
			else if(rfChannel[channel].channelType == CHANNEL_TYPE_RELAY1) {
				vRelay[channel] = new Supla::Control::Relay(vPin);
			}
			else if(rfChannel[channel].channelType == CHANNEL_TYPE_SENSOR1) {
				vSensor[channel] = new Supla::Sensor::Binary(vPin);
			}
		}

Konsola:

Code: Select all

In function 'void setup()':
error: no matching function for call to 'Supla::Sensor::Binary::Binary(int&)'
vSensor[channel] = new Supla::Sensor::Binary(vPin);
                                                      ^
supla-arduino-master\src/supla/sensor/binary.h:28:3: note: Supla::Sensor::Binary::Binary(int, bool)
   Binary(int pin, bool pullUp);
   ^
supla-arduino-master\src/supla/sensor/binary.h:28:3: note:   candidate expects 2 arguments, 1 provided
supla-arduino-master\src/supla/sensor/binary.h:26:7: note: constexpr Supla::Sensor::Binary::Binary(const Supla::Sensor::Binary&)
 class Binary : public ChannelElement {
       ^

A teraz coś użytecznego. Skoro działa odczyt kodów RF dla przekaźników, można zrealizować zapalanie światła na określony czas po odebraniu takiego kodu (na przykład z czujnika PIR). Co prawda cały czas wykorzystuję po stronie Supli kanał przekaźnika zamiast sensora, ale ważne, że działa.


1. Kanał oświetlenia zmieniamy na funkcję automatu schodowego. Po jego włączeniu i ustawionym czasie nastąpi powrót do stanu OFF.



2. Na Sonoff Bridge ustawiamy kod dla przekaźnika ON/OFF.



3. W cloud ustawiamy funkcję dodanego przekaźnika jako włącznik zasilania.



4. Za pomocą skryptów tworzymy scenę, która będzie przywracała stan "OFF" kanału z RF Bridge. Warunkiem wywołania sceny jest ID kanału przekaźnika z poprzedniego kroku, tak samo na tym kanale podejmowana jest akcja po upłynięciu ustawionego czasu.



5. Za pomocą skryptów tworzymy scenę, która po włączeniu kanału PIR powoduje włączenie kanału z oświetleniem. Warunkiem wywołania sceny jest ID kanału z PIR (z korku 3), natomiast akcję wywołujemy na kanale z oświetleniem - z kroku 1.



Oczywiście sceny z kroków 4 i 5 można połączyć w jedną. Opóźnienie między zadziałaniem czujnika PIR, a włączeniem oświetlenia to około 3 sekundy. Generalnie na tym sofcie mimo błędów da się ogarnąć całkiem sporo np. powiadomienia push z czujników zalania. Trzeba tylko trochę pokombinować Dzięki za kawał pracy @Goral64

No właśnie, sensory chyba nie działają bo testowałem z sonoff DW1
- elegancko się wykrywają i parują
- kanały tak samo widać w aplikacji
- zmianę stanu sensora widać po sygnalizacji na plytce RF (diody czerwona/niebieska)

niestety w aplikacji zima, brak reakcji na cokolwiek

ps. posprawdzam na kanale przekaznika:)

[Goral64]

Obiecuję, że niebawem nad tym siądę.

[klimasstudio]

Czy FIRMWARE znajdzie się na https://gui-generic-builder.supla.io/ ?