Also killed my Doorbell, but restoring won't work.

[sanscorp1]

I have two doorbells, one stock and one none functional at the moment. Both are identical (SW and HW).

I THINK I used the wrong env, at the very least I tried to apply the wrong hack for version 2.x.x. The camera is version 4.0.7 and I first need to restore it back to factory default.

I now have telnet again, but the device won't register to the Android Tuya app. Is there anything I can do from the CLI?

I set env to: bootargs=mem=64M console=ttyAYA0,115200n8 and left he NULL intact.

proc/cmdline shows: mem=64M console=ttySAK0,115200n8 loglevel=10 mtdparts=spi0.0:256k(bld),64k(env),64k(enc),64k(sysflg),3m(sys),4032k(app),640k(cfg) ppsAppParts=5 ip=0 - ip=30;/mnt/mmc01/initrun.sh)&:::::;date>/tmp/hack;(sleep

Which is identical to the working doorbell.

/proc/self/root/etc/init.d/S90PPStrong shows: proc_s90ppstrong.txt

Device info: devname Smart Home Camera model Bell 8S softwareversion 4.0.7 hardwareversion BE8S_A2_V10_43 firmwareversion ppstrong-a3-tuya2_general-.0.7.20210513

[guino]

@sanscorp1 sorry for the delay, I haven't had a chance to hop back into github lately.

The cmdline you showed me is from #13 (good) -- that cmdline should allow the device to boot even without a SD card installed, so if the device isn't starting up normally/stock without the SD card installed then it could only be due to hardware malfunction (which would be unrelated to the rooting process).

If the device is booting and allowing you to telnet into it (which can only happen with SD card in place): it may not register to the tuya cloud/app if ppsFactoryTool.txt is present in the SD card -- this doesn't happen on all firmware but it does happen on some firmware versions. Just rename the ppsFactoryTool.txt file (to anything else like disabled-ppsFactoryTool.txt) and reboot to see if the device works normally (the built-in URLs like /proc/cmdline won't work anymore but they are only needed for rooting which you have completed since you have telnet).

[sanscorp1]

No worry's, it's all hobby and you have helped me quite a bit in the meantime (more then one coffee would justify...) I did try to connect the device to the Tuya app without SD card installed. So I ruled out any modifications, there was something wrong (i.e. I used the wrong version) with initrun and env in the end.

I have been busy and the good news is I can access the camera trough the Tuya app again and Telnet is still available. ttyAYA0 was wrong in the ENV file and I used ttySAK0 in the end.

I was uncertain which files and which methode to use and I ended up mixing 720p, 1080p and BazzDoorbell MMC files which resulted in a working / rooted camera :) IF you could provide me with a few rules of text concerning which files to use on which camera I could write a how to.

offline.log:

[sanscorp1]

OK maybe I cheered to soon. After a reboot, no more telnet, no RTSP, no connection to the Tuya app.

Removing the SD card and resetting also results in not being able to reconnect as a new device.

I included the contents of the SD card last used: Copy SD card Doorbell.zip

[guino]

@sanscorp1 if it is not booting without the SD card, then either you messed up the /proc/cmdline when restoring it OR it is a hardware malfunction.

If both doorbells are the same model/firmware, what I recommend you do is:

1. Create a ppsFactoryTool.txt for the working/stock doorbell
2. Get the /proc/cmdline from the working doorbell (only requires ppsFactoryTool.txt -- no need to modify/root it). Once you get the 'original' /proc/cmdline you can delete the ppsFactoryTool.txt file and keep it stock/original.
3. Using the 'original' /proc/cmdline from the working doorbell, use the troubleshoot/restore process from #2 to create the env file and restore the device but BE SURE to use the ppsMmcTool.txt file from Merkury1080P since you posted your firmware is 4.x

Doing that should restore the boot settings to what they were originally and allow the device to boot stock -- if this doesn't happen you're likely dealing with a hardware issue in which case I'd recommend claiming warranty if it is possible.

[sanscorp1]

For the ease of things I have used the USB connector with a standard Samsung USB charger. It would seem this has caused it's own problems, perhaps too low voltage or amps. It would explain the irratic behaviour of working / not working So I'm now back with the original powersupply to test further.

After a reboot with the correct env file I am able to reconnect to the Tuya app. Copying the known working SD card from the indoor camera, offline.log is also filled on the doorbell. Rebooting again and the ring keeps blinking blue and no connection at all.

[guino]

@sanscorp1 check your 'samsung' charger -- you have to be really careful cause a lot of those output more than 5V and can damage 5V devices that are not ready for these 'fast' chargers. I have burnt a Raspberry pi board with one of those samsung chargers in the past, so you may have damaged it. It would be too perfect if all chargers with USB plugs were 5V -- samsung logic (and many others) for you.

[sanscorp1]

I will check the consistency of reboots, if inconsistent I will return it for warrenty.

The second one should be a matter of plugin in the SD card and it's good to go.

[sanscorp1]

The other (known good / stock camera) shows exactly the same behaviour when inserting the SD card and booting with the reset button pressed for 5 seconds (the first time).

The current SD card is a 1:1 copy of the known working Indoor camera, with the same Version 4.x.x hack.

Booted the camera 4 times, 3 times nothing, no RTSP, telnet or tuya app. 4th time (after a good few minutes) everything works fine.. Beats me.

I did notice this on the outdoor camera and on a few occasions on the indoor camera's as wel. Sometimes a second or third reboot is needed.

[guino]

@sanscorp1 are you testing with the offline script ? if so the time it takes to re-enable the wifi may vary on each boot. I would be sure to test without the offline script and no ppsapp file in the root of the SD card to see if you get more consistent results.

The other thing to notice is the first boot may take a little longer as it decompresses the home/* files from the firmware.

You could also test if the devices consistently boot normally without the SD card (despite the cmdline being different after rooting).

[sanscorp1]

Yes the offline script is running. I will test better and with difference scenario's over a larger amount of time.