bk7252 camera interface and mjpeg

[AapoTahkola]

There is an effort at https://community.home-assistant.io/t/popular-a9-mini-wi-fi-camera-the-ha-challenge/230108/300 to add HA support for at least some of these cheap A9 cameras. They are relatively cheap costing less than 5 euro in some cases(temu aliexp). I have been able to run the PinScan example via telnet.

I have some difficulty navigating the source code but I think the action is at https://github.com/daniel-dona/beken7252-opencam/blob/main/project/beken378/func/camera_intf/camera_intf.c

I would be happy to help as I know C(who doesn't with GPT these days) but I am not familiar with the arduino framework.

[kuba2k2]

Hi

LibreTiny supports BK7252, so things like WiFi and GPIOs work fine. However, it doesn't support any camera interfaces (of any chip).

ESPHome has an ESP32 camera component (which works with Home Assistant, I presume).

In order to support these cheap cameras in LibreTiny, one would have to write LibreTiny API for camera support, as well as an ESPHome component using that LibreTiny API to talk to the camera sensor. I'm afraid that GPT won't be able to do it, yet :smile:

You're free to link this thread on the HA forums, maybe someone from there would feel up to taking this task.

[AapoTahkola]

Oh yes, hi. I am personally more interested in more direct approach just opening a port with mjpeg data https://www.home-assistant.io/integrations/mjpeg/

[AapoTahkola]

https://pastebin.com/Nsmf8j9t is a updated version of spi flasher using ftdi232rl. It works but for whatever reason it is difficult to make the chip enter flash mode. Also if you write like entire 2MB flash, reading it back and comparing often reveals that there are errors, which is why I implemented WriteSector and ReadSector so that it will retry. You should probably only use this program to flash bootloader and use ltchiptool to flash app image.

I guess the next step would be to modify pinscan to support https://github.com/libretiny-eu/libretiny/issues/172 so that one can update flash OTA. One thing that worries me though is that there are tables in camera_intf.c like gc0328c that setup the sensor. There are dates like 2010 and 2016 so I think it is safe so assume the camera in question is none of the mentioned SDK source code. A9 camera modules camera has text "xy233b" on one side and "std 96 56vo" on other. Neither produce interesting results with google or ddg, supposedly it is a CMOS sensor. Supposedly all these sensors use I2C which uses only two wires SDA and SCL so it would be possible to snoop I2C traffic using esp8266/esp32/arduino/rp2040 quite easily. Second approach would be to disassemble the original firmware and find the tables there. Having reverse engineered graphics cards in my youth, I would say this is fairly difficult reverse engineering feat to complete. I am not sure if I will continue on this effort or not.

[kuba2k2]

I think the SPI flasher could be integrated in ltchiptool too, if it was stable enough. Did you write it yourself or is it based on some other program?

The CMOS sensor is probably supported by the SDK. Even if the code is dated, it might work with this sensor - I wouldn't expect it to be any recent one. Finding any I2C initialization tables is not very hard, provided you know what binary to load and where. A simple string search usually gives good results.

While I don't disagree with continuing the work in any way, it's worth considering just how bad the camera quality actually is 😂

[kuba2k2]

Oh and one more thing, instead of PinScan you can use Esphome-kickstart, which has a similar (better?) feature built in, and supports OTA.

[AapoTahkola]

It is based on https://github.com/openshwprojects/BK7231_SPI_Flasher same as https://docs.libretiny.eu/docs/platform/beken-72xx/ . I never learned python but now that we have GPT, I just asked it how to do spi using ftdi233rl and bit banging. bk7231_spi_flasher.py is buggy, there should be "Wait_Busy_Down" after page write "spi.xfer(send_buf)".

I think quality is little better than any esp32-cam I have seen. Someone suggested that these could used to remote read sensors which do not support HA. It could have some uses in ingenious hands. My immediate though was something along the lines of https://www.home-assistant.io/integrations/doods/

I can tell you I have VL53L0X esp8266 distance sensor pointing at the comfy seat where I usually watch movies and when I sit on it, lights turn off, video projector starts and gamma of PC display is turned down to reduce reflections. If I stand up from it, lights turn on but projector stays on for couple minutes meaning I can take run for the fridge. Fact of the matter is that this automation is making me more likely to use the projector to begin with.

[kuba2k2]

I've tested the SPI flasher on FT232RL, and it didn't work for me. I've rewritten the SPI xfer function to use pyftdi instead of pylibftdi, which made it successfully talk to the Beken chip (BK7231T in my case).

Also, thanks to pyftdi's synchronous mode, it's now significantly faster - even 2900 bytes/sec (on highest baudrate), which can read all 2 MiB in just about 14 minutes! (compared to 2.5 hours haha) Few quick tests show that it's reading with no errors or bad bytes, but I haven't tried writing yet.

ft232spi.py

If you'd like, I can integrate this into ltchiptool (I've been wanting to do that for some time, actually).

