wysyłanie danych pogodowych

[klew]

Dodałeś też dependencję do ArduinoJson, która jest używana w pliku cpp, więc wszystkie targety na Arduino IDE będą to kompilować.
Osobiście nie używałem tej biblioteki. Wstępnie rzuciłem okiem i wygląda dość ok (brak dependencji do rzeczy specyficznych dla Arduino, licencja MIT). Ale dodanie takiej dependencji powoduje, że każdy musi tą libkę zainstalować, aby móc skompilować SuplaDevice, nawet jeśli tego nie używa w swoim kodzie.

[malarz]

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

Dokładnie tego oczekiwałem.

"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.

Sorki, nie zauważyłem. Ja znam tylko te klasy, które gdzieś użyłem albo przypadkiem znalazłem. Może jakaś sugestia nazwy. Dostosuję się.

Folder Protocol był zamierzony 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ż zwykły Element. Jest tam też trochę metod specyficznych dla "Supla SRPC", ale tych nie trzeba ruszać.

Ktoś mi takie miejsce zasugerował: viewtopic.php?p=199850#p199850 Takie wysyłanie danych nie jest jakiś procesem ciągłym. Przygotowujemy paczkę danych, wysyłamy i zapominamy. Wziąłem po Supla::Element bo to mi wystarczało.

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

Wiem, ale nie chciało mi się z tym walczyć. Można z tego całkiem zrezygnować (wysyłać i zapominać); ja chciałem w logu mieć info czy wysłanie było dobre. 100ms mi wystarczyło (dla aqi.ecu i sensor.community). Trochę po odpowiedziach dochodziłem co powinienem poprawić w JSONie, bo dokumentacja tych serwisów ma małe braki. W sumie można by spróbować odczytać kilka sekund po wysłaniu ale to by wymagało rozbudowy klasy (stan po wysłaniu, stan po odczytaniu odpowiedzi).

Obserwując samo działanie WiFiClienta (który potrafi dodać kilkunastosekundowego deleaya przy problemach z połączeniem) stwierdziłem, że ta niecała sekunda nic nie zmieni. Zresztą ta klasa jest dla stacji pogodowych a nie urządzeń sterujących, więc takie opóźnienia raczej nikomu w niczym nie zaszkodzą.

Dlaczego można dodać tylko jeden termometr przez addSensor ? I analogicznie każdy inny typ można dodać tylko raz.

Bo i tak można wysłać tylko jedną temperaturę na jedną stację pogodową. Dzięki temu jak już chyba pisałem nie muszę się zastanawiać którą temperaturę klasa ma wysłać. Jak ktoś ma na jednym ESP różne pomiary z dwóch miejsc to powinien zarejestrować dwie stacje w takim serwisie i ich pomiary oddzielnie wysyłać. Wtedy mamy dwa obiekty klasy AqiEcu z dodanymi różnymi termometrami.

Jak trzeba to przerobię na listę, ale wydaje mi się, że zabawa nie jest tego warta. Nawet jak rozbudujemy listę rodzajów sensorów np. do 25.

Teoretycznie Aqi.Ecu przyjmie na raz jeszcze drugą temperaturę (z grzałki HECA viewtopic.php?t=16621), ale i tak nie ma co z tym zrobić (poza zbieraniem danych historycznych), więc pomijam to milczeniem. Jakby się na to zdecydować to i tak trzeba dodać kolejny rodzaj sensora zdefiniowany jako temperatura w grzałce a nie temperatura powietrza.

Dodałeś też dependencję do ArduinoJson, która jest używana w pliku cpp, więc wszystkie targety na Arduino IDE będą to kompilować.
Osobiście nie używałem tej biblioteki. Wstępnie rzuciłem okiem i wygląda dość ok (brak dependencji do rzeczy specyficznych dla Arduino, licencja MIT). Ale dodanie takiej dependencji powoduje, że każdy musi tą libkę zainstalować, aby móc skompilować SuplaDevice, nawet jeśli tego nie używa w swoim kodzie.

Podobne coś nam wyszło w przypadku sensora PM. Stąd moje pytanie w poprzednim poście dot plików: Jak rozumiem klasę WebSendera (po zmianie nazwy) powinienem raczej rozbić na .h i .cpp, zaś klasę AqiEcu scalić tylko w .h aby nie trzeba było u wszystkich instalować tej biblioteki.

Resztę uwag muszę spokojnie przetrawić, zajrzeć do kodu SD, więc do nich nie mam na razie pytań. Dzięki za uwagi. Kilka(naście) dni (wieczorów) mi się zejdzie.

[malarz]

Klasę bym nazwał WeatherSender (nie powinno się z niczym kłócić)

Jako miejsce jeżeli nie /src/supla/protocol/ to może /src/supla/network/weather/

@klew co Ty na to?

[klew]

Zostaw ją na razie w protocol.
Network mi jeszcze bardziej nie pasuje ale nie mam lepszych pomysłów. Ewentualnie można dodać osobny folder jeśli planujesz tych integracji pogodowych więcej.

[malarz]

Na dzień dzisiejszy planuję 1 (ogólna) +3 (serwisy). Z tej trójki jedną mam gotową do przeróbki (jest w tym PR), druga w trakcie (w sumie już wszystko rozgryzłem jak wysyłać, ale sam kod nie napisany i czeka na ustalenia dot. ogólnego), trzeci chciałbym, ale nie mogę dotrzeć od opisu API.

