Standardy w automatyce domowej

Aug 18, 2022 65 Replies

Parę lat temu zacząłem projektować moduły, które miały stanowić element prostego systemu automatyki domowej - płytka wyposażona w interfejs Ethernet, która komunikowałaby się ze światem za pośrednictwem protokołu MQTT, sterowała załączaniem świateł i informowała o zdarzeniach (otwarcie drzwi albo okna, naciśnięcie przycisku na ścianie, odczytanie danych z jakiegoś czujnika temperatury/ciśnienia/wilgotności).



Początkowo planowałem wszystko napisać samodzielnie - zarówno firmware do mikrokontrolerów, jak i prosty interfejs webowy albo aplikację mobilną. Potem jednak projekt trafił na chwilę do szuflady, a w międzyczasie zaczęły się pojawiać coraz powszechniejsze rozwiązania komercyjne oparte na "inteligentnych żarówkach" z wbudowanym WiFi (tudzież modułami RF, współpracującymi z dedykowaną bramką sieciową). Ludzie zaczęli też się chwalić projektami automatyki domowej, opartymi na gotowym sofcie odpalanym na Raspberry Pi albo innych miniaturowych komputerkach.



Czy na chwilę obecną istnieją już jakieś powszechnie obowiązujące standardy, których mógłbym się trzymać pisząc firmware do swoich modułów? Nie chciałbym wynajdować koła na nowo i potem pisać osobne proxy pośredniczące w komunikacji pomiędzy moimi modułami albo jakimś Domoticzem lub innym podobnym systemem.


W dniu 18.08.2022 o 11:40, Marek pisze:

formatting link

Raczej narzędzia.

Home Assistant + ESPHome.

Z grubsza: ESPHome pozwala na "napisanie" termostatu na ESP8266 w minutę i spięcie go z HomeAssistantem w następną minutę. Po dwóch minutach maś śliczny UI w przeglądarce do kontroli termostatu.

ESPHome jest w wersji, będącej toolem w środku HomeAssistanta i pozwalając na programowanie (kompilacja, edyca itd) z poziomu przegladarki z automatyczną aktualizacją firmware po WiFi. Wspiera większośc gotowców, takich jak sonoff.

Do zagadnień typu "fikuśny wylacznik śwaitła ze ściemniaczem, wyrzutnią Iskanderów i czujnikiem zmierzchu" jak znalazł.

Używam.

W dniu 18.08.2022 o 11:30, Atlantis pisze:

Raczej nie istnieją standardy. Napisałbym, że to część konkurencji i każdy system ma inne firmware. Raz jeden jest bardziej popularny a później inny. Później każdy chwali to, w co akurat wdepnał.

Chyba jednak właściwiej napisać proxy, bo wtedy możesz się oprzeć o wiele systemów ale google home ma już takie "proxy" więc nie wiem czy w ogóle warto tworzyć na nowo.

Ło matko jaka nazwa, myślałem że to jakiś lapsus językowy.

On chyba raczej pyta o protokoły, sposoby oraz metody a nie o gotowe narzędzia...

W dniu 18.08.2022 o 13:02, Marek pisze:

Raczej nie znasz języków :)

formatting link

ESPHome jest czymś w rodzaju protokołu i gotowego narzędzia w jednym właśnie.

Pisanie dzisiaj od zera stosu TCP z MQTT jest mało sensowne.

Integracja rózncyh systemów automatyki nie odbywa się na protokołach, tylko na wysokich abstrakcjach, jak HomeAssistant. Nie da się rozmawiać o tym w oderwaniu od narzędzi.

Stosu TCP nie muszę pisać, bo mam bibliotekę od Microchipa, którą wykorzystuję w swoich projektach. Z MQTT trochę gorzej, bo nie została ona zaimplementowana dla tego stosu - istnieje co prawda biblioteka napisana przez kogoś, ale nie do końca działająca i posiadająca sporo błędów - obecnie ją właśnie poprawiam. Tyle tylko, że MQTT to tylko protokół odpowiedzialny za przesyłanie informacji za pośrednictwem TCP. Mogę za jego pomocą przesyłać niemal dowolne dane, w niemal dowolnej formie. Aplikacja odpowiedzialna za zarządzanie automatyką domową może równie dobrze oczekiwać tam JSON-ów o odpowiedniej zawartości, jakiegoś innego protokołu opartego o ASCII, albo komend binarnych. I właśnie tego dotyczyło moje pytanie. Bo zakładam, że systemy automatyki działają właśnie w oparciu o jakiś broker MQTT. Pozostaje jednak jeszcze kwestia nazewnictwa tematów i przesyłanej zawartości.

Jeśli sprzęt nie jest obsługiwany negatywnie to z reguły jest dostępny mechanizm pluginów, bindingów, czy jak to jeszcze inaczej nazywają (np. proxy), wykorzystujący API dostarczane przez aplikację zarządzającą.

I wcale MQTT nie jest jakąś dominującą szyną ...

Domoticzem się mocno nie interesowałem, ale używam na co dzień OpenHAB - tam tych pluginów jest ponad 200, przy czym MQTT występuje właśnie jako binding - obok modbus, ZigBee, etc.

