[BK7231N CBU] Generic Temperature and Humidity Sensor

I dont know why at me show like this after set pin:

@dheenhasty says:
"pins": {
"7": "SHT3X_SCK;0",
"8": "SHT3X_SDA;2;3",
"17": "Rel;5",
"20": "dInput_n;0",
"23": "ADC;4",
"26": "LED;1"
}
P6 should be P7.
And in P8 it should assign channels 2 and 3, not just 2.

Yes don't why but the pin configuration in the webapp is kind of buggy. i'd prefer to pass thru configure module menu in web frontend configuration

and you might need to wait for the last pull request to be merge to have correct behaviour regarding battery measurement and deep sleep.

But as mention, be carefull if battery is too low you might encounter a freeze !!!! and it need to be reflash thru uart with a 2mb erasing.

Hi,

first of all: Thanks for the great work!
Just started to flash my first device. This basically works, however I missed to put out the batteries and so they have been drain to the end... No problem I thought - however now the device - or at least the wifi - won't come up again (with recharged batteries of course...). I tried to force it into safe/AP mode, which also does not work. I also re-flashed the device (by uart) which also did not change anything.
I had a look at the serial console now which gives the following:
Nothing more...
I did not check the log before (when it was running)... probably there should be more?

I also noticed, that the current consumption of this bricked device with about 20mA is much less than a device running the original tuya firmware (around 100mA when active) - probably not suprising if the wifi is not active...

Is there any way to reset the configuration of the device by uart?
Is it possible that the wifi hardware is damaged by the low voltage (over quite a long time)? However I think than I should even see more log output?

thanks

@pasdVn3 don't worry it's only at ram level.

First can you please backup your firmware in this state thru uart and upload it for analysis

Then here's an original tuya firmware. You can flash it to your device and then reflash an openbeken one. Just change back the mac address after.

Great, that worked! Thank you!

I attached the backup (note, that I replaced SSID and passphrase within the binary). On creating the backup and flashing the tuya firmware, I noticed a crc missmatch warning. Is this normal (I used the uartprogram python script). On downloading the openbeken firmware there was no crc error...
Btw: Is there some documentation about the memory/"partiton" layout?

Have you tried BK7231 datasheet/pinout topic? As far as I remember, partitions are mentioned here:
https://www.elektroda.com/rtvforum/topic3951016.html

I will be finishing next two youtube tutorials for OpenBeken first and then I might also do some work with deep sleep, maybe on one of my test setups...

Ok i have compare the 2 binary (who is drastically different due to OpenBeken and Original firmware )

But what can i say :

BK7231N:
Name From to
Bootloader 0x00000000 0x00011000
Application 0x00011000 0x0012A000
ota 0x0012A000 0x001D0000
RF Firmware 0x001D0000 0x001D1000
NET info 0x001D1000 0x001D2000
If i compare Backup with the QIO Openbekend 392. it's ok nothing change. so i don't think the Bootloader and the Application is to blame
For RF and NET the partition is here, and there's not clear sign of corruption but @p.kaczmarek2 i will need you to confirm that .... i'm not sure about the data format of the config partition.*
(one point could be to compare with a working one ... wondering if you could do another dump of your working again one @pasdVn3 )

after 0x1D2000. i got a lot of different information and repeating pattern from the Backup one if i compare with the tuya original one ..... maybe deep sleep mode store some data in this partition ..... and the default parameter in manual_ps is not correct .... (it will not suprised me as this was clearly a mess in SDK ...... )

@dheenhasty
To avoid getting in the corruption state I would suggest one change in the script.
As the sensor aproximates to the critical battery voltage (2V) we could publish an mqtt error message and ask to replace batteries and increase DeepSleep to 4h for example or gradually the DeepSleep timer to 2h, 4h or 10h with adding more 'if' statements..

for example:

. . . . .
echo "activate voltage meassurement"
setChannel 5 1
delay_s 1
if $CH4/1000<=2200 then goto batlow
. . . . .
. . . . .
DeepSleep 600

batlow:
publish "Bat_fail_Replace_asap" $CH4/1000'
. . . . . .
. . . . . .
echo "deepsleep 4h for example"
DeepSleep 14400

nelliug54 wrote:

@dheenhasty
To avoid getting in the corruption state I would suggest one change in the script.
As the sensor aproximates to the critical battery voltage (2V) we could publish an mqtt error message and ask to replace batteries and increase DeepSleep to 4h for example or gradually the DeepSleep timer to 2h, 4h or 10h with adding more 'if' statements..

for example:

. . . . .
echo "activate voltage meassurement"
setChannel 5 1
delay_s 1
if $CH4/1000<=2200 then goto batlow
. . . . .
. . . . .
DeepSleep 600

batlow:
publish "Bat_fail_Replace_asap" $CH4/1000'
. . . . . .
. . . . . .
echo "deepsleep 4h for example"
DeepSleep 14400

That's a good point, but before that i want to put in place the timer deep sleep but with a possibility to wake up thru gpio too. (It's possible but i dont had time to work on it) cause else the deepsleep will continue even if you change the battery (due to capacitor)

Hi guys, it is logged this set of error messages everytime the read is launched:

Error:CMD:command with name SHT_Calibrate already exists!
Error:CMD:command with name SHT_MeasurePer already exists!
Error:CMD:command with name SHT_LaunchPer already exists!
Error:CMD:command with name SHT_StopPer already exists!
Error:CMD:command with name SHT_Measure already exists!
Error:CMD:command with name SHT_Heater already exists!
Error:CMD:command with name SHT_GetStatus already exists!

Do you know the reason for it?

I can fix it right now but I don't know if @dheenhasty has unpushed changes? I don't want to get merge conflicts.


Hmmm maybe for deep sleep we could use a formula? Someething like... DeepSleep (1024-batteryLevel)*15 , etc etc? But we dont' have support for braces yet, hmm... I will look into it.

Normally, I have Corrected the battery measurement in my last commit everything should be better.

i have no plan to update the sht driver for the moment. they're load of work to do on this (implementing the channel mode for the heater, and alerting part) i'm clearly lacking some time to work on that .....

i have again check the Deep Sleep more deeply in BK SDK. for the N. seems like the sys_ctrl only include a RTC mode and a GPIO mode. but no possibility to activate both. in GPIO mode RTC is deactivate. and in RTC GPIO is deactivated ....

the more i dig on it ... the more this manual_ps mode seems depressing .... i'm wondering if tuya doesn't rely only on power_save sdk function.

Deep sleep is really effective .... but something is clearly fishy on the way sdk implement it.

Added after 1 [minutes]:

nelliug54 wrote:

Hi guys, it is logged this set of error messages everytime the read is launched:

Error:CMD:command with name SHT_Calibrate already exists!
Error:CMD:command with name SHT_MeasurePer already exists!
Error:CMD:command with name SHT_LaunchPer already exists!
Error:CMD:command with name SHT_StopPer already exists!
Error:CMD:command with name SHT_Measure already exists!
Error:CMD:command with name SHT_Heater already exists!
Error:CMD:command with name SHT_GetStatus already exists!

Do you know the reason for it?

Bad CPP coding by me it redeclare the void each time you read .....

Added after 8 [minutes]:

nelliug54 wrote:

I don't get the function of the Q1 n-mosfet , its connections have been checked several times...
I hope no mistakes.

i'm wondering if this mosfet is here to prevent issue in case you decide to put 3,3v directly to the BK (thru pin 14/15) instead of the battery.

Wasn't Q1 for reverse polarity protection?

@dheenhasty are your changes ready to merge? At least that part that's done.

By the way, it seems that "wake up on GPIO" works only on T and not on N.

p.kaczmarek2 wrote:

Wasn't Q1 for reverse polarity protection?

@dheenhasty are your changes ready to merge? At least that part that's done.

By the way, it seems that "wake up on GPIO" works only on T and not on N.

Sir yes sir.

So we have T with GPIO OK but not RTC
and N with RTC and not RTC ......

but the rtos and the chip behind have the same capabilities ..... so it's only a matter of SDK implementation.

@dheenhasty I am merging software I2C codes together for LED drivers, I will also merge for your driver changes now, please check tomorrow for ready version of common i2c interface

Dodano po 31 [minuty]:

@dheenhasty , you had a bug in your code. You initialized pins too early, before getting them from config - PreInit must be called after setting indices.

