Dlaczego TASMOTA oraz ESPHOME nie nadają się do autonomicznej automatyki

Tytuł troszkę przewrotny powiedzmy że w stylu clickbaita ale do rzeczy.

Odpowiedź jest trywalnie prosta - po 6-ciu dniach poszukiwań i eksperymentowania dochodzę do wniosku, że oba te systemy nie posiadają kluczowej funkcjonalności - nie znalazłem metody odczytu stanu binary_switch po restarcie ESP32 (np. w wyniku utratu zasilania). Jest to rzecz jak dla mnie niesamowita, która kompletnie przekreśla zastosowanie ww. systemów w poważnych zastosowaniach. Dziwie się jak można coś takiego zrobić chwaląc się jednocześnie możliwościami automatyzacji bez udziału serwera HA.
Dla jasności w Arduino IDE jest to 1 komenda i niestety będę prawdopodobnie musiał pisać całość oprogramowania właśnie w tym systemie co nie jest zbyt wygodne.
Jeśli ktokolwiek natrafił na metodę takiego sprawdzenia chętnie skorzystam i serdecznie przeproszę posypując głowę popiołem.

1 polubienie

Nie bardzo rozumiem co masz za problem , bo co oznacza ?

Przecież jak skonfigurujesz jakiś przełącznik i ustawisz SwitchMode do potrzeb, to po restarcie, czy zaniku zasilania tasmota zwraca aktualny stan


Opisz co chcesz uzyskać, będzie łatwiej zrozumieć problem

2 polubienia

To jest kontynuacja innego tematu w którym autor jest niezadowolony z własnej krzywej uczenia :wink:
Również nie znając ESPHome, w dokumentacji znalazłem przykład jak odczytywać statyczne stany GPIO i na ich podstawie wykonać jakieś operacje.

binary_sensor:
  - platform: gpio
    name: "Cover End Stop"
    id: top_end_stop
cover:
  - platform: template
    name: Living Room Cover
    lambda: !lambda |-
      if (id(top_end_stop).state) {
        return COVER_OPEN;
      } else {
        return COVER_CLOSED;
      }

W tym przykładzie lambda zwraca statyczny stan open/closed, który mógłby być równie dobrze lato/zima (bo o to cała sprawa idzie).

Tak… niejednokrotnie zrobienie czegoś “na miarę” jest szybsze niż kopanie w dokumentacji

3 polubienia

Dziękuję za odpowiedzi, jestem zawzięty z definicji i się nie poddaję tak łatwo.

Właśnie wrzuciłem ponownie Tasmotę i otrzymuję po restarcie:

14:33:48.963 MQT: tele/PC5ET/STATE = {"Time":"2024-06-10T14:33:48","Uptime":"0T00:00:08","UptimeSec":8,"Heap":148,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Berry":
{"HeapUsed":4,"Objects":42},"POWER1":"ON","POWER2":"OFF","Wifi":{"AP":1,"SSId":"wifi434","BSSId":"84:A1:D1:C5:40:10","Channel":1,"Mode":"HT20","RSSI":100,"Signal":-43,"LinkCount":1,"Downtime":"0T00:00:03"}}

Dopiero po ustawieniu teleperiod 10 otrzymuję

14:35:51.082 MQT: tele/PC5ET/SENSOR = {"Time":"2024-06-10T14:35:51","ZIMA":"ON","PIEC":"OFF","COUNTER":{"C1":0},"CWU":{"Id":"3CE10457111E","Temperature":25.3},"RETURN_CO":{"Id":"3CE1E380484D","Temperature":26.3},"TempUnit":"C"}

czyli pytanie moje powinno brzmieć jeśli TASMOTA wie o stanie przełączników po restarcie to w jaki sposób wykorzystać to w Rule 1 która wygląda tak:

Rule1 ON System#Boot DO Backlog DS18Alias 8B3CE10457111E28,CWU;DS18Alias A03CE1E380484D28,RETURN_CO; POWER1 0; POWER2 0 ENDON

w tej regule powina być reakcja na stan przełącznika Switch1 jeśli ON to Rule2 1 i Rule3 0 jeśli OFF to Rule2 0 i Rule3 1

@zebaczpl jak pisałem w poprzednim Twoim wątku mam w domu ESPHome i jakoś nie ma problemu ze stanem kontaktronów po restarcie ESPHome :slight_smile:.
Coś zaproponowałem, zadałem dodatkowe pytania w poprzednim wątku jednak brak reakcji z Twojej strony ale żale na ESPHome i Tasmota już wylane, wszystko jest “be” :wink:.

