Kontrakton bramy garażowej

Na początku chciałbym się przywitać jestem nowy. Mam swieżo zainstalowany aktualny HA na RPi3+. podpięte parę sensowrów z Supli po mqtt. ale aktualnie walczę z Sonoff SV. służy jako sterowanie bramy garażowej, wgrana najnowasz tasmota i podpięty poprzez integrację Tasmota. sam przekażnik działa OK co prawda jako zwykły switch ale jest OK. nie umiem za to uzyskać informacji o podpiętym kontaktronie do GPIO14. W tasmota mam GPIO14 ustawione jako switch3 w konsoli co jakiś czas idzie info
08:47:30.544 MQT: tele/tasmota_28C9E5/SENSOR = {“Time”:“2022-06-20T08:47:30”,“Switch2”:“OFF”}. ,
Switchmode2 ustawione na 1
niestety w HA nie umiem - nie wykrywa mi encji odpowiedzialnej za ten switch/kontaktron

po dalszym przeczesywaniu sieci dodałem do pliku configuration.yaml poniższy wpis :
binary_sensor:

  • platform: mqtt
    name: Brama-garazowa
    state_topic: “DVES_28C9E5_fb/cmnd/POWER2”
    payload_on: “ON”
    payload_off: “OFF”
    device_class: door

pojawiła się encja którą dodałem do karty bramy garażowej niestety cały czas ma status “nieznany”
na tasmocie mam ustawiony Switchtopic “DVES_28C9E5_fb”
ktoś może jakieś sugestie co nie tak ?

…a druga końcówka kontaktrona do czego podłączona - GND/VCC ?
Stan OFF jest ze zbliżonym magnesem?

Druga końcówka do GND, stan OFF na zbliżonym magnesie

Odłącz w ogóle kontaktron od GPIO i zobacz czy zmieni się stan.
Jeśli się nie zmieni to dodaj rezystor podciągający ok 4k7 - 10k pomiędzy gpio14<>VCC

1 Like

po otwarciu bramy - kontaktron się rozjechał mam status:
12:43:09.651 MQT: tele/tasmota_28C9E5/SENSOR = {“Time”:“2022-06-20T12:43:09”,“Switch2”:“ON”}
czyli zmiana na ON, odwórcone stany wynikają z switchmode2 1
kwestia tylko czemy HA nie łapie i nie wyświetla stanu sensora, status nieznany i w histori nie ma żadnej aktywności, pytanie czy moj wpis binary_sensor w configuration.yaml jest poprawny ?

Ten nie jest…

state_topic: “DVES_28C9E5_fb/cmnd/POWER2”

Stan jest w temacie tele… co prawda nie jest on odświeżany natychmiast ale co ok 300sek.
Jest na to obejście, ale na początek wystarczy.
Zmien /dodaj w .yaml

state_topic: tele/tasmota_28C9E5/SENSOR
value_template: "{{ value_json.Switch2 }}"

Zacznij od wykluczenie możliwego błędu w state_topic, skorzystaj z programu MQTT Explorer i upewnij się w jakim temacie masz podawany stan kontaktronu.

powyższe zmiany dały efekt :slight_smile: dziękuje bardzo, teraz mam status zamknięte przy zamkniętej bramie, fakt odświeżanie jest co 300s. zaraz postaram się zgłebić temat MQTT stat tele i cmnd i ewentualnie jak obejść to odświezanie co 300s

Może łatwiej będzie ogarnąć to przez ESPHome:

EDIT:

Możesz użyć SwitchMode 15

narazie podpiołem pierwszy moduł na tasmocie przeflashowanie na ESPhome to nie problem.
Pytanie czy Tasmota lepsza od ESPhome czy odwrotnie ewentualnie co wybrać może ktoś ma jakieś sugestie
ps. MQTT Explorer już sciagłem :slight_smile:

Tego nie da się porównać na zasadzie lepsze - gorsze, to są różne filozofie podejścia do uzyskania zasadniczo tego samego efektu końcowego.

