Uploading OpenBK software to MOES BHT-002-GCLW v4 thermostat with TUYA CB3S BK7231N chip

Name: Uploading OpenBK software to MOES BHT-002-GCLW v4 thermostat with TUYA CB3S BK7231N chip
Uploaded: 2023-09-27T18:02:34+02:00
Description: Hello I purchased a MOES BHT-002-GCLW version v4 thermostat hoping to upload Tasmota. It turned out that there is a TUYA CB3S BK7231N chip inside. With the BK7231Flasher program I read the contents (details attached), having previously soldered out the two components marked in red in the picture...

Question

Hello I purchased a MOES BHT-002-GCLW version v4 thermostat hoping to upload Tasmota. It turned out that there is a TUYA CB3S BK7231N chip inside. With the BK7231Flasher program I read the contents (details attached), having previously soldered out the two components marked in red in the picture...

p.kaczmarek2 · Answer

This device is based on TuyaMCU. OpenBeken supports devices with TuyaMCU at a fairly good level, but you need to know the dpID of the variables you want to support. Then again, it's the same with Tasmota. Without knowing which dpID is which variable you won't get started.
This topic about TuyaMCU:
https://www.elektroda.pl/rtvforum/topic3880546.html

You need to either find the documentation of this device e.g. for Tasmota (maybe the dpIDs match the version on BK), or on the dev account of Tuya approach what dpIDs are there (I've never done it this way, but it was mentioned on the forum) or capture the dpID e.g. with my analyzer:
https://github.com/openshwprojects/TuyaMCUAnalyzer

Then in OpenBeken you map dpID to channels and script anything you want.

See this topic, about is also about the device on TuyaMCU:
https://www.elektroda.pl/rtvforum/topic3959907.html

If you haven't already flashed, I advise you to do so:
1. solder everything in place
2. connect to Tuya application
3. while disconnected from mains power, only supplying from safe 3.3V or there 5V (before LDO), perform in UART (on U1TX and U1RX of WiFi module) packet capture at separate operations e.g.. temperature setting, relay switching on, etc. so that you can determine which dpID is the relay, which dpID is the temperature - you can analyze the packets in TuyaMCUAnalyzer
4. once you capture these packets and know which dpID is which variable, you can upload OBK and I will help you configure it

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

tomik67 · Answer

I'm unhappy about this because earlier versions of this thermostat sat with the ESP8266 and produced two great projects: and an even more interesting fork: ...and here's such a surprise PS. Of course I haven't sflash yet, too much risk.

p.kaczmarek2 · Answer

I see that in this code there are mentions of dpID and of TuyaMCU, even there are fragments of packages in the commentary (55 AA etc), but I have not yet found there a list of all the dpID from this device. Maybe you know where it is there? And if not, you need to capture the packets and that will do too....

tomik67 · Answer

From their project on which I also shared my misery, I received this response today: So they know the subject.

p.kaczmarek2 · Answer

After all, I was the one who wrote back in that topic....

tomik67 · Answer

But a blunder, I didn't even check the author of the reply. Sorry.

tomik67 · Answer

Today I had some time so I eavesdropped on what is happening on RXD1 and TXD1 of the BK7231N module, the details are attached.
In the files at the bottom there is also communication right after powering up the thermostat.
Unfortunately, neither on RXD1 nor TXD1 did I find any trace of the relay on/off commands, nor its current state, I suppose that such communication takes place only between the MCU and the relay board without the participation of the BK7231N.
Are we closer to solving the problem ?

PS. Additional information
The capture results partially agree with this table :
Link

Date is updated every hour or so.:

55 AA	00	1C		00 08	0117091913010B01	7D	
HEADER	VER=00	Date		LEN	bOk=1 23/9/25 19:1:11	CHK
55 AA	00	1C		00 08	0117091912000201	72	
HEADER	VER=00	Date		LEN	bOk=1 23/9/25 18:0:2	CHK	
55 AA	00	1C		00 08	0117091911003401	A3	
HEADER	VER=00	Date		LEN	bOk=1 23/9/25 17:0:52	CHK

Confirm no relay status, even the TUYA application relies on comparing the desired temperature vs. the actual temperature, it happens that in the application switching every 0.5 degree the contactor is supposedly off, and in fact on the thermostat is still on due to the Deadzone Temperature set, here they also write about it:
Link

PS2.
One more list.:
Link

Quote:
full list of "dp"

1 -. enable-disable
2 - doubled target temperature
3 - doubled current temperature (internal or external sensor it regard to your settings on device)
4 - 0 - auto mode; 1 - hand mode
5 - eco mode
6 - input blocking
102 - doubled current temperature of external sensor
104 - dont know. always "true" for me

PS3.
However, it is possible to obtain the relay state by modifying the hardware and firmware of the module .:
Link
While the hardware mod I can grasp (voltage divider and passing 3.3V to CB3S on P7 or P8), the firmware modification (pushing GPIOP_7 or GPIOP_8 state as dpID) I will not undertake due to lack of such skills.

p.kaczmarek2 · Answer

Based on this, you could already create OpenBeken configurations. You can make a copy of the original batch and upload OBK. Too bad there is no relay exposed to dpID, but are you sure? I see in the quote hand mode , what is it based on?

No problem, you can outside the MCU use the free GPIO for this, then you don't need dpID at all.

tomik67 · Answer

Unfortunately there is definitely no relay exposed to dpID in this model, they elaborate on this in the link I provided in the last post, so hardware and firmware modification is necessary. I would love to play with this mod so being able to use this outside of the MCU would make me very happy.

Hand mode (Manual mode) dpID 4, V=1 Manually set the expected (desired) temperature on the thermostat
Auto mode (Programmable mode) dpID 4, V=0 Using pre-scheduled heating time and temperature intervals

There is also ECO mode, (Energy saving) dpID=5 Bool V=1 (ON), dpID=5 Bool V=0 (OFF) that is, energy saving mode, activates the default expected heating temperature of 20 *C, but it can be modified.
Included is the instruction manual EN.

p.kaczmarek2 · Answer

Simple variables we will map to OBK without a problem, the relay will also connect without a problem, but what about this?


Received by WiFi module:  to prawdopodobnie zassanie z serwera TUYA programów grzania, 6 przeziałów czasowych w dni pracujące, 6 w sobotę i 6 w niedzielę.
55 AA	01	07		00 3A	65 00 00 36 190F2601081B1D0B1E1E0D2200112C00161E0006280008281E0B281E0D2800112800161E0006280008281E0B281E0D2800112800161E 		30	
HEADER	VER=01	State		LEN	dpId=101 Raw V=19 0F 26 01 08 1B 1D 0B 1E 1E 0D 22 00 11 2C 00 16 1E 00 06 28 00 08 28 1E 0B 28 1E 0D 28 00 11 28 00 16 1E 00 06 28 00 08 28 1E 0B 28 1E 0D 28 00 11 28 00 16 1E	CHK

Do you need support for this data format and is the meaning of each byte known?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

tomik67 · Answer

It seems to me that these variables could be ignored because if we integrate such a thermostat with Home Assistant and say goodbye to the TUYA servers, we set the applicable heating schedule in HA. The only hassle would be power outages, HA would have to periodically push out info about the expected state of the thermostat (or thermostat request) because I'm not sure if it remembers the last state before the power outage (without contacting TUYA), I would have to check. Without this, the update would only occur during the next schedule change or after a manual adjustment.
I assume that without receiving these variables, the default schedule remains in it and HA will take care of the rest.
Do I think correctly ?

p.kaczmarek2 · Answer

From OBK you can send variables to the thermostat at any time. In the same way, if you correctly pin in, you could try a three-state control of the relay:
- forced high state
- forced low state
- acquiescent control of TuyaMCU over the relay
But I didn't have this device, so I won't give a guarantee either. I think that if we know the dpID then you can try to upload in OBK and write autoexec.bat

Make a copy of the batch, upload OBK, and specify what baud is used here (9600 or the 115200 one?).

tomik67 · Answer

The mod is only to control the presence of the supply voltage to the coil of the relay, and this real and not simulated state is important for further automation of the device. Through the mod we can not control the relay. Only commands to the MCU.
I don't know what the actual speed is, in the CH340G controller I have it set to 115200, in the file downloaded from the thermostat it says baud 9600 (I think it's the same as in the CB3S specification) and in the BK7231 Flasher it's set to 921600 and that's how it worked for me.