Klickbait => nie klikać!

A ja nie wiem czy mam pisać tu czy w temacie gdzie próbowaliśmy z Tasmota. Nadal uważam, że można zrobić pełną automatyzację w Tasmota. To co tu opisujesz jest jakimś nieporozumieniem. Nadal nie wiem w czym jest problem…

Czytam w dokumentacji i widzę:

I w konsoli widzę, że działa to tak jak oczekiwałeś przy SwitchMode 15 w połączeniu z Setoption114 1:

Konfiguracja GPIO dla zobrazowania:

Wynik w konsoli

19:20:34.928 MQT: tele/tasmota_B89B9C/SENSOR = {"Time":"2024-06-10T19:20:34","Switch1":"ON","Switch4":"OFF"}
19:23:44.297 MQT: tele/tasmota_B89B9C/SENSOR = {"Time":"2024-06-10T19:23:44","Switch1":"OFF","Switch4":"OFF"}
19:23:46.949 MQT: tele/tasmota_B89B9C/SENSOR = {"Time":"2024-06-10T19:23:46","Switch1":"ON","Switch4":"OFF"}
19:23:48.649 MQT: tele/tasmota_B89B9C/SENSOR = {"Time":"2024-06-10T19:23:48","Switch1":"OFF","Switch4":"OFF"}
19:23:52.198 MQT: tele/tasmota_B89B9C/SENSOR = {"Time":"2024-06-10T19:23:52","Switch1":"ON","Switch4":"OFF"}
19:23:55.748 MQT: tele/tasmota_B89B9C/SENSOR = {"Time":"2024-06-10T19:23:55","Switch1":"OFF","Switch4":"OFF"}
19:23:58.248 MQT: tele/tasmota_B89B9C/SENSOR = {"Time":"2024-06-10T19:23:58","Switch1":"ON","Switch4":"OFF"}

Wracając do reguły z Twoimi założeniami

zapisał bym ją tak (zakładając, że ten przedmiotowy Switch masz u siebie pod nr 1):

Rule1
 ON System#Boot DO Backlog DS18Alias 8B3CE10457111E28,CWU; DS18Alias A03CE1E380484D28,RETURN_CO; POWER1 0; POWER2 0 ENDON
 ON Switch1#state=ON DO Backlog Rule2 1; Rule3 0 ENDON
 ON Switch1#state=OFF DO Backlog Rule2 0; Rule3 1 ENDON

To nie do końca tak wygląda. Szukam rozwiązania na każdej z platform, co zajmuje sporo czasu. Twoją odpowiedź czytałem, ale w związku z tym, że pracowałem w tym momencie nad tasmotą ciężko było odpisać z konkretami. Projekt na tasmocie był prawie na ukończeniu gdy zderzyłem się że scianą. Co do narzekania to sam powiedz czy szlag by cię trafiał gdybyś inwestował długie godziny w szeroko chwalony projekt w którym dokumentacja jest dość nieprzyjazna. Po wielu godzinach spędzonych w sieci, znalezieniu licznych postów osób opisujących ten sam problem i braku konkretnego rozwiązania mogę napisać, że prawdopodobnie istnieje metoda sprawdzenia stanu binary switch i nawet jest opisana w oficjalnej dokumentacji, tylko jeszcze jej nie przetestowałem w realu i nie mogę tego realnie potwierdzić. Jak sprawdzę osobiście to podam rozwiązanie. Dziwię się tylko że nikt z Was nie zna tego rozwiązania i nie podaje go w odpowiedzi co jak dla mnie świadczy o tym że nie jest łatwo w dokumentacji EspHome znaleźć równoważnik prostej komendy digitalRead(PIN) z Arduino.

Widzisz, ja nie mam wiedzy o Arduino, jak działa program napisany pod Arduino dlatego nie mam problemów z ESPHome bo nie myślę w kategorii “digitalRead(PIN) z Arduino”.

1 polubienie

Ja podobnie jak @macek , nie widzę potrzeby odpytywanie w konfiguracji ESPHome o stan GPIO, bo on zawsze jest znany tylko może tego nie widzi użytkownik. Nie przeszkadza to w tworzeniu odniesień w lambda jak powyżej pokazał w przykładzie @RobinI30. Zwyczajnie można pisać kod zakładając, że stan GPIO jest zawsze aktualny z tym co dzieje się fizycznie na tym pinie.

