TuyaMCU (the MCU itself) remembers data between reboots. You need to power if off. You can also enable TuyaMCU queue in the flags.
Helpful post? Buy me a coffee.
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
Nordlicht77 wrote:
it shows a host but unfortunately this host is not updated
Nordlicht77 wrote:I did a reset and re-flashed which flags should be on
Nordlicht77 wrote:
Can you remove the word Toogle from Buttom name?
There is a limit because of the button, see picture
Nordlicht77 wrote:setChannelType 3 temperature_div10 setChannelLabel 3 "Low temperature alarm value" linkTuyaMCUOutputToChannel 103 val 3 addRepeatingEvent 15 -1 publishFloat temperatur_min $CH3/10 0 2 //set value to Channel 103 TuyaMcu fakeTuyaPacket 55AA0307000867020004000000E664 //set virtual button temp min setChannelLabel 21 "Temp min" setChannelType 21 Toggle
Nordlicht77 wrote:
To set the values for the min and max, I used the following page
https://www.rapidtables.com/convert/number/decimal-to-hex.html
and there I selected Decimal to Hexadecimal
Under Decimal I wrote the host in plain text
You will then get the result under Hex
An example
the first numbers of 55AA03070008 for example of 55AA0307000866020004000000FA77 remain the same in this case
The 66 is the number of TuyaMCU dpID in hex in plain text 102
The next numbers of 55AA0307000866020004000000FA77 i.e. 0200040000 remain
The 00FA in the number of TuyaMCU value in Hex in plain text 250
The next numbers from 55AA0307000866020004000000FA77 i.e. 77 is the checksum
This must be converted on the page
https://www.scadacore.com/tools/programming-calculators/online-checksum-calculator/
To do this, take the result of the hex without the last two numbers in this case 55AA0307000866020004000000FA
inserts it under Hex Input
Then press AnalyzeDataHex
Under AnalyzeDataHex there is the checksum, i.e. the last two numbers
I then inserted this host under config-> Execute custom command with fakeTuyaPacket 55AA0307000866020004000000FA77
Here is my fakeTuyaPacket with positive feedback
fakeTuyaPacket 55AA0307000866020004000000FA77 id 121
Info:TuyaMCU processIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU parseState: id 102 type 2-val len 4
Info:TuyaMCU parseState: int32 250
Info:GEN:CHANNEL_Set channel 2 has changed to 250 (flags 0)
Info:MQTT:Channel has changed! Publishing 250 to channel 2
Info:MQTT publishing val 250 to obk0DE017Cuuuu/2/get retain=0
tuyaMcu_sendState [dpID] [dpType] [dpValue]
addRepeatingEvent 15 -1 tuyaMcu_sendState 103 2 2300
delay_s 1
tuyaMcu_sendState 103 2 2300
delay_s 1
tuyaMcu_sendState 104 2 1234
delay_s 1
tuyaMcu_sendState 105 2 2345
TL;DR: With a 2MB backup and the right baud rate, the PH-W218 can be moved to OpenBeken; as one expert put it, "fakeTuyaPacket simulated TuyaMCU" and should not be used to write real thresholds. This FAQ helps Home Assistant and OpenBeken users flash the CB3S module, confirm TuyaMCU communication, and map pH, ORP, TDS, EC, and temperature correctly. [#21146899]
Why it matters: The thread shows that most PH-W218 failures come from power, baud, UART traces, or wrong command choice, not from the sensor hardware itself.
| Option | Use it for | Worked result in thread | Main risk |
|---|---|---|---|
| 9600 baud | Normal TuyaMCU link on this device | Stable values reported after full setup | No data if the module is miswired |
| 115200 baud | Diagnostic retry when 9600 fails | Some users saw values, but also more errors | Noisy logs and unstable parsing |
fakeTuyaPacket |
Testing parser input only | Changes Wi-Fi-side values only | Does not write real MCU settings |
tuyaMcu_sendState |
Writing real dpID values to TuyaMCU | Correct method for thresholds | Can fail if sent too early after boot |
Key insight: OpenBeken replaces only the CB3S Wi-Fi module. The PH-W218’s secondary MCU still runs the measurement logic and keeps the built-in displays working, so success depends on reliable TuyaMCU serial communication, not on rewriting the whole device. [#21134253]
tuyaMcu_setBaudRate 9600, delay_s 120 on first start, and a 15-second loop for periodic checks and MQTT publishing. [#21203138]publishFloat gained a decimal-place argument, so publishFloat ph_aktuell $CH4/100 0 2 publishes 7.40 instead of 7.400000. [#21138792]TuyaMCU driver, set the baud, and map dpIDs such as 8, 106, and 111 to channels. 3. Check the Web App log and only then add MQTT or Home Assistant publishing. The thread’s working examples use tuyaMcu_defWiFiState 4, then channel mapping, then tuyaMcu_sendQueryState. [#21131597]setChannelType, setChannelLabel, and linkTuyaMCUOutputToChannel [dpID] val [channel] to map them. [#21131505]TuyaMCU, save the config, and power the whole device fully off and on. 2. In the log, look for heartbeat or state lines such as cmd 0 (Hearbeat) or cmd 7 (State). 3. If needed, run tuyaMcu_sendQueryState and verify that the MCU actually answers. A console OK only means the command was accepted, not that the MCU replied. [#21202813]tuyaMcu_setBaudRate 9600, while 115200 produced values for one user but also “a lot of errors.” If neither speed shows TuyaMCU messages after a full power cycle, suspect flags, broken traces, or lost UART connection instead of firmware logic. [#21203138]tuyaMcu_sendState, not with simulated packets. The maintainer’s example was a short boot sequence such as delay_s 1, then tuyaMcu_sendState 103 2 2300, then another delay before the next dpID. He also warned that addRepeatingEvent 15 -1 tuyaMcu_sendState ... sends forever every 15 seconds, which is usually wrong for fixed alarm limits. [#21147072]fakeTuyaPacket is the wrong tool because it only simulates packets arriving from the MCU to the Wi-Fi module. It can change what OpenBeken displays or publishes, but it does not write real settings into the PH-W218 controller. Use tuyaMcu_sendState [dpID] [dpType] [value] whenever you want the actual TuyaMCU to receive a threshold or setting and calculate the checksum automatically. [#21146899]publishFloat formatting. The thread shows pH published as $CH4/100 0 2, so a raw value like 740 becomes 7.40; temperature used /10, while ORP was often published with 0 decimals. For PH specifically, the maintainer added a decimal-place argument, so publishFloat ph_aktuell $CH4/100 0 2 fixes outputs like 7.400000 and publishes 7.40 instead. [#21138792]unit_of_measurement: Ph together with device class ph. In the thread, a fix was proposed so the PH channel type stops publishing unit_of_meas, and the maintainer later said current releases should not send it for PH. If the error returns, remove the device and re-pair through Home Assistant discovery so stale discovery data is cleared. [#21645909]