[malarz]

@klew naniosłem część sugerowanych zmian:

1. zmiana nazwy klasy
2. połączenie .h i .cpp w przypadku klasy wymagagącej JSONArduino aby można było kompilować bez
3. czytanie danych z Supla:Chennel

Jakbyś miał chwilkę czasu i to krótko zrecenzował (szczególnie pkt. 3) to byłoby fajnie. W związku z tą zmianą będzie parę kolejnych:
* rezygnacja z współczynników korekty (bo przecież są już odpowiednie w kanałach)
* zmiana typu dla dodawanych czujników z Supla:Element na Supla:Channel (albo coś w okolicach)

[malarz]

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.

O ile dla termometru, higrometru i ciśnieniomierza Supla::Channel (z funkcją getDoubleValue()) jest dobrym źródłem dla odczytania wartości o tyle dla czujników opartych na KPOP zdecydowanie lepszym wydaje się Supla::Sensor::GeneralPurposeChannelBase (z funkcją getCalculatedValue()). Jedynym wspólnym przodkiem tych klas jest chyba Supla::LocalAction.

Czy jest może w planach (rozważaniach) jakaś akcja przepisania części kodu czujników ThermHydroPress tak aby też bazowały na GPCB? Obecne rozbicie na dwa podtypy sensorów jest trochę nielogiczne, wiem, że wynika z historii powstawania klas.

[malarz]

Dobra, zakończyłem moją porcję zmian (lub ich braku) w reakcji na dotychczasowe uwagi. Teraz jeszcze raz usiadłem do uwag i stwierdziłem, że chyba na razie nie mam co zmieniać.

"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).

klasa nazywa się WeatherSender (src/supla/protocol/weathersender.h)

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).

Jak wcześniej pisałem - tutaj wysyłamy i zapominamy co zrobiliśmy. Kolejne przesyłki nie są ze sobą powiązane. Moim zdaniem nie ma po co sobie komplikować życia i analizować poprzedniej próby komunikacji.

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();

Serial.println wyleciało (moje przeoczenie), zaś WifiClientSecure jednak jest używane w PV SolderEdge:
https://github.com/SUPLA/supla-device/b ... edge.h#L25

Powiem szczerze, nie wykombinowałem jak skorzystać z createClient() więc albo bym zostawił jak jest albo proszę o jakieś wskazówki a najlepiej od razu przykład.

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

Nawet chciałem to zaimplementować. Ale potem zajrzałem do rozgrzebanego wysyłania do sensor.community - tam będzie wysyłanych kilka kolejnych komunikatów (liczba zależna od konfiguracji)i zrobienie tego w rozsądny sposób wymaga strasznego rozbudowania struktury pamiętanych informacji i sposobu decydowania co i kiedy robimy. Wydaje mi się, że zabawowy charakter tej klasy umożliwia trochę nagięcie zasad przyjętych w projekcie. Jest mało prawdopodobne, że na tym samym module, na którym będzie działała stacja pogodowa będziemy chcieli jeszcze sterować wystrzeliwaniem rakiet balistycznych

Jeżeli będziesz mocno oponował przeciwko pozostawieniu to po prostu usunę delaya i fragment wrzucający status odpowiedzi do logu bo jest to zbyt mało ważne, aby się tym zajmować. 100ms jest zaś jakimś kompromisem - w większości sytuacji da to jakiś wpis w logu i jednocześnie nie przetrzyma długo w przypadku problemów z połączeniem.

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.

poprawione

Dlaczego można dodać tylko jeden termometr przez addSensor ? I analogicznie każdy inny typ można dodać tylko raz.

Pisałem wcześniej: nie ma jak przekazać do tych serwisów danych z dwóch termometrów jako temperatury z jednej stacji pogodowej

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

Ile zatem przyjąć? Tu bym skorzystał chętnie z jakiejś podpowiedzi. Domyślny ma 11 znaków + '\0'. "123.123.123.123" ma 16 znaków. Podejrzewam, że i tak nikt tego nie będzie definiował.

Dodałeś też dependencję do ArduinoJson, która jest używana w pliku cpp, więc wszystkie targety na Arduino IDE będą to kompilować.
Osobiście nie używałem tej biblioteki. Wstępnie rzuciłem okiem i wygląda dość ok (brak dependencji do rzeczy specyficznych dla Arduino, licencja MIT). Ale dodanie takiej dependencji powoduje, że każdy musi tą libkę zainstalować, aby móc skompilować SuplaDevice, nawet jeśli tego nie używa w swoim kodzie.

Teraz jest tylko w ".h", więc do kompilacji u nieużywających nie będzie potrzebna. Mógłbym z niej zrezygnować, ale kod będzie mniej czytelny. Może da się oszczędzić kilka bajtów pamięci rezygnując z biblioteki, ale i tak to będzie działało jedynie na ESP32, więc chyba gra nie jest warta świeczki.

[malarz]

Przypominam się.

[malarz]

AQI.ECU jest już włączone przez @klew do supla-device

Teraz będzie mała przerwa na SCD41 (czujnik CO2) i potem wracam do wysyłania danych do sensor community