---

Fact of the matter is that this automation is making me more likely to use the projector to begin with.

Nice! I really like that idea, in fact I bought this A9 camera few months ago with the intention of using it as a motion sensor or something.

[AapoTahkola]

As far as I am concerned, you are free to use it in ltchiptool.

It still does not want to enter flash mode very easily, I have been waiting for 10 minutes already. Most often it gives: d2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 But once in a while also: 52 d2 d2 d2 d2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I cannot think of anything that could fix this behavior. Perhaps it could check for 0xd2 in the array and give some indication that wiring is ok, suggest that wiring is bad otherwise, but continue nonetheless. I could see some people thinking this is not going to work at all having to wait for so long

[kuba2k2]

This looks like correct output, it does the same on my boards (tested on two BK7231Ts and one BK7231N). Are you sure it doesn't read the flash ID? What ID does it show in the logs? I switched it to accept BK7231 ID, you need to switch it back to BK7252.

[AapoTahkola]

Alvid_81 has tested your version and found it working. Oh yes, I forgot, change it so that it will accept both flash ids. It does seem to enter flash mode easier now, great! I think it was a timing issue

[Alvid81]

Hi, here is python code, what I use, I have changed pinouts in code, so be carefull, also my bk7252 chip send a[0] == 0x00 and a[1] == 0x1C and a[2] == 0x70 and a[3] == 0x15: as ID... also all we need in unbrick bk7252 is to write bootloader in 0x00-0x11000 afterfore we can upload saved bin(if it saved))) with ltchiptools exclude 0x11000 area... I have try whis with success. flash2.py.txt

[Alvid81]

At my camera I have GC0328C camera module.

[AapoTahkola]

Hmm, is there a way to run app_demo_udp_init() from pinscan:help.cpp ? I tried exporting the symbol with: extern int app_demo_udp_init(void); And set CFG_USE_HSLAVE_SPI and CFG_USE_SPIDMA to 1 in sys_config.h but I get undefined references.

[kuba2k2]

Demos are not included in libretiny, they're not compiled in SDK.

If you need any code from the demos, try copying it. You don't even need to use PinScan, it's just an example. You can create a new PlatformIO project and run everything there.

[AapoTahkola]

Okay, I pulled the code from SDK and massaged it a bit and it now almost compiles: http://at-rk.duckdns.org/uploads/231111-082245-PinScan.tar.bz2 undefined reference to my_video_transfer_deinit() undefined reference to video_transfer_init(tvideo_setup_desc*)

I have no idea why it is giving those errors, prototypes are there.

[Alvid81]

Link 404

[AapoTahkola]

https://ufile.io/oz6ty4av something wrong w/ my firewall still. https://ufile.io/xit5optu updated got past that. Now it is looking bad: undefined reference to co_list_init(co_list)' undefined reference to gdma_memcpy(void, void const*, unsigned int)'

[daniel-dona]

As far as I am concerned, you are free to use it in ltchiptool.

It still does not want to enter flash mode very easily, I have been waiting for 10 minutes already. Most often it gives: d2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 But once in a while also: 52 d2 d2 d2 d2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I cannot think of anything that could fix this behavior. Perhaps it could check for 0xd2 in the array and give some indication that wiring is ok, suggest that wiring is bad otherwise, but continue nonetheless. I could see some people thinking this is not going to work at all having to wait for so long

