But here we have a CBU module and an additional light sensor which can measure light intensity by Lux at a range between 0 ~ 6500, give or take:
A few things about device and flashing:
- it is not a TuyaMCU device
- there is no need to cut connections or desolder CBU module
- flashing works flawlessly with bk7231flasher Windows tool
- the device can be powered with 2xAAA batteries, which makes sense with deep sleep driver (Door Sensor function)
- it can also be powered with 5V via MicroUSB
- the reaction time until Wifi is connected and status reported with OpenBK deep sleep is about ~5 seconds
- without deep sleep the Wifi connection is kept stable and it reacts instantly on motion
- After detecting motion, it changes to "Clear" within ~5 seconds when no further motion is detected
--> edit: I have bought several of those devices, and actually only the first one I bought has this fast clearing of motion interval, all the others take 30 seconds to change the status to "Clear" when no further motion is detected.
Unfortunately, I was unable to get the light sensor working. I tried GPIO doctor with all the pins dInput with and without pullup, no success. Any contribution to make the light sensor work would be appreciated.
I was able to trace back the connections, there are 3 connections directly to CBU pins! That is very interesting!!
Let's have a look:
The connections arrive at P6, P7, and P26 of CBU, which are all PWM pins. The other side of the light sensor is connected to GND.
I am not sure about I2C... until today I had no knowledge about it but read a bit and understand that there are two data lines (SDA and SCL), between the host (main device) and slave (sensor). We seem to have three lines here, all of which are data lines.
Can you make something of this information? Thank you.
Inside it contain LED, BUTTON, PiR sensor, Battery monitor and Light sensor (U4 on the board):
The device build on TUYA CBU module and contain testpoints TP6 and TP7 (Tx and Rx) from the module. I cannot re-flash it with tuyacloud, only with BK7321 Flash tool. Also, non Flash tool, not tuya cloudcutter cannot extract tyua template (the Tyua firmware attached)
From my investigation i found connection for this device:
P8 - PiR sensor
P16 - LED /WiFi LED
P24 - Button
P23 - Batt ADC (coefficient 1.97 work fine for me)
P22 - Batt Relay
Light sensor (U4 on the board):
P6 - I2C clock
P7 - I2C data
P26 - programmable interrupt from light sensor, when the light strong(over the range), the signal fall down
I dont know what is a light sensor, but i attach 2 PulseView files:
- one is Tuya FW sensor capture
- OBK power on sensor capture
I tried to execute scanI2C command, i have see OK result, but i cannot see anything on the bus (the signals is not changes, and was always high). Maybe i dont execute the command right way, but threre no info about this command.
I will glad if this driver will be implement in OBK firmware.
Hi, I had a look at mouser to see if I can find any. It seems not a very easy task, there are many different kinds which look similar, and it is hard do tell what is the difference as a non-professional.
So, how is the process with unknown I²C components? Do we need to do reverse engineering and read/encrypt data that is sent through I²C bus? I suppose special equipment and some electric knowledge is required here? Or if we are lucky we can find the required data of components in docs and data sheets?
Hi, On the stock firmware, the module stays in deep sleep mode. The motion or interrupt from a huge light source (flashlight from a mobile), and it updates 3 things: - motion - light (lumens) - battery percentage
Yes, the slave address doesn't match. But pinout exactly fits. I also looked for all LiteOn sensors and cannot find 0x38. Maybe something is wrong with my analyzer, it's a simple $5 board. I have a Keysight at work, but it will be next week. Is it possible to scan addresses in OBK?
The scan function you've found was for the hardware I2C bus. Apparently the hardware bus is not used often and our drivers are implemented now as bit-bang in software. Still, if you think that could helpful, hmm... I can think about something and add some kind of generic I2C scanner for software I2C.
I think it will be great. Take pins marked as SoftSDA and SoftSCL (or some other type, just for scanning) and scan full addresses.
It will be great for someone (like me) who wants to add some sensors to current devices. I want to use this device and add an I2C weather sensor to the I2C bus and an IR Tx LED to an unused pin. In one nice package, I will have all necessary sensors for the room.
And many thanks to you for excellent work! I'm ready to help with the project to the best of my abilities.
Wow! This is a really cool idea, to add weather sensors and extend the function of this sensor board. Could you share your project here in this thread and explain how you do it? I would be interested to follow the progress...
@p.kaczmarek2 , thanks for combining our topics!
Added after 3 [hours] 5 [minutes]:
I was trying to find the sensor again with google search, found some similar ones but that one seems hard do get. I will try to ask a Chinese friend if they can find it in Chinese internet.
I want to share another photo I took under the microsope. We have 5 internal pins inside the sensor, and it looks like the SMD package has 6 pins, 3 on each side, similar to the LITEON one.. in my photo it looks slightly rectangular, but actually it is square shaped! (display problem)
I tried with setting P6 to SoftSCL and P7 to SoftSDA, as @dgel27 suggested thad I2C communication is handled through those. Then I set the driver via autoexec.bat and restarted. Now I use a strong flashlight to trigger the sensor, but I don't get any result in log about I2C. Am I using the correct approach here?
As P26 seems to be the pin where the lux value arrives, which function should we assign to that pin?
It possibly to try, but registers addresses not fit.
More closer registers adresses in LTR-390, LTR-381RGB, LTR-308, LTR-216, but also not fit that i see in logic analyzer.
VISHAY have different pinout and different command sysytem - it uses 2 different addresses for read and write (0x38 and 0x39)
But anyway, i think we have progress, if not in this device, but in full firmware.
If we can detect device, it possible add many different drivers, and automatically add detected devices to the bus.
This concept brings OBK to all development possibilities, not just devices present on the market currently.
OK, we cannot find currently what is device with 0x38 address, ok, it possible order breakout board with known sensor, solder 4 wires... and WOW... we have additional light sensor, that works, and non-works wait for future use....
@dgel27 great idea!
would you mind do share your steps on how to add known devices to I2C bus and configure them to add their function of the module? maybe a little guide with commented photos would help some other people like myself.
I have a spare CBU module from a broken device, which still works and could be used for some experimental project like this! I also have a spare motion sensor with 3 pins and could try to connect it, or some buttons or LEDs, or little siren. But I don't have enough knowledge yet which pin to connect where and then to configure it.
I have flashed more than 20 devices now with OpenBK, it is super cool and makes me addicted somehow 😅I want to get to that point where I can erase all different smarthome apps from my phone and run everything independently and locally with Home Assistant or simple web interface.
How many steps are needed to get the measurement results with that device? Maybe we just could rewrite the steps observed into the logic analyzer into the code... of course assuming we know how we get the data and the data is in some simple format with not much postprocessing needed