wysyłanie danych pogodowych

[malarz]

Do jakich bezpłatnych serwisów wysyłacie dane ze stacji pogodowych? Czy możecie podzielić się kodem?

Znalazłem rozwiązania:

@SOYERa (do aqi.eco)
viewtopic.php?p=191272&hilit=aqi.eco#p191272

@shimano73 (też aqi.eco)
https://github.com/shimano73/Stacja_pog ... on.ino#L99

Zastanawiam się, czy nie warto napisać to jako klasy Supli (@klew jakiego typu?). Wtedy łatwo (czytelnie) można by go dołączać do różnych projektów.

[klew]

W Supli prawie wszystko dziedziczy po Supla::Element.
To klasa bazowa dla większości obiektów.
Tam masz metody, które są uruchamiane w określonych momentach (ładowanie configa, ładowanie stanu, rejestracja, iteracja/loop, iteracja gdy jest połączenie z serwerem supli itd.)

Jeśli piszesz klasę, która dziedziczy po Element, to wstawiając fragment kodu do "iterateAlways", będzie się on wykonywał za każdym loopem programu.

[malarz]

A jak już pytam, to gdzie ją potem umieścić?

src/supla/upload/aqi.eco.h
src/supla/upload/aqi.eco.cpp

Będzie dobrze?

[klew]

W zasadzie można to potraktować jako kolejny "protokół" do którego udostępniamy dane. Obecnie jest tam Supla i MQTT.
Tylko same protokoły mają trochę inną strukturę, ale to bym musiał przy kompie sobie odświeżyć jak to działa i czy to będzie dobre miejsce.

[malarz]

W zasadzie można to potraktować jako kolejny "protokół" do którego udostępniamy dane. Obecnie jest tam Supla i MQTT.
Tylko same protokoły mają trochę inną strukturę, ale to bym musiał przy kompie sobie odświeżyć jak to działa i czy to będzie dobre miejsce.

Powoli kończę, mam problem związany z czytaniem z webinterface:

Code: Select all

