[BK7231N CBU] Generic Temperature and Humidity Sensor

Hi, I have added voltage meassurement publissing to your scrip.
it has a deviation of .5V from the real battery voltage, it seems no correct meassurement at all, but correction can be applied.
I don't have much knowledge of script language so is possible some math functions could be applied onto the scrip itself.

@nelliug54 Good job, yes i had trouble with the math in script mode too...... now we can see that battery is consumed really quickly

and we can test multiple thing to optimize that.
i saw that during my test with Out Of Box sensor they act like that.
Connect to wifi
Push value
Disconnect wifi
wait 1h
Reconnect to wifi
push value
Wait 1h .......

if i push the button it connect to wifi, push value and go back to sleep .....
so i'm wondering if it's not they're way to keep up the battery (turning of BLE and WIFI)

@nelliug54 very good job figuring it out. Before we finish the docs, the best thing to look for examples would be here:
https://github.com/openshwprojects/OpenBK7231...blob/main/src/selftest/selftest_expressions.c
My only question is - do you have measurements telling that it makes sense to disable the sensor?
I think that device will eat power no matter whether sensor is used, and the correct approach is DeepSleep

@dheenhasty I've been thinking about the approach for this device and I think we could get away with using DeepSleep commands once it's working.


so something like:


basically, after reboot it will wait 120 seconds (with infinite repeats, but it doesn't matter), and then do a DeepSleep for 100 seconds.
or at least I think so, on my T deep sleep doesn't work, but according to @dheenhasty it works on N?)

p.kaczmarek2 wrote:

, on my T deep sleep doesn't work,

i had take a look on T sdk and power saver lib seems really different.... i try to reverse engineer all that but that's tricky i don't know why sdk is so much different, on beken git they're the same .... only some conf and rtos module is different.

https://github.com/bekencorp/bdk_freertos

and seems like tuya is making a low cosumption module the CBU-NL. I find the sdk ..... but there's not so much difference with the N one .....

with deepsleep on N. If i do some math.
normally it drain the batterie in 6 hour (so 21600 sec)
in ds mode, if we consider active time to be 3min (180sec) we can do 180 measurement with a full battery so 5days with a point each hours .....
We need to lower the active time.... i will do some test

@nelliug54 i have try another angle but calculating the percentage :

echo "activate voltage meassurement"
setChannel 5 1
delay_s 1
publishFloat "voltage" $CH4/1000
publishFloat "battery" $CH4/25
setchannel 5 0
setChannel 3 0

i have the same derivation as you around 0,5v so dividing by 25 give an idea of the battery percent ;

good point, percentage is more usefull.

So after a lot of test with the deep sleep method..... seems like the BK don't like it on startup script ..... i think it missed some verification. Somewhere.

but anyway after a lot of test i have completely crashed my BK. i doesn't want to come back to life even after an uart flash....... so 1 down. i need to flash another one to continue testing but it will take some other time.

@dheenhasty first of all, do you know that device will boot into safe mode if it was up for less than 30 seconds for 5 times?

You can change that behaviour in the settings. This can be used to recover device if startup script breaks something.

How do you know that your bk is crashed? Maybe you need to wait for capacitors to discharge, I had something like that few times when testing deep sleep.

Do you get a correct results while flashing via uart? If so, then bk is not dead...

p.kaczmarek2 wrote:

@dheenhasty first of all, do you know that device will boot into safe mode if it was up for less than 30 seconds for 5 times?

You can change that behaviour in the settings. This can be used to recover device if startup script breaks something.

How do you know that your bk is crashed? Maybe you need to wait for capacitors to discharge, I had something like that few times when testing deep sleep.

Do you get a correct results while flashing via uart? If so, then bk is not dead...

Yeap i bring back it online with uart flashing the original firmware and back to OpenB with uart. i suspect a corruption on littlefs side that prevented the firmware to boot up .......

and another thing, the sensor original firmware have been update, so now cloudcutter doesn't work anymore ...... i will extract the new firmware and upload the new profile on git.

But anyway, device up and running again, so i can continue my testing


EDIT : ok new firmware info pushed to cloudcutter

Adding 2 new command :

https://github.com/openshwprojects/OpenBK7231T_App/pull/625

SetupSHT3X dependent of sht3x driver permit to calibrate the sensor
Ex : SetupSHT3X -4 10 // it will remove 4 degrees to Temperature and add 10% to humidity.

Battery_measure :
It will calculate and publish voltage and battery percentage base on min battery and max battery in args.
The calculation is based on Tuya SDK ( /4096 * 2400 ) of ADC (done some check and seems like the volt is align with physical check .
IOR_ADC must be assigned
mqtt topic => voltage and battery
Ex : Battery_measure 1500 3000 // will give you the percentage of battery based on this 2 value.

@p.kaczmarek2 , i just found something weird and could explain a lot of issue. seems like the script don't take in account some of system void.

Here's an example i have done modification on DeepSleep command to avoir boot loop. (i was suspecting that the system execute the script before the boot complete)

Quote:

static commandResult_t CMD_DeepSleep(const void* context, const char* cmd, const char* args, int cmdFlags) {
int timeMS, WaitTime;

ADDLOG_INFO(LOG_FEATURE_CMD, "CMD_DeepSleep: enable power save");
Tokenizer_TokenizeString(args, 0);

if (Tokenizer_GetArgsCount() < 2) {
ADDLOG_INFO(LOG_FEATURE_CMD, "CMD_DeepSleep : Not enough arguments.( SleepTime , WaitTime)");
return CMD_RES_NOT_ENOUGH_ARGUMENTS;
}

timeMS = Tokenizer_GetArgInteger(0);
WaitTime = Tokenizer_GetArgInteger(1);
#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);
ADDLOG_INFO(LOG_FEATURE_CMD, "CMD_DeepSleep : wait 120 Seconds to prevent bootloop");
rtos_delay_milliseconds(WaitTime * 1000);
ADDLOG_INFO(LOG_FEATURE_CMD, "CMD_DeepSleep : Go to sleep");
rtos_delay_milliseconds(1000);
bk_wlan_ps_wakeup_with_timer(timeMS);
#elif defined(PLATFORM_W600)

#endif

return CMD_RES_OK;
}

So when i execute it thru webapps command line, it works flawlessly. but when i execute it thru script. it jump directly to the deep sleep.

any idea on what happens ?

Another point i have done some comparaison between T and N regarding the deep sleep. seems like the deep sleep lib en N is more elaborate than on T..... i don't think it's an issue with the support the BK is really similar, and freertos is the same. but seems like the sys_ctrl lib and the manual_ps is clearly not the same. and modification is really deep .....

I while dive a little bit more on the T one to find why it's not working. but i don't have any T device .... so i rely on you to test [/quote]

Very good job @dheenhasty . I apologize for being silent for about a day but I worked on BL602 OTA and it was a real mess to solve. At least, it works now, BL602 platform finally has OTA, after all these months...

Okey, back to Beken - my first guess would be a stack size. Maybe call is too nested and you run out of the stack?

Another thing.... do I see correctly, are you trying to do a 1000ms delay?
The script is executed from 25 ms (or so, I don't remember now) timer, trying to wait 1000ms there will have unexpected results.
The web app commands, on the other hand, are handled from the TCP server which creates a thread per each client, so it can wait 1000ms....
Maybe that's the cause of your problem?


I can help testing, I have spare WB2S devices, you can look at this topic, I've did a little showcase there:
https://www.elektroda.com/rtvforum/topic3951016.html


I haven't yet experienced any issues with deep sleep, but I didn't test it much on N, and on T, as you know, it's just not working yet.





EDIT: Maybe the root cause of your problems is that you call deep sleep several times? Maybe you can remove the delay and add a guard like that:

p.kaczmarek2 wrote:

Another thing.... do I see correctly, are you trying to do a 1000ms delay?
The script is executed from 25 ms (or so, I don't remember now) timer, trying to wait 1000ms there will have unexpected results.
The web app commands, on the other hand, are handled from the TCP server which creates a thread per each client, so it can wait 1000ms....
Maybe that's the cause of your problem?

Hum, i think you point out one of the issue, the web is kind of synchrone command who can wait. but the script one is an async so to put a wait sequence in a CMD use by a script we need to implement a global timer (just like the HA discovery)

i was just try to launch a deep sleep once in script mode :

startDriver SHT3X
DeepSleep 300 120

the startDriver was correctly ran but the DeepSleep No .... i will continue my investigation then

@dheenhasty so do something like that: a global variable "bWantDeepSleep" and then in main timer/loop (user_main.c) check for that variable, and if set, then init deep sleep and exit.
Is it working better than current version?

p.kaczmarek2 wrote:

@dheenhasty so do something like that: a global variable "bWantDeepSleep" and then in main timer/loop (user_main.c) check for that variable, and if set, then init deep sleep and exit.
Is it working better than current version?

Hum i'm trying another trick by checking the uptime:

extern void bk_wlan_ps_wakeup_with_timer(UINT32 sleep_time);
if (Time_getUpTimeSeconds() < 120)
{
ADDLOG_INFO(LOG_FEATURE_CMD, "CMD_DeepSleep : Deep Sleep cannot be launch at start");
return CMD_RES_OK;
}
bk_wlan_ps_wakeup_with_timer(timeMS);

main concern here is to avoid bootloop.

Are you really sure that check is necessary? Futhermore, why exactly 120 seconds?
I also think that Tuya devices can get back to sleep immediately, without waiting extra time.
I haven't managed to play with BK yet today, so far all my time was spent on BL602, but I will try to check that deep sleep more this evening.

all this is for testing purpose. i just want to eliminate culprit here.

To sum up on N :
- Deep Sleep behaviour is OK :
- launched from webapp directly
- launched from script in webapp
- Deep Sleep break the system :
- put the script in startup command. (sensor is no more responding, but battery is drained ... so i suspect a bootloop)

So i have put a 120 check (2 min) to permit me to access the sensor before looping. but since that's not the issue .....

here's the testscript :

again:
echo "activate startDriver sht3x"
startDriver SHT3X
echo "DeepSleep"
DeepSleep 300
stopDriver SHT3X
echo "looping"
goto again

I think I can see what's wrong. You have a wrong base assumption.

dheenhasty wrote:

again:
echo "activate startDriver sht3x"
startDriver SHT3X
echo "DeepSleep"
DeepSleep 300
stopDriver SHT3X
echo "looping"
goto again

This will NEVER work, because, as far as I know, "DeepSleep" command will purge all RAM content. This will just turn off the device. Anything below "DeepSleep 300" will NOT get executed. By design, never.

This is because "DeepSleep" basically means "turn off whole device and reboot from 0 after N seconds".

Normally yes the DeepSleep will reboot if the bk_sleep command is executed.

But since i asked him to not be executed if uptime is below 120sec. it will continue the loop.

until we reached a uptime higher that 120sec.

the it will reboot the device, and relaunch the script.

But you are right for something .... i forget to put a delay between deepsleep and start driver -_- ......

It is still incorrect because in this case:

Will start and stop SHT3X driver in a single frame.
Not to mention that restarting driver doesn't make any difference for the power consumption...

I'd rather assume you want something like this (this is autoexec.bat):

This will start driver SHT3X on reboot, device will run for 30 seconds, and then go into deep sleep for 600 seconds (if that's the argument value), then again reboot from scratch, and run again, etc...

Ok So now that the DeepSleep if more stable (and my mind on how to use it too )
i have added the majority of command for SHT :


SHT_Calibrate => to calibrate before measurement
SHT_Measure => to do one shot measure
SHT_LaunchPer => to launch internal sensor periodic capture
SHT_MeasurePer => to fetch the periodic data captured
SHT_StopPer => to stop periodic capture
SHT_Heater => to activate/deactivate Heater
SHT_GetStatus => retrieve the sensor Status

and deactivate the capture every Seconds .

so with this scripts :

echo "activate startDriver sht3x"
startDriver SHT3X
SHT_Calibrate -4.6 +5
SHT_Measure
echo "send ADC info"
Battery_measure 1100 2500
stopDriver SHT3X
echo "DeepSleep"
addRepeatingEvent 120 -1 DeepSleep 600

Seems like it's working

Nice, but what is SHT3X_Heater ?

Futhermore, what is the application of doing less samples (single measure etc)? It's not like that can save much energy.

Based on datasheet who is really complete.

The heater is here for external purpose i think.
cause it heat it ... pretty quick.

For the capture method i don't have seen a difference, between them except that
the one shot require a 15ms delay before reading.

The periodical one store the last value so the fetching is pretty stray forward. And i suppose a prereq for alerting.

i will try to work on alerting, it's really interresting, cause it permit the sensor to pull up a gpio and so leave the deepsleep too.

https://sensirion.com/resource/application_no...TYQFnoECBUQAQ&usg=AOvVaw1QIoqDKNLpI6IpPoVJmTw

I understand that you can find thar a little bit overkill
We might need an expert on sensor to understand all that

The GPIO wakeup is working for BK so it might be useful in some edge cases.

The heater you mentioned is described here (I first confused it with an external heater control):


Still, I will note that any advanced control logic of, well, for example, external heater (by relay) with the temperature sensor should be done on channels level (outside the driver):
The correct approach would be:
1. make your sensor save the value to given channel (as it already does), just like any other sensors
2. then you make a change handler for the channel:

3. in change handlers you can enable and disable heaters
If you want a true PID, then we could also think of something else, maybe in a form of generic driver that can be linked to channels.

The idea is to keep the generic stuff shared and channel-based so it will work also if we swap sensor to TC74, etc.

Ok thank you for the guidance. I will adapt accordingly

Ok after one night run, i can annonce 2 good news.

Battery seems ok no major drain
And captor doesn't need the calibrate after 4 or 5 deep sleep temperature is pretty align with environment. (I suppose the 3 or 4 degrees issue is the heat dissipation of the bk or the regulator thru the board)

@dheenhasty it seems that my sensor arrived:
I might be able to help playing around with it soon.

I will also most likely merge I2C software code because right now it... it's repeated several times. This is a wrong design. I will move it to common file.

So what are last script and last config PIN?

Thanks

Last pin config has been update in the repository so you should be able to use the automatic config from the webapp.
"pins": {
"7": "SHT3X_SCK;0",
"8": "SHT3X_SDA;2;3",
"17": "Rel;5",
"20": "dInput_n;0",
"23": "ADC;4",
"26": "LED;1"
}
You can change the LED to WifiLed if you prefer (it permit to verify that the device is correctly getting out of DeepSleep
For the script this one work for me but if the battery is too low seem like the sensor is stuck in DeepSleep. so you have to unlock it thru safe mode.

Quote:

echo "Init driver and powersave "
startDriver TuyaMCU
setChannelType 1 temperature_div10
setChannelType 2 humidity
setChannelType 3 toggle
setChannelType 4 Voltage
setChannelType 5 toggle
PowerSave

echo "activate SHT3X Sensor"
startDriver SHT3X
setChannel 3 1
echo "Send some measure"
delay_s 2
echo "stop SHT3X driver"
stopDriver SHT3X
echo "activate voltage meassurement"
setChannel 5 1
delay_s 1
publishFloat "voltage" $CH4/1000
publishFloat "battery" $CH4/25
setChannel 5 0
setChannel 3 0
echo "wait 2min before deeSleep for 10min and reboot "
delay_s 120
DeepSleep 600

you should get that :


and then do as me forget to change battery...... and dead so need to be reflash .... (i'm really wondering if on battery low the littlefs does not corrupt itself .....

So it works, but it's not really really stable. it clearly need more work.

Added after 1 [hours] 27 [minutes]:

p.kaczmarek2 wrote:

@dheenhasty it seems that my sensor arrived:
I might be able to help playing around with it soon.

I will also most likely merge I2C software code because right now it... it's repeated several times. This is a wrong design. I will move it to common file.

I was thinking about a simpler way to address the I2C Driver. maybe by enabling the readbyte(s) and writebyte(s) command in script mode we can address past usecase (SHT/CHT) and future usecase.

just a specific script with repeated event can do the trick for many I2C Sensor as it's basically just a start adresse, a command and a read.

my only concern is regarding the variables manipulation in script mode and multiple I2C sensor.

Added after 1 [hours] 35 [minutes]:

@p.kaczmarek2 Another thing regarding the Deep Sleep and the battery ..... i really think there is a corruption issue after batterie low and deep sleep seems like the device is frozen on Init_Before_Delay :



i you have any hints to test before a do a Flash with uart method (seems like it's the only way to revive sensor) seems like the cfg is corrupted somehow ......

here's another exemple of corruption after going below 2V of battery ....

initLog()done!
Info:MAIN:Main_Init_Before_Delay
undefinedinstruction
Currentregs:
r00:0xddbc00e2r01:0x00000000r02:0x005ddc12r03:0x00000052
r04:0x005ddbc0r05:0xffbf5877r06:0x003ff1c6r07:0xddbc0000
r08:0x08080808r09:0x09090909r10:0x10101010
fp:0x11111111ip:0xffe377f0
sp:0x004055c8lr:0x0080006epc:0x0080006e
SPSR:0x800000ff
CPSR:0x800000db

separateregs:
SYS:cpsrr8-r14

And since i'm on capture the TX2 here's the ouput of the official Firmware for the CBU sensor :

[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,net_t:-----val:180
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,rstcnt:-----val:3
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,bt_pin:-----val:20
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,bt_lv:-----val:0
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,net_led_pin:-----val:26
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,net_led_lv:-----val:1
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,i2c_scl_pin:-----val:7
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,i2c_sda_pin:-----val:8
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,nxtalm_t:-----val:5
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,rep_t:-----val:1
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,tmp_max:-----val:600
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,tmp_min:-----val:-100
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,hum_max:-----val:100
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,hum_min:-----val:0
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,samp_type:-----val:1
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,samp_sw_pin:-----val:17
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,samp_pin:-----val:23
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,max_V:-----val:3000
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,min_V:-----val:2200
[01-01 18:12:15 TUYA Notice][lr:0x5a017] key:,alarm_st:-----val:1
[01-01 18:12:15 TUYA Notice][lr:0x5a045] g_hw_abs_tb.res_key.pin is:20,

seems like they defined the P20 button as a button and as a reset button too (i suppose for the gpio Deep Sleep method)

Thanks for posting the configuration.

dheenhasty wrote:

@p.kaczmarek2 Another thing regarding the Deep Sleep and the battery ..... i really think there is a corruption issue after batterie low and deep sleep seems like the device is frozen on Init_Before_Delay :



i you have any hints to test before a do a Flash with uart method (seems like it's the only way to revive sensor) seems like the cfg is corrupted somehow ......

Can you (in the future) provide a full 2MB dump for this issue? We could use it to investigate more.


Regarding scriptable I2C driver - I am not sure, maybe, but if you have a person who can write I2C driver in our script, then you already can get C code for driver easily, so I am not sure if it's worth.