Trzeba popróbować i wybrać pod siebie - Tasmota ma nieco szerszą bazę peryferiów (np. czujników) z którymi współpracuje, ESPHome to młodszy i mniejszy projekt, ale dzięki dość ścisłemu powiązaniu z HA (obecnie również finansowemu) ma spore widoki na rozwój i być może pod tym względem różnice się kiedyś wyrównają.

Podstawowym założeniem Tasmoty było jedno uniwersalne binarne firmware “do wszystkiego”, oczywiście ten cel był nie do zrealizowania, bo ESP nie jest z gumy, więc nawet dobrze zoptymalizowany kod zawierający “wszystko” już się nie mieści - stąd specjalizowane wersje buildów Tasmoty do nieco bardziej nietypowych zastosowań.

Natomiast kluczowym założeniem ESPHome był brak binarnego gotowca - kompilujesz sobie sam dopasowany soft pod konkretne zastosowanie (tu to założenie też nie przetrwało, gdy powstał pomysł produkowania urządzeń z preinstalowanym ESPHome, ale to inna para kaloszy), plusem tego rozwiązania jest dużo większa elastyczność licencyjna - można używać kod, którego nie wolno rozpowszechniać w postaci binarnej (np. platforma Bosch BME680 BSEC to wykorzystuje).
Natomiast mimo tego, że kod nie jest prawdopodobnie równie dobrze zoptymalizowany jak w Tasmocie, (bo kluczowym elementem ESPHome jest generator kodu - w najbardziej typowym przypadku użytkownik piszę “gołą” konfigurację na podstawie której jest generowany kod źródłowy i finalnie z niego jest kompilowany kod binarny, choć oczywiście wstawki własnego kodu są też możliwe), to finalnie dzięki temu, że wkompilowywane są jedynie potrzebne biblioteki można “wyprodukować” urządzenia niedostępne “z pudełka” w Tasmocie (bo kod binarny nie zawiera “wszystkiego” a jedynie to z czego istotnie korzystamy, więc np. można upchnąć do jednego firmware funkcje które w Tasmocie wymagałby użycia np. 2 sztuk MCU i 2 różnych firmware, z drugiej strony Tasmotę można modyfikować samodzielnie, ale wtedy to już wypada być programistą “pełną gębą” - “niedzielny programista” raczej tego nie ogarnie w rozsądnych ramach czasowych).

Inna kwestia jest taka, że np. ESPHome integruje się po API bezpośrednio z HA (nie jest potrzebne MQTT, choć ma opcję wykorzystania MQTT by być międzyplatformowe).

Z powyższych (oraz pewnie wielu które pominąłem) powodów Tasmota bardziej się nadaje do instalacji w gotowych prostych urządzeniach, które chcemy np. “odchmurowić”, bo zawiera też mnóstwo “gotowców” pod konkretne modele nieskomplikowanych urządzeń, o co jest trudno w ESPHome (choć przy odrobinie chęci można przekształcić template Tasmoty w działający YAML w ESPHome by uzyskać porównywalną funkcjonalność).

Natomiast ESPHome świetnie się nadaje do budowy własnych konstrukcji DIY “od zera” przy właściwie znikomej wiedzy o programowaniu (wystarczy uważnie czytać dokumentację), jakkolwiek widziałem już bazujące na ESPHome projekty alternatywnego softu dla dość skomplikowanych urządzeń (ale nie składały się one wyłącznie z “gotowych klocków” jakie mamy dostępne standardowo, a zawierały zwykle sporo własnego kodu autora).

Tu trzeba przyznać że dokumentacja ESPHome w porównaniu do dokumentacji Tasmoty wygląda dość biednie (i zbudowana jest mocno rekurencyjnie - każdy “klocek” jest opisany osobno, a do budowy jakiegokolwiek urządzenia trzeba użyć przynajmniej kilku “klocków”) no i szczególnie słabo jest z dobrymi tutorialami (choć dawno nie szukałem czegoś takiego).

3 Likes