[peetpeet]

Witam. Planuję zbudować taką mini stację monitorującą stan domu... temperatura, wilgotność, zalanie, otwarte okna, załączone światło itp.
To sporo różnych czujników i nie widzę możliwości łączenia tego kablami po całym domu... Wiec tylko bezprzewodowe... Ale jaka technologia? BT, WiFi, RF2,4 czy jeszcze coś innego? Liczę około 10-12 czujników na cały dom... No i najważniejsze...czy UNO to pociągnie przy założeniu że jeszcze będzie z odczytów robić transmisję Wifi?
Jeżeli nie to ile czujników maksymalnie można tak połączyć?

Wysłane z mojego POT-LX1 przy użyciu Tapatalka

[semi]

Witam. Planuję zbudować taką mini stację monitorującą stan domu... temperatura, wilgotność, zalanie, otwarte okna, załączone światło itp.
To sporo różnych czujników i nie widzę możliwości łączenia tego kablami po całym domu... Wiec tylko bezprzewodowe... Ale jaka technologia? BT, WiFi, RF2,4 czy jeszcze coś innego? Liczę około 10-12 czujników na cały dom...

Najszybciej i najprościej zrobisz to przez Wi-Fi przy użyciu ESP.

No i najważniejsze...czy UNO to pociągnie przy założeniu że jeszcze będzie z odczytów robić transmisję Wifi?

Zapomnij o UNO. Na dzień dobry musisz do niego dołączyć ESP lub inną kartę sieciową. ESP ma zasoby wielokrotnie większe niż UNO więc bez sensu aby ESP pracował w roli mostka, a UNO pociło się sterowaniem ze swoja nikłą szybkością CPU i śladowa ilością RAM. Do tego zadania raczej ESP32 niż ESP8266.
Jak jakieś bardziej zaawansowane zadania (rozbudowana strona WWW, serwery FTP, itp) to RaspberryPi.

Jeżeli nie to ile czujników maksymalnie można tak połączyć?

Prawie ile chcesz, problem ile będzie trwać odswieżanie danych

Wysłane z mojego POT-LX1 przy użyciu Tapatalka

Wysłane z mojej lodówki przy użyciu Coldtalka.

[error105]

BT, WiFi, RF2,4 czy jeszcze coś innego?

 BT odpada ze względu na zasięg zapewne, co do reszty to już Twój wybór, każde rozwiązanie ma zalety i wady. Ja u siebie postawiłem na WiFi akurat.

...czy UNO to pociągnie przy założeniu że jeszcze będzie z odczytów robić transmisję Wifi? 
Jeżeli nie to ile czujników maksymalnie można tak połączyć?

A co to UNO miałoby robić ? być serwerem, uC do komunikacji pomiędzy czujnikami a modułem WiFi czy coś jeszcze innego ?
Wnioskuję że miałoby zbierać dane z czujników i wysyłać dalej przez WiFi, tylko po co UNO wtedy jak mamy ESP (do tego tańsze często). Poza tym jak to zasilać chcesz ? Bo samo UNO na baterii to Ci może z 3-4 dni wytrzyma.

Co do drugiej części, to do uno możesz podłączyć całkiem sporo czujników, pytanie czy analogowe, komunikujące się po I2C, SPI, UART, 1Wire...... bo od tego zależy głównie ilość.

[peetpeet]

Wnioskuję że miałoby zbierać dane z czujników i wysyłać dalej przez WiFi, tylko po co UNO wtedy jak mamy ESP (do tego tańsze często).

Tak właśnie sobie założyłem jako laik, który dopiero zaczyna przygodę. Kupiłem ESP jako płytkę rozszerzenie do UNO.

Poza tym jak to zasilać chcesz ? Bo samo UNO na baterii to Ci może z 3-4 dni wytrzyma.

Na co dzień z zasilacza sieciowego a awaryjnie z akumulatora....wszystko to z systemu alarmowego...taka jest koncepcja.

A na jakich elementach zbudowałeś te czujniki z Wi-Fi? Chodzi mi o część komunikacyjną. Możesz pokazać jakiś przykładowy?

Wysłane w biegu

[semi]

Czy czujniki maja być zasilane z baterii? Jeśli tak, to Wi-Fi i prądożerne ESP odpada. W takiej sytuacji używam modułów 315/433/868MHz np RFM12B. Gdy czujnik ma wysyłać dane co 30 sekund i w razie sytuacji alarmowej, na CR2032 może działać nawet rok, na CR2455 ok 1,5 roku.

[peetpeet]

Tak. Zasilanie bateryjne. Aktualizacja danych nie częściej niż co 2-5 minut. Nie widzę potrzeby częściej w przypadku temperatury i wilgotności. Inne dotyczące stanów nietrwalych i szybko zmieniających mogą być częściej...

