Choć w tym przypadku pozostanie pewnie zakup konwertera USB-UART(TTL).
Myślę, że ten wpis na stronie Tasmota rozjaśnia problem:
Choć w tym przypadku pozostanie pewnie zakup konwertera USB-UART(TTL).
Myślę, że ten wpis na stronie Tasmota rozjaśnia problem:
Czy mógłbyś napisać w jaki dokładnie sposób wgrałeś wersję Tasmoty 9.1.0 z AIS po kablu ? U mnie po wgraniu mam w konsoli poniższe informacje i nie widzę AP gniazda.
Z logów wynika, że gniazdko próbuje połączyć się. Nie masz żadnej rozgłaszanej sieci o nazwie dom?
Nie mam takiej.
Przez chwilę pojawił mi się poniższy AP ale nie mogłem się z nim połączyć.
Po “reset 1” mam tak:
Czyli masz tak samo jak ja miałem. Ja do wgrania użyłem Tasmotizer:
Udało mi się podłączyć do swojej sieci poleceniem:
Backlog SSID1 (NazwaSieciWiFi); Password1 (HasloWiFi);
Uff
Spróbuj z ręku podać komendy ustawiające sieć:
Backlog SSID1 **WiFiSSID** Password1 **WiFiHaslo** ; PowerRetain 1; SetOption19
Uwaga: SSID rozróżnia wielkość liter.
Edit: byłeś szybszy…
@Cezary.K w tym samym czasie Dzięki
Nadal poszukuję sprawdzonego adaptera WI-Fi pod USB z obsługą AP pod Linux`em. Czy ktoś może jakiś polecić?
Tak może trochę się wcisnę w temat. Sam korzystam z Raspberry Pi do flashowania tuya-covert.
Ale mam kartę na USB WiFi i z ciekawości sprawdziłbym czy obsługuje ona tryb AP, jak to zrobić najłatwiej na Raspianie lub Ubuntu Server?
Wpisując komendę iw list
wypluje miedzy innymi:
Cisco DPW632 - zasięg ma lepszy niż wifi wbudowane w RPi
Oczywiście obsługuje AP.
Korzystam z TEGO na RTL8812BU. Obsługuje “Soft AP” ale nie musiałem z tego trybu korzystać. Uruchomiłem wirtualkę z Ubuntu, wgrałem sterowniki z TEJ strony i zadziałało od pierwszego razu.
Dzięki za kolejne namiary. Chciałem uniknąć kompilacji sterownika w Linux dlatego odesłałem TP-Linka TL-WN722N. Więc poszukiwania karty działającej po włożeniu do portu USB w trybie AP nadal aktualne.
P.S. Nie żebym się bronił przed sterownikami ale może inni mniej wprawni w konsoli Linuxa skorzystają z naszych doświadczeń.
Dla zainteresowanych:
Zrobiłem kilka poniższych testów na nowych gniazdach:
Reset 5 po zakończeniu aktualizacji.
Po wgraniu z AIS tasmota-minimal.bin lub tasmota.bin gniazdo już się nie podnosi.
Podmiana w katalogu tuya-convert/files oryginalnego pliku tasmota.bin na tasmota-minimal.bin z AIS.
Gniazdo się podnosi, pojawia się nowe AP do którego można się podłączyć ale nie można wyświetlić zawartości 192.168.4.1.
Podmiana w katalogu tuya-convert/files oryginalnego pliku tasmota.bin na tasmota.bin z AIS.
Nie ma możliwości wyboru wgrania Tasmoty.
Pozostaje sprawdzona metoda aktualizacji za pomocą przewodów.
Czyli nie muszę już próbować, dzięki @CichY.
Myślę jednak, że reset 5
nie załatwia sprawy. Może należy użyć reset 2
mając na uwadze, że pojawiały się nam AP dom
i równolegle AP ESP
. Przypuszczam, że tu jest konflikt przy stawianiu serwera DHCDP przez ESP. Proponuję, jak już mamy oryginalny plik bin z Tuya Convert, to pozostać przy nim, następnie zaktualizować do pełnej Tasmota (orginał) i wówczas reset 2. Czysta Tasmota do pozostawienia lub dalszych testów z aktualizacjami po OTA na AIS.
Przetestowałem na ostatnim gniazdku i zadziałało
Krótki opis:
Zauważyłem tylko jedną różnicę pomiędzy wgraniem Tasmota AIS z wykorzystaniem przewodów a Tuya Convert. W wersji wgrywanej za pomocą przewodów (a) kolory przycisków w konfiguracji są szare a przy Tuya Convert (b) są niebieskie.
a:
b:
Czyli coś z oryginału Tasmota pozostaje w pamięci.
Dzięki @zielony. Zmieniłem WebColor na taki jaki jest w AIS-Tasmota:
WebColor {“WebColor”:["#eeeeee","#2f2f2f","#2f2f2f","#000000","#dddddd","#4caf50","#1e1e1e","#ff5661","#008000","#faffff","#b9babb","#767879","#d43535","#931f1f","#47c266","#007b20","#faffff","#999999","#eaeaea"]}
W oryginalnej Tasmocie jest tak:
WebColor {“WebColor”:["#eaeaea","#252525","#4f4f4f","#000000","#dddddd","#65c115","#1f1f1f","#ff5661","#008000","#faffff","#1fa3ec","#0e70a4","#d43535","#931f1f","#47c266","#5aaf6f","#faffff","#999999","#eaeaea"]}