p.kaczmarek2 · Answer

Chaos... Flashing speed is a different thing than communication with TuyaMCU. I was asking about what you set as you captured packets. But it doesn't matter much, upload OBK and fire up autoexec.bat, for a test:


startDriver TuyaMCU
tuyaMcu_defWiFiState 4

After reboot in Web App Log you should see TuyaMCU packets, heartbeat, and so on.
Additionally command:


tuyaMcu_sendQueryState

should work and receive dpID. Then we will configure further.

tomik67 · Answer

I'm trying to upload OBK but it won't start, I guess I'll have to solder these two components again.

I succeeded but after re-soldering the components

Now they are back in place.
These commands I fired in Execute custom command, is that right or were they supposed to be in Startup command ?
First logs attached.

p.kaczmarek2 · Answer

To upload the firmware, the UART connection to the MCU must be broken.

tomik67 · Answer

I have completed the previous post.
After the successful upload, can I already unsolder the wires from the CB3S or will they still be needed?

Communication with the MCU works:

Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 03 02 00 04 00 00 00 28 40 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 3, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 40
Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 3 with value 40 is not mapped

Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 66 02 00 04 00 00 00 F8 73 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 102, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 248
Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 102 with value 248 is not mapped

# Po trzykrotnym zwiększeniu temperatury na panelu.:

Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 02 02 00 04 00 00 00 30 47 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 48
Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 2 with value 48 is not mapped

Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 02 02 00 04 00 00 00 31 48 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 49
Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 2 with value 49 is not mapped

Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 02 02 00 04 00 00 00 32 49 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 50
Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 2 with value 50 is not mapped

