Pytania techniczne dotyczące kodu [bramka ZigBee]

[klew]

Jeszcze jedno:

Code: Select all

Supla_Z2S_HvacBase->setButtonTemperatureStep(50);

Czy to nie powinno spowodować, że (-) i (+) w aplikacji będą zmieniać setpoint o 0,5 st. C?

Nie, to jest do fizycznych przycisków w urządzeniu.
Nie da się zmienić kroku w apce.

[klew]

, ale pomimo tej linii:

Code: Select all

Supla_Z2S_HvacBase->setTemperatureRoomMax(3000); //hvac_room_temperature_max);

termostat nadal wyświetle 40 st. C?

To jest niestety trochę skomplikowane.
Ogólnie termostat w trakcie inicjalizacji (onInit) i ustawiania funkcji, czyści te "room max/min" i kilka innych i przywraca domyślne dla danej funkcji.
Wynika to z tego, że termostat może mieć różne zakresy dla różnych funkcji.

Użyj tych metod:

Code: Select all

void HvacBase::setDefaultTemperatureRoomMin(int32_t channelFunction,
    _supla_int16_t temperature);

Tylko trzeba je ustawić dla każdej wspieranej funkcji przez termostat (SUPLA_CHANNELFNC_.... )

[vajera]

To jest niestety trochę skomplikowane.
Ogólnie termostat w trakcie inicjalizacji (onInit) i ustawiania funkcji, czyści te "room max/min" i kilka innych i przywraca domyślne dla danej funkcji.
Wynika to z tego, że termostat może mieć różne zakresy dla różnych funkcji.

Użyj tych metod:

Code: Select all

void HvacBase::setDefaultTemperatureRoomMin(int32_t channelFunction,
    _supla_int16_t temperature);

Tylko trzeba je ustawić dla każdej wspieranej funkcji przez termostat (SUPLA_CHANNELFNC_.... )

Dzięki, wypróbuję!

[vajera]

Nie, to jest do fizycznych przycisków w urządzeniu.
Nie da się zmienić kroku w apce.

Rozumiem, to się i tak koryguje samoczynnie po chwili jak głowica odeśle rzeczywistą wartość, ale myślałem, że może to ogarniemy systemowo.

[vajera]

@klew Mam (dwa) trzy pytania

1. Funkcja Supla::Notification::RegisterNotification(int16_t context, bool titleSetByDevice = true, bool messageSetByDevice = true, bool soundSetByDevice = false) działa "jednorazowo", tzn. jej kolejne wywołania ze zmienionym parametrem titleSetByDevice lub messageSetByDevice nie zmieniają już ustawień w obrębie serwera Supla - konieczne jest usunięcie kanału i jego ponowne dodanie - rozumiem, że to jest by design?
2. Czy jest jakaś opcja, żeby w obrębie widgetu dimmera ukryć/wyłączyć ten przycisk ON/OFF?
3. jaka jest dokładnie rola funkcji fillSuplsChannelNewValue(..)?

[klew]

Funkcja Supla::Notification::RegisterNotification(int16_t context, bool titleSetByDevice = true, bool messageSetByDevice = true, bool soundSetByDevice = false) działa "jednorazowo", tzn. jej kolejne wywołania ze zmienionym parametrem titleSetByDevice lub messageSetByDevice nie zmieniają już ustawień w obrębie serwera Supla - konieczne jest usunięcie kanału i jego ponowne dodanie - rozumiem, że to jest by design?

Takie było założenie. Ogólnie to jest funkcjonalność przewidziana oryginalnie tylko dla DIY. Założenie było takie, że urządzenie na początku rejestruje co robi i tego nie zmienia.
Rozumiem, że bramka nie pasuje do tego założenia, bo tam się sporo może zmienić...

Czy jest jakaś opcja, żeby w obrębie widgetu dimmera ukryć/wyłączyć ten przycisk ON/OFF?

"widgetu" - co przez to rozumiesz?
Ale ogólnie nie da się tego ukryć, niezależnie od tego, czy mówisz o widgetach, włącz/wyłącz z listy kanałów, czy też przycisku on/off w widoku szczegółowym dimmera czy też RGB.

jaka jest dokładnie rola funkcji fillSuplsChannelNewValue(..)?

Tam jest chyba kilka możliwych użyć. Ogólnie kanały dostają polecenia sterujące z serwera w jakimś określonym formacie (8 bajtów danych) i jest to jakoś przez serwer wypełniane.
Nie na każdym interfejsie dostaję te same dane (np. z mqtt może polecieć trochę mniej danych) i aby nie robić osobnych interfejsów sterujących, np. dla mqtt, to najpierw wypełniam sobie tą strukturę (przez kanał, używając w/w medoty) i potem modyfikuję tam odpowiednie pola, tak jak to z reguły serwer Supli robi.
Raczej nie widzę potrzeby, abyś musiał w to ingerować.
Chyba, że chcesz robić na dimmer/rgb rzeczy, do których on nie jest przystasowany...

