Following our tutorial on how to enable I2C on the camera (please read first), in this tutorial we will see an easy way on how to add more GPIOs using IO Expander
Wiring
The driver uses the PINS: GPIO 7: label TX2, level 3.3v GPIO 6: label RX2, level 3.3v
Using IO Expander I2C
A simple way to add more GPIOs is to use boards with PCF8574 This unique model is interesting because it is easy to cascade by connecting several in series.
In this tutorial I will demonstrate how to 1. Compile a driver for Anyka camera and 2. how to implement i2C software and 3 using the example of IO Expander.
This is a series of tutorials, you can see the topic list here
Despite this being a market hardware, I ended up finding several GPIOs that can be used for general purpose, which makes it useful for developing some range of applications.
With the need to be able to have more IOs, I was looking for an alternative like maybe connecting an Arduino Nano and this being my GPIO “bridge”. This way it is also safer, avoiding burning the camera if you do something wrong.
As the camera has a second UART marked on the PCB (RX2, TX2), my first attempt was this. But I couldn’t compile a driver that enabled this function.
Doing a reverse engineering, I saw that there were some calls (insmod) for i2C drivers, but it wasn’t exactly for this camera model, because it doesn’t have motors.
These files exist in the original firmware: ./mvs/modules/ak_gpio_i2c.ko ./mvs/modules/akcamera.ko ./mvs/modules/aw_gpio_moto_driver.ko ./mvs/modules/ex_gpio_driver.ko ./mvs/modules/i2c-gpio-soft.ko
Also after several attempts to use the existing drivers, I couldn’t either. Even inserting the drivers, no new entries appear.
Ref: insmod /mvs/modules/ak_gpio_i2c.ko gpio_sda=7 gpio_scl=6 (not works !!!)
I ended up deciding to try to implement a virtual I2C driver (software).
The Kernel
The kernel used as a base to compile the modules is in this repository
Note that not all drivers are compatible, I had problems for example compiling the standard UART driver. I believe the v380 camera kernel is slightly different from this one .
Keep this information in mind, when trying to compile other drivers, for example the UART one, I had this error.
insmod gpio_uart.ko gpio_uart: Unknown symbol ak_timer_enable_sync (err 0) gpio_uart: Unknown symbol ak_timer_request (err 0) gpio_uart: Unknown symbol ak_timer_config (err 0) insmod: can’t insert ‘gpio_uart.ko’: unknown symbol in module, or unknown parameter
Modifications to the build script.
I made some modifications to the build script, so as not to compile unnecessary things, you can use this file:
In this tutorial I will give quick tips on how to compile NodeJS for ARMv5 architecture used in camera v380. And also how to call native code through javascript.
This is a series of tutorials, you can see the topic list here
Download repository, goto folder /nodejs/v0.10_arm , and run ./build.sh
This will create a folder called: node_install, and static binary in /bin/node
This binary can be copied to camera and run on camera without dependencies..
Limitations
Although it also has NPM it is not very functional, because the file system is read only, it takes a long time to run. So the package management I do manually, copying the node_modules on the PC to the SDCARD.
Some modules I wanted to use like ‘sqlite3’ use native integration (C++). As modules generally use the N-API API, and this api was only introduced in Node v8, libraries that use this feature will not work.
Below I present an alternative to be able to call C++ code using NodeJs from old versions
You can just copy to camera and run. Note that here I am making use of an extra package “bindings”, it is responsible for helping to load the native library
TODO
I’ll provide more examples later, how to use typescript, and automatically generate a file with the modules in just a single file.
So that’s it, we have a high-level language to speed up the development process and when you need to be able to integrate with native code.
Here I will explain how to boot from the SD card without having to make any changes to the flash memory. The idea is to change parameters of the booloader (u-boot) of the camera to allow loading rootfs directly from the sdcard.
You will need soldering skills and a serial adapter … (I hope you are a maker)
Most linux cameras have some serial port (RX, TX), labeled or not, where you can access the console terminal, where you can execute commands…
As soon as you turn on the camera (this is in question), the “first thing” to run is the bootloader (usually u-boot), it is responsible for loading the kernel, and passing parameters that can also control the way the linux boots.
It is possible to load the Kernel directly from the SDCARD, but I could not in this camera. I believe u-boot was not compiled with this support. So let’s content ourselves with passing parameters to the existing Kernel, to load a roofs (/) from the SD.
The camera I’m working on doesn’t have an Ethernet card, but it’s possible to load the Kernel and Roofs over network using TFTP…
Serial Connection
TIP: I’m using enameled copper wire, taken from a transformer. The advantage of using this wire is that soldering is more accurate and less prone to breaking contact pads (yes, this happened to me using other wires)
Preparing SDCARD
First you must partition the memory card, with two partitions: 1Gb ext3, and the rest as FAT32. You can use any tool for this.
The file system (rootfs) used in the camera is SquashFs, but when formatting you can choose ext3 for example. To prepare rootfs we can backup the original partition, and unzip it or use a new and “cleaner” distribution.
Basically the commands you need 1. Generate squashfs file from rootfs folder mksquashfs [FOLDER] root.sqsh
2. Burn image to SDCARD using DD sudo dd if=root.sqsh of=/dev/DEVICE status=progress bs=1MB
# CAUTION: DD CAN DESTROY YOUR HDD, PLEASE CHECK DEVICE using lsblk
I prepared a new distribution without any Chinese programs that will be spying on you. And a script with make SquashFs file and send to SDCARD.
You can use file /rootfs_v1basic/root.sqsh , or use script: make_sd.sh to create new root and send to SDCARD (please change the DEVICE in make_sd.sh, i’m using partition2 )
Booting new system (changing u-boot settings)
Connect the serial adapter to the PC and use this command (on linux terminal) to open serial port:
screen /dev/ttyUSB0 115200
Now power IP Camera …. If everything is ok you should see the screen below, quickly press any key to enter the u-boot terminal;
You can follow some tips how to do this connection in Windows from this vídeo, or use WSL
Now there are several commands that you can explore in u-boot. Write help end hit ENTER, it will show the list of available commands;
Another command is printenv, which will show all the environment variables. We are going to modify then in order to change the boot process. Note that all changes are temporary, and if you want to make them permanent you can use saveenv
Now, shutdown the camera and plug SDCARD. Power again, and… quickly press any key to enter the u-boot terminal;
Execute two commands to set boot to “/dev/mmcblk0p2”.
In this series of posts I’m going to cover some techniques I used to hack a IP Camera and take full control of it, from root access, reverse engineering, remote debugging, compiling your own programs and having access to the GPIO and image sensor. How about running NodeJS ??, in the end, you will have a cheap linux device to be able to do whatever you want..
My goal is to be able to turn a camera into a low-cost IoT device that is easy to find in the market. Maybe in the end she even stops being a camera, who said she was born to be a camera? Hahaha
The great advantage of this hardware in my point of view, was the amount of usable GPIOs, a USB port (used by WiFi), and …. after a lot of headache I managed to access the raw image sensor…
[BR Disclaimer] Essa camera é facilmente encontrado no Mercado Livre e AliExpress por volta de (BRL – R$120 -150).
Processor : ARM926EJ-S rev 5 (v5l) BogoMIPS : 199.06 Features : swp half fastmult edsp java CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part : 0x926 CPU revision : 5
Hardware : Cloud39E_AK3918E+H42_V1.0.2 Revision : 0000 Serial : 0000000000000000
There are multiple ways from getting root access from cameras Examples:
Using defaults passwords (or luck)
DUMP Flash and unpack roofs, change password, repack and flash
Use the camera’s own update mechanism.
Boot you system from SD card or network (TFTP)
Here, a will explain two techniques.
Firstly thanks to the work of another developer, who reverse-engineered the original camera update system. It is possible to generate patches that run shell script, and patches to update the flash partition.
It is important that you read the original article, here I will only give my simplification of the scripts I created
Next execute ‘make.sh‘ script, the patch will be generated and moved to correct folder. Then copy the files from the /COPY_TO_SD folder to the root of the sdcard
Put sdcard into camera, you should hear some messages that the patch is being applied
The ‘run.sh’ script will start telnet as ‘root’… and you will be able to login without asking for a password. From you PC connect using: telnet 192.168.XX.XX
Now the power is yours…
Making permanent changes.
The rootfs is ready-only, you can not edit password, you need generate a patch to do this.
The ROOTFS patch is well explained in the original article, what I can add is some tips
Remember that it is possible to create a script that performs the backup of the rootfs partition. So that you can change the root password and generate a new rootfs patch. That way you can make permanent changes to the original system, so be careful.
TIP: Generate root password using (MD5):
openssl passwd -1
TIP: Script to backup all partitions (you can use in run.sh)
#!/bin/sh
echo "XXXXXXXXXXXXXXX BACKUP /proc/mtd XXXXXXXXXXXX"
cat /proc/mtd
BACKUP_DIR="/mnt/sdcard"
cat /proc/mtd | tail -n+2 | while read; do
MTD_DEV=$(echo ${REPLY} | cut -f1 -d:)
MTD_NAME=$(echo ${REPLY} | cut -f2 -d\")
echo "Backing up ${MTD_DEV} (${MTD_NAME})"
# It's important that the remote command only prints the actual file
# contents to stdout, otherwise our backup files will be corrupted. Other
# info must be printed to stderr instead. Luckily, this is how the dd
# command already behaves by default, so no additional flags are needed.
dd if="/dev/${MTD_DEV}ro" > "${BACKUP_DIR}/${MTD_DEV}_${MTD_NAME}.backup" || die "dd ${MTD_DEV}ro failed, aborting..."
done
Este é um guia básico de como utilizar um ESP8266 como Sensor de RF no Home Assistant, criando assim um RFBridge.
O sensor utilizado para receber RF 433Mhz : MRF-01 JFL OBS: Outros sensores para Arduino podem ser utilizados (veja)
Para envio dos dados, podemos por exemplo usar um sensor/controle de mercado:
Os protocolos de RF compatíveis são:
HT6P20X
SC5262 / SC5272
HX2262 / HX2272
PT2262 / PT2272
EV1527 / RT1527 / FP1527 / HS1527
Não vai funcionar, se tiver usando um controle do tipo rolling code. Porque toda vez que você pressionar, ele vai enviar um sinal diferente (criptografado).
Você pode abrir o controle e verificar se ele tem algum chip com essas referências.
Iniciando
Primeiro você deve seguir o tutorial do ESPHome para fazer o flash do ESP:
Veja no manual como colocar ele no modo de ABERTURA E FECHAMENTO. Depois de ter configurado, ele vai começar enviar 1 código para abertura e outro código para fechamento
Sensor Magnético Sem Fio Digital Smw 150 Sulton 433,92mhz FUNÇÃO: SOMENTE ABERTURA
Controle Rf433mhz De Parede -para Sonoff Rf/pro/pro R2
Sensor genérico
Sensor Presença Movimento Ivp Visory Rf Sem Fio 433mhz Ecp F105548 Original Saw Frequencia Estvável