Skocz do zawartości

Jak podłączyć bezprzewodowo czujnik do Domoticza


Elvis

Pomocna odpowiedź

Większość osób pewnie zauważyła, że na forum znajdziemy kurs obsługi Raspberry Pi oraz jego kontynuację z opisem konkretnych projektów. Jednym z tematów, które mnie zainteresowały jest "inteligenty dom", czyli konfiguracja Domoticza: https://forbot.pl/blog/kurs-raspberry-pi-projekty-domoticz-ds18b20-maile-id27526

Bezpośrednie podłączanie czujników do malinki jest bardzo fajne, ma jednak pewne ograniczenia. Po pierwsze liczba dostępnych pinów może okazać się niewystarczająca. Drugi i poważniejszy problem to konieczność kładzenia kabli - powiedzmy do termometru za oknem, czy w innym pomieszczeniu. To prowadzi nie tylko do plątaniny kabli, kosztów remontu mieszkania, ale i do czysto elektrycznych problemów wynikających z długości przewodów.

Spróbowałem więc do Domoticza działającego na Raspberry Pi podłączyć przykładowy czujnik (termometr DS18B20) za pomocą WiFi. Ponieważ ostatnio bardzo spodobała mi się zabawa z układami ESP32 wybrałem moduł z właśnie takim układem.

Wybór platformy sprzętowej był prosty, jako serwer Raspberry Pi 3+, czujnik DS18B20 podłączony do modułu z ESP32. Do komunikacji używam WiFi, co chyba nie wymaga komentarza - wspomnę tylko, że moja sieć lokalna używa adresów 168.168.0.x.

Trudniej było zdecydować się na odpowiedni protokół komunikacji między ESP32, a serwerem. Ostatnio interesowałem się protokołem MQTT, który jest wspierany przez Domoticz-a, więc postanowiłem go użyć. Jest to prosty protokół przeznaczony do telemetrii, czyli dokładnie tego co staram się uzyskać (więc powinno pójść łatwo).

Na szczęście MQTT ma dobre wsparcie zarówno po stronie malinki, jak i ESP32 - nie trzeba więc pisać obsługi tego protokołu od podstaw, można wykorzystać gotowe narzędzia. Do obsługi MQTT po stronie serwera potrzebujemy tzw. broker. W tym celu wystarczy zainstalować na Raspberry Pi dwa pakiety: mosquitto oraz mosquitto-clients.

Protokół MQTT opiera się na mechanizmie publikacji/subskrypcji danych. Dane przesyłane są w postaci tak zwanych tematów (ang. topic). ESP32 może więc publikować wyniki pomiarów z czujnika, a Domoticz je subskrybować. Może brzmi to dziwnie, więc na początek mały test.

Raspberry Pi ma u mnie adres IP 192.168.0.150. Działa na nim serwer mosquitto na domyślnym porcie 1883. Aby zacząć subskrybować dane wpisuję np.

mosquitto_sub -h 192.168.0.150 -v -t "forbot/test"

Pierwsza opcja, czyli -h ustala adres serwera (poleceni można uruchomić ze zdalnego komputera), -v zwiększa gadatliwość programu (wyświetla nazwy tematów), a ostatni czyli -t określa nazwę tematu.

Teraz z innego terminala, a nawet komputera mogę opublikować testowy komunikat:

mosquitto_pub -h 192.168.0.150 -t "forbot/test" -m "Hello world!"

Efekt wykonania tych poleceń wygląda następująco:

2019-01-13-213726_3840x1080_scrot.thumb.png.e7054bb47dab64de688dcd2d520c325e.png

Liczba dostępnych opcji jest znacznie większa, ale to co przetestowałem wystarczy na początek. Teraz mogę przejść do Domoticza i skonfigurować obsługę MQTT.

Konfiguracja Domoticza

Na początek zainstalowałem i skonfigurowałem Domoticz-a mniej-więcej według kursu. W każdym razie zaczynam bez podłączonych czujników z samą malinką oraz oczywiście mosquitto.

Pierwszy krok w stronę MQTT to dodanie odpowiedniego urządzenia (opcja Setup->Hardware). Interfejs Domoticza jest dla mnie straszny, ale chociaż działa. W każdym razie opcje, które muszę wypełnić to:

  • Name - nazwa urządzenia, nieistotna ale coś trzeba wpisać
  • Type: "MQTT Client Gateway with LAN interface"
  • Remote Adress - adres serwera, pewnie zadziała 127.0.0.1, ale ja wpisuję 192.168.0.150
  • Port: 1883

