[BK7231N CBU] Generic Temperature and Humidity Sensor

I think that current software I2C code has no global variables, so multiple sensors can be run together.

EDIT: I have split the Tuya-cloudcutter wireless flashing discussion into separate topic, see:
BK7231 flashing sensor via tuya-cloudcutter, not connecting to network

Hello.
I finally managed to flash the module via UART with no issues. Everything works as expected, but I have the same problem that @akkipro had, that is, in Home Assistant, both the voltage and the battery level are updated every 10 seconds, but neither the temperature nor the humidity are updated, unless you manually run autexec.bat.
I have tried many configurations, simple as:

PowerSave
scheduleHADiscovery
delay_s 60

and more complicated:

PowerSave
startDriver SHT3X
SHT_Calibrate -3.2 +6
SHT_Measure
Battery_Setup 2000 3030 2.29
battery_measure
publishFloat "voltage" $CH4/1000
publishFloat "battery" $CH4/25
mqtt_broadcastInterval 300
scheduleHADiscovery
addRepeatingEvent 300 -1 SHT_Measure

but I still don't have the updated temperature and humidity.

By the way, I have noticed that if I "play" with the sensor for some time, the temperature difference between the offered sample and the real one is about 4 degrees Cesius, but if I let the module work "alone", the difference is reduced to about 2 degrees.

As soon as I get the module working normally, I will do a more in-depth study to be able to give a more approximate measurement.

Greetings.

Added after 9 [minutes]:

More info about the problem:

LOG:
Info:SENSOR:SHT3X_Measure: Temperature:21.5C Humidity:55%
Info:MAIN:Time 48871, idle 65970/s, free 64960, MQTT 1(1), bWifi 1, secondsWithNoPing 48800, socks 2/38 POWERSAVE
Info:DRV:DRV_BATTERY : Measure Battery volt en perc
Info:GEN:CHANNEL_Set channel 5 has changed to 1 (flags 0)

Info:MQTT:Channel has changed! Publishing 1 to channel 5
Info:MQTT:Publishing val 1 to obkFF8FA1BC/5/get retain=0
Info:GEN:CHANNEL_Set channel 5 has changed to 0 (flags 0)

Info:MQTT:Channel has changed! Publishing 0 to channel 5
Info:MQTT:Publishing val 0 to obkFF8FA1BC/5/get retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkFF8FA1BC/5/get
Info:MQTT:MQTT in topic obkFF8FA1BC/5/get
Info:MQTT:MQTT topic not handled: obkFF8FA1BC/5/get
Info:MQTT:Publishing val 3027 to obkFF8FA1BC/voltage/get retain=0
Info:MQTT:Publishing val 99 to obkFF8FA1BC/battery/get retain=0
Info:DRV:DRV_BATTERY : battery voltage : 3027.093750 and percentage 99.717834%
Info:MAIN:Time 48872, idle 134749/s, free 52744, MQTT 1(1), bWifi 1, secondsWithNoPing 48801, socks 3/38 POWERSAVE
Info:MQTT:channelSet NOT 'set'
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkFF8FA1BC/5/get
Info:MQTT:MQTT in topic obkFF8FA1BC/5/get
Info:MQTT:MQTT topic not handled: obkFF8FA1BC/5/get
Info:MQTT:channelSet NOT 'set'
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkFF8FA1BC/voltage/get
Info:MQTT:MQTT in topic obkFF8FA1BC/voltage/get
Info:MQTT:MQTT topic not handled: obkFF8FA1BC/voltage/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkFF8FA1BC/battery/get
Info:MQTT:MQTT in topic obkFF8FA1BC/battery/get
Info:MQTT:MQTT topic not handled: obkFF8FA1BC/battery/get
Info:MQTT:channelSet NOT 'set'
Info:MQTT:channelSet NOT 'set'

Thank you for reporting a problem. There was indeed a missing condition for automatic SHT3X publish. It will be fixed in 15 minutes.

I also looked into your script. This script is NOT valid:

minchutu wrote:

PowerSave
startDriver SHT3X
SHT_Calibrate -3.2 +6
SHT_Measure
Battery_Setup 2000 3030 2.29
battery_measure
publishFloat "voltage" $CH4/1000
publishFloat "battery" $CH4/25
mqtt_broadcastInterval 300
scheduleHADiscovery
addRepeatingEvent 300 -1 SHT_Measure

you are missing a delay_s before publishFloat . This will not work because MQTT will not be yet online.

With latest fix, it should be better to use automatic publish and deep sleep, but in general keep in mind to use publishFloat after MQTT is connected.

In the next update, I will add a command waitFor that will allow script thread to wait for MQTT connect event easily.

