Witam,
Pracuję z urządzeniem Neptun Smart+ wykorzystującym komunikację OpenBeken i TuyaMCU.
Zauważyłem następujące zachowanie:
Urządzenie posiada dwa zawory sterowane przez dwa różne punkty danych Tuya:
DP104
DP105
Kiedy wysyłam polecenie zmiany stanu DP104, mikrokontroler TuyaMCU zmienia również stan DP105.
To samo wydaje się dziać w odwrotnym kierunku: zmiana stanu jednego zaworu wpływa na stan zgłaszany przez drugi zawór.
Wygląda na to, że mikrokontroler posiada jakąś wewnętrzną logikę łączącą te dwa zawory.
Problem polega na tym, że OpenBeken obecnie wysyła polecenie do mikrokontrolera Tuya, ale nie śledzi automatycznie końcowego stanu zwracanego przez mikrokontroler. Z tego powodu OpenBeken może stracić synchronizację z rzeczywistym stanem urządzenia. Na przykład:
OpenBeken może wyświetlać zawór 1 = WYŁ. i zawór 2 = WYŁ.
ale mikrokontroler mógł w rzeczywistości otworzyć jeden zawór i odpowiednio zaktualizować DP drugiego.
Moje pytania:
Czy istnieje zalecany sposób w sterowniku OpenBeken dla TuyaMCU, aby po zmianie wartości DP poczekać na odpowiedź MCU i ją przetworzyć?
Czy powinienem okresowo sprawdzać wartości DP104/DP105 i traktować zwrócony stan jako źródło prawdy?
Czy istnieje zdarzenie/wywołanie zwrotne TuyaMCU, które można wykorzystać do wykrywania zmian stanu otrzymanych z mikrokontrolera?
Czy takie zachowanie jest oczekiwane w przypadku zaworów Tuya, w których dwa stany DP są wewnętrznie powiązane?
Będę wdzięczny za wszelkie porady dotyczące prawidłowej implementacji.
Dziękuję!
Dodano po 5 [godzinach] 51 [minutach]:
Na razie takie rozwiązanie:
autoexec.bat
Szybko przełączam tam i z powrotem i na razie nie udało mi się doprowadzić do rozsynchronizacji.
Pracuję z urządzeniem Neptun Smart+ wykorzystującym komunikację OpenBeken i TuyaMCU.
Zauważyłem następujące zachowanie:
Urządzenie posiada dwa zawory sterowane przez dwa różne punkty danych Tuya:
DP104
DP105
Kiedy wysyłam polecenie zmiany stanu DP104, mikrokontroler TuyaMCU zmienia również stan DP105.
To samo wydaje się dziać w odwrotnym kierunku: zmiana stanu jednego zaworu wpływa na stan zgłaszany przez drugi zawór.
Wygląda na to, że mikrokontroler posiada jakąś wewnętrzną logikę łączącą te dwa zawory.
Problem polega na tym, że OpenBeken obecnie wysyła polecenie do mikrokontrolera Tuya, ale nie śledzi automatycznie końcowego stanu zwracanego przez mikrokontroler. Z tego powodu OpenBeken może stracić synchronizację z rzeczywistym stanem urządzenia. Na przykład:
OpenBeken może wyświetlać zawór 1 = WYŁ. i zawór 2 = WYŁ.
ale mikrokontroler mógł w rzeczywistości otworzyć jeden zawór i odpowiednio zaktualizować DP drugiego.
Moje pytania:
Czy istnieje zalecany sposób w sterowniku OpenBeken dla TuyaMCU, aby po zmianie wartości DP poczekać na odpowiedź MCU i ją przetworzyć?
Czy powinienem okresowo sprawdzać wartości DP104/DP105 i traktować zwrócony stan jako źródło prawdy?
Czy istnieje zdarzenie/wywołanie zwrotne TuyaMCU, które można wykorzystać do wykrywania zmian stanu otrzymanych z mikrokontrolera?
Czy takie zachowanie jest oczekiwane w przypadku zaworów Tuya, w których dwa stany DP są wewnętrznie powiązane?
Będę wdzięczny za wszelkie porady dotyczące prawidłowej implementacji.
Dziękuję!
Dodano po 5 [godzinach] 51 [minutach]:
Na razie takie rozwiązanie:
autoexec.bat
startDriver TuyaMCU
tuyaMcu_setBaudRate 115200
tuyaMcu_defWiFiState 4
setChannelType 0 Toggle
linkTuyaMCUOutputToChannel 104 bool 0
setChannelType 1 Toggle
linkTuyaMCUOutputToChannel 105 bool 1
addEventHandler OnChannelChange 0 setChannel 1 $CH0
addEventHandler OnChannelChange 1 setChannel 0 $CH1
mqtt_broadcastInterval 1
mqtt_broadcastItemsPerSec 1Szybko przełączam tam i z powrotem i na razie nie udało mi się doprowadzić do rozsynchronizacji.
