Since the CB2S is working I will leave it as it is
For the chip on PCB you are correct I could use these pins... But.
Test pad P7 translates to P21/I2C1_SDA on pin 19
Test pad P6 translates to CEN on pin 21
I don't think the CEN pins is usable, correct?
Nope you can't, i was naively thinking that p6/p7 correspond to p06/p07 ....... -_- i suppose i overestimated the design of this board.
If you cannot use 2 free pwm you are screwed.....
i added all the alert mode mecanism for the SHT. so now we can use that to wake CBU from the pindeepsleep by adding a dinput to p16 for this sensor and setting all the Alert parameter as needed.
will try to propose a full autoexec.bat this week end with all mode included to save as much power as possible.
@dheenhasty good job, but can you also then create a separate topic here, with a proper name, explaining step by step how each command works, so we can link it from our repository? Posting this here in just a post would cause it to get easily lost for new users.
@ShadowLight30 Was thinking about your issue, but maybe you can just swap the TX2 with P7. cause i think the issue is mainly due to the chip trying to communicate thru TX2 and make the CLK goes wrong on the SHT. and P7 might be more stable for that.
Thanks in advance for all your work on this device, but I wanted to ask you if you see something strange in the configuration or something because when I integrate it into home assistant NaN appears in the temperature sensor and NaN in the humidity sensor and I do not know if it is because it does not detect anything or what happens. Maybe I have not understood correctly how to configure it, I am quite new to this.
You just miss a script to launch the sht driver and the measurement at startup.
You can find various example in this topic
To do so go to launch web app menu
Then > filesystem > create script > give it a name and open it to edit
Here's a sample example to test it will send measurement every 5min :
But it will drain the battery so you will need to use deepsleep if you want your device to be off for a certain time.
As i see your battery is already low the adc is lower than 3600 (so arround 1v per battery)
The command for the battery management will arrive soon. Once everything is merged i will publish here 2 script to cover different use case for the CBU.
@dheenhasty , referring to our previous discussion with a friend from Ukraine, who was converting a smart LED bulb to temperature/humiditry sensor, please change the code so the SHT30 does automatic measurements every 10 or so seconds by default, and add a command to override. Something like SHT_Auto 1/0.
The SHT30 stuff should be able to get humditiy/temperature data without writing a single line of code (script) for non-technical users.
i was thinking of adding a detection of button push to cancel the deep sleep on deepsleep rtc script.... 60 sec seems to short to access frontend
next evolution could be adding some sort of command (slider, button) for managing the Alert mode and Heater.....
Edit
@p.kaczmarek2 : i encounter something strange, the deepsleep and pindeepsleep work really well on command line and on script. but if i use them in autoexec.bat file it's seems like it's not working.
for example i create a file myroutine with one of the script up there and put it on startupcommand. no problem.
but if i pass through creating autoexec.bat (who is executed automatically) and put script it crash ..... the delay_s is not taken in account. so it goes deepsleep too quick and go in failsafe mode.
issue is that since it's the autoexec.bat it's a pain to remove that in failsafe (lfs not accessible offline) so only method is to reflash it with uart. or thru OTA on Offline webapp (but you need to have a local http server.... so not very easy for simple user )
think i found the issue, it that autoexec.bat is called by an exec in user_main instead of a startScript. :
Quote:
// NOTE: this will try to read autoexec.bat,
// so ALL commands expected in autoexec.bat should have been registered by now...
CMD_ExecuteCommand(CFG_GetShortStartupCommand(), COMMAND_FLAG_SOURCE_SCRIPT);
CMD_ExecuteCommand("exec autoexec.bat", COMMAND_FLAG_SOURCE_SCRIPT);
if you're ok with that i will propose a change in my merge :
Quote:
// NOTE: this will try to read autoexec.bat,
// so ALL commands expected in autoexec.bat should have been registered by now...
CMD_ExecuteCommand(CFG_GetShortStartupCommand(), COMMAND_FLAG_SOURCE_SCRIPT);
CMD_ExecuteCommand("startScript autoexec.bat", COMMAND_FLAG_SOURCE_SCRIPT);
You are 100% correct. Autoexec.bat is run in place while the "startScript" is something totally different. I am aware about that and I've been thinking about doing that change for last few weeks.
The only problem is that I am not sure if it's safe to do this. Have you done enough test to know that won't break anything?
The only difference I can think of is that "startScript" will run the script next frame (next tick) and "exec" runs it in place, but does it matter in that case?
Maybe we can just do this change and in worst case.... wait for users to report potential problems.
Still, the basic idea is the same as mine.
Ok, so.... let's try it and see how it goes for our users?
according to your last remark on the no script for beginner, i was thinking of bringing all the capabilities of this sensor to the front and HASS (mqtt ).
so no problem for having a (get/set) for alert with slider for low temp / high temp and low hum / high hum
A parameter for the measure time / Sleep time could be good too.
Auto start of the sht driver if pin is set.
the mechanism could be included in driver easily
=> if alert mode is set => measurePer => publish => pindeepsleep
=> if alert mode is unset => measure => publish => deepsleep rtc
but there's something that tickle me a little bit. the original firmware wake regularly and on button ..... so i'm not sure they used the deepsleep mode (this will explain why the deepsleep implementation in there SDK was a mess) but instead they just shutdown the wifi and restart it when needed. according to documentation CBU consumption is around ~6ma without the wifi and 100ma with it. we are far from the 6uA in deep sleep but could be enough for 2 AA to handle 15 or 20 day.
I just realized, is autostart missing for SHT30? I will add this right away.
Added after 2 [minutes]:
I am testing SHT30 with RGBCW led conjunction in Windows simulator, SHT30 values are hardcoded.
Dheen you might want to round the number of zeroes after SHT read results
Sort of habit i corrected the data first (who doesn't prevent me to change the visualisation also).
Anyway, with the flag i detected a small bug on cfg_generic page, the current value doesn't take in account the 32 upper bit.
it's just visualisation, but don't know how you want to handle that in future (if you want to push that thru template, or do a backup)
Hmm you can fix it if you want. There is a 64-bit word support in our sprintf, or is there? We are using not the official sprintf, but the lightweight replacement, so it might be worth checking.
We already have 64 bit flags in config structure.
Basically, pins to indicate ADC relying on battery and Rel for the vdivider. so we can unable an auto start of the driver.
And taking a look at majority of tuya sensor seems like it's 2AA one, so i suppose by default 2000mv => 3000mv is good with a vdivider of 2.29 just like the 5 one i got.
Now it may be a good time to look into the Tasmota JSON syntax update, so apps like Tasmota Control from Google Play can get sensor values.
Would you like to help, @dheenhasty ?
Get that mobile app from Google Play.
Then look here:
https://www.elektroda.com/rtvforum/topic3789324.html It should be possible to update our json_interface.c to use the same mechanism to check for temperature channel and add a temperature result to json, maybe same for humidity....
That we can get measurement results in Tasmota Control app.
Are you 100% sure that it works with Tasmota Control and ioBroker?
You seem to have added a JSON block with SHT3X name:
The problem is, I don't know if this header is recognized by those apps.
It is very possible that we will need to fake a DS18B20 header just to make sure that apps are able to get our measurement results. I don't know at the moment.
Yes you had to indicate the type of sensor, seems like a free string.
I tested it works with Tasmota Controle and tasmoadmin too ( just got an issue with cmd SensorRetain who is not implemented in your code, i will take a look later)
Now i'm struggling with the battery and passing correct value
Edit : SensorRetain corrected, so now json is fully compliant with tasmoadmin. But in read only mode
After reading the code, I think it was intended to also support the battery relay pin? However actually I cant get it work - I think because IOR_BAT_Relay is used for that, however it can't be configured right now, or am I wrong (also IOR_BAT_ADC, however this seems to work with the normal ADC)? OR am I wrong?
Other point which might be relevant: I think in Batt_Measure() there is no delay between switching the bat relay pin and reading the ADC. Maybe that this might cause incorrect measurements?
The discussion centers on a generic WiFi temperature and humidity sensor based on the BK7231N CBU module with an SHT30 DIAS7M sensor, purchased from AliExpress. Key technical challenges include implementing effective power-saving strategies, particularly deep sleep modes, to extend battery life in this battery-powered device. Contributors explored the device's pinout, I2C communication (notably software I2C on pins P7 and P8), and firmware modifications using the OpenBeken SDK. Deep sleep implementation on BK7231N shows partial success: the device enters deep sleep and reboots after a set time but may reboot unexpectedly or cause boot loops if deep sleep is triggered too early in the startup script. PowerSave commands reduce power consumption but are insufficient alone; deep sleep with wake-up via GPIO or timer is essential. Battery voltage measurement and reporting were added, with calibration and percentage calculations to monitor battery health and trigger alerts on low voltage. The SHT30 sensor driver was enhanced with commands for calibration, single and periodic measurements, heater control, and alert modes that can wake the device from pindeepsleep. Scripts for automated measurement, battery management, and deep sleep cycles were developed and refined. Issues with script execution timing, startup command behavior, and SDK differences between BK7231N (N) and BK7231T (T) platforms were discussed. GPIO wake-up works on BK7231T but was initially unavailable on BK7231N until recent SDK updates. The MOSFET on the board likely provides reverse polarity protection. Integration with Home Assistant and Tasmota Control via MQTT and JSON was addressed, including sensor data formatting and auto-discovery. Challenges remain with battery-induced firmware corruption below 2V, requiring UART reflashing. Relay-based devices using CB2S boards with BK7231N were also discussed, highlighting pin assignment constraints and I2C communication issues. Overall, the community is actively developing firmware and scripts to enable local control, power optimization, and reliable sensor data reporting for these generic BK7231N-based temperature and humidity sensors. Summary generated by the language model.
![[BK7231N CBU] Generic Temperature and Humidity Sensor](https://obrazki.elektroda.pl/2846070300_1676933902.png "[BK7231N CBU] Generic Temperature and Humidity Sensor")
![[BK7231N CBU] Generic Temperature and Humidity Sensor](https://obrazki.elektroda.pl/4535726600_1676933901.png "[BK7231N CBU] Generic Temperature and Humidity Sensor")
![[BK7231N CBU] Generic Temperature and Humidity Sensor](https://obrazki.elektroda.pl/6638910600_1676933901.png "[BK7231N CBU] Generic Temperature and Humidity Sensor")
but could be enough for 2 AA to handle 15 or 20 day.
![[BK7231N CBU] Generic Temperature and Humidity Sensor](https://obrazki.elektroda.pl/7149778300_1677398768.png "[BK7231N CBU] Generic Temperature and Humidity Sensor")
![[BK7231N CBU] Generic Temperature and Humidity Sensor](https://obrazki.elektroda.pl/7469162300_1677399003.png "[BK7231N CBU] Generic Temperature and Humidity Sensor")
![[BK7231N CBU] Generic Temperature and Humidity Sensor](https://obrazki.elektroda.pl/7030952800_1677442256.png "[BK7231N CBU] Generic Temperature and Humidity Sensor")
