I2c temp/hum sensor, any pointers please?

[35nine]

Hi. I've managed to flash an Arlec PCTH01HA socket, it's a Bunnings special in Aus with CB3S module.

It has a external i2c temp/hum module, chip is marked CHT8305. Any pointers how I can go about accessing that data?

Found this http://sensylink.com/a/products/lm2/CHT8305.html and https://github.com/sensylink/CHT8305 but that's where currently am. Thanks very much

[openshwprojects]

We haven't seen this device yet, but we can add support for that soon.

The first question would be here is the sensor connected? To hardware I2C port of BK or to a non-I2C pins?

Can you create a short teardown with photos, screenshots from where to buy, information which pin is connected where, how to flash, etc, and post it to our database: https://openbekeniot.github.io/webapp/devicesList.html ?

[monkeyatcomputer]

I have one of these too and have been looking at converting to OpenBK along with other Arlec smart switches, DETA outdoor power points and DETA motion sensor.

A teardown showing how you got inside would be very useful.

[ByteMangler]

Us Aussies must be bored! I grabbed a PCHT01HA from my last trip to Bunnings and was looking at writing code to add it to OpenBK. This is what I've found: Module: Tuya CB3S. BK7231N P8 Relay P7 PB P6 led P9 SCL P14 SDA

ADC3/P23 BL0937SEL P26 BL0937CF1 P24 BL0937CF

I haven't identified the temp/hum sensor but I sniffed the i2c comms. The 7bit device address is 0x40. The sequence seems to write 0 which looks like it starts the conversion. The next transaction some 10's milliseconds later reads 4 values. delay. Rinse and repeat. The values I got were: 0x65 0xbc 0x76 0x78. The first two bytes are the temperature. I think the conversion is value/65536 165 - 40. Next two bytes are humidity. value/65536 100.

The method of opening is to run a spudger along the seams. The case is either welded or glued but it doesn't take much effort to break the weld.

[35nine]

I'll post a few pics in the teardown next, no worries.

edit, done: https://www.elektroda.com/rtvforum/viewtopic.php?p=20371956#20371956

Agreed with ByteMangler comments regards spudger, my case looked to be welded in just corners, few gentle whacks with rubber mallet helped. If you're pretty slow/patient, the case takes no damage at all, listen for the cracking as the spudger goes along and go slow.

Power values - making some progress, will put in teardown.

Be great to get the temp hum data also, thanks again

[ByteMangler]

@35nine - good catch with the part# for the sensor. I'd not heard of the CHT8305 before, so I searched the usual suspects and came up empty. Of course, once one knows the part# and does a Google you get a heap of hits. I clearly don't spend enough time in Arduino land.

My power readings seem to be stable, although I've only done basic testing to see the values are half sensible - I've not verified them with my Fluke. There is a small offset with the current value.

According to it, my 3d printer pulls around 83W whilst printing and 9W whilst idling. This seems reasonable.

Note that the pin ADC3/P23 is set to BL0937SEL - your writeup omits this.

[35nine]

Hey, many thanks, in my reading around on this, I missed the need for the 3rd pin define. Added ADC3 now and yep, stable as. Cheers mate, I'll edit my teardown to reflect. Only the i2c remains the thing to crack, hopefully openshwprojects will have a gander when time. Cheers all

[ByteMangler]

I'm having a look at it at the moment. Reading through the app code to get a feel for how it all hangs together.

I haven't been able to find what the official I2C pins are. Seems there is two I2C interfaces.

[openshwprojects]

I2C info here in post 2 : https://www.elektroda.com/rtvforum/viewtopic.php?p=20372131#20372131

[ByteMangler]

Yes, I came to the same conclusions with the I2C, so I've just run my first cut of a driver for this device.

Attached is a zip file with my dodgy code and changed files along with a OTA build. Hopefully some kind person will take my dodgy code and whip it into shape. The main issue is integration - I don't understand the structure of pin roles enough, so MQTT reports byte values for temp and humidity to the same tag.

Using the build in the zip file: configure P9 to CHT8305_SCK and P14 to CHT8305_SCL. enable the driver with the command: startServer CHT8305

temperature and humidity! No guarantees etc....

CHT8305_driver.zip

[openshwprojects]

Wow that is great, very good job, it really works? @ByteMangler ? I can help you improve it, are you interested? I can tell you how to get it better.

Why under same tag?

This is correct:

CHANNEL_Set(g_cfg.pins.channels[g_pin_clk], (int)(g_temp * 10), 0);
CHANNEL_Set(g_cfg.pins.channels2[g_pin_data], (int)(g_humid), 0);

EDIT: Wait, you are taking first channel from clk and second from data? That's a strange conversion. But it's up to debate from where we should take channel indices. And it should be documented.

you just set first channel to, for example, ch10 and second to ch11 and listen to obkdev/10/get and obkdev/11/get topics...

[35nine]

Hi both, first - really appreciate the help above. Seeing that code erupt from my question, makes me realise how little code I know - much respect to you.