Tak dla zaspokojenia Waszej ciekawość - w jedno popołudnie napisałem w Arduino IDE kompletny program który działa. Nie jestem zadowolony do końca z rezultatu ale jednego jestem pewien - jest on kompletnie autonomiczny. Teraz staram się go spiąć dodatkowo z HA za pomocą brokera mqtt.
Ale przejdżmy do sedna - nadal z Tasmoty nie jestem zadowolony. Albo ja coś źle rozumiem albo to kompletnie nie działa - do sprawdzenia jak ktoś ma 5 minut czasu.
Moja konfiguracja Tasmoty:

Setoption114 ON
SwitchMode3 1
SwitchMode4 1
załóżmy że chcemy zastosować najprostszą regułę bazującą na stanie Switcha3 i aktywującą Relay 1 - wg. mnie powinna mieć ona postać np:

Rule2 ON Switch3#state=ON do Power1 1 endon

Rule2 1

Restart 1

po czym widzimy:

20:52:05.087 MQT: tele/PC5kW/SENSOR = {"Time":"2024-06-13T20:52:04","Switch3":"ON","Switch4":"OFF","COUNTER":{"C1":50351},"CWU":{"Id":"3CE1E38017FB","Temperature":50.9},"GAZ-OUT":{"Id":"3C2FF6490D14","Temperature":18.9},"GAZ-IN":{"Id":"3CC7F649BE74","Temperature":19.1},"H2O-OUT":{"Id":"3CE1E3806DB1","Temperature":19.8},"H2O-IN":{"Id":"3C63F649F9BB","Temperature":21.8},"BK100":{"Id":"3CE10457DB34","Temperature":16.7},"CO-RETURN":{"Id":"3C63E381176B","Temperature":19.9},"CWU-RETURN":{"Id":"3CB6F6495F8F","Temperature":20.4},"TempUnit":"C"}

oczywiście

