[BK7231N CBU] Generic Temperature and Humidity Sensor

Hello,

Normal IOR_BAT_ADC and IOR_BAT_RELAY is available on last releases. you just need to map you ADC to BAT_ADC and Relay to BAT_Relay in module.

i'll ask for a merge to correct auto_config on webapp.

https://github.com/OpenBekenIOT/webapp/pull/45

"7": "SHT3X_SCK;0",
"8": "SHT3X_SDA;2,3",
"16": "dInput;8",
"17": "BAT_Relay;5",
"20": "Btn;6",
"23": "BAT_ADC;4",
"26": "WifiLED;0"

for the delay, i tested that and seems fine without the delay it works flawlessly.

Thank you, it's merged now.

I think it's now time to look into similar I2C sensors from Aliexpress. Do you have any idea what else might be popular?

Hum, i buy some i2c sensor for air quality the sgp30 and will try to add them to this one. (With external usb alim cause battery is really troublesome ....)

But i suppose air quality sensor, maybe some detection sensor.....

>>20465075

Does autoexec.bat still need the channel set commands from earlier posts i.e:

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

I have got this working fine using DeepSleep but temperature and humidity don't seem to arrive in Home Assistant, only the binary sensors and battery sensors

I figure I am missing something obvious but would love it if someone could point me in the right direction.

Hello,

No it's not needed. You have temp and humidity showed correctly on web ui ?

Try to launch a scheduleHAdiscovery again

Thanks for the quick reply!

My autoexec.bat is simply:

PowerSave
startDriver SHT3X
startDriver Battery
Battery_Setup 2000 3000 2.29
scheduleHADiscovery
delay_s 90
DeepSleep 300

The webui shows correctly:



The module is set as follows:



But deleting the device from Home Assistant and repeated auto discovers doesn't seem to cause temperature and humidity to display. Any ideas?

In latest releases you don't need to start batt and sht driver. If pin is assign it will start automatically.

Maybe there's a bug .... I will try to reset my device today to check that.

Something strange is that you should not have all the energy counter on discovery

It should be only this :

Maybe you are missing "broadcast self state on mqtt connect" or something flag

Have confirmed that the flag is set. Logs are below in case they help:

Info:GEN:dhcp=0 ip=10.0.10.67 gate=XXXX mask=255.255.255.0 mac=XXXX
Info:GEN:sta: 1, softap: 0, b/g/n
Info:GEN:sta:rssi=-49,ssid=XXXX,bssid=1c:61:b4:bc:d6:08 ,channel=6,cipher_type:CCMP
Info:MAIN:Time 81, idle 72984/s, free 66352, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 POWERSAVE
Info:GEN:CHANNEL_Set channel 2 has changed to 251 (flags 0)

Info:MQTT:Channel has changed! Publishing 251 to channel 2
Info:MQTT:Publishing val 251 to obkFF8E089A/2/get retain=0
Info:GEN:No change in channel 3 (still set to 56) - ignoring

Info:SENSOR:SHT3X_Measure: Temperature:25.1C Humidity:56%
Info:DRV:DRV_BATTERY : Measure Battery volt en perc
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkFF8E089A/2/get
Info:MQTT:MQTT in topic obkFF8E089A/2/get
Info:GEN:CHANNEL_Set channel 5 has changed to 1 (flags 0)

Info:MQTT:Channel has changed! Publishing 1 to channel 5
Info:MQTT:MQTT topic not handled: obkFF8E089A/2/get
Info:MQTT:Publishing val 1 to obkFF8E089A/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 obkFF8E089A/5/get retain=0
Info:MQTT:Publishing val 2432 to obkFF8E089A/voltage/get retain=0
Info:MQTT:Publishing val 43 to obkFF8E089A/battery/get retain=0
Info:DRV:DRV_BATTERY : battery voltage : 2432.677734 and percentage 43.267776%
Info:MAIN:Time 82, idle 94054/s, free 54360, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38 POWERSAVE
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkFF8E089A/5/get
Info:MQTT:MQTT in topic obkFF8E089A/5/get
Info:MQTT:MQTT topic not handled: obkFF8E089A/5/get
Info:MQTT:channelSet NOT 'set'
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkFF8E089A/5/get
Info:MQTT:MQTT in topic obkFF8E089A/5/get
Info:MQTT:MQTT topic not handled: obkFF8E089A/5/get
Info:MQTT:channelSet NOT 'set'
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkFF8E089A/voltage/get
Info:MQTT:MQTT in topic obkFF8E089A/voltage/get
Info:MQTT:MQTT topic not handled: obkFF8E089A/voltage/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkFF8E089A/battery/get
Info:MQTT:MQTT in topic obkFF8E089A/battery/get
Info:MQTT:MQTT topic not handled: obkFF8E089A/battery/get
Info:MQTT:channelSet NOT 'set'
Info:MQTT:channelSet NOT 'set'
Info:MQTT:channelSet NOT 'set'
Info:MAIN:Time 83, idle 54380/s, free 66352, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 POWERSAVE
Info:MAIN:Time 84, idle 74945/s, free 66136, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38 POWERSAVE
Info:MAIN:Time 85, idle 83836/s, free 66352, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 POWERSAVE
Info:MAIN:Time 86, idle 77097/s, free 66352, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 POWERSAVE
Info:MAIN:Time 87, idle 78421/s, free 66352, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 POWERSAVE
Info:MAIN:Time 88, idle 74933/s, free 66352, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 POWERSAVE

