supla.org

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: 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 to kanał 0 oraz 2 w apce się ustawia za to kanał 1 się nie ustawia.

Macie jakieś sugestie jak to rozwiązać??

Jednak stan 2 kanału się zmienia ale z 30s opóźnieniem, czy jest to wina clouda?

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

na 4

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.

A zmieniałeś plik srpc.c ?

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.

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.

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.

To jest problem po stronie urządzenia.

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