Wysłane w biegu

[PiegowatyGuziec]

To jak bateryjne i 5min interwał to dość często.
Mi ESP ci 5min wysyła dane na serwer i na ogniwie 2200mah trzyma około 8 miesiecy, jak to wystarczy Ci to tedy droga - jak za krótko to już ESP i WiFi ci odpada na wstępie.

Dodam że jest to też czujka alarmowa, więc ma czujnik ruchu dodatkowo więc czasem częściej się wybudza, zależy od ustawień.

[semi]

Tak. Zasilanie bateryjne. Aktualizacja danych nie częściej niż co 2-5 minut. Nie widzę potrzeby częściej w przypadku temperatury i wilgotności. Inne dotyczące stanów nietrwalych i szybko zmieniających mogą być częściej...

To zapomnij o Wi-Fi z powodu poboru prądu. BT odpada ze względu za zasięg. Celowałbym w LoRa albo jak już pisałem 315/433/868MHz. 

W przypadku serwera większa dowolność, naturalnie nie marne UNO, wtedy lepiej ESP z wskazaniem na ESP32. Jeszcze, jak wspomniałem, RPi a gdy pobór prądu jest istotny (np praca awaryjna) to ARM (np STM32) z ETH (STM32F107 itp z wbudowanym ETH).

"Trochę" roboty Cię czeka. Gotowców nie znajdziesz, takich gotowców, co:
- Będą oszczędzać energię.
- Rozwiążą problem kolizji nadawanych informacji przez czujniki.
- Zrealizują szyfrowanie/autoryzację aby nie było możliwości podstawienia nadajnika symulującego pracę czujnika co oszuka serwer.
- Rozwiążą problem "zagłuszania" transmisji przez do serwera, bo może zablokować wysyłanie informacji o alarmach i serwer nic nie zauważy.
Robiłem coś takiego. Samo zaprojektowanie/napisanie softu czujników i "hosta" zbierającego informacje trwało ok 2 miesięcy. Sam koszt prototypowych PCB i elementów to ok 1000..1500zł.
Serwera do tego nie robiłem, wiem tyle, że na SoC jest zrobiony. Mogę szacować, że to kilka miesięcy pracy. Koszt elementów niewielki, tyle co np RPi (ok 200zł) lub OrangePi-Zero (ok 100zł razem z kartą SD i zasilaczem).

Aktualnie buduję system archiwizacji danych, podobny jak potrzebujesz. Część już działa http://es2.noip.pl/automatyka/ Jak widzisz, poza temp., ciśnieniem itp, rejestrowany jest pobór energii elektrycznej, podłączona jest kamera. Czujniki komunikują się miedzy sobą. Na każdym z urządzeń można wyświetlić dane innego. W tym sensie czujniki są autonomiczne. Na razie jeszcze nie ma trzeciego i czwartego. Dane wysyłane są w sumie na 4 serwery (docelowo 2), dwa lokalne, dwa w sieci rozległej. Wszystko to zbudowane na:
Czujniki:
- "Pirometr tęczowy": AVR + ESP-01 + VNC-2 (dodatkowa rejestracja na pen drive).
- "Mini stacja pogodowa": ESP32 z OLED (od tego projektu stwierdziłem, że dane będę rejestrował tylko na serwerach).
- "Termometr tęczowy" (jeszcze nie wrócił prototyp z testów): STM32F072 + ESP01.
- Nie dokończony jeszcze "Zegar, termometr" (6 matryc 8x8 na WS2812): STM32F105 + ESP-01.
- "Interfejsy liczników ORNO": Wemos D1 ale to tylko tymczasowo, bo ESP nie nadaje się do zaawansowanych zadań. Docelowo slave na STM32F072 + RFM12B + E-INK, host na STM32F072 + RFM12B + OLED - komunikacja z serwerem przez USB (opcja Wi-Fi na ESP-01).
Serwer: RPi 3B+ (pełni także rolę serwera NAS, FTP, niedługo e-mail).
Tylko jeden projekt (pierwszy i ostatni raz)  zrealizowany jest na ESP8266 z wykorzystaniem ArduinoIDE. "Wybadam" przydatność ESP32 może coś z niego będzie bo jak na razie, ESP8266 dobrze sprawuje się w roli karty sieciowej Wi-Fi a nie rejestratora danych. ESP32 ma dwa rdzenie, więc może coś z tego wyjdzie?
Prace trwają ponad rok i potrwają jeszcze pewnie kolejny. Faktem jest, że realizuje także inne zadania, więcej gdybym tylko zajął się systemem czujników, pewnie prace byłyby już zakończone. Ty masz prościej, bo jeden typ czujnika. Jak się "sprężysz" to w pół roku zrobisz o ile dobrze znasz się na programowaniu i nie będziesz tego realizował na Arduino, które ma duże ograniczenia. Część ograniczeń można zlikwidować modyfikując biblioteki ale gdy zacznie się to robić, dochodzi się do wniosku, że lepiej to napisać od nowa, pomijając ograniczone Arduino, w IDE z prawdziwego zdarzenia z obsługą debugera. Gdybym nie używał debugera, to pewnie dopiero skończyłbym "Pirometr tęczowy" a prace nad całością w 2030 roku.

