Nie zmieniają się wszystkie stany za pomocą channelValueChanged

[krycha88]

Na 100% to nie wina clouda. Zwiększ rozmiar kolejki.
https://github.com/SUPLA/arduino/blob/m ... srpc.c#L46

na 4

Sprawdzę dzisiaj to wieczorem, czy będzie lepiej.

Ale muszę przyznać, że priorytet tego problemu trochę zmalał jak pisałem posta to byłem przekonany, że stan 3 kanału się nie zmienia. Problem w moim przypadku będzie widoczny tylko przy starce urządzenia czyli bardzo rzadko. Nie mam podpiętych żadnych DS i nie mogę potwierdzić tego co pisze @Zybi

int status = client.read((uint8_t *)buf, size);
Serial.println(status);
if (status == 26) {
SuplaDevice.channelValueChanged(0, read_supla_relay_state(0));
SuplaDevice.channelValueChanged(1, read_supla_relay_state(1));

Pytanie - skąd ta wartość "26" ?

Zawsze po nawiązaniu połączenia i zarejestrowaniu urządzenia serwer mi zwracał 26 a co ona oznacza po stronie serwera to nie mam pojęcia.

[vajera]

client.read(...) zwraca chyba tylko liczbę odczytanych bajtów ?

[pzygmunt]

Wcześniej patrzyłem na to z tel i nie widziałem całego kodu.

Poważnym błędem jest wywołanie channelValueChanged z supla_arduino_tcp_read. Może to prowadzić do zapętlenia i w efekcie rozłączenia przez serwer. To nie może poprawnie działać.
Kolejna sprawa. client.read nie zwraca żadnego statusu tylko ilość bajtów przeczytaną z socketa.

[krycha88]

Wcześniej patrzyłem na to z tel i nie widziałem całego kodu.

Poważnym błędem jest wywołanie channelValueChanged z supla_arduino_tcp_read. Może to prowadzić do zapętlenia i w efekcie rozłączenia przez serwer. To nie może poprawnie działać.
Kolejna sprawa. client.read nie zwraca żadnego statusu tylko ilość bajtów przeczytaną z socketa.

Dziękuję za pokazanie problemu w moim kodzie.
Pierwsza myśl zrobić coś podobnego jak w SuplaDeviceClass::iterate tylko nie wiem jak w ładny sposób odczytać czy urządzenie jest zarejestrowane w cloudzie.

W jaki sposób mogę to rozwiązać, macie jakiś pomysł?

[pzygmunt]

Dlaczego to chcesz robić w iterate ?
Nie lepiej w callbackach które do tego służą ?
Dodatkowo masz timer do wykorzystania.

[vajera]

Można to zrobić bezpośrednio w funkcji impl_arduino_status ?

[pzygmunt]

impl_arduino_timer

[cino111]

impl_arduino_timer

Pzygmunt jeżeli zmiany mają być tylko w pliku src to może byś je wprowadził jeszcze na obecnej bibliotece. Pewnie na razie nowej wersji biblioteki nie masz czasu przygotować, a ta mała zmiana dużo by rozwiązała.

[krycha88]

w setup() dodałem SuplaDevice.setStatusFuncImpl(&status_func) później:

Code: Select all

void status_func(int status, const char *msg) {
  if ( status == 17 ) {
    Serial.println("wczytano stan przelacznikow");
    SuplaDevice.channelValueChanged(0, read_supla_relay_state(0));
    SuplaDevice.channelValueChanged(1, read_supla_relay_state(1));
    SuplaDevice.channelValueChanged(2, read_supla_relay_state(2));
  }
}

Chyba jest to już lepsze rozwiązanie niż moje pierwotne? Nie wiem jak bym miał do tego wykorzystać impl_arduino_timer.

[krycha88]

Na 100% to nie wina clouda. Zwiększ rozmiar kolejki.
https://github.com/SUPLA/arduino/blob/m ... srpc.c#L46

na 4

Nic to nie daje.
Opóźnienia są szczególnie widoczne przy obsłudze multi pomiarów na DS-ach w połączeniu ze sterowaniem przekaźnika. Dlatego też w swoich softach ograniczam ilość DS-ów do 4.
Przekazywanie stanu kanałów przekaźników i sensorów do apki na smartfonie działa tak jakby miały mniejszy priorytet od przekazywania wartości pomiarów od termometrów, chociaż samo wykonanie zmiany stanu przekaźnika w urządzeniu następuje praktycznie bez zwłoki.
Przekazywanie stanu kanału bez opóźnień działa dopiero po stabilizacji temperatury na termometrach, czyli de facto wtedy, gdy pomiary temperatury nie są przekazywane do Cloud-a.

spróbowałem poprawić plik srpc.c faktycznie nic to nie daje. Przekazanie stanów 2 pierwszych kanałów następuje natychmiast stan 3 kanału w apce odświeża się dopiero po ok 30s.