2019-01-13-214637_1918x1058_scrot.thumb.png.e61a8cc53a75cf61acb3ab573c2ddf79.png

Teraz wystarczy przycisnąć "Add" i obsługa MQTT została dodana. Od razu ostrzeżenie - to co robię jest delikatnie mówiąc niezbyt bezpieczne. Należałoby dodać obsługę hasła oraz SSL, ale na razie nie będę się tym zajmować.

Kolejny krok to dodanie urządzenia typu dummy (manekin?). Ponownie nazwa jest nieistotna, liczy się typ: "Dummy (Does nothing, use for virtual switches only)".

2019-01-13-215418_1918x1058_scrot.thumb.png.81af0031cf830a925c8daf1a146911ec.png

Po dodaniu manekina pojawia się on na liście urządzeń. Ale co najważniejsze w kolumnie "Type" jest też przycisk "Create Virtual Sensors" - nie wiem czy tylko mnie interfejs Domoticza doprowadza do furii... ale jak już wspominałem ważne że działa. Naciskam ten jakże intuicyjnie umiejscowiony przycisk i pojawia się tym razem podejrzanie proste okienko dialogowe:

2019-01-13-215957_1918x1058_scrot.thumb.png.670fc837248e14314bc1b809c68cca20.png

Nazwa jak to nazwa, chociaż tym razem już nieco ważniejsza niż wcześniej, ale jak zwykle należy zwrócić uwagę na typa. Zacznę od przełącznika, skoro tak domoticz doradzał. Wybieram więc Switch i naciskam OK.

Zgodnie z oczekiwaniem nowo dodane urządzenie będzie widoczne w zakładce Switches:

2019-01-13-220143_1918x1058_scrot.thumb.png.7ba68ff3549a11b4189d82d1ca4d847c.png

Klikając myszą na ikonę żaróweczki można się takim przyciskiem bawić w nieskończoność - w końcu domoticz uprzedzał, że to nic nie robi... ale okazuje się że niezupełnie.

Wracamy do linii poleceń i poznanego już mosquitto_sub. Tym razem uruchamiam nasłuchiwanie wszystkich tematów - w MQTT używany jest w tym celu znak #, coś jak * we wszystkich normalnych przypadkach.

mosquitto_sub -h 192.168.0.150 -v -t "#"

Na początku nic ciekawego się nie dzieje:

2019-01-13-220518_1916x1055_scrot.thumb.png.85d1727906b76fe73aa8d2082d028e0e.png

Ale skoro wirtualny przycisk też nic nie robi to co szkodzi go przycisnąć:

2019-01-13-220624_1918x1058_scrot.thumb.png.64d8377a56bf21878ca92b2bb0c45b97.png

Wirtualna żaróweczka zaczyna świecić, ale co ważniejsze coś otrzymaliśmy przez MQTT:

2019-01-13-220631_1916x1055_scrot.thumb.png.3bc61c64cf4949f53630ebce75d039cb.png

Dla osób nie lubiących oglądać obrazków poniżej kod:

domoticz/out {
   "Battery" : 255,
   "RSSI" : 12,
   "description" : "",
   "dtype" : "Light/Switch",
   "id" : "00014051",
   "idx" : 1,
   "name" : "prztyczek",
   "nvalue" : 1,
   "stype" : "Switch",
   "svalue1" : "0",
   "switchType" : "On/Off",
   "unit" : 1
}

domoticz/out to nazwa tematu, to co domoticz wysyła domyślnie wędruje właśnie tędy.

Cała reszta to informacja o przyciśnięciu przycisku w formacie JSON. Można jeszcze raz nacisnąć przycisk i zobaczyć co się stanie:

domoticz/out {
   "Battery" : 255,
   "RSSI" : 12,
   "description" : "",
   "dtype" : "Light/Switch",
   "id" : "00014051",
   "idx" : 1,
   "name" : "prztyczek",
   "nvalue" : 0,
   "stype" : "Switch",
   "svalue1" : "0",
   "switchType" : "On/Off",
   "unit" : 1
}

Nie trzeba być szerlokiem, aby zrozumieć jak to działa - pole "nvalue" przesyła informację czy przycisk został włączony, czy wręcz przeciwnie.

Teraz wystarczy takie dane sparsować i możemy mieć własny, zdalnie sterowany moduł. To działa bardzo ładnie na ESP32, ale chciałem na razie opisać własny czujnik.

Dodawanie czujnika

Poprzednio dodałem przycisk, teraz w bardzo podobny sposób dodaję wirtualny termometr. Na początek wracam do listy urządzeń (Setup->Hardware) oraz naciskam magiczny przycisk "Create Virtual Sensors":