I'm really impressed. You read the message, answer and solve the problem in a few minutes. Not even the most expensive support service is as effective. Bravo!

It works perfectly now. In a self way. You don't need to reconfigure anything. I've just added a calibration command:

PowerSave
startDriver SHT3X
SHT_Calibrate -4 +6
SHT_Measure
scheduleHADiscovery

Really thank you very much!

Thank you, however I have to note, that in my opinion your current approach is not the most energy-saving one. You would get much better result (longer battery live) if you used DeepSleep command to sleep for given time, maybe 120 seconds or maybe even more.

@DeDaMrAz is working on similar device right now, I think

I am adding new feature now (it will work soon), an ability to wait for given event in script (for example, wait for MQTT connect):

but maybe that's not a perfect solution yet, because in case of no MQTT, that would wait forever... maybe one would need some timer/addRepeatingEvent with 1 count and time like 300 as a backup plan in case that mqtt does not go up

Here is the solution for ONE type of battery powered devices I am working on right now, more of them to come.

this is the script:



- Note that in my particular case 2.02 (Vdevider) is set to accurately represent the battery level, test and adjust for your use case.
- Battery_cycle measurement is set to 10s for testing purposes, it can be adjusted as well to 12-14s (to have 2 measurements while device is awake).
- SHT_Calibrate is for adjusting your sensor reading -2'C and +3% for humidity in my case, both values can be either + or - (confirm and adjust for your sensor)
-Delay of 30s is there to accommodate device waking from DeepSleep and give it chance to measure the batt, get the sensor reading, connect to MQTT and publish values.
- DeepSleep 300s is also for testing (it will eat your batteries if you left it this low, move it to 900s = 15min or more for longer battery life)

Another thing is flags, activate flags - 7, 10, 21, 35 and 37.
One note here after setting these notes delete your device from HA and set up new discovery for flag 35 to take effect - this will solve unavailable issue for readings after 120s in HA.

Hope it helps - next thing on the list is to tweak the awake time for logger battery life. Stay tuned...

EDIT: pin config for my module



It is a good practice to separate channels

@p.kaczmarek2 I really appreciate your comments. Power is not an issue for this sensor because it is permanently connected to a power source, that's why I don't take the DeepSpeep command into account. For me the main thing is to have the measure permanently in HA.

However, @DeDaMrAz 's comment opens another door for me. I was unaware that by playing with the flags you could force HA to retain the value (and not get the unavailable result in automations). I have tested it and it works perfectly. Thank you so much. Although in my case the power is not a problem, I have enabled the DeepSleep as indicated since it does not make much sense to send the temperature every 10 seconds (my house is not a space rocket or a nuclear power plant )

¡Saludos!

@minchutu

This is a battery powered device, it makes sense to preserve the battery and spend least amount of time working - and in that time report readings. I am still playing with possibilities to get the wake time as low as possible and still get the readings. More to come in the next 10-15 minutes

Added after 21 [minutes]:

Here is my final setup:

Pin assignment from the web app:



Script with explanation:



Attached is the tar file you can drag and drop to create autoexec.bat.

EDIT: activate flags - 2, 7, 10, 21, 35 and 37. remove your device from HA and set it up for auto discovery again from config.



I will now test the battery life and post results when done.

Here is the original FW backup from that device.

There is a fix to lower the publish time down to 5 seconds, once approved I will upload the corrected autoexec script.

Fun fact, it is faster than original Tuya device by 3-8 seconds and battery life should be improved with this!

I think the battery life could be futher improved with new waitFor command, but it would make reconfiguration harder.
Sample usage:

I think the sample usage can be modified. We could put a DeepSleep command just after last publish (with a delay) and make device go to sleep just after state is published.

>>20544067

