[BK7231N CBU] Generic Temperature and Humidity Sensor

Thank you for posting this. I can see that's a battery powered device. We need to enable power save in order to save battery.

First of all, please add "PowerSave" command to short startup command, but for now, it won't help much.

You will need two things for those device:
- a deep sleep system (we're working on that!)
- a SHT30 support (I bought that sensor for you and I am waiting for package)


SHT30, however, seems very simple to support. I could do it remotely. For now, can you please tell me where is SHT30 connected? Which pins of CBU?

I wonder if they are using a hardware I2C of Beken.

EDIT: I see you marked SCL and SDA, great, wait a sec...
Here:

P8 and P7...

Dodano po 8 [minuty]:

Doesn't look like a hardware I2C:

Here are I2C pins of BK7231:


So we will need software I2C for your device.

Dodano po 1 [minuty]:

I could try to figure out something remotely, do a software I2C test with other device and then ask you for testing... I will think about it.

Thank you for your publications. I am curious how long the battery will last after changing the firmware and will there be a low battery notification?
I wonder if the device can operate on 2 x AAA rechargeable batteries?

I have a similar sensor (I don't know if it's the same because I haven't disassembled it). On new good batteries it works 2-3 weeks depending on the temperature. It is worth mentioning that temperature data is transmitted once an hour, not continuously.
When it comes to working on AAA batteries, unfortunately, it is weak here. Especially at low temperatures. The sensor reports a low battery level shortly after inserting the batteries. Realistically (until turned off) the sensor works on batteries for up to a week.
That's the beauty of working over WiFi. The same sensors are available but with ZigBee. Those on new batteries work for at least months.

Hello, anyone figured out how to config this device to show temp , humidity, battery lvl?

@lionboy if you have the same device type, you should wait for the implementation for two things:
- deep sleep (so batteries won't drain fast). Current "powerSave" command will not be enough for that
- SHT30 support
I will try looking into that soon, but so far all the sensors I had were a TuyaMCU one - TuyaMCU sensor is a device with a WiFi module and extra microcontroller, that extra mcu is a TuyaMCU and it does all the processing and sends data to WiFi via UART, and, furthermore, TuyaMCU only enables WiFI module power when it needs to report the status. So deep sleep of WiFi module is not required. On the other hand, in case of the device from this topic, the deep sleep is mandatory so it has to be enabled before using such sensors.

Basically just wait, I will try to post a new guide and/or update this topic when it's done.

And if you have other kind of device, please show us. The TuyaMCU version is already supported

p.kaczmarek2 wrote:

@lionboy if you have the same device type, you should wait for the implementation for two things:
- deep sleep (so batteries won't drain fast). Current "powerSave" command will not be enough for that
- SHT30 support
I will try looking into that soon, but so far all the sensors I had were a TuyaMCU one - TuyaMCU sensor is a device with a WiFi module and extra microcontroller, that extra mcu is a TuyaMCU and it does all the processing and sends data to WiFi via UART, and, furthermore, TuyaMCU only enables WiFI module power when it needs to report the status. So deep sleep of WiFi module is not required. On the other hand, in case of the device from this topic, the deep sleep is mandatory so it has to be enabled before using such sensors.

Basically just wait, I will try to post a new guide and/or update this topic when it's done.

And if you have other kind of device, please show us. The TuyaMCU version is already supported

I have the same sensor, i wll wait until fix the problem, is flashed but no problem, i saw from last night until now battery is empty

Our team member and contributor, @btsimonh , has received a battery-powered PIR sensor (CBU module) few days ago with no MCU. He will be most likely looking into supporting that as well.

Mine is 3 x AAA powered, 'N' based (CBU).
I bought it 2nd hand on ebay, just so I had one . But no manual or mountings.
Looking at a manual online for a similar device, they claim 5 months on 3 x AAA.
So, the question will be, does the original firmware wake on GPI, or wake on timer & poll the sensor.
Mine has no additional MCU chip.

I also note that Tuya no longer offer a wifi PIR sensor design, opting now for BLE/ZigBee only. This is probably because the performance was poor, and powersave difficult to implement.

It will be a few weeks before I can take a serious look at the device,

br,

Simon

Hi everibody, I'm new on the forum, I have some experience in "brain changes" to convert tuya devices to local control with Tasmota. At this moment I'm focussed in fotovoltaic generation and home energy autoconsum. In my current project based in python with Modbus and influxdb I need to capture external temperature and humidity in order to include in the calculus model those parameters. I had a DHT22 sensor connected to a reconverted (brain changed) Tuya thermostat running with Tasmota. Until now that has been working with blocking problems. Issue was the sensor connection. I have adquired one of these generic sensors you mention on this topic and I have fortunatelly found this work you are performing. In the next days will play with it and the SDK and will inform. One quick question do you know where I can find the bk7231n datasheet or programming manual? I think the biggest issue is to put to sleep the processor as much as possible. I will try to prepare a reverse engineering shematic just to check what is the function of the rest of the electronics in the device.

There is no datasheet, just our own research. But we have that:

And that datasheet (but it's not BK7231 chip datasheet, but for module):
https://www.elektroda.pl/rtvforum/download.php?id=1133903

How good power save you need?

Currently, OpenBeken supports PowerSave command, which is indeed saving a lot of power as long as you don't have IR driver running and have a Web Application log closed.

The Deep Sleep is also almost covered, we managed to get waking up system by external IO (like a button), but it's a very deep sleep and it loses RAM content (basically it reboots from 0 device), there is also a timed deep sleep (sleep for N ms) but we didn't manage to get it running.

Please do that schematic, if you want. Our teardowns database needs exactly that kind of materials.

DHT22 is supported by OpenBK, you can easily publish DHT results to HA or even send them by GET to HTTP server.

If there is something specific you need, let me know. I will do my best to help.

Hello, new on this forum.

i have publish a merge request to add the sht3X support. it works but measurement is not ideal even if i have taken the constructor reference for the sht3X. i support that the board has some heating dissipation that impact the sensor.

So Temp is higher of 5 Celsius Degrees And Humidity lower from around 10 (you can easily correct that on HA)

Feel free to test

here the config apply at captor level :

SCL on pin P7
SDA on pin P8 with Channel 1 , 2
Button on pin P20
LED on pin P26 with Channel 3



And here's the start script :
addEventHandler OnClick 20 startScript this runmeas 456

init:
echo "Init driver and powersave "
startDriver TuyaMCU
setChannelType 3 toggle
setChannelType 1 temperature_div10
setChannelType 2 humidity
PowerSave

again:
echo "activate SHT3X Sensor"
startDriver SHT3X
setChannel 3 1
echo "Send some measure"
delay_s 2
echo "stop SHT3X driver"
stopDriver SHT3X
setChannel 3 0
echo "wait 10min"
delay_s 600
goto again

runmeas:
// stopScript ID bExcludeSelf
// this will stop all other instances
stopScript 456 1
echo "Force measurement"
startDriver SHT3X
setChannel 3 1
delay_s 2
stopDriver SHT3X
setChannel 3 0
echo "go back to loop"
goto again;

And for the moment i don't have feedback regarding power consumption.

i will try to work optimisation (merge CHT8305 and SHT3x in Generic I2C for example)

Edit : here's the yaml example for homeassistant :
mqtt:
binary_sensor:
- unique_id: "temperature_1_state"
name: "temperature_1 0"
state_topic: "temperature_1/0/get"
availability:
- topic: "temperature_1/connected"
sensor:
- unique_id: "temperature_1_temp"
name: "temperature_1 Temperature"
state_topic: "temperature_1/1/get"
value_template: "{{ ( value | multiply(0.1) ) - 5.00 | round(2) }}"
unit_of_measurement: "°C"
- unique_id: "temperature_1_hum"
name: "temperature_1 humidité"
state_topic: "temperature_1/2/get"
value_template: "{{ (value | float) + 10.00 | round(2) }}"
unit_of_measurement: "%"

Hello, very good job. I will llook into your code, but have you considered using PowerSave command to reduce current consumption and lower heating?

Yes it's activated at the init of the script.
And i activate tuyamcu who suppose to deactivate wifi when not needed.

For the moment the battery voltage is pretty stable.

i have tested the measure between 2 sensor. The one with openbeken and one who is brand new with no modification. And the measurement is this same if you retrieve 5degree and add 10% humidity.

So i suppose tuya take that in account in there firmware

But that would be a per-device calibration?

I don't know it's a supposition .... maybe a missread the documentation and you have some sort of calibration that can be done at init .....

So batterie Died in 6h with a 10 min refresh.

Will try some other test to improve battery life but i think we really need deep sleep for this sensor, wifi is really draining batterie (that can explain why they are set to 1h by default).

@btsimonh , any progress with deep sleep?

There is an API for deep sleep in the Beken SDK but I am not sure if I should point you towards it, @dheenhasty . If you enable deep sleep, then you might end up unable to reset device for a long time because it is in so low power mode that power off/on cycles does not affect it due to the capacitors on the board. I remember also having issues with CEN, but I am not sure now.

There is a deep sleep that can be waken up by IO press:

https://github.com/openshwprojects/OpenBK7231T_App/search?q=bk_enter_deep_sleep
https://github.com/openshwprojects/OpenBK7231T/search?q=bk_enter_deep_sleep
note that the IO press wakes up the device, but device reboots from 0, like a fresh boot.

There was also somewhere a timer-based deep sleep but I am not sure if we have managed to get it working.

Related files:
https://github.com/openshwprojects/OpenBK7231...k7231t_os/beken378/func/include/wlan_ui_pub.h
https://github.com/openshwprojects/OpenBK7231...1t/bk7231t_os/beken378/func/wlan_ui/wlan_ui.c

The automatic power save is already in place, but the thing we need is a manual PS to make device sleep deep for 10 minutes and then boot from start and do a report. You might need to look into manual_ps.c:

This works but it's a wakeup by IO.
https://github.com/openshwprojects/OpenBK7231...7231t_os/beken378/func/power_save/manual_ps.c
There also must be a timer-based wakeup....
Hmmm that one:

and here:

If you're up for some action, try using it on some test device and be prepared to wait long for capacitors to try out! I might try again as well.
NOTE: do not force-add it into the Main_Init, just do it into a command that is run per user request

Dodano po 29 [minuty]:

Added a command for testing that, but it doesn't work for me yet:
https://github.com/openshwprojects/OpenBK7231...mmit/f5ec52f94f0512f4897f4de4b742e95a524505c7
device does not wake up - any ideas why?

I have try to compile for the 8371N, but seems like the SDK is broken for the powe_save once i activate the manual power saving flag:

beken378/func/power_save/manual_ps.c:190:20: error: 'SCTRL_LOW_PWR_CLK' undeclared (first use in this function)
reg = REG_READ(SCTRL_LOW_PWR_CLK);
^
./beken378/driver/include/arm_arch.h:55:56: note: in definition of macro 'REG_READ'
#define REG_READ(addr) (*((volatile UINT32 *)(addr)))
^
beken378/func/power_save/manual_ps.c:191:14: error: 'LPO_CLK_MUX_MASK' undeclared (first use in this function)
reg &= ~(LPO_CLK_MUX_MASK);
^
beken378/func/power_save/manual_ps.c:192:13: error: 'LPO_SRC_ROSC' undeclared (first use in this function)
reg |= (LPO_SRC_ROSC << LPO_CLK_MUX_POSI);
^
beken378/func/power_save/manual_ps.c:192:29: error: 'LPO_CLK_MUX_POSI' undeclared (first use in this function)
reg |= (LPO_SRC_ROSC << LPO_CLK_MUX_POSI);
^
beken378/func/power_save/manual_ps.c:194:14: error: 'GPIO_ARM_WAKEUP_EN_BIT' undeclared (first use in this function)
param = (GPIO_ARM_WAKEUP_EN_BIT);
^
beken378/func/power_save/manual_ps.c:195:19: error: 'ICU_DEV_NAME' undeclared (first use in this function)
sddev_control(ICU_DEV_NAME, CMD_ARM_WAKEUP, &param);
^
beken378/func/power_save/manual_ps.c:195:33: error: 'CMD_ARM_WAKEUP' undeclared (first use in this function)
sddev_control(ICU_DEV_NAME, CMD_ARM_WAKEUP, &param);
^
beken378/func/power_save/manual_ps.c:198:5: error: 'PS_DEBUG_DOWN_OUT' undeclared (first use in this function)
PS_DEBUG_DOWN_OUT;
^
beken378/func/power_save/manual_ps.c:199:5: error: 'PS_DEBUG_UP_OUT' undeclared (first use in this function)
PS_DEBUG_UP_OUT;
^
beken378/func/power_save/manual_ps.c:200:26: error: 'PWD_UART2_CLK_BIT' undeclared (first use in this function)
param = (0xfffff & (~PWD_UART2_CLK_BIT));

I have tested it only for BK7231T.
Here is the only change needed to compile:


If you are compiling for N, and for example SCTRL_LOW_PWR_CLK is undefined, do a Notepad++ search for SCTRL_LOW_PWR_CLK in all SDK files and try to include missing header.

Please try to add missing headers and tell me how it goes. You could also do a pull request to our N platform SDK.


I tried with deep sleep again today but I am not able to get device to wake up on T platform.

@dheenhasty Very good job
Here is the shematic.


I think a new massurement could be taken, that is battery voltage.
Just putting P17 high, ADC meassuremet and P17 low.
So Ubattery = 2*ADC_meassurement if we take RQ2on ~ 0
I don't get the function of the Q1 n-mosfet , its connections have been checked several times...
I hope no mistakes.
Yesterday I was finally successfull to download OpenBK7231 to my device and to start and run it correctly.
I had a problem caused by powering the circuit with the power supply of the serial converter. It was continuously rebooting. Finally powered with a battery everything working fine.
Fantastic environment. I'm gratefully surprised
Now I will try to configure as you mentioned ..

p.kaczmarek2 wrote:

I tried with deep sleep again today but I am not able to get device to wake up on T platform.

I found something weird regarding the timer sometime it's in ms and on some other call it's in second ..... so maybe the wake up delay is due to that, if you try 200ms and it put deep sleep for 200s.

@nelliug54 > thanks the last version include hass autodiscovery but the temp and humidity value will not be correct. I will try to optimise the driver to be able to apply correction at script level.

@nelliug54 very good job! I didn't analyze it yet, but I know that MOSFET can be used a protection against reverse polarity connection.

@dheenhasty is it just a guess or did you check it?
I must admit I thought about that yesterday and tried sleep with "10" argument, expecting it to wake up after 10 seconds, but no luck.
Have you managed to compile deep sleep code for N? I can help, if that's needed.

p.kaczmarek2 wrote:

@dheenhasty is it just a guess or did you check it?
I must admit I thought about that yesterday and tried sleep with "10" argument, expecting it to wake up after 10 seconds, but no luck.
Have you managed to compile deep sleep code for N? I can help, if that's needed.

Supposition. Need to clean my dev env i will retry that tonight.

@p.kaczmarek2 > Ok so i finally manage to compile with deep sleep .... seems like the power_save and the manual_ps is a mess on N. so correct all the lib.

And it seems it's kinda work ........ but the issue is that it does not freeze the cpu ..... it freeze the cpu and then reboot it

So if i try a DeepSleep 10, it will sleep for 10 Sec and reboot. so it take 25 sec to be up again.

will do some more test before submitting change (but it's basically at SDK level (and the last tuya sdk is a mess too .....)

Huh? It works on N?

That's a mess, I'm sure it doesn't work on T, but I will triple-check and compare SDKs.

Please submit a PR so I can check.

Hello i have done the update : https://github.com/openshwprojects/OpenBK7231N/pull/14

i will go deeper in understanding the behavior of this but seems like it's realying on RTOS Sleep mode ..... but since it's base on 9 version .......maybe improvement have been done.

I cannot refresh the lib/drv with the tyua official repo cause there's a lot of cross ref issue .... and it take ages to correct all that.

Are you 100% sure that it really goes to deep sleep for given amount of seconds? And not just crash-restarts in place?

I have merged your pull request and will try it now, but my BK7231N has no TXD2 hooked up to UART so I have no debug log access.

I tested 2 different value DeepSleep with 10 and i cannot access the sensor for ~25 seconds
And with 300 i cannot access the sensor for ~5 min.

So yes it go to deepsleep ..... .but it may crash when system try to wakeup

Why do you think that it may crash?

Do you have a T device?

The reboot is not normal even in Deep Sleep.

No i only have N

Done some other test around the idle_sleep .... but seems like it's not very effective.

For the deep sleep i try a run at DeepSleep 60 and is was sleeping for 1m and 15s

I think it crash due to the reboot ...... but thinking of that i think it's more an issue with the priority level of the Tuya OS between RTOS behind that.

but it can be troublesome to implement that if some one do a deepsleep at starttime ...... (think in about some 5sec or 10sec delay