[vajera]

Funkcja Supla::Notification::RegisterNotification(int16_t context, bool titleSetByDevice = true, bool messageSetByDevice = true, bool soundSetByDevice = false) działa "jednorazowo", tzn. jej kolejne wywołania ze zmienionym parametrem titleSetByDevice lub messageSetByDevice nie zmieniają już ustawień w obrębie serwera Supla - konieczne jest usunięcie kanału i jego ponowne dodanie - rozumiem, że to jest by design?

Takie było założenie. Ogólnie to jest funkcjonalność przewidziana oryginalnie tylko dla DIY. Założenie było takie, że urządzenie na początku rejestruje co robi i tego nie zmienia.
Rozumiem, że bramka nie pasuje do tego założenia, bo tam się sporo może zmienić...

To nie tak, że nie pasuje - w sumie wydaje mi się, że to rozwiązanie, które przyjąłem (tytuł na serwerze, treść w urządzeniu) ma największy sens - bramka nie zna (i nie może znać) aktualnej nazwy kanału, zna za to stan urządzenia i może to zawrzeć w treści. Przy okazji - nie znalazłem tego issue, o którym pisałeś - {name} jako zmienna w tytule powiadomienia?
To pytanie raczej dla Twojej informacji - jeżeli takie było założenie to OK.

Czy jest jakaś opcja, żeby w obrębie widgetu dimmera ukryć/wyłączyć ten przycisk ON/OFF?

"widgetu" - co przez to rozumiesz?
Ale ogólnie nie da się tego ukryć, niezależnie od tego, czy mówisz o widgetach, włącz/wyłącz z listy kanałów, czy też przycisku on/off w widoku szczegółowym dimmera czy też RGB.

Miałem na myśli szczegółowy widok dimmera w aplikacji.

jaka jest dokładnie rola funkcji fillSuplsChannelNewValue(..)?

Tam jest chyba kilka możliwych użyć. Ogólnie kanały dostają polecenia sterujące z serwera w jakimś określonym formacie (8 bajtów danych) i jest to jakoś przez serwer wypełniane.
Nie na każdym interfejsie dostaję te same dane (np. z mqtt może polecieć trochę mniej danych) i aby nie robić osobnych interfejsów sterujących, np. dla mqtt, to najpierw wypełniam sobie tą strukturę (przez kanał, używając w/w medoty) i potem modyfikuję tam odpowiednie pola, tak jak to z reguły serwer Supli robi.
Raczej nie widzę potrzeby, abyś musiał w to ingerować.
Chyba, że chcesz robić na dimmer/rgb rzeczy, do których on nie jest przystasowany...

Szukam rozwiązania na wprowadzanie danych z aplikacji do urządzenia - pomysłu na coś, co mogłoby służyć do przekazania urządzeniu kilku opcji a nie tylko ON/OFF, jak w przypadku wirtualnego przekaźnika. W sumie zrobiłem już kiedyś taki komponent do termostatu - wirtualny przekaźnik, który przy każdym ON zwiększa wartość a przy OFF zmniejsza, ale wciąż szukam innych opcji dlatego kombinuję z tym dimmerem.
BTW - taka ciekawostka - aplikacja pokazuje np. 50% w widoku szczegółowym dimmera a handleNewValueFrom Server dostaje 49%...

[klew]

Dla dimmera nie ma znaczenie czy to jest 50 czy 49% . Pewnie tam coś inaczej się zaokrągla w jakimś miejscu.

[vajera]

Żeby nie wyważać otwartych drzwi może ktoś nakieruje mnie, jak najprościej zrobić własny formularz WWW do Webinterface i prowadzący do niego przycisk w widoku głównym (tam gdzie SAVE/SAVE&RESTART)?

[klew]

Żeby nie wyważać otwartych drzwi może ktoś nakieruje mnie, jak najprościej zrobić własny formularz WWW do Webinterface i prowadzący do niego przycisk w widoku głównym (tam gdzie SAVE/SAVE&RESTART)?

Gotowy serwer www na supla-device nie przewiduje takich funkcji.
Tam na sztywno są dwie ścieżki ustawione: / oraz /beta

Ogólnie zobacz:src/supla/network/esp_web_server.cpp
Ten serwer odpala sendPage lub sendBetaPage zależnie od wybranego patha.

Ale cały ten mechanizm używany w supla-device jest mocno inwencją własną autora ;P