.

p.kaczmarek2 · Answer

Now you need to map the dpID to OBK channels. Wires are unlikely to be needed.

Start with:


1 - enable-disable


startDriver TuyaMCU
tuyaMcu_defWiFiState 4

setChannelType 1 toggle
setChannelLabel 1 OnOff
// linkTuyaMCUOutputToChannel dpId verType tgChannel
linkTuyaMCUOutputToChannel 1 bool 1

Then add:


# Włączenie trybu Energy saving.:
Type Bool Values 0,1
Received by WiFi module:
55 AA	00	06		00 05	0501000101	12									//R 25.09.2023 11:25:51 WiFi received:
HEADER	VER=00	SetDP		LEN	dpId=5 Bool V=1		CHK						55AA00060005050100010112

That is, we have:


startDriver TuyaMCU
tuyaMcu_defWiFiState 4

setChannelType 1 toggle
setChannelLabel 1 OnOff
setChannelType 2 toggle
setChannelLabel 2 EnergySaving
// linkTuyaMCUOutputToChannel dpId verType tgChannel
linkTuyaMCUOutputToChannel 1 bool 1
linkTuyaMCUOutputToChannel 5 bool 2

Test to see if what I gave works. And now I think I need to add a special channel type for this device. Do I see it correctly:



# Zmiany temperatury od 5*C do 35*C co pół stopnia.:
Type Val, Values min=10 max=67

Received by WiFi module:
55 AA	00	06		00 08	020200040000000A	1F	
HEADER	VER=00	SetDP		LEN	dpId=2 Val V=10		CHK	

Received by WiFi module:
55 AA	00	06		00 08	020200040000000B	20	
HEADER	VER=00	SetDP		LEN	dpId=2 Val V=11		CHK

10 corresponds to 5C, and 11 is 5.5C? I have not encountered this yet, I will add to the firmware of this support immediately.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

tomik67 · Answer

Yes, here these values are doubled temperature.This is certainly a silly question but since I have with OBK as well as with Tasmota only the first experience, where should I enter these commands ?.

p.kaczmarek2 · Answer

autoexec.bat is created in LittleFS:

tomik67 · Answer