May not be same spec but looks like dfrobot use a simillar spec sensor, CHT8305C. Anything in their code/lib to use? https://wiki.dfrobot.com/SKU_SEN0546_I2C_Temperature_and_Humidity_Sensor_Stainless_Steel_Shell

Second thought, we have the unit open. Code skills I don't got but soldering skills yes. Would it make life easier to undo their pin arrangement, re solder the sensor i2c lines to the chip hardware i2c pins instead? Haven't traced out yet, maybe some caps and resistors to factor in. Random thought, not to undermine above for sure, just chucking that idea?

I'll be up to try any code, will wait for any feelings on above first. Thanks

[openshwprojects]

From a quick glance, @ByteMangler did 100% job very well. There is no need for extra hackery.

My only concern would be that, if this device is true I2C, we could separate generic I2C functions and do not reimplement them again.

But.... @35nine you also have the very same sensor?

I will merge @ByteMangler code tomorrow and you will be able to check if it works

[ByteMangler]

@openshwprojects Most of the soft I2C code was lifted out of the SM2135 driver. I just added the readByte and readBytes functions. From what I could determine, the CHT8305 is standard I2C.

I'd agree that there would be some code savings to be had by separating out the soft I2C functions.

As I previously mentioned, I didn't quite understand the mechanism of roles etc - there's existing code to output the temp/hum for the DHT/SHT sensors, but I didn't dig deep enough to utilise it thus my strange hackery. I'm happy for you to do what you want with the code so that it fits into the overall architecture.

Along with @35nine, many thanks for creating this project. I know it takes an enormous amount of time and effort to get these projects up and running and this one seems to be getting some activity. The likes of Tasmota showed what you could cram into a smart lightbulb and this project carries on that tradition. I'm happy that I can make a small contribution.

Some time ago I hacked the Commodore VIC20 basic interpreter into Tasmota. Why?? Because i could!! I wired in the VIC20 i/o channel into the Tasmota command interpreter so you could have the VIC20 basic program do things with the lightbulb. It might be too big to fit into the BK7231. If you're interested, see my github.

@35nine, the zip file I posted has a build of the firmware you can try right now. No need for hardware mods. I had sniffed the I2C comms with the original firmware, so I had that info to work from. When you posted the actual sensor chip number, that was extra information to verify what I had sniffed. Turns out the original firmware uses a shortcut method to read the data that isn't entirely obvious from reading the datasheet. Had it not been for your post here, this might have been another one of my projects that would sit on the shelf for another day.

[openshwprojects]

@ByteMangler the idea is that you can set two channels for a pin. Those are linked channels. For DHT , there is a single pin for communication. And there are two channels to set. So the standard is that first channel will store temperature, second will store humidity. for I2C, there is a Data and a Clock pin, so it's kinda more messy, but we just would need to assume, that, let's say, first channel from DATA pin is temperature and second channel from DATA pin is a humidity. And of course document it, yes, we're still working on docs.

Regarding I2C - my idea was to create a generic "SoftSDA1","SoftSCL1" roles and let them support everything through the "drvi2c***" code but.... you did your driver so good and quickly that I think I will merge it for now and do a more advanced one later.

[openshwprojects]

@ByteMangler will you prepare a pull request with your updates or would you like me to add them myself?

[ByteMangler]

The code I provided needs a little love and attention applied to it, so I'm happy to have you do this. Besides, creating a pull request is somewhat alien to me at this juncture.

[openshwprojects]

I will push it in at most a hour, here you can set channel indices for temp and humid:

[ByteMangler]

if i configure the pin P14 (N/A) CHT8305_SDA 0 0, I get this via mqtt:

(b'smart_pwr_temp/0/get', b'37') (b'smart_pwr_temp/0/get', b'308') (b'smart_pwr_temp/0/get', b'37') (b'smart_pwr_temp/0/get', b'308') (b'smart_pwr_temp/0/get', b'37') (b'smart_pwr_temp/current/get', b'0.023715') (b'smart_pwr_temp/0/get', b'308') (b'smart_pwr_temp/0/get', b'37') (b'smart_pwr_temp/0/get', b'308') (b'smart_pwr_temp/0/get', b'37') (b'smart_pwr_temp/0/get', b'308') (b'smart_pwr_temp/0/get', b'37') (b'smart_pwr_temp/voltage/get', b'246.771087')

if i configure the pin P14 (N/A) CHT8305_SDA 0 1, I get this via mqtt:

(b'smart_pwr_temp/current/get', b'0.023715') (b'smart_pwr_temp/0/get', b'307') (b'smart_pwr_temp/0/get', b'308')

my expectation would be something like:

(b'smart_pwr_temp/current/get', b'0.023715') (b'smart_pwr_temp/temperature/get', b'307') (b'smart_pwr_temp/humidity/get', b'45')

An excerpt from the logs:

:GEN:No change in channel 1 (still set to 37) - ignoring

Info:SENSOR:DRV_CHT8304_readEnv: Temperature:30.839094C Humidity:37.463951% Info:MAIN:Time 300, idle 182622/s, free 74192, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38 Info:GEN:No change in channel 0 (still set to 308) - ignoring

Info:GEN:No change in channel 1 (still set to 37) - ignoring