I merged I2C codes, does your sensor still work?
https://github.com/openshwprojects/OpenBK7231...mmit/75c1717930c83de86d4ae892f1ebc674efafe878

@p.kaczmarek2 i have test the latest release 1.15.439 not sure it include your modification ? if so it works flawlessly

i have done again a lot of test on deepsleep side, GPIO is working but i cannot figure how to handle the edge map and index map. if i put them on FFFFFF / FFFFFF it execute thedeesleep but go alive directly (so i suppose it detect a input) but i have try to play around the pin with the button and cannot find a way ....


to play i have done some modification on manual_ps and cmd_c :

deep_sleep in cmd :

Quote:

static commandResult_t CMD_DeepSleep(const void* context, const char* cmd, const char* args, int cmdFlags) {
int timeMS, idx_map = 0, edg_map = 0;

Tokenizer_TokenizeString(args, 0);

// following check must be done after 'Tokenizer_TokenizeString',
// so we know arguments count in Tokenizer. 'cmd' argument is
// only for warning display
if (Tokenizer_CheckArgsCountAndPrintWarning(cmd, 1)) {
return CMD_RES_NOT_ENOUGH_ARGUMENTS;
}

timeMS = Tokenizer_GetArgInteger(0);
idx_map = Tokenizer_GetArgInteger(1);
edg_map = Tokenizer_GetArgInteger(2);
#ifdef PLATFORM_BEKEN
// It requires a define in SDK file:
// OpenBK7231T\platforms\bk7231t\bk7231t_os\beken378\func\include\manual_ps_pub.h
// define there:
// #define PS_SUPPORT_MANUAL_SLEEP 1
extern void bk_wlan_ps_wakeup_with_timer(UINT32 sleep_time, UINT32 idx_map, UINT32 edg_map);
bk_wlan_ps_wakeup_with_timer(timeMS, idx_map, edg_map);
return CMD_RES_OK;
#elif defined(PLATFORM_W600)

#endif

return CMD_RES_OK;
}

and on manual :

Quote:

void bk_wlan_ps_wakeup_with_timer(UINT32 sleep_time,UINT32 idx_map, UINT32 edg_map)
{
PS_DEEP_CTRL_PARAM deep_sleep_param;

deep_sleep_param.sleep_time = sleep_time;
deep_sleep_param.wake_up_way = PS_DEEP_WAKEUP_GPIO;
deep_sleep_param.gpio_index_map = idx_map;
deep_sleep_param.gpio_edge_map = edg_map;

os_printf("---deep sleep test param : 0x%0X 0x%0X 0x%0X 0x%0X %d %d\r\n",
deep_sleep_param.gpio_index_map,
deep_sleep_param.gpio_edge_map,
deep_sleep_param.gpio_last_index_map,
deep_sleep_param.gpio_last_edge_map,
deep_sleep_param.sleep_time,
deep_sleep_param.wake_up_way);

bk_enter_deep_sleep_mode(&deep_sleep_param);
}

i think in future, if we can resolve the issue with timer on T and GPIO on N, we can modify the Deep_Sleep call to handle the method we want.

My I2C changes are already in place, but I also have to finalize them and move shared I2C software code to separate file.

All drivers are using now the same I2C functions.

Regarding edge map, we already got it.

Here is a command:

See new_pins.c and search for g_gpio_edge_map and g_gpio_index_map.
It works on T.
It basically scans pin roles and then all buttons on device can wakeup from the sleep.
It works on my BK7231T test device

@p.kaczmarek2 Thanks a lot for all this i have unlock the GPIO for N. will publish the update on the N SDK

issue was void not available in N manual_ps.c and that we got a test debug void who was executed each time .... so i correct this and it works flawlessly

i add submitted a merge for SDK and APP to make that available.

Sadly you can't do timer and GPIO Sleep (it needs more SDK modification). so you have to chose.

it's a big step for this sensor next the alarms mode for the sht who can permit to wakeup device is temp or hum is too low or too high.

Hello guys!

I'm also playing with those sensors and I was able to add one to a relay based on a CB2S board! But I'm stuck with another relay with a bare BK7231N on the PCB... Thing is: in this configuration, I cannot choose the pins I'm going to be using for the sensor, I have to deal with the test pads on the PCB. Fortunately, on both relays the UART2_RXD/I2C2_SDA and UART2_TXD/I2C2_SCL were available.