Both commands work perfectly.
This is what it looks like in the logs:
Energy saving OFF. :

Info:MQTT:Channel has changed! Publishing 0 to channel 2 
Info:MQTT:mqtt_host empty, not starting mqtt
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 02 02 00 04 00 00 00 32 49 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 50
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 05 05 01 00 01 00 13 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 5, dataType 1-DP_TYPE_BOOL and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:GEN:No change in channel 2 (still set to 0) - ignoring

Energy saving ON.:

Info:MQTT:Channel has changed! Publishing 1 to channel 2 
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 02 02 00 04 00 00 00 28 3F 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 40
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 05 05 01 00 01 01 14 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 5, dataType 1-DP_TYPE_BOOL and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:GEN:No change in channel 2 (still set to 1) - ignoring

OnOff ON.:

Info:MQTT:Channel has changed! Publishing 1 to channel 1 
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 05 01 01 00 01 01 10 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 1, dataType 1-DP_TYPE_BOOL and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:GEN:No change in channel 1 (still set to 1) - ignoring

OnOff OFF.:

Info:MQTT:Channel has changed! Publishing 0 to channel 1 
Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 05 01 01 00 01 00 0F 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 1, dataType 1-DP_TYPE_BOOL and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:GEN:No change in channel 1 (still set to 0) - ignoring

Added after 3 [hours] 39 [minutes]:

I added two switches to myself as a test, a Button Lock and a Manual/Programmable Mode switch.:

startDriver TuyaMCU
tuyaMcu_defWiFiState 4

setChannelType 1 toggle
setChannelLabel 1 OnOff
setChannelType 2 toggle
setChannelLabel 2 EnergySaving
setChannelType 3 toggle
setChannelLabel 3 ButtonLock
setChannelType 4 toggle
setChannelLabel 4 ManualMode
// linkTuyaMCUOutputToChannel dpId verType tgChannel
linkTuyaMCUOutputToChannel 1 bool 1
linkTuyaMCUOutputToChannel 5 bool 2
linkTuyaMCUOutputToChannel 6 bool 3
linkTuyaMCUOutputToChannel 4 bool 4

While the lock works, the Manual/Programmable Mode does not. Maybe because of the variable type "Enum".

When I started Programmable Mode manually in the logs it showed this:

Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 05 04 04 00 01 00 15 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 4, dataType 4-DP_TYPE_ENUM and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:GEN:CHANNEL_Set channel 4 has changed to 0 (flags 0)

Info:MQTT:Channel has changed! Publishing 0 to channel 4

After manually re-enabling Manual Mode I got this:

Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 05 04 04 00 01 01 16 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 4, dataType 4-DP_TYPE_ENUM and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 
Info:GEN:CHANNEL_Set channel 4 has changed to 1 (flags 0)

Info:MQTT:Channel has changed! Publishing 1 to channel 4

tomik67 · Answer

It looks like the MCU needs to be informed of the current time every hour, the manually set clock resets after this period.
With the original software it looks like this:
RAW.:

//R 05.10.2023 16:15:30 WiFi received:
55AA001C000801170A05100F0E047B

Decode.:

55 AA	00	1C		00 08	01170A05100F0E04	7B	
HEADER	VER=00	Date		LEN	bOk=1 23/10/5 16:15:14	CHK

Earlier, right after powering up the thermostat, the MCU gets this info:
RAW.:

//R 05.10.2023 16:13:14 WiFi received:
55AA0008000007

Decode.:

55 AA	00	08		00 00		07	
HEADER	VER=00	QueryInitStatus		LEN	INVALID date			CHK

According to the tutorial I started NTP but it reads UNIX time from server 217.147.223.78, at 11.01.33 I get the following:

Info:NTP:Seconds since Jan 1 1900 = 3905571693
Info:NTP:Unix time  : 1696582893
Info:NTP:Local Time : 2023/10/06 09:01:33

Would it be possible to implement in OBK querying a self-defined NTP server ?

PS. Manual/Programmable Mode switch also works after time update.

tomik67 · Answer

