Skanowanie Wifi w trybie cfg

[klew]

Niedługo wrzucę taką funkcję:

Clipboard___July_2nd__2026_2_41_PM.png

Clipboard___July_2nd__2026_2_45_PM.png

Będzie można z listy wybrać znalezioną sieć. Jest też informacja o zasięgu.

Przy dodawaniu urządzenia z apki, na ostatnim ekranie będzie też informacja czy wybrana sieć była znaleziona i jaki był sygnał.

Dzięki temu będzie można trochę łatwiej diagnozować problemy z dodaniem urządzenia i brakiem połączenia.

Funkcja dla DIY oraz oficjalnych urządzeń opartych o procesory z rodziny ESP32

Wrzucę to w wersji 26.07

[QBA-dev]

Elegancko. Przyda się
Swoją drogą(trochę offtopic) w trybie config lepiej byłoby obsługiwać ustawienia czymś w rodzaju CGI działającym na ścieżce np. IP/supla lub IP/cgi-bin/supla i jsonem

Chodzi mi o obsługę konfiguracji w taki sposób że można by było pobrać ją zapytaniem GET i zwrotnie dostawałoby się obiekt json z nazwą sieci, emailem i adresem serwera itd... i zwrotnie odsyłało też jsona zapytaniem POST
A nie jak jest teraz że aplikacja pobiera cały formularz HTML i wyciąga z tego stan inputów w HTML. Kształt interfejsu konfiguracyjnego jest przez to zafiksowany łącznie z elementami interfejsu.
Wiem że ze względu na kompatybilność wsteczną to co proponuje może być problematyczne, ale jeśli to możliwe prosiłbym o zmianę w tym kierunku kiedyś

To by otwierało drogę do konfigurowania urządzeń z kreatora w aplikacji nawet takich Linux embedded z na przykład busybox-httpd
Ja robię od dłuższego czasu w ten sposób urządzenia w pracy i mam gotowy interfejs również gdyby ktoś chciał zrobić aplikację do konfiguracji czy na PC

[klew]

Możemy dodać endpoint w formacie json, ale w gruncie rzeczy nie ma dużej różnicy czy to HTML czy json.
Dodatkowo obecnie dochodzi https oraz logowanie z hasłem i cookie do sesji.

[QBA-dev]

@klew json nieporównywalnie latwiej się parsuje. Z mojej strony nie ma jakiegoś ciśnienia. W pracy niestety nie robię nic z obsługą SUPLi(branża nie IoT) ale potencjalnie json jest lepszym sposobem na wymianę danych bo nie forsuje wyglądu formularza HTML jak to robi , albo robiła aplikacja(dawno nie patrzyłem w kod, a dużo się dzieje)

U mnie to wygląda w taki sposób że generuję formularz na podstawie tego co zwróci mi fetch

Code: Select all

fetch(esp_url+"/supla?action=get_config")

I odsyłam zmodyfikowane dane POSTem:

https://github.com/QB4-dev/esp-supla-fi ... pt.js#L105

To samo bym zrobił na webserverku na czymś z Linuksem, z tym że tam najczęściej wykorzystuję bardzo podstawowy busybox-httpd i wymusza on żeby takie operacje robić z użyciem CGI więc ścieżka byłaby /cgi-bin/supla ale filozofia ta sama GET/POST json

Aaa i wtedy trzymałbym zgodne nazwy pól z tymi których używacie w HTML typu: svr - server eml - email itd

[klew]

cgi-bin raczej nie dodamy. To jakiś archaizm .
Jeśli dodamy endpoint na dane w formacie json, to będzie to np przez dodanie ?format=json, albo czegoś w ten deseń. Inny url też jest opcją.

Natomiast nadal - wszystko idzie w stronę https. W SUPLI używamy własnych certyfikatów i podpisane certyfikaty są używane tylko w oficjalnych urządzeniach.
Po drugie: dochodzi tworzenie hasła dostępowego do urządzenia.
Po trzecie: zanim jakikolwiek GET/POST zrobisz, to musisz się zalogować, a następnie utrzymywać sesję poprzez przesyłanie ciasteczka.

Jeśli używasz jakiegoś narzędzia, które pracuje tylko na "cgi-bin", to wątpię, czy tam takie operacje jak https/sesja się ogarnie.

[QBA-dev]

cgi-bin raczej nie dodamy. To jakiś archaizm .
Jeśli dodamy endpoint na dane w formacie json, to będzie to np przez dodanie ?format=json, albo czegoś w ten deseń. Inny url też jest opcją.

Natomiast nadal - wszystko idzie w stronę https. W SUPLI używamy własnych certyfikatów i podpisane certyfikaty są używane tylko w oficjalnych urządzeniach.
Po drugie: dochodzi tworzenie hasła dostępowego do urządzenia.
Po trzecie: zanim jakikolwiek GET/POST zrobisz, to musisz się zalogować, a następnie utrzymywać sesję poprzez przesyłanie ciasteczka.

Jeśli używasz jakiegoś narzędzia, które pracuje tylko na "cgi-bin", to wątpię, czy tam takie operacje jak https/sesja się ogarnie.

Tak, masz rację z tymi CGI. Od lat korzystałem z bardzo podstawowego webserwerka: busybox-httpd który obsługuje co najwyżej Basic-auth, TLS i https tu nie ma, websocketów też nie

Ale nadchodzi era CRA i moim zdaniem to trochę przerost formy nad treścią że trzeba będzie szyfrować lokalne połączenia i używać nawet tu https
Tak czy inaczej mus i będzie trzeba zamienić busybox-httpd na coś nowocześniejszego... z tym że nie bardzo mam kandydata. Wszystkie te cuda na node.js średnio moim zdaniem nadają się do embedded. Jak widzę co robi npm i ile rzeczy ściąga to płaczę w środku bo mam na przykład 128MB pamięci na cały system
Python i flask? Może tędy droga, chociaż python zaczyna się robić dziwny i skomplikowany przez te całe virtual envy i zmiany w składni niemal co wersję
Jest super projekt w C moongose-webserver, ale płatny w zastosowaniach komercyjnych
Jest też jeszcze lighthttpd którego na przykład widziałem ze używają w sterownikach przemysłowych WAGO

Tak czy inaczej bardzo ucieszyłaby mnie wymiana danych konfiguracyjnych jsonem bo moment zaimplementowałbym to na ESP i ogólnie porządniej by to wyglądało niż zabawy z HTMLem

[klew]

Trochę nie rozumiem
Dlaczego piszesz o web-serwerze w kontekście konfigurowania/wysyłąnia html do urządzeń?

[QBA-dev]

Trochę to zagmatwałem.
Pisze tu o teoretycznym urządzeniu z Linuksem embedded(lub ESP) które potencjalnie dałoby się skonfigurować używając kreatora w aplikacji.
Według stanu jaki pamiętam aplikacja oczekuje że urządzenie stworzy WiFi access point z nazwą SUPLA-xxxxx
Następnie aplikacja łączy się z tą siecią i oczekuje na adresie 192.168.4.1/ formularza HTML z danymi konfiguracyjnymi - dokładnie tego który jest zwracany przez urządzenia w trybie konfiguracji, łącznie z np. elementem <span>LAST STATE: </span> co nie jest fajne, bo forsuje strukturę formularza HTML, ale rozumiem że ze względu na kompatybilność wstecz musi tak być

Jako alternatywę dla tego HTMLa proponowałbym zwracania i oczekiwania jsona(GET/POST) na jakimś znanym endpoincie typu 192.168.4.1/supla bo byłoby to ładniejsze i czystsze rozwiązanie