Jakie są aktualne standardy w automatyce domowej dla MQTT i Ethernet?

Thu Aug 18, 2022 11:30 am   

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.

Thu Aug 18, 2022 11:40 am   

On Thu, 18 Aug 2022 11:30:49 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Co to Domoticz?

--
Marek

Thu Aug 18, 2022 12:25 pm   

Thu Aug 18, 2022 12:25 pm   

On 18/08/2022 11:30, Atlantis wrote:

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.

Thu Aug 18, 2022 12:30 pm   

Thu Aug 18, 2022 1:02 pm   

Thu Aug 18, 2022 1:06 pm   

On Thu, 18 Aug 2022 12:25:32 +0200, heby <heby@poczta.onet.pl> wrote:

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

--
Marek

Thu Aug 18, 2022 1:07 pm   

Thu Aug 18, 2022 1:17 pm   

On 18/08/2022 13:06, Marek wrote:

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.

Thu Aug 18, 2022 3:16 pm   

On 18.08.2022 13:17, heby wrote:


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.

Thu Aug 18, 2022 3:40 pm   

On 18.08.2022 15:16, Atlantis wrote:

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

Thu Aug 18, 2022 3:47 pm   

On 18/08/2022 15:16, Atlantis wrote:

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

Thu Aug 18, 2022 3:49 pm   

On 18.08.2022 15:40, Piotrek wrote:

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

Piotrek

Thu Aug 18, 2022 3:49 pm   

On 18/08/2022 15:49, Piotrek wrote:

HA ma też od groma automatyzacji.

Obecnie wybranie jakiegoś to chyba bardziej kwestia gustu.

Thu Aug 18, 2022 3:57 pm