Here is the pin config on both relays:


And here is my autoexec.bat script:


However on the problematic relay the sensor would send measurements... until the relay is reset! After that the only data read on the bus is FF FF... This is what SHT_GetStatus shows anyways.

I'm running the last release. Any idea? I can't understand why it is working on one relay and not the other, with the exact same wiring...
Also, why are you using the TucaMCU for?

Hello,

i have tried tuya mcu for some powersaving it include .... but it's not making any difference.

the getstatus seems really strange FF FF should not be possible.

https://www.mouser.com/datasheet/2/682/Sensir...ty_Sensors_SHT3x_Datasheet_digital-971521.pdf

the only thing that came in mind is that after the reset it lost the init/preinit pattern. you can try to do a stop of sht driver it will launch a soft reset of the SHT sensor.

I might be able to try soon, my sensor from aliexpress should arrive this or next week.

Why not just let the measure be done automatically? It won't increase power consumption much, I think.

and if you want to reduce power usage, you are still missing "PowerSave" command.

@dheenhasty btw why are you reading the function decls to the function itself in your PR, while I already added #include for HAL header?

in general, it's better to include the header. The same should be done for sleep functions.

@p.kaczmarek2 i had error at compilation time. will try to remove the external to check if it's still the case.

i found some Sample from sensirion for the alert : https://sensirion.com/media/documents/7E4FA82...midity_Sensors_Software_SHT3x_Sample_Code.zip

dheenhasty wrote:

i have tried tuya mcu for some powersaving it include .... but it's not making any difference.

Ok I didn't know about the power saving feature. Since I'm using relays, it doesn't matter for me

dheenhasty wrote:

the only thing that came in mind is that after the reset it lost the init/preinit pattern. you can try to do a stop of sht driver it will launch a soft reset of the SHT sensor.

I tried multiple times. Stop then start... With and without reboot. Same thing. I thought the sensor had blown for some reason so I tested it with an Arduino and it was working. I swapped another sensor and it worked... Until the relay module rebooted :p and now I can't get any measurements. That's so weird.

ShadowLight30 wrote:

Ok I didn't know about the power saving feature. Since I'm using relays, it doesn't matter for me

What do you mean with "relays"? I think that this feature helps on every device, but it will only really save power if you don't keep Web App log open. Otherwise the log query done every 2 seconds or so will keep device awake. The PowerSave is not a deep sleep, so device will still run and respond to MQTT and buttons, etc. It's almost transparent sleep, I think.

Some of the cheapest devices might have low quality power supplies which can get quickly tired without PowerSave command. I even had to replace a faulty capacitor once...
https://www.elektroda.pl/rtvforum/topic3898805.html

You can share some picture of your device ?

https://www.elektroda.com/rtvforum/topic3912748.html#20145042
That's the relay I'm talking about.

@ShadowLight30 hum i think you use the bad pin (TX2/RX2) for the CB2S, who can generate strange behavior. You cannot use other unused pwm on (p6/p7) for example ?


You can find the pinout on developper.tuya site

Well the relay with a CB2S works that way. If you look at the datasheet of the BK7231N you see those 2 pins serve as UART_2 and I2C_2. On the CB2S those pins are on the back of the PCB.

The relay I can't get the SHT30 to work with has its chip soldered on the relay PCB like the first post of the link I shared. And this one stops working after a reboot. I can't use any other pin because the unused pins are not traced to any test pad on the PCB. So aside from the switch inputs, relay and led outputs, tx1 and rx1, tx2 and rx2... I have no way to connect to the chip :p

it's really confusing

Ok so the one that work is the one with the CB2S board soldered on it.
So you can see here that it's really not recommended to use P0 or P1 , https://developer.tuya.com/en/docs/iot/cb2s-module-datasheet?id=Kafgfsa2aaypq

For the one with the soldered beken directly you can this one ? :


And for the one with CB2S based on tuya doc :


No ?


Edit : for reference on CBU https://developer.tuya.com/en/docs/iot/cbu-module-datasheet?id=Ka07pykl5dk4u it's the same P0/P1 is not for use. i think it's global for BK7231N. this pin is reserved