Hi! I was facing this exact problem at the beginning so I modified the original SPI flasher to retry and also try changing the SPI bus speed until I got the correct SPI chip ID.

BTW, in new cameras the Beken chip is different (still marked as 7252, but different pinout) and also the SPI memory has a different ID and flashing needs to be a bit different.

I'm working on documenting all this here: https://github.com/daniel-dona/beken7252-opencam/wiki/BK7252-SoC-variations

New SPI flash id is "0x00 0x0b 0x40 0x15" that is XT25F16B (not currently supported by flashrom)

[kuba2k2]

I see you're writing your custom firmware for that chip. May I suggest using LibreTiny as the base platform - it provides a tested framework with Arduino-like API (optional, of course) as well as access to BDK code. It also has a built-in flasher based on ltchiptool, which is more reliable and easier to use than hid_download_py.

LibreTiny can already run ESPHome on BK7252. It shouldn't matter which QFN package you have, they most likely have the same features but less GPIOs.

Besides, I am writing a GUI for ltchiptool to allow SPI flash writing (to recover a bricked bootloader). Just like the attached .py scripts above, it can be used with a FT232R adapter.

[daniel-dona]

I see you're writing your custom firmware for that chip. May I suggest using LibreTiny as the base platform - it provides a tested framework with Arduino-like API (optional, of course) as well as access to BDK code. It also has a built-in flasher based on ltchiptool, which is more reliable and easier to use than hid_download_py.

LibreTiny can already run ESPHome on BK7252. It shouldn't matter which QFN package you have, they most likely have the same features but less GPIOs.

Besides, I am writing a GUI for ltchiptool to allow SPI flash writing (to recover a bricked bootloader). Just like the attached .py scripts above, it can be used with a FT232R adapter.

I'm not so sure about this new BK7252 version, tried to flash the firmware from the old A9 in the new one and I it didn't boot. But anyway for the moment I'll focus in the old one.

For me it's easier to first try to build a working image using the original BDK and then port/develop over LT.

[Alvid81]

Production, as well as development, does not stand still in China. We are trying to understand a chip that was manufactured at least five years ago. Chinese children made crafts from it for competitions at least in 2019... An animal feeder, an intercom - that's at least what was made based on this chip.... We need a Chinese child to teach us Chinese))) In Your logs from cam I see what a camera variants is over 13. My googling is find of 8 varians of code accepted... So 13 is in China side... everyone jerks off as they want.. sorry for my Eng. It very poor..

[AapoTahkola]

As far as I am concerned, you are free to use it in ltchiptool. It still does not want to enter flash mode very easily, I have been waiting for 10 minutes already. Most often it gives: d2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 But once in a while also: 52 d2 d2 d2 d2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I cannot think of anything that could fix this behavior. Perhaps it could check for 0xd2 in the array and give some indication that wiring is ok, suggest that wiring is bad otherwise, but continue nonetheless. I could see some people thinking this is not going to work at all having to wait for so long

Hi! I was facing this exact problem at the beginning so I modified the original SPI flasher to retry and also try changing the SPI bus speed until I got the correct SPI chip ID.

BTW, in new cameras the Beken chip is different (still marked as 7252, but different pinout) and also the SPI memory has a different ID and flashing needs to be a bit different.

I'm working on documenting all this here: https://github.com/daniel-dona/beken7252-opencam/wiki/BK7252-SoC-variations

New SPI flash id is "0x00 0x0b 0x40 0x15" that is XT25F16B (not currently supported by flashrom)

This is the same flash id that I have on two of my A9 cameras. ft232spi.py that kuba2k2 provided works with it if you change the chip id. It enters flash mode immediately unlike my version. The only software I have been able to run on it was flashed with ltchiptool and is this PinScan which if you modify pinscan.h has working lwip stack. The reason why this is pretty great is that these WiFiMulti, WiFiServer, and WiFiClient are same as used by esp8266/esp32 on Arduino, which means we can just open more ports for serial and continue without using serial at all. I have pretty almost always gone full wireless with esp8266 and Arduino for my projects because I do not like keeping all these wires dangling on my desk. It is a good idea to keep the telnet interface around because initializing the camera interface could crash the chip also taking OTA down.