Seek and ye shall find This settled the matter.:Code: text Expand Select all Copy to clipboard// Start NTP Driver startDriver NTP // Set NTP Server ntp_setServer 10.9.10.250 // Set timezone ntp_timeZoneOfs +2:00 It would be nice if summer time and winter time (while it still works) could be fixed. It would be nice if summer time and winter time could be fixed.

p.kaczmarek2 · Answer

Sorry for the slow response, sometimes it's hard to grasp the whole forum. I see you handled that, yes?

There is still a command to send the time "on demand" from the script, but I don't think that's needed, because the firmware also sends the time itself when TuyaMCU asks for it.

What else is needed? Do I need to prepare some missing GUI for the dpID from this thermostat?

Quote:

While locking works, Manual/Programmable Mode does not. Maybe because of the variable type "Enum".

When mapping, you can set the enum type, then the enum value will go to the channel (and back).

You can also create a pretty custom custom GUI of your own in:
https://www.elektroda.pl/rtvforum/topic3971355.html

tomik67 · Answer

Thank you for your response, I realize that the topic is growing and there is not enough day for everything, so I am very grateful to you for your help so far, I am educating myself hard and I miss a lot.
I am not a programmer but an electronics technician, but with automation in various forms (SATEL, Fibaro, etc.) I have been dealing with for many years, this topic is the next step.
If I could have a small wish list then I testify to the following:

1. Manual/Programmable Mode works as I mentioned in one of the last posts, it was necessary to update the clock, then it went off.
2. It would be nice to be able to implement summer/winter time, I found that in Tasmota it is done like this.:

Europe/Warsaw	Backlog0 Timezone 99; TimeStd 0,0,10,1,3,60; TimeDst 0,0,3,1,2,120

Link

It would be smart to have something similar, it would save manual adjustment in each thermostat (and other devices) when changing the time.

3. In one of the posts treating Tasmota in previous versions of the thermostat there was a reference to the instability of WiFi connections with b/g/n standards, the way out of the situation was to force communication only b/g, no n.
I also have blackouts once an hour, perhaps because of this, it looks like this:

Info:NTP:Seconds since Jan 1 1900 = 3905648534
Info:NTP:Unix time  : 1696666934
Info:NTP:Local Time : 2023/10/07 08:22:14
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:NTP_CheckForReceive: Error while receiving server's msg
Info:NTP:Seconds since Jan 1 1900 = 3905648666
Info:NTP:Unix time  : 1696667066
Info:NTP:Local Time : 2023/10/07 08:24:26

4. You once mentioned that:

Quote:
Check if it works what I gave. And now I think I need to add a special channel type under this device. Do I see correctly:
Code: text Expand Select all Copy to clipboard

# Temperature changes from 5*C to 35*C in half degree increments.:
Type Val, Values min=10 max=67

Received by WiFi module:
55 AA 00 06 00 08 020200040000000A 1F
HEADER VER=00 SetDP LEN dpId=2 Val V=10 CHK

Received by WiFi module:
55 AA 00 06 00 08 020200040000000B 20
HEADER VER=00 SetDP LEN dpId=2 Val V=11 CHK

10 corresponds to 5C, and 11 is 5.5C? I haven't encountered this yet, I'll add support for this to the firmware right away.

Have you been able to get this topic moving ?

Thanks again for your help.

PS.
My current autoexec.bat looks like this:

// Start NTP Driver
startDriver NTP
// Set NTP Server
ntp_setServer 10.9.10.250
// Set timezone
ntp_timeZoneOfs +2:00
startDriver TuyaMCU
tuyaMcu_defWiFiState 4
waitFor NTPState 1
echo "NTP is ready"

setChannelType 1 toggle
setChannelLabel 1 OnOff
setChannelType 2 toggle
setChannelLabel 2 EnergySaving
setChannelType 3 toggle
setChannelLabel 3 ButtonLock
setChannelType 4 toggle
setChannelLabel 4 ManualMode
// linkTuyaMCUOutputToChannel dpId verType tgChannel
linkTuyaMCUOutputToChannel 1 bool 1
linkTuyaMCUOutputToChannel 5 bool 2
linkTuyaMCUOutputToChannel 6 bool 3
linkTuyaMCUOutputToChannel 4 enum 4