Based on your logs, seems like information is pushed correctly to Broker.

but the logs does not include Discovery.

you can put log on debug for HASS and launch a schedule discovery ?

on which version of the firmrware your on ?

Edit : ok i found the issue @p.kaczmarek2 :

Quote:

#define IS_PIN_TEMP_HUM_SENSOR_ROLE(role) (((role)==IOR_SHT3X_DAT) || ((role)==IOR_CHT8305_DAT))

but the name of the pin has been switch to SDA since your standardisation of I2C.

i will push the modification. if you can merge it

Forget it ..... @akkipro i think you had an old firmware with bad pin name on it (Or store one is not correct). you can try to update and change the pin for SHT3X :

SHT3X_SDA => should be SHT3X_DAT
SHT3X_SDC => should be SHT3X_CLK

Just updated to version 1.15.576 to check this but the old names still appear:



Sorry if there is something I am missing?

No your right .... just check on web interface it's still the old name .... but it should not be an issue :



ok i will try to do some test on my side

Why are there two temperature channels?

Quote:

@akkipro please perform some simple tests with console commands, for example, do

and see if the obkDev/myTest/get value 123 is received by HA

Ok i have done some test.

i have reset the firmware on my device with the last and delete the Home Assistant. and i have the same issue has you.

battery not detected correctly and temp/hum not pushed by discovery ......

It seems we need to add more self-tests of automatic discovery to self-tests system on WIndows

Added after 7 [minutes]:

@dheenhasty I found at least one bug, why was Battery included in DRV_IsMeasuringPower ? I will push fix soon

yes just saw that it's an issue a will push a correction ... it broke the discovery .....

i'm currently testing a correction

Edit : https://github.com/openshwprojects/OpenBK7231T_App/pull/721

test on HASS ok and and Tasmota Admin Ok too.

I add put by mistake the battery in measuring power for the tasmota json file ..... and forget to create a separate void for battery. it's corrected and more clean now

By changing that it bring back temp and humdity .... that is really strange. i think of another bug in Discovery when you measure power.

Sorry @dheenhasty , I haven't seen your change. Please sync your changes in PR if something is missing.

I have added automatic self test for battery:
https://github.com/openshwprojects/OpenBK7231...mmit/ac263958dd05493d66228aaa51922c595cd861d5

Seems like you already done the job :p

@akkipro you can test the last firmware and confirm it works on your side => 1.15.579

in you autoexec you don't need to start battery and sht Driver. and your parameter is the default one. so something like that :

Quote:

PowerSave
scheduleHADiscovery
delay_s 60
DeepSleep 1800

should work

I have added some more self testing for BL0942 and SHT30 auto discoveries (very basic and crude tests, but they will at least detect if discovery is broken like it was earlier today):
https://github.com/openshwprojects/OpenBK7231...mmit/e025a13b177e6354edd27f1727836513a3d51beb

Thanks - confirming that its now working fine on the latest firmware. Thanks for the bug fixes!

@dheenhasty we need more automatic tests for the JSON and MQTT features

The deep sleep setting is nice, but it makes using the sensor in HA more or less pointless. The side-effect of deep sleep is that 90% of the time it shows now sensor unavailable instead of the actual sensor reading. In fact, it is possible to see the reading in HA only if you randomly look at the exact moment when the sensor is on. I don't have much experience with mqtt, but would it be possible to improve this situation by adding the mqtt payload "retain= True" flag? As I understand it, the retained message flag should keep the information in mqtt broker active until new data is received.

Also, thought for p.kaczmarek2, shouldn't it be nice to create a rule or at least a good practice, that all teardown initiators of the device, place in the first post, when the device is ready into operation, the exact step-by-step instructions for the users on how to do this with a particular device, so that sometimes they don't have to review hundreds of posts to do that?

minusync wrote:

The side-effect of deep sleep is that 90% of the time it shows now sensor unavailable instead of the actual sensor reading.

You are incorrect. This will happen only if you publish availability topic during HASS discovery. It will not happen if this topic is not set. You just most likely have to remove sensor from HA and then pair it again after Door Sensor driver is started, so it knows that is using Deep Sleep mode and pairs with HA correctly.
EDIT: Wait, you are referring to the humidity sensor... then procedure is a bit different
See: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/flags.md
You need flag 35 before HASS discovery.


Regarding first post - it's a good idea, but we also have a "help" topics like this and they sometime can become lengthy. Is there anyone who wants to make a clear, now final, description how to setup this sensor?

yes the flag 35 for avty publishing for sensor.

i'm not quite satisfied with this sensor, it's really consuming a lot of battery. event in deep sleep . and it's not due to OpenBeken you had some consumption but i have the same sensor with original firmware and it consume the same .....except that with OBK you can set your battery level lower