void setup() {
...
  // start parameters from memory
  Supla::Storage::Init();

  // aqi.eco sender
  const char AQIPARAM[] = "aqitk";
  new Supla::Html::CustomTextParameter(AQIPARAM, "aqu.eco Token", 32);
  char token[33] = {};
  if (Supla::Storage::ConfigInstance()->getString(AQIPARAM, token, 32)) {
    SUPLA_LOG_DEBUG(" **** Param[%s]: %s", AQIPARAM, token);
  } else {
    SUPLA_LOG_DEBUG(" **** Param[%s] is not set", AQIPARAM);
  }
...

Daje w logu efekt:

Code: Select all

...
19:45:37.163 -> SERVER: key aqitk, value xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...
19:45:40.752 -> Main storage not configured
19:45:40.752 -> LittleFsConfig: file "/supla-dev.cfg" size 632
19:45:40.752 -> LittleFsConfig: initializing storage from file...
19:45:40.752 -> LittleFsConfig: init result success
19:45:40.783 ->  **** Param[aqitk] is not set
...

i powoli już nie wiem, gdzie coś mogłem popsuć (w jakiejś innej klasie / uruchomieniu webinterfejsu podczas pracy / ...)

[klew]

Daje w logu efekt:

Code: Select all

...
19:45:37.163 -> SERVER: key aqitk, value xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...
19:45:40.752 -> Main storage not configured
19:45:40.752 -> LittleFsConfig: file "/supla-dev.cfg" size 632
19:45:40.752 -> LittleFsConfig: initializing storage from file...
19:45:40.752 -> LittleFsConfig: init result success
19:45:40.783 ->  **** Param[aqitk] is not set
...

Czemu masz najpierw jakiś log w web serwera, a chwilę później ze startu urządzenia?
Jest reset w międzyczasie robiony?

Ten tekst "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ma 32 znaki. Do tego trzeba dodać '\0' na zakończenie ciągu znaków i robi się 33 bajty. Także musisz zwiększyć 32 na 33.

[malarz]

Daje w logu efekt:

Code: Select all

...
19:45:37.163 -> SERVER: key aqitk, value xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...
19:45:40.752 -> Main storage not configured
19:45:40.752 -> LittleFsConfig: file "/supla-dev.cfg" size 632
19:45:40.752 -> LittleFsConfig: initializing storage from file...
19:45:40.752 -> LittleFsConfig: init result success
19:45:40.783 ->  **** Param[aqitk] is not set
...

Czemu masz najpierw jakiś log w web serwera, a chwilę później ze startu urządzenia?
Jest reset w międzyczasie robiony?

Ten tekst "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ma 32 znaki. Do tego trzeba dodać '\0' na zakończenie ciągu znaków i robi się 33 bajty. Także musisz zwiększyć 32 na 33.

Tak to jest log po naciśnięciu zapisz i zrestartuj w webinterface.

Tak, tokeny aqi.eco mają 32 znaki (po pobieżnym sprawdzeniu w githubie projektu, wydaje mi się, że zawsze). Sprawdzę wieczorem czy to pomoże.

[malarz]

Tablica była 33 znakowa. W wywołaniu getStringa zmieniłem 32 na 33 i działa. Jeszcze kilka ostatnich testów, zmergowanie poprzedniego PR i będę wrzucał kolejny PR , a ja wracam do HECY

[malarz]

Dobra. Publikuję częściową pracę. Klasa do wysyłania danych do aqi.eco. Mam też prawie gotową klasę dla https://sensor.community, ale musi poczekać na skończenie tej klasy (i klasy ogólnej).

Obecna część zmian jest w:
https://github.com/SUPLA/supla-device/pull/93

Na pewno do poprawy jest https://github.com/malarz-supla/supla-d ... ebsender.h (trzeba z niego wydzielić kod do cpp). @klew, tylko co w nim jeszcze jest do poprawy? Wrzuciłem resztę plików głównie po to aby można było się zorientować w sposobie wykorzystania tej klasy.

Zdecydowałem się każdą część sensora traktować niezależnie; dzięki temu mogę wziąć ciśnienie z BME, temperaturę z DS a wilgotność np. z SHT31.

Z założenia (WebSender) jest to klasa wirtualna (chyba tak to się obecnie nazywa), która służy do ujednolicenia konfiguracji i sposobu wywołania różnych klas wysyłających dane na poszczególne serwisy. Zaszyty w niej jest też mechanizm wyciągania wyników z sensorów. Moje wątpliwości:
* typ SensorType - czy taki sposób ma sens
* tablice sensors[] i kolejne - zdecydowałem się na taki sposób składania listy sensorów do danej wysyłki aby od razu wyeliminować możliwość powtórzenia danych tego samego typu. Zastanawiałem się nad dynamiczną listą sensorów ale stwierdziłem że ma dwie wady - trzeba by zrobić klasę do obsługi listy i trzeba by jakoś wyłapywać powtórzone sensory

Kolejne wątpliwości mam w klasie AQIECO, ale wyartykułuję je po skończeniu poprawej w klasie WebSender. Może poza jedną. Klasa ta wymaga biblioteki ArduinoJson. Trzeba ją jakoś dodać. Czy w takim razie klasa AQIECO powinna być rozbita na pliki h i cpp czy scalić ją tylko w plik nagłówkowy?

[klew]

Dobra. Publikuję częściową pracę. Klasa do wysyłania danych do aqi.eco. Mam też prawie gotową klasę dla https://sensor.community, ale musi poczekać na skończenie tej klasy (i klasy ogólnej).

Zaczałem to przeglądać i najpierw chciałbym pogadać o tym jeszcze tutaj, zanim przejdziemy do szczegółów

"web sender" - klasa o tej nazwie jest już używana w src/supla/network/web_sender.h i służy to obsługi wysyłania fragmentów htmla na lokalnym www.

Samego "Network" nie musisz przekazywać do klas. Network jest zbudowane trochę w stylu "singletona" i masz tam dostęp do Supla::Network::IsReady(), które działa niezależnie od tego czy używasz Wi-Fi, czy też jakiegoś LAN-a (albo obu na raz).

Folder Protocol był zamirzeony dla klas dziedziczących po Supla::Protocol::ProtocolLayer a nie po Supla::Element.
Te protokoły obsługują trochę więcej rzeczy i mają inaczej zbudowaną logikę niż zwkły Element. Jest tam też trochę metod specyficznych dla "Supla SRPC", ale tych nie trzeba ruszać.

Taki protokół domyślnie obsługuje wszystkie użyte elementy i klasy. Można to też skonfigurować po swojemu, aby ograniczyć ilość publikowamych danych (jak w Twoim przykładzie).

Ogólnie unikam rzeczy dostępnych tylko w Arduino, a jeśli są użyte, to często są schowane za jakimiś klasami interfejsami. Np. nie używamy Serial.println, ale SUPLA_LOG_...
Nie używamy WifiClientSecure, tylko pobieramy sobie klienta sieciowego z:

Code: Select all

      client = Supla::Network::Instance()->createClient();

Nie czekamy w klasie synchornicznie na odpowiedź z jakiegoś serwera. delay(100) to może być za mało, aby serwer odpowiedział.

Metody getTemp, getHumi, itd - nie powinny być używane do pobrania aktualnego pomiaru z sensora. Tzn. one są używane przez te sensory, do tego, aby zaktualizować swój stan i udostępnić go reszcie programu, ale nie powinny być używane z zewnątrz. Raczej powinieneś czytać stany kanałów z odpowiedniego Supla::Channel.
Dlaczego można dodać tylko jeden termometr przez addSensor ? I analogicznie każdy inny typ można dodać tylko raz.

33 bajty na adres serwera, to może być za mało.