2019-01-13-221522_1918x1058_scrot.thumb.png.fafb6b9b1cdb4bfd7ee82e9381fb6670.png

Tym razem dodaję urządzenie do pomiaru temperatury:

2019-01-13-221611_1918x1058_scrot.thumb.png.e08836001bcf3935848fefeb278c8e20.png

Zanim przejdę dalej, warto wyświetlić listę zainstalowanych urządzeń. Znajdziemy ją wybierając Setup->Devices:

2019-01-13-221714_1918x1058_scrot.thumb.png.d776a5c3a83d4cc587f9a660a7afd33f.png

Najważniejsza jest kolumna idx. Każde urządzenie ma swój identyfikator. W moim przypadku najpierw dodałem przycisk, który otrzymał numer 1 - stąd w kodzie JSON pole idx miało akurat taką wartość. Teraz gdy mam już dwa urządzenia identyfikatory stały się ważniejsze. A jak widać termometr ma idx równe 2.

Czas zobaczyć jaką temperaturę wskazuje nowo zakupiony wirtualny termometr:

2019-01-13-222134_1918x1058_scrot.thumb.png.d99b2ffa6c4b3f915e6d57d00d636967.png

Jak widać nie działa najlepiej. Spróbujmy więc wysłać do niego (o przepraszam - opublikować) jakąś wiadomość.

mosquitto_pub -h 192.168.0.150 -t "domoticz/in" -m '{ "idx": 2, "nvalue": 0, "svalue": "3.14" }'

Po chwili powinniśmy zobaczyć nasz odczyt z poziomu domoticz-a:

2019-01-13-223205_1918x1058_scrot.thumb.png.68e31ddfcb7c84397fd8f927141dad70.png

Temat do wysyłania danych jest zawsze taki sam, czyli "domoticz/in", parametr "idx" identyfikuje nasz czujnik, a aktualna temperatura przesyłana jest jako napis w polu "svalue".

Teraz wiemy już wszystko co konieczne, aby przygotować własny czujnik. Wystarczy na ESP32 połączyć się z WiFi, odczytać temperaturę z podłączonego termometru, a następnie używając MQTT wysłać komunikat o treści:

{ "idx": <ID_URZADZENIA>, "nvalue": 0, "svalue": "<TEMPERATURA>" }

Do przygotowania takiego komunikatu nie potrzebujemy nawet biblioteki z obsługą JSON, wystarczy prosty sprintf.

Na koniec jeszcze dwa słowa o parametrach przesyłanych w JSON oraz implementacji kodu na ESP32.

Więcej o dostępnych opcja JSON znajdziemy np. tutaj: https://www.domoticz.com/wiki/Domoticz_API/JSON_URL's#Temperature

Przy okazji zauważymy, że zamiast MQTT można byłoby użyć zwykłego http. Ja wybrałem MQTT, ale jak zwykle możliwości jest mnóstwo.

Program na ESP32 implementowałem w IDF. Zarówno WiFi, jak i protokół MQTT obsługiwany jest przez standardowe biblioteki, przykład dla WiFI znajdziemy tutaj: https://github.com/espressif/esp-idf/tree/master/examples/wifi/getting_started/station, natomiast MQTT: https://github.com/espressif/esp-idf/tree/master/components/mqtt

Edytowano przez Elvis
  • Lubię! 1
Link do komentarza
Share on other sites

ESP32 tylko do obsługi ds18b20 to przerost formy nad treścią. Do tego celu wystarczy ESP8266, który jest tańszy.

Oczywiście opis ok, bo pasuje do obu urządzeń.

Najłatwiej podpiąć czujniki do domoticz z wykorzystaniem EasyEsp (działa bezproblemowo z ESP8266, Arduino itp). Nie lubię gotowego sostu ale tam z konfiguracją poradził sobie mój 14-letni siostrzeniec.

Link do komentarza
Share on other sites

Pewnie, że ESP32 w takim przypadku to przesada, ale to tylko przykład - nie to było tu najważniejsze. Fajnie, że @Elvis opisał konfigurację oprogramowania, bo na pewno wiele początkujących z tego skorzysta, gdy będą eksperymentować z Domoticzem. Na EasyEsp też przyjdzie jeszcze czas, nawet mam gdzieś szkic artykułu o tym 🙂

Link do komentarza
Share on other sites

Hejka. Mimo dosyć dużego zaawansowania w różnych tematach, zarówno software jak i hardware, nigdy nie używałem MQTT i jest to dla mnie nowość. Jednakże DZIŚ nastał ten dzień, że zaczynam publikować i subskrybować 🙂