Piotrek

Tak. Ale to nie jest takie proste.

Wyobraź sobie że wysyłasz na MQTT jakies "FOO" o wartości 1.

Możesz zmusić HomeAssistanta, aby zinterpretował to jako temperature, wartość bool, jasność, czas.

Dzięki temu, że istnieją specjalne nadbudówki nad MQTT, możliwe jest automatyczne poinformowanie HA że ma do czynienia z typem "temperatura" a nie wartością liczbową.

Dlatego tak ciezko wyróżnić "protokół". Tak, można spłycić, że wszystko lata po MQTT. Ale to nie do końca prawda - wiele danych tam latających implemetuje informacje wyższego poziomu.

Taki na przykład przełącznik światła sonoff z zaprogramowaną Tasmotą, zgłosi się w HA jako pstryczek z ikoną żarówki. Automatycznie.

Tym właśnie zajmuje się HA + ESPHome w sposób, którego nie musisz znać.

Choc oczywiście możesz.

Mój pierwotny styl pracy bazował na ręcznym wyrzucaniu do MQTT jakiś informacji i męczeniu się w HA aby je prawidłowo sklasyfikować.

Potem okazało się, że np. Tasmota ma autodiscovery, które HA rozumie.

Potem okazało się, że ESPHome robi to wszystko automatycznie.

Systemy automatyki to nie jest bare matal MQTT. Tam jest znacznie więcej gotowych i bardzo wygodnych rozwiązań.

Przykładowo tutaj masz kod pstryczka do światła, bazującego na sonoff T1 (90% tego kodu napisał ESPHome), który automatycznie jest rejestrowany i dostępny w HA jako pstryczek, żaróweczka i kilka statusów. Update tego kodu, po wifi, mogę przeprowadzić w dowolnym momencie z poziomu przegladarki w HA:

esphome: name: wlacznik-swiatla-w-garderobie

esp8266: board: esp01_1m

# Enable logging logger:

# Enable Home Assistant API api:

ota: password: "39rj38ur390r9i093i09i3rr"

wifi: ssid: !secret wifi_ssid password: !secret wifi_password

# Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "Wlacznik-Swiatla-W-Garderobie" password: "xxxxxx"

captive_portal:

binary_sensor: - platform: gpio pin: number: GPIO0 mode: input: true pullup: true inverted: true id: button_1 on_press: then: - light.toggle: light_1

- platform: status name: "T1 Status"

output: - platform: gpio pin: GPIO12 id: relay_1

light: - platform: binary name: "Garderoba" id: light_1 output: relay_1

status_led: pin: number: GPIO13 inverted: yes

Pisałem z głowy, czyli z niczego - pluginów jest blisko 400, obsługuje prawie 3000 różnych gadżetów.

Piotrek

HA ma też od groma automatyzacji.

Obecnie wybranie jakiegoś to chyba bardziej kwestia gustu.

W dniu 18.08.2022 o 13:07, LordBluzg®🇵🇱 pisze:

Miało być bez "z" :]

formatting link

Czyli rozumieć, że mogę Home Assistanta "nauczyć" obsługi własnego, niestandardowego protokołu?

Czyli rozumiem, że HA potrafi rozpoznać poszczególne urządzenia i mógłbym napisać firmware do swoich modułów w ten sposób, żeby naśladował któreś z dostępnych rozwiązań? Właśnie coś takiego miałem na myśli.

Generalnie na początku chciałbym zacząć od czegoś skromnego - systemu zdalnego/automatycznego gaszenia świateł w warsztacie/budynku gospodarczym (tam przerabianie instalacji elektrycznej będzie znacznie mniej problematyczne). Jednocześnie chciałbym umieścić kilka czujników w drzwiach czy sensorów temperatury/wilgotności/ciśnienia.

Jestem jednak uczulony na dostępne na rynku "prowizorki" w stylu "inteligentnych żarówek z WiFi", które wymagają pozostawiania zostawienia cały czas włączonego zasilania na włączniku w ścianie. Jeśli już, to powinien być moduł z przekaźnikami półprzewodnikowymi, które będą załączane po po otrzymaniu wiadomości siecią albo aktywowaniu wejścia.

Docelowo system może się potem rozrosnąć o kolejne elementy: sterowanie bramą, stację pogodową, załączanie świateł w innych pomieszczeniach (to już przy okazji jakiegoś remontu).

Swoją drogą, Home Assistanta można w miarę prosto zintegrować z asystentem głosowym Google na Androidzie? :)

Tak. Na przykłąd zmusiłem go do sterowania centralą rekuperatora, po RS485/modbus (u mnie z konwerterem na wifi).

Ręcznie wyjasniłem HA jakie rejestry i gdzie są dostępne, jak je czytać, jak interpretować, w jakich zakresach przyjmują dane, w pliku konfiguracyjnym.

I w efekcie mam "suwak" którym steruje jego prędkość, dostępny z panelu usera. Jak to działa pod maską jest bez znaczenia.

Tak.

ESPHome.

Wymarzona robota dla:

1) wyłacznika sonoff 2) ESPHome 3) ewentualnie Tasmota (trudniejsze)

Bedziesz Pan Zadowolony.

Sonoff T1 + wymiana softu na ESPHome.

Tak. HA ma od groma gotowych automatyzacji. Wieszość rzeczy wykrywa samodzielnie. Integruje się praktycznie ze wszytskim co jest sterowane w domu, wliczając w to klimatyzatory, telewizory, roomby itd itp.

Tak.

Albo za darmo - wtedy to trochę roboty. Albo płatnie - wtedy to ~1 kliknięcie.

Jedna uwaga:

HA jako HA nie nadaje się do pracy. To tylko szkielet.

To czego szukasz, to HassIO. To cały system operacyjny zawierający HA, gotowy do pracy, automatycznie updateowany, skonfigurowany, ze wszsytkimi integracjami dostępnymi z repozytorium.

U mnie bangla na wirtualizowanym kompie (proxmox), ale wczesniej pomykał sobie na Pi3 i też było dobrze.

Generalnie wolę unikać stosowania WiFi tam, gdzie mogę nie stosować WiFi. A szczególnie razi mnie marnowanie modułu WiFi, zasobów radiowych i adresu IP na coś, co będzie pojedynczym włącznikiem. Tym bardziej, że i tak trzeba będzie do tego podciągnąć zasilanie kablem. Dlatego jakiś czas temu zacząłem projektować swoje własne moduły na PIC32MX270F256, wyposażone w interfejs Ethernet, która mają współpracować z czujnikami i układami wykonawczymi na magistrali I2C. Cała elektronika zamknięta w hermetycznej obudowie, w której zbiegają się kable biegnące od włączników i do źródeł światła. Podobny moduł (z nieco innymi elementami wykonawczymi) może posłużyć do skomunikowania się ze sterownikiem bramy albo stworzenia stacji pogodowej. Nie wykluczam możliwości, że w pewnym momencie zastosuję też inne magistrale (w tym bezprzewodowe) ale na razie, w miarę możliwości będę chciał opierać się na Ethernecie tam, gdzie będzie się go dało bez większego problemu podciągnąć.

W przypadku wyłącznika światła dużo rozwiązań innych nie ma, poza samoróbką.

IP jest w sieci wewnętrznej. Masz 2^24 adresów w sieci 10.x.y.z. Jakiś problem z "marnowaniem"?

Zasoby radiowe? Te urządzenia komunikują się sporadycznie. Nie obciązają sieci wifi w stopniu jakimkolwiek.

Nie. Jesli to wyłacznik światła to ... zależy. U mnie jest N i L specjalnie w każdej puszce oświetleniowej. Któraś wersja sonoff działa z pasozytniczym zasilaniem, ale powoduje to lekkie problemy z niektórymi typami oświetlenia.

Opcja desperacka: można zanabyć maulteńki sonoff mini, schowany w żyrandolu a w gniazdko wsadzić sonoff T1 i zmajstrować sterowanie jednego drugim w HA.

I nie szkoda Ci marnować IP na ethernet? ;)

Jeśli chcesz, są moduły na 433MHz, ale to jest absolutnie dno jeśli chodzi o możliwości.

Tak się kiedyś robiło. Obecnie Wifi załatwia wszystkie problemy. Topologia "gdziebądź".

To go sobie wepniesz do HA. Nikt nie broni.

A wyłączniki na Wifi. Po co lepsze? Wifi się popsuje - wyłacznik dalej działa jak wyłacznik.

To ciągnij, ale tam gdznie nie - Wifi rozwiązuje wszelakie problemy, bezproblemowo, tanio, wygodnie. Może nie warto ciągnąc ethernetu.

Krytycznej automatyki na wifi nie pociągnę, ale głupi wyłacznik światła w ścianie jest niekrytyczny.

Na marginesie: sonoff z ESPHome pracuje u mnie w ścianie już ~3 lata bez awarii. Dostępny cały czas w HA. Nic nei znika, rozpina się, głupieje. Stabilne jak skała. Drugi, z Tasmotą, zaliczył jedną wpadkę - nie wstał po mignięciu zasilania (ale dalej działał jako zwykły wyłacznik). Działa też koło 3 lat.

Jesli strasznie się boisz wifi, to są Zigbee i Z-Wave. Mam z nimi o wiele więcej problemów niż z wifi.

W dniu 18.08.2022 o 17:57, Atlantis pisze:

Tak nawiasem, akurat ja, używam rozwiązań Supla (heby nie lubi). Jak dla mnie znacznie bardziej korzystne i co najważniejsze to ciągle się to rozwija. Można mieć wszystko u siebie albo korzystać z chmury obcej. Dodatkowo są skrypty i wszelakie wariacje na ten temat, gdzie można bez problemu robić sobie sceny, zależności, cokolwiek, sonoffy, wemosy, arduino, maliny, można tym karmić. Jak dla mnie, idealne rozwiązanie na automatykę domową. Mam na tym cały alarm na działce, stację pogodową (całe stada czujników wszelakich) i co najważniejsze, to powiadomienia/eventy...cokolwiek

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required