Info:SENSOR:DRV_CHT8304_readEnv: Temperature:30.839094C Humidity:37.463951% Info:MAIN:Time 301, idle 178620/s, free 74496, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38 Info:GEN:No change in channel 0 (still set to 308) - ignoring

Info:GEN:No change in channel 1 (still set to 37) - ignoring

Info:SENSOR:DRV_CHT8304_readEnv: Temperature:30.839094C Humidity:37.463951% Info:MAIN:Time 302, idle 184634/s, free 74496, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38

note the b'"prefix is just micropython's addition.

firmware version is: "Build on Jan 10 2023 01:17:34 version 1.15.305"

[openshwprojects]

Here's small fix: https://github.com/openshwprojects/OpenBK7231T_App/commit/39d611ed20d22a80305d06c65304f40302978436 This is correct solution: we don't send aliased names yet, so you will get obkDev/1/get etc etc obkDev/2/get etc

[ByteMangler]

@openshwprojects again, many thanks for your efforts. I've had release 1.15.306 running for over 12 hours with no issues observed. I've got another device with a BME280 sensor for comparison and both units report similar values. For me, I can declare CHT8305 support is working.

[ByteMangler]

some things to consider: sampling temperature/humidity every second is probably overkill. What would be a more reasonable sample period? 30 seconds?

an option for always send mqtt data or only send on change (current implementation)? For graphing it can be easier having regular samples.

an option to scale/offset the readings?

[openshwprojects]

"an option for always send mqtt data or only send on change (current implementation)? For graphing it can be easier having regular samples." - broad ast self state every minute is in flags, the "minute" amount is confiruable i think

"an option to scale/offset the readings?" great idea! It could be done on channels level, so it would work for everything. Something like "setChannelDelta" and then MQTT broadcasts that value with delta?

"sampling temperature/humidity every second is probably overkill. What would be a more reasonable sample period? 30 seconds?" this could be done in many ways, but is it needed? We could make a drivers "one second tick" configurable or add a solution separately per-driver

[35nine]

Morning. Been away, this weekend shall sure test this out. Amazing work from both, to get this help from total strangers makes me appreciate the world out there, it's not all doom and gloom hey so thank you both.

I'd feel sampling once per min or so would be good. Again I've no programming basis/data, only a gut feeling to minimise any load on the chip?

Will report back once loaded and tested, looking forward to being free of the cloud and using the full spec of device!

[ByteMangler]

@35nine The old adage 'many hands make light work'!

@openshwprojects yeh, the trick is to come up with a mechanism that is universal without adding extra overhead. An idea that keeps re-appearing in my mind is something like a tiny virtual machine that implements the base features like spi, i2c, mqtt, web etc and an event mechanism like 'on input(x) do {}' with events like time related, external inputs, user events and so on.

From what I can observe, there's not much time critical code. For the most part it's servicing comms like the web page, mqtt etc. Everything else is pretty much 'pulling levers' as in an event to turn the light on or off - the code just toggles a port bit. To read the temperature, a couple of i2c transactions, a little math then publish. Simply: event->task->done. Everyone wants something a little different - it's all variations on a theme but to implement everything in one app becomes unwieldy. So I think an extra layer of abstraction is the way forward. Give people the tools rather than the solution.

The event operations only need to complete in milliseconds to give the appearance to the human that it is 'instant'. So my thinking is that outright performance is secondary. Flexibility and a small code/ram footprint is the goal. The other observation is that once configured, the device is rarely changed, so the configuration can be done offline then loaded onto the device.

Another observation is that there's way more compute power in the browser, so if the embedded device can offload the grunt work to the browser, that can open a new world of possibilities. Also with the advent of PWAs (progressive web apps) that gives the convenience of not requiring an active internet connection at the time of use.

Micropython would be nice, but it is just a bit too big in terms of code and ram requirements. I haven't looked closely at webasm, but I'd think something similar that implements a stack based machine would be the go methinks. The challenge then becomes the front end to allow the user to easily express the functionality, press a button to compile then download to the device. The old 'Basic Stamp' comes to mind.

OR

have a web service that does a custom build of code based on the selected features.

I'm not suggesting you NEED to do any of this, but just throwing some ideas to the wind. Why haven't I done this myself? Too many other projects at the moment I'm afraid and it is on the edge of my skillset in regards to the compilation side.

[35nine]

"an option for always send mqtt data or only send on change (current implementation)? For graphing it can be easier having regular samples." - broadcast self state every minute is in flags, the "minute" amount is configurable i think

Confirming above works well, gone with command setting 5mins in autoexecbat file - mqtt_broadcastInterval 300

Stability is great, no issues. Small snafu by myself, relay is channel 0. With that, looks needed to make temp and hum channels then, 1 and 2, not with a gap like 2 and 3 - if anyone gets this, thats the way I'm around it.

Happy if either closes this issue off now or continue the chat and tweaks. Plug is out inside the closed up garage now, Melbourne reading a pleasant 38C currently in there 👍🏻

[ByteMangler]

@35nine I ran into the channel issue as well. Relay kept on turning on every second!