.

p.kaczmarek2 · Answer

Point 4. - is this type of channel under the native GUI for this temperature to be read-only (just convert to C and show), or is it to be something that also allows you to set this temperature from the GUI?

What about the rest I'll think about, 3. requires checking whether we have such an option at all in the SDK on which we rely.

tomik67 · Answer

As for pt. 4.:As for me, changing the temperature in the GUI is not necessary, it can be done manually while being at the thermostat, the GUI is rarely used on a daily basis. What is important, however, is the ability to receive commands to change the temperature setpoint (and other switches) via MQTT from HA and convert to understandable numbers for the thermostat.I forgot to add two more points:5. Relay status - since this thermostat does not report relay status, I added a wire to the pin 14 P7 I/O GPIOP_7, which corresponds to P7 of the IC, PWM 1 a wire on which if the relay is on, there is a voltage of 3.25V, when off there is no voltage. It would be great to send information over MQTT about a change in the state of the relay (and possibly a light - indicator in the GUI).In one case I soldered a wire to 13 P8 I/O GPIOP_8, which corresponds to P8 of the IC, PWM 2 , because through inattention while soldering I got rid of the solder pad on P7 6. Would it be possible to apply an additional function in the form of a flag that would cause after a restart or restoration of power and communications to send queries about switch states and temperature settings to the HA? I know that there is an option via -1 to keep the settings from before the restart, but during the power outage something could have changed in the HA and only the next command would give changes in the thermostat. With debugging, the thermostat would be up to date right away.Is this kind of debugging practiced at all?

p.kaczmarek2 · Answer

All that is on the channels is published, as far as I know. Worse, for now it's in the form without multiplication, although it would probably be possible to script multiplication as well. Although, for example, in OnChannelChange publish multiplied. Example: Code: text Expand Select all Copy to clipboard addEventHandler OnChannelChange 5 publishFloat myTemp $CH5*0.2 Where number 5 is the channel with temperature. Multiplication to be corrected. Similarly, whatever you send to OBK on the channel through the set topic, it will go to TuyaMCU. Automatically. Set the free channel to ReadOnly type (I guess, but you could give a better one too), give it RelayState label, and set the selected GPIO to dInput (or dInput_noPullUp, depends). I'm not sure what it is about yet, but in autoexec.bat you can add anything like this: Code: text Expand Select all Copy to clipboard // wait for mqtt to connect waitFor MQTTState 1 // extra delay delay_s 1 publish myEvent123 rebooted and in HA pick up the 'rebooted' write and then split the automation? As for WiFi.... hm, I'll think about it, although I think it would also work through: Code: text Expand Select all Copy to clipboard typedef enum HALWifiStatus { WIFI_UNDEFINED,//0 WIFI_STA_CONNECTING,//1 WIFI_STA_DISCONNECTED,//2 WIFI_STA_AUTH_FAILED,//3 WIFI_STA_CONNECTED,//4 WIFI_AP_CONNECTED, WIFI_AP_FAILED, } HALWifiStatus_t; Code: text Expand Select all Copy to clipboard // when WiFi state changes to WIFI_STA_CONNECTED addEventHandler WiFiState 4 do_anything_on_sta_connect But for now I'm just giving loose ideas as if it could be done in the current firmware version.

tomik67 · Answer

The relay status works flawlessly.
I have a related question:
When I turn on power save mode it shows in the logs :

Info:GEN:CHANNEL_Set channel 5 has changed to 0 (flags 0)

...and MQTT publishes.:

Info:MQTT:Channel has changed! Publishing 0 to channel 5

Why is it that when the MCU reports the current temperature, MQTT similarly does not bother to publish that information ?:

Info:TuyaMCU:TUYAMCU received: 55 AA 01 07 00 08 03 02 00 04 00 00 00 2A 42 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=1]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 3, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 42
Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 3 with value 42 is not mapped

...or at least there is nothing about it in the logs.

Uploading OpenBK software to MOES BHT-002-GCLW v4 thermostat with TUYA CB3S BK7231N chip

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Topic summary