In fact even if your device is on constant power source, the sensibility of the sht and the design of this sensor made the temperature reading a little bit off (that's why you need to use sht calibration ...)
- beken heat
- wifi led to close to sensor
- sht on plain pcb
- enclosure does not make air circulate

To have not so high calibration i found that a deepsleep of 120sec is enough to permit the bk to cool down and a wifiled_n to avoid too much light on night

Indeed, this is what happens as soon as you dispense with DeepSleep:

This is my log of battery powered sensor with DeepSleep enabled for last 36 hours.



May I disagree about DeepSleep statements and precision?

Do consider the cost and the use case for this device. It is a battery powered VERY cheep device with descent precision but both of you are using it very differently than most users would. Of course that doesn't mean you can't customize it to your needs so I understand the position both of you are taking.

My setup is generic and "user friendly" for most of the other users that may come across this project and use the device with basic, almost out of the box experience.

Disclaimer - still waiting for battery usage tests to complete and optimize the script for that use.

I don't think I have expressed myself well.
I completely agree with the use of DeepSleep, whether power supply or batteries are used. Otherwise the measurements would be much more different from reality (as seen in the picture above).
DeepSleep to the power!

I've just got one as well:

I am working on automatic GPIO configuration:

OpenBeken flasher is now able to automatically get GPIO config for most of the devices, the I2C humidity sensor will be also supported soon.

Added after 51 [seconds]:

Here is extracted Tuya config:

I can see I2C pins and battery voltages.

p.kaczmarek2 wrote:

I think the sample usage can be modified. We could put a DeepSleep command just after last publish (with a delay) and make device go to sleep just after state is published.

Maybe someone can tell if there has been any progress with deep sleep and battery optimization with this sensor setup? I also have a small problem, I have version 1.15.581 but for some reason the OTA update for me to the latest version is no longer possible. The web application says starting OTA and then nothing happens, (same time in the main window it shows "OTA In Progress. Downloaded: 0 B Flashed: 06AFFFh") after really long time it says rebooting but wakes up in safe mode, still with the old version and all settings wiped clean.
thanks

minusync wrote:

p.kaczmarek2 wrote:

I think the sample usage can be modified. We could put a DeepSleep command just after last publish (with a delay) and make device go to sleep just after state is published.

Maybe someone can tell if there has been any progress with this sensor setup? I also have a small problem, I have version 1.15.581 but for some reason the OTA update to the latest version is no longer possible. The web application says starting OTA and then nothing happens, or after really long time it says rebooting but wakes up in safe mode, still with the old version and all settings wiped clean.
thanks

I have one such sensor and my solution was to flash it with BK Flasher to a new version (not via OTA), you can save the config and autoexec if you have them and reapply that after updating the FW.

DeDaMrAz wrote:

I have one such sensor and my solution was to flash it with BK Flasher to a new version (not via OTA), you can save the config and autoexec if you have them and reapply that after updating the FW.

Sure I can try (at least I hope) that, but fiddling with solder and wires again is really annoying. Also, there is always the possibility to screw something up with solder. OTA worked for me before and I did hope that maybe simply something with the procedure has changed

minusync wrote:

DeDaMrAz wrote:

I have one such sensor and my solution was to flash it with BK Flasher to a new version (not via OTA), you can save the config and autoexec if you have them and reapply that after updating the FW.

Sure I can try (at least I hope) that, but fiddling with solder and wires again is really annoying. Also, there is always the possibility to screw something up with solder. OTA worked for me before and I did hope that maybe simply something with the procedure has changed

Hacking a device can be tedious OTA was fixed sometime in version 1.17 and your device FW is really old. Give it a try and take you time.

I did manage to update the software to the latest. I also changed the autoexec file to the latest version as was suggested below. For some reason, it now shows with brand new batterys, battery 0 and voltage -1.18. With the previous variant, the battery information worked and I managed to use the sensor up to 1V per battery.
I would also like to ask whether there are any developments regarding the mentioned possibility of bringing the publish time down to 5 seconds.

DeDaMrAz wrote:

Pin assignment from the web app:

Code: text Expand Select all Copy to clipboard  "pins": {
    "7": "SHT3X_SCK;0",
    "8": "SHT3X_SDA;2",
    "17": "BAT_Relay;5",
    "20": "Btn;6",
    "23": "BAT_ADC;4",
    "26": "WifiLED;1"
  },

Script with explanation:

Code: text Expand Select all Copy to clipboard//2.02 is Vdevider, measure and adjust to your device, 2000 is Vmin the device will still work I don't recomend changing bellow that value
Battery_Setup 2000 3000 2.02 2400 4096
//measure batt every 2s
Battery_cycle 2
//calibrate SHT sensor with -4'C and +3% for humidity in this case
SHT_Calibrate -4 3
//measure temp and humidity every 2 seconds
SHT_cycle 2
//hold button on P20 to get into safe mode
addEventHandler OnHold 20 SafeMode 
//broadcast as fast as possible for all the channels 
mqtt_broadcastInterval 1
mqtt_broadcastItemsPerSec 5
//this delay is the actual awake time for the sensor, increase it if you don't get correct readings to >30s
delay_s 25
//this is the interval of device sleep in seconds increase value to preserve batt
DeepSleep 900

Attached is the tar file you can drag and drop to create autoexec.bat.

minusync wrote:

I would also like to ask whether there are any developments regarding the mentioned possibility of bringing the publish time down to 5 seconds.

Not sure what you meant by this? Do you need device to publish 5 seconds after awaking from deep sleep or something else?

minusync wrote:

For some reason, it now shows with brand new batterys, battery 0 and voltage -1.18

Check you voltage divider and parameters and adapt to your case, the syntax is explained here - https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md



Added after 12 [minutes]:

Sorry, I see now what the question for publish time is

In general several setting have to be changed in order for this to work:

- Flag 37 is to be enabled - Flag 37 - [WiFi] Quick connect to WiFi on reboot (TODO: check if it works for you and report on github)
- static IP address has to be set
- and Uptime seconds required to mark boot as ok: to be set to 3

However this is dependent on WiFI signal strength/quality and on some occasions can lead to no broadcasts at all due to packet loss or improper boot - so use it more as for testing and not as a 100% working solution (!!!)

DeDaMrAz wrote:

- Flag 37 is to be enabled - Flag 37 - [WiFi] Quick connect to WiFi on reboot (TODO: check if it works for you and report on github)
- static IP address has to be set
- and Uptime seconds required to mark boot as ok: to be set to 3

In that case I basically have it already done. Only thing to correct is boot timing from 5 to 3

Has anyone ever thought of a way to force the sensor into a "test" mode somehow? I remember it being discussed somewhere, but possibly in the context of some other sensor. If currently, autoexec is already running, it is almost impossible to do anything with the sensor without before completely removing the settings - there is simply not enough uptime for that.

@minusync

You can use this command in your autoexec to utilize the button on the device to go into safe mode.

DeDaMrAz wrote:

ou can use this command in your autoexec to utilize the button on the device to go into safe mode.

Code: text Expand Select all Copy to clipboardaddEventHandler OnHold 10 SafeMode

Originally this line was OnHold 20 SafeMode
Which one is correct at the moment?

Moderated By p.kaczmarek:

It should be SafeMode without arguments. The number after OnHold is GPIO index where the button is. I have edited this post.

Anyway, safe mode is not truly test mode. In safe mode, I need to connect to the sensor's local network, which means I can not same time use web application, so I can't do much about managing sensor software. True test mode should simply somehow switch off all sleep functions so I would have all access and functionality

I looked at the battery syntax but are there some rules to set v_divider or is it more like trial and error. I managed with a negative setup (-2.3) to get to the positive 1.34mV value but the battery % is still zero.
thanks

Both are correct, different intervals only, I suggest the shorter one as you are aiming at very small awake time. Again familiarize with the commands you can use in autoexec.bat file and adapt them to your needs. Everybody has it's own needs and use cases and it would be impossible to fulfill them individually.

addEventHandler OnClick can be utilized for that "test" function you would like to have.

Maybe @p.kaczmarek2 can shine some light on this for you?

Added after 8 [minutes]:

minusync wrote:

Anyway, safe mode is not truly test mode. In safe mode, I need to connect to the sensor's local network, which means I can not same time use web application,...

Once you connect to the device in safe mode simply press exit safe mode and you will have access to web app, drivers will not load and autoexec will not be executed. You can than change the setup and autoexec and then reboot the device to get to normal/working state.

Added after 1 [minutes]:

minusync wrote:

I looked at the battery syntax but are there some rules to set v_divider or is it more like trial and error. I managed with a negative setup (-2.3) to get to the positive 1.34mV value but the battery % is still zero.

v_divider is device dependent, usual value is 2 but it varies wildly depending on the manufacturer - so I guess it is trial and error for you.

Thanks, I got things working for the most part. How does measuring every 2 seconds affect battery consumption? If I update the results once an hour, does the change in the measurement interval also have any benefit in terms of battery life?

If anyone has a good idea why the battery is 0% while the voltage is 2.6, let me know. Maybe the battery calculator doesn't like v_divider negative numbers?

minusync wrote:

Thanks, I got things working for the most part. How does measuring every 2 seconds affect battery consumption? If I update the results once an hour, does the change in the measurement interval also have any benefit in terms of battery life?

Battery_cycle 2 means that voltage is being sampled or measured every 2 seconds, it should not have a detrimental effect on battery life (further testing is needed of course) and 2 seconds was chosen to have a chance of getting the correct value due to time constraint and quick sleep time.

Can you post your autoexec file and a picture of your device so we can try to guide you somehow to the solution for your batt problems?

I can check your config in simulator to see if it works correctly.

By the way, on some devices you can extract battery voltages this way:
https://www.youtube.com/watch?v=WunlqIMAdgw&
but if I remember correctly, I tried that for the dump from this topic and in this case it's not possible - Tuya didn't use JSON for this device, they just hardcoded settings

DeDaMrAz wrote:

Can you post your autoexec file and a picture of your device so we can try to guide you somehow to the solution for your batt problems?

Hi. My autoexec is exactly as your latest suggested. (copy paste) The only difference is my v_divider is -4.45 (Battery_Setup 2000 3000 -4.45 2400 4096) and deepsleep 3600
My device is exactly as described in the first post of this thread.
thanks