- studium problematiky WiFi a IoT
- typicke problemy: spotreba energie, vyuziti jiz postavene site, lze se spolehnout na rychlost (napr u MQTT)
- dava smysls smerovani na urovni MAC address?
- teoreticky ano, nikde se neuziva, proce?
- jak smerovat? Vyuziti modelu DNS?
- otazky
- nebudou problem, kdyz budou 2 zarizeni moc blizko u sebe?
- bude samotne vysilani ovlivnovat polarizace a volba kanalu?
- jake specialni moznosti nabizi IEEE 802.11 pro IoT?
- viz: ./docs/volba-modulu.md
- vitezem je ESP32-S2
- treba pouzit nasledujici konfiguraci pro PlatformIO
[env:esp32dev]
platform = espressif32
board = esp32-s2-saola-1
framework = arduino
; config microcontroller
board_build.mcu = esp32s2
upload_protocol = esptool
board_build.f_cpu = 240000000L ; change MCU frequency
board_build.flash_mode = dio ; this option is important for ESP32-S2- a nakonfigurovat
usbEventCallback(viz 3.0.1)
Závěrečný report k samostatnému proejtku je možný ke stažení v Issues #9 na odkaze: https://github.com/petrkucerak/rafting-button/files/10468332/kucerp28_samostatny-projekt.zip
- ESP může fungovat 2 módech: AP (Access Point), STA (Station Mode)
- Článek, jak aktivovat ESP-NOW a Wifi zároveň
- v módu STA pravděpodobně nefungovalo, protože při neaktivitě modul přecházel do spánku
- Diskuze na Arudion Foru
- Jednoduse ano: tento mod by mel fungovat, otazka vypocetni sily MC -> třeba provést testy
- bude třeba nějaký implementovat nebo jednoduše spojím všechny zařízení mezi sebou? v specifikaci limit 10 zařízení, bude stačit?
- pokud ne, bylo by třeba hledat alogritmus pro vytvoření clusterů
- Z předmětu PDV známo několik algoritmů a způsobů, které by šlo aplikovat
- Idea ukládat pořadí jako pole, které bude replikované na všechny nodes
| řešení | zjednodušený model | garance | algritmy |
|---|---|---|---|
| zavedení logického času | asynchronost | bezpečnost a živost | Lamportovy vektorové hodiny |
| globální spatshot | asynchronost | bezpečnost a živost | Chandy-Lamport |
| propracovaný alogritmus na konsezus | asynchronost a selhání | bezpečnost | RAFT |
- PTP? -> spíše ne, nevidím výhodu v ladění přesné časové značky, stačí logický čas -> synchronizace na zaklade logickych casovych znacek
- každé zařízení má své logické hodiny
- při události inkemetuje lokální vektorové hodiny a každá odeslaná zpráva jedny své hodiny má, při přijetí zvyšuje hodnotu na vyšší
- vektorové, aby determinovali souběžnost
- mohu pomocí tohto alogoritmu vůbec garantovat?
- není řešení problému, spíše se možné inspirovat při navržení vlastního alogritmu
- možná až moc komplikovaný
- na druhou stranu zajišťuje i detekci chyby (toto ale možná lepší řešit na úrovni algorimu pro propojení)
- absence živosti - to by mohl byt problem
- pro ovládání: display nebo RGB LED?
- display i na zobrazování výsledků
- joystik - pro masivnejsi ovladani
- baterie vs akumuator (nabijeni z USB)