Jednej rzeczy nie rozumiem, albo chcę głośno powiedzieć, tym samym układając to sobie w głowie. Skoro domoticz wysyła (publikuje) do brokera komendę - włącz/wyłącz pstryczek, to robi to tylko do brokera. Broker sam z siebie nie wyśle komendy do esp, więc esp co chwilę musi pytać brokera (subskrybować) czy jest dla niego jakiś job? Am I right? Jeśli tak to jest to trochę lipa... Druga sprawa, skąd taki biedny esp ma wiedzieć, czy dany job już przetworzył, czy nie? 

EDIT:

Co ja pierniczę. Subskrybując jestem podłączony do brokera cały czas a ten śle wszystko co mu się publikuje... Moim zadaniem w takim razie jest przeparsować komunikat i wykonać zadanie jeśli stwierdzę, że jest dla mnie. 

Edytowano przez matimoto87
  • Lubię! 1
Link do komentarza
Share on other sites

Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

Dnia 15.01.2019 o 10:01, Treker napisał:

Pewnie, że ESP32 w takim przypadku to przesada,

Jak chce się zrobić szybko i dobrze to sam ESP8266 nie da rady. Trzeba modyfikować biblioteki, bo "loop()" może stanąć na długo, dla mnie i dla moich zleceniodawców to 100ms już jest bardzo długo.

W praktyce, najczęściej, wszystkie rozwiązania "darmowe w chmurze" trzeba zastąpić swoimi. Rezygnacja z TCP na rzecz UDP daje ogromne oszczędności dlatego nie mogę zrozumieć dlaczego Arduino na siłę promuje TCP? Realne wyniki komunikacji TCP (90ms) vs UDP (0,7ms - 128 razy mniej czasu). Naturalnie, modyfikując biblioteki Arduino - i tu dochodzimy do tego, ze ma byc szybko, łatwo i przyjemnie. Bez modyfikacji bibliotek - kicha. Modyfikować, łatwo powiedzieć - bez debugera? Prościej i szybciej wszystko napisać samemu od nowa albo użyc najtańszego ESP w roli karty sieciowej, co najczęściej robię. Próbowałem "szybko i łatwo z Arduino" ale to nie działa.

 

Link do komentarza
Share on other sites

12 minut temu, RFM napisał:

Rezygnacja z TCP na rzecz UDP daje ogromne oszczędności

Jakim kosztem? Takim, że nie wiesz, czy wysłana informacja dotarła do serwera, prawda? Ale o tym nie wspominasz?

Oczywiście - można się bawić i przy UDP w potwierdzenia, retransmisje... ale w takim przypadku po prostu odtworzylibyśmy to, co w TCP mamy na dzień dobry i cała oszczędność czasu poszłaby się paść.

Poza tym co ma wspólnego biblioteka Arduino z ESP? Akurat w ESP biblioteki WiFi z Arduino nie mają nic wspólnego oprócz interfejsu (no, ale o tym trzeba się przekonać zaglądając do kodu, i w dodatku jeszcze ten kod rozumieć). A nie bardzo rozumiem, jak jakość biblioteki miałaby wpłynąć na czas transmisji wydłużając go do 90 msec (przecież to raptem kilka pakietów, w tym tylko jeden z danymi).

Może chodziło Ci o to, że serwery TCP odpowiadają po zbyt długim czasie? Ale to już nie ma nic wspólnego z jakością bibliotek Arduino.

22 minuty temu, RFM napisał:

Trzeba modyfikować biblioteki, bo "loop()" może stanąć na długo, dla mnie i dla moich zleceniodawców to 100ms już jest bardzo długo

Możesz sobie modyfikować do woli - tego że procek ma jeden rdzeń i nie może się zajmować Twoimi zleceniodawcami w czasie kiedy nadaje/odbiera pakiety WiFi nie przeskoczysz.

Poza tym mowa była o odczycie pojedynczego DS-a, a tu narzekanie na długi czas komunikacji to chyba jakaś paranoja.

Wiesz - może wróć do swoich STM-ów, bo zaczynasz się wypowiadać w tematach o których nie masz zielonego pojęcia. Mnie czy kogokolwiek, kto wie coś o protokołach internetowych i ogólnie o sieciach to może śmieszyć, ale ktoś mógłby to wziąć na poważnie i potem trzeba by było tłumaczyć...

  • Lubię! 2
Link do komentarza
Share on other sites

Bądź aktywny - zaloguj się lub utwórz konto!

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto w ~20 sekund!

Zarejestruj nowe konto, to proste!

Zarejestruj się »

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się »
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.