so i decided to do a little bit of tuning so an am117 later and usb connector :



i decided to desolder the CBU from mainboard cause now that i'm on usb i want it to retrieve temp more often and no deepsleep. so the board will heat if CBU is on it . (it's a conception issue first ..... SHT should be isolate from the mainboard. )

next step is adding more sensor to it (CO2 and UV) and do a proper case 3D printed

Don't forget that we have a DIY section:
https://www.elektroda.com/rtvforum/forum513.html
With some strange projects submitted by me few years ago:
https://www.elektroda.com/rtvforum/topic3789324.html

Why do you think that the sensor is responsible for current consumption? Have you tried to do measurement?

it's not the sensor who is responsible of the consumption

i just think Beken with wifi is not made for 2AA battery .......

with and usb and ampmetter i got 5v with 70 mA so an average consumption of 350mw and it's within the low spec of the CBU datasheet with wifi on. it's pretty good, it's just not suited for battery. Zigbee is clearly better

I just noticed that this sensor is consuming an insane amount of power. This is definitely not the way it should be. If the battery wears out in a week, it makes the battery sensor useless. For normal use, this time should be at least tenfold.
I don't know how Tuya does it, but here are some thoughts that might be worth considering. I have no idea if any of this is possible to realize at all so they are just thoughts.
First of all, it is obviously beneficial to reduce the working time. One option is to extend the overall rest time, another option would be to see what exactly the sensor does when it starts. Right now it seems to me that it takes at least a minute for the data to transfer when it wakes up - although I have no way of measuring it exactly. This time seems too long. When I look at the HA log, it shows that in one session the sensor turns on and off as many as five times before going to sleep. It seems kind of excessive. What for all this? Would it have any effect if the temperature data were transmitted a little more frequently, but other data only every few hours?
Is it possible to reduce the power of the transmitter? Less power = less energy consumption.
The CBU has also a Bluetooth transmitter. When the sensor starts, does it also start the Bluetooth transmitter along with the wifi (even if it doesn't transmit anything from there) If this should be true, it will probably at least double the energy consumption immediately?

In fact, your right, consumption is an issue.

That's why tuya with the default firmware wake up device every hour. For around 45 seconds.

You can do the same with obk :

Under général/flags =>
- Tick flag 37 for quick connect
- change value of boot time to 10.
Then on your script :
- change the delay to 45 seconds (could be less but mqtt might need more time)
- deepsleep for 3600.

And close the web pages if your on logs

You should have the same behavior has tuya.
Equation is pretty simple :
AAA battery => 800mAh usable by cbu ( below the dc behave strangely)
Average usage=> 70mAh
So roughly 11 hours of constant usage in stock.
So with param upthere =>
11 x 3600 / (10 + 45 )=> you have 720 runs
So arround 30 days if we have one run per hour

With my test script =>
11 x 3600 / ( 30 + 60 ) => 440 runs
We count 2 runs per hour do ~9 days.

No that powersave is activated by default you have all power consumption optimisation.

Another option is to use pindeepsleep with the alert mode of the sht sensor (for climate in hass) the cbu will wake up depending on you define high and low temperature. You have the detail to implement that in tutorial section of the sht.

But even with that my other sensor with tuya firmware last 3 or 4 weeks....

It's sad cause the sht sensor is pretty cool ! And the cbu also. That's why i decided to tune it a little bit

dheenhasty wrote:

change the delay to 45 seconds (could be less but mqtt might need more time)

As I mentioned, one session of the sensor seems to be too much in terms of time. 45 sec, the sensor transmits the same data about five times! I could shorten this time by 20 seconds, which according to your calculations would immediately double the life of the battery, but then you can never be sure if everything will still go through. For example, looking at the logs, it seems to me that the first attempt to connect to mqtt almost always fails with error 4. A much more elegant solution would be not to depend on the time limit but to disconnect immediately when the mqtt data has actually been transmitted. If such a solution were possible, it would immediately mean at least doubling the life of the battery. Maybe more.
Can someone tell me what the 5 and 8 in the sensor data mean? Thanks.

Sorry for the delay in answer was kind a busy week.

i understand your point. but if delay is too short, in case of issue or need to update thru OTA, the delay might be not enough.
to implement this kind of improvement we need to secure the access to sensor. for example define as a prerequiste a reset button. and if you hold it it will deactivate the deep sleep until the next restart.

the 5 is the alert pin for the SHT take a look at the tutorial part. and the 8 is the relay to divide the voltage input on ADC. basically ADC can only detecte voltage up to 2,4V. and battery can be more than that. so tuya implement an Relay to divide the input voltage to be able to read exactly the level of battery.

Added after 2 [hours] 2 [minutes]:

@p.kaczmarek2 > i'm trying to adding another sensor to this one (another Sensirion one the SGP for air quality) but seems like your implementation of the softi2c only take 1 sensor in account the object seems global. am i wrong ?

if so i need to start SHT Driver / measure / stop it and the start the SGP Sensor / take measure and stop it.

EDIT : Forget it i found the solution and it works flawlessly with your modification