[Alvid81]

My experiments with .bin files. I flash via SPI only bootloader (because it is wasting of time waiting of an hour). Then with HEX Editor I merge clear bootloader with some flashes without bootloader (as rtthread_uart_cam_2M_UART1.20190828.bin or rtthread.bin). After this, it becomes possible to flash the chip using ltchiptools. Yes, the checksums don't match, but it works. I was unable to get working firmware using SCons. The only firmware that worked this way (displayed information in the UART and commands could be sent to them) is rtthread_uart_cam_2M_UART1.20190828.bin and rtthread_uart_cam_4M_UART1.20190828.bin And .uf2 from Platformio of course. Settings of ltchiptools on screenshot - end address - is the length of .bin without bootloader.

[kuba2k2]

You don't need to flash the bootloader or merge anything with HEX editor (unless you want to change the bootloader). ltchiptool (with settings from your screenshot) will not touch the bootloader area, so it doesn't even have to be valid in the input file. Also, please update to v4.8.0 - it has some flasher improvements, such as not having to specify flashing length.

[Alvid81]

Merge helps to said to ltchiptools type of written file. Ltchiptool dont work with RAW file ... I have 4.8.0. But I use one or the other whichever is closer))) "File is not flashable"

[kuba2k2]

It doesn't need to know the type of file, you're not using auto-detect. In fact, it detects it incorrectly (it's not a Realtek bootloader...). It can flash whatever you want in this mode.

[Alvid81]

I know this! SCons(env by RT-Thread) build firmware without bootloader - becken packager merged this firmware with bootloader(I did this by HEX Editor... hm only now I understand what I can use becken packager). So... The firmware itself is not recognized by ltchiptool. That's what I'm talking about. This is simply a statement of fact. Although it would be nice to introduce “god mode” into ltchiptool for flashing anything...

[kuba2k2]

Oh, I didn't notice your second screenshot. Right, it recognizes the file as ARM binary so it blocks flashing. Usually you can flash anything if it doesn't recognize it. Unchecking "auto-detect" should be the "god mode", but apparently there's a bug somewhere.

[Alvid81]

I see you're writing your custom firmware for that chip. May I suggest using LibreTiny as the base platform - it provides a tested framework with Arduino-like API (optional, of course) as well as access to BDK code. It also has a built-in flasher based on ltchiptool, which is more reliable and easier to use than hid_download_py. LibreTiny can already run ESPHome on BK7252. It shouldn't matter which QFN package you have, they most likely have the same features but less GPIOs. Besides, I am writing a GUI for ltchiptool to allow SPI flash writing (to recover a bricked bootloader). Just like the attached .py scripts above, it can be used with a FT232R adapter.

I'm not so sure about this new BK7252 version, tried to flash the firmware from the old A9 in the new one and I it didn't boot. But anyway for the moment I'll focus in the old one.

For me it's easier to first try to build a working image using the original BDK and then port/develop over LT.

Can you share "the firmware from the old A9 and the new one" plz. Didnt know how to use personal messages here...

[Alvid81]

Hi, I don’t know what I did, but today the chip is no longer detected. It seems to me that it does not enter SPI mode; reset signals are visible on the oscillogram. Ltchiptool reads and writes via uart... Where is the problem? d2 d2 d2 d2 d2 d2 d2 d2 d2 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 0 00 00 00 00 00 00 00 00 00 00 Test by sending get ID Speed: 123 bytes/sec 00 00 00 00 ID bad Failed to read flash id Send 250 'D2' Speed: 141 bytes/sec d2 d2 d2 d2 d2 d2 d2 d2 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 0 00 00 00 00 00 00 00 00 00 00 Test by sending get ID Speed: 133 bytes/sec 00 00 00 00 ID bad Failed to read flash id Send 250 'D2' Speed: 122 bytes/sec d2 d2 d2 d2 d2 d2 d2 d2 d2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 0 00 00 00 00 00 00 00 00 00 00 Test by sending get ID

[kuba2k2]

I don't know, but try undoing what you did to make it stop working. I didn't change anything in ltchiptool or the script.

[Alvid81]

I'm not saying that anyone other than me broke something))) Strange answers d2 d2 d2 d2 d2 d2 d2 d2 d2 00 00 00 00 00 00 00 although there should be d2 00 00 00 00 00 00 00 00 00 00 00 00 00. The chip is simple return sending command and after time stops responding... Maybe you have encountered such behavior of the chip..

[AapoTahkola]

I'm not saying that anyone other than me broke something))) Strange answers d2 d2 d2 d2 d2 d2 d2 d2 d2 00 00 00 00 00 00 00 although there should be d2 00 00 00 00 00 00 00 00 00 00 00 00 00. The chip is simple return sending command and after time stops responding... Maybe you have encountered such behavior of the chip..

My experience is that as long as it is returning any 'd2' wiring is ok, how many d2's there are does not really matter. As you can see in DD and DDNEw functions, changing any of the parameters does not make any difference how easy it is for it to enter flash mode. It could be that what is written to app area at 0x11000 affects how long it stays in bootloader so if you have bad firmware in there it is more likely to enter flash mode and if there is good firmware it is less likely to enter flash mode.

Anyway, the thing is, we really have no need to replace the bootloader at any stage anyhow. Although it complains "App verify failed! Need to recovery factory firmware.", it actually enters 0x10000 . BK7256 on the other hand supports secure boot which essentially allows for the vendor to completely lock the system if they so choose. Luckily we are unlikely to encounter this chip in A9 cameras.

I try and see if I can modify PinScan to support OTA flashing. EDIT: So basically I wrote code for OTA flashing and now the damn thing wont boot PinScan anymore. EDIT2: I put my modified versions of these spi flashers at http://at-rk.duckdns.org/uploads/bk7252/ . There is also PinScan version that compiles EDIT3: I have updated http://at-rk.duckdns.org/uploads/bk7252/ft232spi.py . This has bunch of fixes so if one wants to SPI flash bootloader this is the only version that actually does what it says in the tin. There was write protect bit that had to be turned off.

[Alvid81]

Bad contact at QFN ... Hm... I cant rewrite bootloader... No errors but entire is same... trying with command at code: WriteImage(0,"bootloader.bin",0x11000) # write only bootloader code.....

[Alvid81]

I'm not saying that anyone other than me broke something))) Strange answers d2 d2 d2 d2 d2 d2 d2 d2 d2 00 00 00 00 00 00 00 although there should be d2 00 00 00 00 00 00 00 00 00 00 00 00 00. The chip is simple return sending command and after time stops responding... Maybe you have encountered such behavior of the chip..

So in summary - this is reaction of chip on TCK signal absense. Provided code only reads flash, it is not for write(in my case), we somth missing, maybe some init command for erase-write or else....

[kuba2k2]

TCK/SCK signal is absolutely necessary, it's the clock signal. Without it the chip never actually receives data from your flashing program.

You have previously stated that writing works for you with the code I provided. I did not change anything in it. If you did, please re-download the code I sent and try it again.

Flashing problems of an end-user (most likely caused by connection problems or wrong usage of the code) is not an issue related to LibreTiny. That being said, I am preparing a flashing plugin for ltchiptool, based on a 3-rd party, tested library. You'll be able to test it as soon as it gets published.

Until then, please consider reducing the number of posts in the main (and only) thread here about BK7252. Future viewers, who want to learn something, would probably not like having to scroll through many pages of flashing issues.

Let's keep the GitHub conversation tidy and to-the-point. You're more than welcome to join our Discord server where everyone can discuss all kinds of issues with other developers in realtime.

[biemster]

I'm working on firmware for my bk7252 doorbell here: https://github.com/biemster/bdk_rtt_v3 This repo compiles with modern py3 scons, and seems to contain a web_camera example that puts out a mjpeg stream. I'll report back here when I get that working, since I also prefer a libretiny solution. As a bonus it also contains an SPI flasher that can flash a new bootloader in 10 seconds or so, but I think a very similar bit of code already was mentioned in this thread.

[AapoTahkola]

It sounded a bit like A9 cameras produced these days do not use bk7252 anymore but TXW806-840 which is probably cheaper which is why it is being used. If that is the case, then whats the point of continuing with the development?

[daniel-dona]

It sounded a bit like A9 cameras produced these days do not use bk7252 anymore but TXW806-840 which is probably cheaper which is why it is being used. If that is the case, then whats the point of continuing with the development?

I have a box with +10 of these cameras from a couple of months ago from different sellers in Aliexpress and half of them are still BK7252 (some with a variant with less pins), some are TXW, some are an unknown chip that by the dump could be a XR819 and I think there was even an additional different SoC but I can't remember...

Looks more like "what is cheap this week", maybe more than one manufacturer copying the board and making changes (same chip but some use a dedicated IC for battery, others use BK7252 battery management).

I think this cameras are still interesting (and cheap) and further development on BK7252 can also benefit LibreTiny in general, I wish I had more time to keep working on this :S

[AapoTahkola]

It sounded a bit like A9 cameras produced these days do not use bk7252 anymore but TXW806-840 which is probably cheaper which is why it is being used. If that is the case, then whats the point of continuing with the development?

I have a box with +10 of these cameras from a couple of months ago from different sellers in Aliexpress and half of them are still BK7252 (some with a variant with less pins), some are TXW, some are an unknown chip that by the dump could be a XR819 and I think there was even an additional different SoC but I can't remember...

Looks more like "what is cheap this week", maybe more than one manufacturer copying the board and making changes (same chip but some use a dedicated IC for battery, others use BK7252 battery management).

I think this cameras are still interesting (and cheap) and further development on BK7252 can also benefit LibreTiny in general, I wish I had more time to keep working on this :S

It is possible that there are multiple manufacturers of the PCBs and the plastic casing can be bought separately. After all it is the injection molding of the case that is the most expensive part of making these devices. But yeah, having hard time justifying keeping working on this when I only really need one camera for basic monitoring if I am away.

I found Reolink and Wyze cams but I find them little too splashy products for my use case. "Tuya Smart 1080P 5Ghz ONVIF" on aliexpress for 20e kind of looks like something that could work.

[kuba2k2]

Just don't be fooled by the product description - you might find yourself paying 20EUR for a "1080p" camera and getting the same Beken crap. After all, the A9 cams are also advertised as 1080p.

[snelltheta]

What is necessary to go forward? I'm interested in furthering the development.

[kuba2k2]

LibreTiny APIs for camera peripheral, board bindings for various A9 cameras, ESPHome support for these APIs, and two hands with some spare time. To name a few.

[snelltheta]

This sort of programming is not my forte, but if there are bite-sized chunks that somebody more familiar with the project could give me, I should have some time to do some of it.

[biemster]

I'm working on this, but having issues finding the camera on the i2c bus. @snelltheta is that some bite-sized chunk you can pick up?

[AapoTahkola]

Just don't be fooled by the product description - you might find yourself paying 20EUR for a "1080p" camera and getting the same Beken crap. After all, the A9 cams are also advertised as 1080p.

Okay I found this https://github.com/fjramirez1987/PTZ-YCC365 . I guess for 720p and works with HA these do not seem too bad for around 20e. But yeah, might be Beken.

[AapoTahkola]

I'm working on this, but having issues finding the camera on the i2c bus. @snelltheta is that some bite-sized chunk you can pick up?

Did you try i2c scan like https://learn.adafruit.com/scanning-i2c-addresses/arduino ? This is how I have always done it.

[biemster]

I'm working on this, but having issues finding the camera on the i2c bus. @snelltheta is that some bite-sized chunk you can pick up?

Did you try i2c scan like https://learn.adafruit.com/scanning-i2c-addresses/arduino ? This is how I have always done it.

Yes I did, nothing responded. My guess is that I need to pull up (or down) one pin on the camera to switch it on, but I did not manage that yet.

[kuba2k2]

How did you do that? I2C on Beken is not implemented yet in LibreTiny.

[biemster]

I'm currently developing on the rtt bdk: https://github.com/biemster/bdk_rtt_v3/tree/doorbell, and will move to LibreTiny when I have access to the camera (the rest works)