Hello,
I am working with a Neptun Smart+ device using OpenBeken and TuyaMCU communication.
I noticed the following behavior:
The device has two valves controlled by two different Tuya datapoints:
DP104
DP105
When I send a command to change DP104, the Tuya MCU also changes the state of DP105.
The same seems to happen in the opposite direction: changing one valve affects the reported state of the other valve.
It looks like the MCU has some internal logic linking the two valves.
The problem is that OpenBeken currently sends the command to TuyaMCU but does not automatically track the final state returned by the MCU. Because of this, OpenBeken can get out of sync with the real device state. For example:
OpenBeken may show valve 1 = OFF and valve 2 = OFF
but the MCU may have actually opened one valve and updated the other DP accordingly.
My questions:
Is there a recommended way in the OpenBeken TuyaMCU driver to wait for and process the MCU response after changing a DP?
Should I periodically query DP104/DP105 and use the returned state as the source of truth?
Is there a TuyaMCU event/callback that can be used to detect state changes received from the MCU?
Is this behavior expected for Tuya valves where two DP states are internally linked?
Any advice about the correct implementation would be appreciated.
Thanks!
Added after 5 [hours] 51 [minutes]:
Пока что такое решение:
autoexec.bat
Быстро переключаю туда-сюда и пока что не получилось добиться рассинхрона.
I am working with a Neptun Smart+ device using OpenBeken and TuyaMCU communication.
I noticed the following behavior:
The device has two valves controlled by two different Tuya datapoints:
DP104
DP105
When I send a command to change DP104, the Tuya MCU also changes the state of DP105.
The same seems to happen in the opposite direction: changing one valve affects the reported state of the other valve.
It looks like the MCU has some internal logic linking the two valves.
The problem is that OpenBeken currently sends the command to TuyaMCU but does not automatically track the final state returned by the MCU. Because of this, OpenBeken can get out of sync with the real device state. For example:
OpenBeken may show valve 1 = OFF and valve 2 = OFF
but the MCU may have actually opened one valve and updated the other DP accordingly.
My questions:
Is there a recommended way in the OpenBeken TuyaMCU driver to wait for and process the MCU response after changing a DP?
Should I periodically query DP104/DP105 and use the returned state as the source of truth?
Is there a TuyaMCU event/callback that can be used to detect state changes received from the MCU?
Is this behavior expected for Tuya valves where two DP states are internally linked?
Any advice about the correct implementation would be appreciated.
Thanks!
Added after 5 [hours] 51 [minutes]:
Пока что такое решение:
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 1Быстро переключаю туда-сюда и пока что не получилось добиться рассинхрона.
