Nie zmieniają się wszystkie stany za pomocą channelValueChanged

krycha88
Posts: 360
Joined: Fri Nov 16, 2018 7:25 am

Mon Jun 10, 2019 5:34 am

pzygmunt wrote:
Sun Jun 09, 2019 6:23 pm
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
vajera wrote:
Sun Jun 09, 2019 9:31 pm
krystianmen wrote:
Sun Jun 09, 2019 1:33 pm

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
Posts: 179
Joined: Wed Oct 31, 2018 7:58 am

Mon Jun 10, 2019 8:59 am

client.read(...) zwraca chyba tylko liczbę odczytanych bajtów ?
User avatar
pzygmunt
Posts: 6688
Joined: Tue Jan 19, 2016 9:26 am
Location: Paczków
Contact:

Mon Jun 10, 2019 9:04 am

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
Posts: 360
Joined: Fri Nov 16, 2018 7:25 am

Mon Jun 10, 2019 10:01 am

pzygmunt wrote:
Mon Jun 10, 2019 9:04 am
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ł?
User avatar
pzygmunt
Posts: 6688
Joined: Tue Jan 19, 2016 9:26 am
Location: Paczków
Contact:

Mon Jun 10, 2019 10:09 am

Dlaczego to chcesz robić w iterate ?
Nie lepiej w callbackach które do tego służą ?
Dodatkowo masz timer do wykorzystania.
vajera
Posts: 179
Joined: Wed Oct 31, 2018 7:58 am

Mon Jun 10, 2019 1:17 pm

Można to zrobić bezpośrednio w funkcji impl_arduino_status ?
User avatar
pzygmunt
Posts: 6688
Joined: Tue Jan 19, 2016 9:26 am
Location: Paczków
Contact:

Mon Jun 10, 2019 1:49 pm

impl_arduino_timer
cino111
Posts: 636
Joined: Mon May 07, 2018 8:00 pm

Mon Jun 10, 2019 2:27 pm

pzygmunt wrote:
Mon Jun 10, 2019 1:49 pm
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
Posts: 360
Joined: Fri Nov 16, 2018 7:25 am

Mon Jun 10, 2019 2:30 pm

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
Posts: 360
Joined: Fri Nov 16, 2018 7:25 am

Mon Jun 10, 2019 2:40 pm

Zybi wrote:
Sun Jun 09, 2019 6:42 pm
pzygmunt wrote:
Sun Jun 09, 2019 6:23 pm
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.
Post Reply