[elvis]

Jak chodzi o komunikację to WiFi faktycznie jest nieco zbyt prądożerne jak na zasilanie bateryjne. Porady w rodzaju GSM/LTE są jeszcze gorsze.
Gotowe rozwiązania oczywiście istnieją, ale nie są tanie: chociażby ZigBee - ma wszystko co potrzebne i jest gotowe... tylko drogie.
Z tańszych alternatyw jest Bluetooth LE, który ma niższą prędkość i zapotrzebowanie na energię ale znacznie większy zasięg niż klasyczny Bluetooth.
Ostatnio ciekawą opcją może być też LoRa.
Moim zdaniem warto zainteresować się BT LE, to chyba dość dobry kompromis między ceną / zasięgiem, a możliwościami. ESP32 ma wbudowaną obsługę BT LE, więc można zrobić coś na kształt mesha z ZigBee - umieścić kilka ESP32 w różnych miejscach domu, które będą przesyłały sygnał na serwer.
Lora ma też takie możliwości, nawet może od razu wysyłać dane w chmurę (LoRaWAN), ale bramki są dość drogie.
Więc to chyba jest jak zawsze - albo tanio, albo szybko i prosto. Natomiast warto wiedzieć, że są gotowe rozwiązania, nie trzeba wymyślać koła od początku.

[semi]

albo tanio, albo szybko i prosto. Natomiast warto wiedzieć, że są gotowe rozwiązania, nie trzeba wymyślać koła od początku.

O ile autor tematu nie napisze inaczej, wychodzę z założenia, ze ma być tanio.

Zasugerowałem rozwiązanie z RFM12B bo jest tanie, pobiera mało prądu i wypróbowałem je w praktyce. Pobór prądu w stanie uśpienia to kilka uA (dokładnie nie pamiętam 2 może 3?) przy 3V. W czasie pracy (co ile trzeba, 30 sek, minuta, kilka minut) 18mA przez 20..30ms zależnie jak długa jest ramka danych. Gdy dane będą wysyłane co 60 sekund da to średni pobór prądu w czasie nadawania 30mA / (60 sek * 1000 / 18ms ) = 9uA. Do tego dodajemy to co całość bierze w uśpieniu co daje ok 12uA. 200mAh wystarczy więc na blisko 700 dni co daje rok i 11 miesięcy. Tyle teoria, w praktyce napięcie na baterii będzie spadać. Różni producenci, różnie określają pojemność, jedni dla napięcia końcowego 2,4V inni dla 2V. RFM12B działa chyba do 2,4V, więc w praktyce 200mA to ok roku czasu pracy co i tak dużo jak na CR2032 (o ile jest dobra jakościowo). Jak to mało to jest CR2455 czy 2 x AAA albo i AA. Kilka lat pracy gwarantowane.
Jak by nie było, nie sądzę aby jakaś technologia BT LE, LoRa czy ZigBee  przeskoczyła te średnie 12uA a może być mniej, np nadawanie co 5 minut, krótsza ramka, większa prędkość transmisji, niestety większa prędkość realnie mniejszy zasięg (przy 19200 na 433MHz zasięg przez 2 stropy ze stopą błędów poniżej 8%)
Warto zaznaczyć, że baterie CR2032 i podobne mają dużą rezystancję wewnętrzną. Trzeba dodać kondensator 1000uF czy więcej bo w czasie nadawania napięcie będzie spadać (nie pamiętam gwarantowanego ciągłego poboru prądu przez CR2032 ponadto zależy od producenta). Jeśli ktoś jest zainteresowany to mam oscylogramy jak wygląda spadek napięcia przy różnych pojemnościach kondensatora.

Dałem więc sprawdzone w praktyce rozwiązanie poparte nie tylko wyliczeniami ale także praktycznymi testami. Nic tylko używać, można zaoszczędzić wiele czasu. Same testy zasięgu to ok 2 tygodni roboty. Testy baterii tydzień czy dwa.
Pozostaje zaimplementować szyfrowanie, tu gotowca nie dam, mogę tylko coś podpowiedzieć. Czasy nadawania trzeba losować aby ewentualne kolizje w kolejnej transmisji "rozjechały się". W roli ziarna użyłem nr seryjnego STM32. generatory pseudolosu w różnych kompilatorach (bibliotekach) są różne. Warto poświęcić trochę czasu na testy owej losowości.