Nie mogę nigdzie znależć działającego przykładu który nakierowałby mnie na rozwiązanie.
Zdefiniowałem sobie pin18 na Switch - w tasmocie w konsoli przy przełączaniu otrzymuję poprawne stany (ON, OFF) które chciałbym połączyć z regułami. Problem jest taki, że chciałbym widzieć też ich stan poprzez broker MQTT w HA i tutaj kompletnie poległem. Np stan przekaźnika z konsoli poznamy wpisując np POWER1 ale wpisując SWITCH1 otrzymuję komunikat unknown command - gdzie popełniam błąd.
Myślałem że stan wyślę za pomocą reguły np.
Rule4 on SWITCH1#state=1 do Publish stat/PC5kW2_0FE780/SWITCH1 ON ENDON ON SWITCH1#state=0 do Publish stat/PC5kW2_0FE780/SWITCH1 OFF ENDON
ale nawet Rule4 dostaję unknown command (czy jest ograniczenie w ilości reguł ?? )
Wszystkie filmy i przykłady jakie obejrzałem dotyczą zazwyczaj przekaźnik sprzężonego ze switchem a u mnie jest inny patent.
Tasmota ma bardzo dobrą dokumentację. Jest obszerna ale daje szeroki obraz tego jak działa logika zastosowana w tej koncepcji. Przeczytaj dział dotyczący reguł, a wieczorem pomogę Ci z resztą.
Już na wstępie masz wytłumaczone, że rule1, rule2, rule3 to zestawy reguł których w każdej z tych grup może być wiele. Tak naprawdę ogranicza je wielkość pamięci.
Tych zestawów może być 3, oprogramowanie nie przewiduje większej ilości zestawów.
Samych reguł może być wiele w zestawie, a podstawą składni każdej jest: ON <trigger> DO <command> [ENDON | BREAK]
Oddzielenie przekaźnika od switcha zrobiłem na początku. O regułach poczytam ponownie bo jakoś mi to umknęło, ale najważniejsze dla mnie jest w jaki sposób przesłać stan switcha przez mqtt do HA. Z tym sobie nie radzę, a to kluczowe dla projektu. Chciałem wykorzystać esp32 z tasmotą do autonomicznego sterowania pompą ciepła z klimatyzatora. Zamysł jest taki, żeby HA zbierał dane i mógł sterować, ale żeby pompa była niezależna jak padnie sieć wifi i działała tylko w oparciu o Tasmote. Pompa przez zimę sterowana była Node-Red ale to mnie nie zadowala i chcę to wszystko uprościć. W ostateczności pewnie się okaże, że trzeba będzie Barry Script użyć :-(.
Nadal nie wiem co chcesz osiągnąć ale zobacz na opcję SwitchMode 15.
(próbuję tego ustawienia ale chyba to nie działa tak jak opisano)
Dodatkowo podpowiem Ci, że jest w dokumentacji bardzo dobrze napisana “książka kucharska” z przykładami użycia reguł.
Możliwe, że na tych przykładach się wzorowałeś…
Nadal nie znam pełnego kontekstu i nie wiem jakie masz założenia automatyzacji. Dlatego nie chcę się naprodukować przy pisaniu reguły, która nie wiem jak ma działać. Nie wiem co robi w Twoich założeniach sterowania switch i czym steruje przekaźnik, skoro przełącznik go nie załącza. Dlaczego ma być to oddzielone od siebie? Do czego potrzebujesz informacji o pozycji switch?
Wytłumacz zatem co ma robić te reguła?
Rule1
ON SWITCH1#state=1 DO Publish stat/PC5kW2_0FE780/SWITCH1 ON ENDON
ON SWITCH1#state=0 DO Publish stat/PC5kW2_0FE780/SWITCH1 OFF ENDON
A najlepiej jak byś opisał całość działania w kontekście sprzętowym tego ESP32…
Przełącznik 2 torowy typu rocker ma na 1 torze zwierać opornik szeregowo podłączony do ntc ustawiając temp. pracy pompy (cwu/co) jednocześnie dając na drugim torze informację o załączeniu poprzez zwarcie do masy PIN18) - to tak w skrócie. Przełącznik będzie przełączany 2 razy w roku stąd nie chcę używać dodatkowego przekaźnika.
Zakładam, że chodzi Ci tylko o uwidocznienie samego stanu przełącznika w HA -zima/lato. Sam fakt przełączenia robisz tylko ręcznie tym fizycznym przełącznikiem? Nie potrzebujesz fizycznie przekaźnika? Nie chcesz tego robić zdalnie z HA?
EDIT:
Czekając na odpowiedzi…
Ja bym ustawił to w ten sposób:
Opiszę w skrócie cały projekt - pompa 5kW z klimatyzatora Heiko z wymiennikiem rurowym 9 kW (w rzeczywistości podejrzewam max 2.2 kW ze względu na opory przepływu podłogówki). Ambitne założenia mówiły na początku o przełączaniu pompy ciepła (PC) w tryb grzania wody (CWU) lub ogrzewania domu (CO). Życie te plany zweryfikowało - nie ma to dla mnie najmniejszego sensu stąd maksymalne uproszczenie konstrukcji. Jakie pomysły poszły do kosza - na dzień dzisiejszy:
wyświetlacz do temperatur - po co - w kotłowni nikt nie będzie go oglądał,
sterowanie zaworem 3-drogowym CWU/CO - po co - przełączam 2 razy do roku za pomocą przełącznika monostabilnego 2-kierunkowego (ogólnie szkoda było pieniędzy - wystarczyłby zawór 3-drogowy mechaniczny)
skomplikowane histerezy grzewcze - wyłączanie/ włączanie grzania - po co - przy inercji układu na poziomie 6 godzin opartego w całości na podłogówce nie ma to większego sensu - oszczędności na prądzie są “symboliczne”.
Jak obecnie chcę skonstruować układ ?
Układ sprzężony jest z piecem gazowym poprzez przekaźnik 220 V MY4NJ. Przekażnik ten ma 4 zadania do wykonania:
odcina pompę obiegową PC na czas załączenia pieca,
przełącza zawór 2- drożny odcinając dopływ gorącej wody z pieca do wymiennika rurowego PC,
wyłącza PC poprzez wykorzystanie złącza “ROOM CARD” klimatyzatora,
przekazuje do tasmoty informację za pomocą switcha, że piec jest uruchomiony (Switch2 w Tasmocie),
W Tasmocie mamy do wysterowania/pobrania informacji:
2 przekażniki - jeden steruje pompą obiegową PC, drugi załączaniem PC poprzez “ROOM CARD”
2 switche - jeden pobiera informację z przełącznika mechanicznego typu rocker czy chcemy grzać PC czy CWU (zima/lato), drugi pobiera informację czy piec w danym momencie nie jest uruchomiony
przepływomierz spięty jako Counter 1 - takie dodatkowe zabezpieczenie jakby pompa obiegowa miała awarię (ale to raczej sterowane przez NODE-RED)
7 termometrów (GAZ IN, GAZ OUT, H20 IN, H2O OUT, CWU RETURN, CO RETURN, CWU) z czego tak na prawdę Tasmota lokalnie potrzebuje 3-ch CWU, CWU RETURN do sterowania grzaniem wody i CO RETURN do sterowania grzaniem podłogi.
Układ ma być podłączony z HA aby był podgląd parametrów i statystyki stąd potrzebne informacje o stanie SWITCH’y w TASMOCIE.
Z termometrami w regułach sobie raczej radzę, z przekaźnikami też, nie mogę opanować tylko Switchy.
Układ ma być możliwie jak najbardzie prymitywny bo muszę wytłumaczyć żonie jak się go obsługuje na zasadzie - 2 przełączniki w dół - tu zobaczysz że sie zaświeciło i jeden przycisk trzymasz 10 sekund i tak 2 razy w roku na początek i koniec sezonu - reszta ją nie obchodzi.
Zobacz co napisałem powyżej pogrubionym tekstem. Nie trzeba mieć fizycznie podłączonego przekaźnika ale należy go przypisać (wirtualnie) do któregoś GPIO aby switch uwidocznił się jako encja w HA.
Jako, że masz jeszcze parę wolnych GPIO to myślę, że najprościej będzie stworzyć kolejne dwie pary switch3 z relay3 oraz switch4 z relay4 tylko po to aby mieć wszystko co potrzebujesz w HA.
Czyli dla:
2 przekażniki - jeden steruje pompą obiegową PC, drugi załączaniem PC poprzez “ROOM CARD”
tworzysz osobne switch3 z relay_i 3 oraz switch4 z relay_i 4.
A dla
2 switche - jeden pobiera informację z przełącznika mechanicznego typu rocker czy chcemy grzać PC czy CWU (zima/lato), drugi pobiera informację czy piec w danym momencie nie jest uruchomiony
będą pary switch1 z relay1 oraz switch2 z relay2 (bez fizycznie podłączonych przekaźników pod GPIO).
Da się to zrobić za pomocą reguły w Tasmota.
I w tym momencie przyznam rację dla @macek. W ESPHome możesz to uszyć na miarę pod własne potrzeby, wraz z ikonami dla HA i wszystkim innym, jak choćby automatyzacje zapisane w ESP (odpowiednik reguł Tasmota). Jeśli nie straszny Ci YAML to z naszą pomocą zrobisz to raz i będzie idealne dla tego zastosowania.
Nie upieram się nad Tasmotą - w zasadzie wszystkie pozostałe ESP mam ESPHHOME więc chętnie przejdę z powrotem na ESPHOME, z YAML radzę sobie tak mniej więcej.
Co do obecnych ustawień to mam tak:
Jakie wyciągnąłem wnioski - nie jest potrzebny wirtualny przekaźnik - chyba że chcemy na stronie Tasmoty uzyskać efekt wizualny (mnie się nie udało nawet jak ustawiałem SetOption114 na 0). Komunikaty z przełączników ustawionych na różnych GPO idą na bieżąco po zastosowaniu Switchmode3 1 oraz Switchmode4 1.
Przy okazji udało mi się wreszcie przysiąść i wywalić wcześniejsze tasmoty z HA za pomocą MQTT-EXPLORER oraz zrobić porządek z tą która pozostała.
Prawdopodobnie za namową kolegów zestawię sobie teraz ESPHome na innym ESP32 i będę eksperymentował na stole. I tutaj prośba - niestety dokumentacja pomimo, że obszerna nie daje wg. mnie dość skomplikowanych przykładów konfiguracji - zazwyczaj wszyscy powielają podstawowe yaml’e wraz z prostymi opisami - wywnioskowanie z tego jak zrobić układ złożony to bezsensowne wyważanie otwartych drzwi - może ktoś ma bardziej skomplikowany yaml do wrzucenia z komentarzem ?
