Nie zmieniają się wszystkie stany za pomocą channelValueChanged

krycha88
Posty: 915
Rejestracja: pt lis 16, 2018 7:25 am

ndz cze 09, 2019 1:33 pm

Zawsze obsługiwałem 2 przekaźniki, dzisiaj miałem potrzebę obsłużyć 3 przekaźnik. Po restarcie lub przywróceniu połączenia przywracam sobie domyślne stany w następujący sposób:

Kod: Zaznacz cały

int supla_arduino_tcp_read(void *buf, int count) {
  _supla_int_t size = client.available();

  if ( size > 0 ) {
    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));
      SuplaDevice.channelValueChanged(2, read_supla_relay_state(2));
    }
    if ( size > count ) size = count;

    return status;
  }
  return -1;
}
i teraz kanał 0 oraz 1 w apce się ustawia poprawnie niestety kanał 2 już się nie ustawia.

Kolejność kanałów nie ma znaczenia bo jak zrobię to następująco

Kod: Zaznacz cały

      SuplaDevice.channelValueChanged(0, read_supla_relay_state(0));
      SuplaDevice.channelValueChanged(2, read_supla_relay_state(2));
      SuplaDevice.channelValueChanged(1, read_supla_relay_state(1));
to kanał 0 oraz 2 w apce się ustawia za to kanał 1 się nie ustawia.

Macie jakieś sugestie jak to rozwiązać??
krycha88
Posty: 915
Rejestracja: pt lis 16, 2018 7:25 am

ndz cze 09, 2019 1:43 pm

Jednak stan 2 kanału się zmienia ale z 30s opóźnieniem, czy jest to wina clouda?
Awatar użytkownika
pzygmunt
Posty: 9617
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontaktowanie:

ndz cze 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
cino111
Posty: 712
Rejestracja: pn maja 07, 2018 8:00 pm

ndz cze 09, 2019 6:30 pm

krystianmen pisze:
ndz cze 09, 2019 1:33 pm
Zawsze obsługiwałem 2 przekaźniki, dzisiaj miałem potrzebę obsłużyć 3 przekaźnik. Po restarcie lub przywróceniu połączenia przywracam sobie domyślne stany w następujący sposób:

Kod: Zaznacz cały

int supla_arduino_tcp_read(void *buf, int count) {
  _supla_int_t size = client.available();

  if ( size > 0 ) {
    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));
      SuplaDevice.channelValueChanged(2, read_supla_relay_state(2));
    }
    if ( size > count ) size = count;

    return status;
  }
  return -1;
}
i teraz kanał 0 oraz 1 w apce się ustawia poprawnie niestety kanał 2 już się nie ustawia.

Kolejność kanałów nie ma znaczenia bo jak zrobię to następująco

Kod: Zaznacz cały

      SuplaDevice.channelValueChanged(0, read_supla_relay_state(0));
      SuplaDevice.channelValueChanged(2, read_supla_relay_state(2));
      SuplaDevice.channelValueChanged(1, read_supla_relay_state(1));
to kanał 0 oraz 2 w apce się ustawia za to kanał 1 się nie ustawia.

Macie jakieś sugestie jak to rozwiązać??
Czy mógłbyś wrzucić cały kod programu dla tych 3 przekaźników? Próbowałem coś takiego zrobić, ale mi nie wychodziło.
Awatar użytkownika
pzygmunt
Posty: 9617
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontaktowanie:

ndz cze 09, 2019 6:33 pm

A zmieniałeś plik srpc.c ?
Zybi
Posty: 1489
Rejestracja: ndz cze 26, 2016 4:24 pm

ndz cze 09, 2019 6:42 pm

pzygmunt pisze:
ndz cze 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.
Awatar użytkownika
pzygmunt
Posty: 9617
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontaktowanie:

ndz cze 09, 2019 6:49 pm

Zybi pisze:
ndz cze 09, 2019 6:42 pm
pzygmunt pisze:
ndz cze 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.
Tam nie ma priorytetów. Jak już to będzie problem firmware-u po stronie urządzenia.
Zybi
Posty: 1489
Rejestracja: ndz cze 26, 2016 4:24 pm

ndz cze 09, 2019 7:06 pm

pzygmunt pisze:
ndz cze 09, 2019 6:49 pm
...
Tam nie ma priorytetów. Jak już to będzie problem firmware-u po stronie urządzenia.
Dlatego napisałem tak jakby.

Tym nie mniej ten problem występuje, ale nie widać go w oficjalnych kompilacjach ponieważ one nie obsługują multi pomiarów.
W swoich kompilacjach "kombinowałem" już na wiele sposobów i efekt końcowy jest niestety zawsze ten sam, jak jest stabilizacja temperatury to następuje obsługa zmiany stanu kanałów, a jak tylko spowodujemy zmiany temperatury, to znowu przekazywanie stanu kanałów przekaźników realizowane jest ze znacznym opóźnieniem i po przekazaniu stanu z termometrów.

Natomiast jeżeli w bibliotece SuplaDevice włączymy przekazywanie stanu z termometrów za każdym pomiarem a nie tylko przy zmianach stanu, to już w ogóle mamy odjazd.

Czy to jest problem po stronie firmware urządzenia - nie sądzę, ale to tylko moja opinia.
Awatar użytkownika
pzygmunt
Posty: 9617
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontaktowanie:

ndz cze 09, 2019 8:55 pm

To jest problem po stronie urządzenia.
vajera
Posty: 179
Rejestracja: śr paź 31, 2018 7:58 am

ndz cze 09, 2019 9:31 pm

krystianmen pisze:
ndz cze 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" ?
ODPOWIEDZ

Wróć do „Pomoc”