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).
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