Aktualizacja SuplaDevice

[Duch__]

Czy zmiany będą obsługiwać chwilowe zerwanie połączenia z serwerem CLOUD np. na 10-20 sekund żeby w tym czasie można było nawiązać połączenie z innym serwerem / urządzeniem, pobrać z niego dane i wznowić transmisję z CLOUD?

Pytam pod kątem odpytywania w międzyczasie serwera Airly o stan jakości powietrza by następnie wyświetlić to w aplikacji Supla. Może coś na wzór pakietu z informacją: "Sorry stary, na moment muszę się rozłączyć ale zaraz do Ciebie wracam". Fakt może się okazać że supla-dev nie wznowi już transmisji więc wtedy jakiś timeout po stronie serwera.

[klew]

Czy zmiany będą obsługiwać chwilowe zerwanie połączenia z serwerem CLOUD np. na 10-20 sekund żeby w tym czasie można było nawiązać połączenie z innym serwerem / urządzeniem, pobrać z niego dane i wznowić transmisję z CLOUD?

Pytam pod kątem odpytywania w międzyczasie serwera Airly o stan jakości powietrza by następnie wyświetlić to w aplikacji Supla. Może coś na wzór pakietu z informacją: "Sorry stary, na moment muszę się rozłączyć ale zaraz do Ciebie wracam". Fakt może się okazać że supla-dev nie wznowi już transmisji więc wtedy jakiś timeout po stronie serwera.

Nie kojarzę, aby było gdzieś ograniczenie na nawiązanie drugiego połączenia.
Jedyny problem może być z ilością pamięci na Arduino Mega, bo druga instancja połączenia będzie zajmować pamięć (z tego co pamiętam, to koło 500 bajtów). Biblioteka do ethernet shield pozwala (z tego co pamiętam) na 4 jednoczesne połączenia. Ale sam jeszcze się tym nie bawiłem, więc teoretyzuję .

Druga sprawa jest taka, że serwer/cloud nie pokaże, że utracił połączenie, dopóki nie minie "activity timeout" (teoretycznie konfigurowany na 30 s, ale w praktyce serwer stosuje aktualnie 110-120 s). Więc nawet w te 30 s idzie się wcisnąć.
Także jeśli odłączysz się od serwera i połączysz ponownie, to aplikacja zarejestruje się od nowa i będzie to niezauważalne. Wszelkie obserwowane przez użytkowników efekty takiego ponowenego połączenia należy traktować jak błąd (np. błedami są: klikanie przekaźników, znikanie odczytów temperatury, itd)

[Duch__]

Czyli nie zwracać uwagi na to że wywala komunikat "NOT CONNECTED", a za chwilę "Registered and Ready"?

[Goral64]

Ja właśnie w wolnych chwilach piszę bibliotekę SuplaDeviceGUI dla nowej wersji SuplaDevice by @klew w oparciu o GUI by @Duch__ , żeby było jak najbardziej jednolite i ustandaryzowane.
W tej chwili GUID urządzenia generuje się automatycznie w oparciu o jego Chip ID i MAC.

Właśnie "znalazłem" PrimaryGUI od @krycha88 no i to jest kawał dobrej roboty, tylko przepisać to jako bibliotekę...

[klew]

Czyli nie zwracać uwagi na to że wywala komunikat "NOT CONNECTED", a za chwilę "Registered and Ready"?

O ile masz tylko sensory na tym urządzeniu, to bym się zbytnio nie przejmował. Gorzej jak masz sterowanie czymś przez przekaźniki, wtedy przełączenie przekaźnika może nie zadziałać .

A czym jest spowodowane wyrzucanie tych komunikatów?

[klew]

Ja właśnie w wolnych chwilach piszę bibliotekę SuplaDeviceGUI dla nowej wersji SuplaDevice by @klew w oparciu o GUI by @Duch__ , żeby było jak najbardziej jednolite i ustandaryzowane.
W tej chwili GUID urządzenia generuje się automatycznie w oparciu o jego Chip ID i MAC.

Właśnie "znalazłem" PrimaryGUI od @krycha88 no i to jest kawał dobrej roboty, tylko przepisać to jako bibliotekę...

Docelowo planuję w samej bibliotece dodać automatyczne generowanie GUID i AuthKey, oraz zapisywanie konfiguracji urządzenia w eeprom/flash.
Natomiast nie mam w planach dodawania warstwy GUI i lokalnego serwera www do konfiguracji - to wg mnie powinno zostać jako oddzielna biblioteka.

[Goral64]

Docelowo planuję w samej bibliotece dodać automatyczne generowanie GUID i AuthKey, oraz zapisywanie konfiguracji urządzenia w eeprom/flash.

Ale GUID na podstawie MAC-a? Czy chcesz generować dowolny i go zapisać w eeprom/flash? Znajdę gdzieś opis dotyczący roli AuthKey, które też jest generowane dowolnie?

Natomiast nie mam w planach dodawania warstwy GUI i lokalnego serwera www do konfiguracji - to wg mnie powinno zostać jako oddzielna biblioteka.

Też jestem zdania, że GUI powinno być niezależą nakładką na SuplaDevice. A w formie biblioteki będzie łatwiejsze w użyciu.

[klew]

Ale GUID na podstawie MAC-a? Czy chcesz generować dowolny i go zapisać w eeprom/flash? Znajdę gdzieś opis dotyczący roli AuthKey, które też jest generowane dowolnie?

Generować "dowolny" i go zapisać. Na ESP można używać MAC, ale już na Arduino Mega adres MAC się też konfiguruje, więc nie można na nim polegać do generowania wartości.
AuthKey ma identyczną strukturę jak GUID, tylko nie jest nigdzie wyświetlany. Pozwala na logowanie do serwera w uproszczony sposób (nie trzeba podawać lokalizacji ani hasła). AuthKey powinien zawierać stałą wartość, która była wygenerowana losowo.

[Goral64]

Generować "dowolny" i go zapisać. Na ESP można używać MAC, ale już na Arduino Mega adres MAC się też konfiguruje, więc nie można na nim polegać do generowania wartości.

Czyli na Arduino można najpierw wygenerować MAC, a potem z niego GUID

AuthKey ma identyczną strukturę jak GUID, tylko nie jest nigdzie wyświetlany. Pozwala na logowanie do serwera w uproszczony sposób (nie trzeba podawać lokalizacji ani hasła). AuthKey powinien zawierać stałą wartość, która była wygenerowana losowo.

No właśnie, a jak urządzenie zostanie przypisane do lokalizacji np. 5 przy 10 lokalizacjach na podstawie maila i przypadkowej wartości AuthKey?

[klew]

No właśnie, a jak urządzenie zostanie przypisane do lokalizacji np. 5 przy 10 lokalizacjach na podstawie maila i przypadkowej wartości AuthKey?

To jest nowa wersja sposobu logowania. Urządzenie zostanie przypisane do "pierwszej" z brzegu lokalizacji.
Docelową lokalizację konfiguruje urzytkownik w cloud, a nie na urządzeniu wykonawyczym.
Tak działają wszystkie nowe gotowe urządzenia.

Ani mail, ani AuthKey nie wpływa na to, do jakiej lokalizacji urządzenie trafi domyślnie. Należy po prostu zapomnieć o konfigurowaniu lokalizacji na urządzeniu i przyzwyczaić się do tego, że trzeba to ustawić w cloud.