20:53:08.508 MQT: stat/PC5kW/RESULT = {"Rule2":{"State":"ON"

a przekaźniki milczą

Może ktoś z większą znajomością Tasmoty wskaże błąd ?

Sporo czasu próbowałem odtworzyć Twój brak działania reguły i rzeczywiście nie działa ona po tym jak kopiowałem regułę z forum. Po kilku próbach gdzie już nawet podejrzewałem błąd w oficjalnych wydaniach, kompilacji własnego pliku bin, w końcu wpadłem na pomysł aby wszystko wpisywać w konsoli z palca.

I jak się okazuje, wszystko działa zgodnie z tym co podałeś.

22:48:40.994 QPC: Reset
22:48:42.994 RSL: STATE = {"Time":"2024-06-14T22:48:42","Uptime":"0T00:00:09","UptimeSec":9,"Heap":151,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"Berry":{"HeapUsed":4,"Objects":45},"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"dom","BSSId":"F0:9F:C2:7A:85:AF","Channel":6,"Mode":"HT20","RSSI":48,"Signal":-76,"LinkCount":1,"Downtime":"0T00:00:04"}}
22:48:43.030 RSL: SENSOR = {"Time":"2024-06-14T22:48:43","Switch3":"ON","Switch4":"ON"}
22:48:50.615 CMD: so114
22:48:50.617 RSL: RESULT = {"SetOption114":"OFF"}
22:48:57.775 RSL: RESULT = {"POWER1":"ON"}
22:48:57.776 RSL: POWER1 = ON
22:48:58.996 RSL: RESULT = {"POWER1":"OFF"}
22:48:58.997 RSL: POWER1 = OFF
22:49:04.065 RSL: RESULT = {"POWER1":"ON"}
22:49:04.066 RSL: POWER1 = ON
22:49:07.719 RSL: RESULT = {"POWER1":"OFF"}
22:49:07.720 RSL: POWER1 = OFF
22:49:13.393 CMD: so114 1
22:49:13.396 RSL: RESULT = {"SetOption114":"ON"}
22:49:15.171 RSL: RESULT = {"Switch3":{"Action":"TOGGLE"}}
22:49:18.222 RSL: RESULT = {"Switch3":{"Action":"TOGGLE"}}
22:49:18.922 RSL: RESULT = {"Switch3":{"Action":"TOGGLE"}}
22:49:19.072 RSL: RESULT = {"Switch3":{"Action":"TOGGLE"}}
22:49:32.026 CMD: switchmode3 1
22:49:32.029 RSL: RESULT = {"SwitchMode3":1}
22:49:37.056 CMD: switchmode4 1
22:49:37.058 RSL: RESULT = {"SwitchMode4":1}
22:49:42.139 RSL: RESULT = {"Switch3":{"Action":"OFF"}}
22:49:44.138 RSL: RESULT = {"Switch3":{"Action":"ON"}}
22:50:18.292 CMD: rule2 on switch3#state=1 do power1 1 endon
22:50:18.294 RUL: Stored uncompressed, would compress from 36 to 28 (-22%)
22:50:18.296 RSL: RESULT = {"Rule2":{"State":"OFF","Once":"OFF","StopOnError":"OFF","Length":36,"Free":475,"Rules":"on switch3#state=1 do power1 1 endon"}}
22:50:24.014 CMD: rule2 1
22:50:24.017 RSL: RESULT = {"Rule2":{"State":"ON","Once":"OFF","StopOnError":"OFF","Length":36,"Free":475,"Rules":"on switch3#state=1 do power1 1 endon"}}
22:50:26.037 RSL: RESULT = {"Switch3":{"Action":"OFF"}}
22:50:26.839 RUL: SWITCH3#STATE=1 performs 'power1 1'
22:50:26.844 RSL: RESULT = {"POWER1":"ON"}
22:50:26.845 RSL: POWER1 = ON
22:50:26.847 RSL: RESULT = {"Switch3":{"Action":"ON"}}
22:50:33.045 RSL: RESULT = {"Switch3":{"Action":"OFF"}}
22:50:34.597 RUL: SWITCH3#STATE=1 performs 'power1 1'
22:50:34.602 RSL: RESULT = {"POWER1":"ON"}
22:50:34.603 RSL: POWER1 = ON
22:50:34.605 RSL: RESULT = {"Switch3":{"Action":"ON"}}
22:50:50.199 RSL: RESULT = {"Switch3":{"Action":"OFF"}}
22:50:58.101 RUL: SWITCH3#STATE=1 performs 'power1 1'
22:50:58.106 RSL: RESULT = {"POWER1":"ON"}
22:50:58.107 RSL: POWER1 = ON
22:50:58.109 RSL: RESULT = {"Switch3":{"Action":"ON"}}
22:51:12.252 RSL: RESULT = {"Switch3":{"Action":"OFF"}}
22:51:15.954 RUL: SWITCH3#STATE=1 performs 'power1 1'
22:51:15.959 RSL: RESULT = {"POWER1":"ON"}
22:51:15.960 RSL: POWER1 = ON
22:51:15.962 RSL: RESULT = {"Switch3":{"Action":"ON"}}

W logach widać też zapisy fizycznego używania switch3.
Tak, że ten… cytując klasyka “u mnie działa”.

EDIT:
Znalazłem kluczową różnicę switch3#state=1 - okazuje się że nie działa tu zamienne używanie ON z 1.
Było:
rule2 on switch3#state=ON do power1 1 endon
Powinno być (aby działało):
rule2 on switch3#state=1 do power1 1 endon

Nie ma to natomiast znaczenia dla POWER1 - reguła działa zarówno dla ON jak i 1.

Na szczęście wielkość liter nadal nie ma znaczenia :wink:

2 polubienia

Bardzo Ci dziękuję za sprawdzenie tych ustawień. Jestem przekonany, że ustawiałem reguły nie na ON a na 1 i też nie działały ale po ilości eksperymentów jakie wykonałem przez ostatnie dni nie jestem już tego pewien na 100 %.
Pomimo tego, że mam działający już program na czystym Arduino i jest to tam w miarę proste do zrobienia nie odpuszczam tematu gotowców i po całym wczorajszym dniu siedzenia mam już pewne osiągnięcia na polu ESPHome - udaje mi się odczytać bez problemu stan przełącznika po restarcie na pomocą on_loop (choć jak napisał jeden z kolegów z forum - jest to rozwiązanie nieeleganckie). Niestety dokumentacja do ESPHome w temacie lambda to jakiś nieśmieszny żart - może wystarczająca dla ludzi otrzaskanych w C++ ale nie dla amatorów. Rozpoznanie składni polecania bazując jedynie na jednej stronie dokumentacji oraz z rzadka opisanych przykładach to naprawdę duże wyzwanie. Żeby nie zaśmiecać wątku zadam kolejne pytanie na forum dotyczące lambda jako osobne.
Jeszcze raz dziękuję za rozpoznanie tematu - tak jak napisałem, jeśli otrzymam działającą wersję na ESPHome podziele się na forum wraz z dokładnym opisem.

EDIT:
Niestety wygląda na to, że nie ukończę tego projektu w oparciu o ESPHome ani Tasmotę. Zbyt wiele problemów do rozwiązania w stosunku do czystego Arduino-IDE. Praca z ESPHome to w moim przypadku wieczne “kopanie się z koniem” a dla mnie ważny jest produkt finalny a nie narzędzie do jego napisania. Po analizie ESPHome doszedłem do wniosku, że jest on oparty na zasadzie reakcji na zdarzenie czy to sensora czy przełącznika bądź innego urządzenia dlatego też mój pomysł musiałbym prawdopodobnie wykonać za pomocą pętli on_loop: co nie jest zbyt eleganckie.

W Arduino IDE program pisze się prosto ale o wszystko trzeba zadbać ręcznie - np. o publikację po mqtt jeśli chcemy mieć komunikację z serwerem (w moim przypadku wystarczy jednokierunkowa).

Pozdrawiam i dziękuję za wszystkie odpowiedzi w tym wątku.

Nareszcie :slight_smile:, dopóki nic nie zmieni w stanie encji, nic się nie dzieje - nie muszę czytać stanu przycisku żeby wykonać automatyzację - akcję, wykona się ona automatycznie po zmianie stanu przycisku, w zależności od zmiany jaka nastąpiła na przycisku (on_state - dowolna zmiana, on_press - "automatyka ta zostanie uruchomiona w momencie naciśnięcia przycisku, czyli innymi słowy na zboczu narastającym sygnału", itd) mogę robić różne automatyzacje.
Jak wiadomo, są plusy i minusy takiej logiki, w moim przypadku plusy przesłaniają minusy - I :heart: ESPHome.

1 polubienie

Dokładnie tak jest. Problemem jest to, że jeśli ustawiamy coś w sekcji on_boot: to jest to wykonywane tylko jeden raz przy starcie nawet jeśli zapiszemy tam kontrolę temperatury. W efekcie program przestaje działać bo nie ma zmiany encji - przynajmniej mnie udało się dojść do takich wniosków.

Nawiązując do Twojego kodu z innego postu:

 - platform: dallas
    address: 0x8b3ce10457111e28  
    name: PC_T_CWU
    id: PC_T_CWU
    on_value_range:
      - above: 31.0
        then:
          - switch.turn_off: test1
      - below: 29.0
        then:
          - switch.turn_on: test1

to akcja wykona tylko wtedy kiedy nastąpi zmiana temperatury np. z 28 na 32 albo z 33 na 27, jeżeli będzie zmiana temperatury z 28 na 30 to nie będzie żadnej akcji, tak samo jak z 30 na 32. Wynika to z określonego przez Ciebie zakresu: nieskończoność do 29 i 31 do nieskończoności dlatego wg mnie nie działało to tak jak sobie zakładałeś.

Nie sugeruj się tym Yamlem. Testy robiłem w oparciu o lambdę w której były zawarte jasne warunki temperaturowe. Niestety tak jak wspomniałem wykonuje się to tylko przy starcie on_boot a następnie w trakcie działania nie bierze tego już pod uwagę. Jest to jednokrotny test po którym następuje reakcja, niestety warunek nie jest zapamiętywany i brany pod uwagę w dalszej części działania. Aby to działało musiałem wpisywać warunki do pętli on_loop co mi się nie podoba.
Dzięki za wytłumaczenie, dopiero teraz zrozumiałem pokręconą logikę on_value_range.

Nie jest “zakręcona”, wystarczyło zdefiniować dodatkowy zakres od 29 do 31 i wszystko działa jak to sobie założyłeś.
Dobra, wystarczy tej analizy, nie wszyscy muszą lubić ESPHome :wink:.

Ale ja uważam ESPHome za świetny software tylko nie do tego konkretnego projektu nad którym właśnie pracuje. Jakbyś mógł napisać dwa zdania na temat definicji on_value_range to będę bardzo wdzięczny, a myślę że innym też się to przyda.

Czy nie masz wrażenia, że zmęczyłeś społeczność tego forum swoim skakaniem z kwiatka na kwiatek ? Ja nie wiem jak mi się udaje robić zestawy na tasmocie działające całkowicie autonomicznie, skoro ten firmware się do tego nie nadaje.


A u mnie działa i obsługuje czujnik przepływu, cztery termometry na podstawie których realizowane są różne scenariusze, włącznie ze sterowaniem mocą agregatu jednostki zewnętrznej. Tani moduł Kincony , bez udziwnień :slight_smile:

4 polubienia