Offline patch request

[sanscorp1]

There is an online patch and the camera keeps on working without internet once booted with internet. But with a reboot whilst internet is blocked, the RTSP stream is gone as well.

What is the difference between online and offline patches? Is it something I could do even though lacking most skills?

Firmware: ppstrong-a3-tuya2_electro-4.0.7.20210624 Smart Home Camera Bullet 4S SW: 4.0.7 HW: B4S_V10_A2_2063

What do you require if it is even possible?

Thank you again!

EDIT, I found the offline patch guide but don't even know where to look for what. This is not something I could do without extensive help. https://github.com/guino/BazzDoorbell/issues/4#issuecomment-742596905

[guino]

@sanscorp1 so the common patch (which you referred to as 'online') is a patch just for the RTSP/ONVIF feature -- newer firmware (4.x) usually doesn't require it as you can just enable RTSP/ONVIF on the json file. The 'offline' patch is meant to allow the camera to boot up entirely without internet so the RTSP/ONVIF feature works when there's no internet connection.

That said: if you block internet to the camera completely you will need to set the time on the device somehow otherwise you'll get a wrong date/time in the video feed of the device. You can do this manually by telnet into the camera and setting the time whenever you reboot it, or you can create a NTP server and add a command to the custom.sh script to connect to it and set the time during boot.

The offline patch instructions you found are for older firmware and are fairly advanced so I would not recommend you to try them. Furthermore I want to confirm you understand about the date/time being wrong on the video when there's no internet -- which is the reason why I keep internet access on my own devices.

I also recommend you try this pseudo-offline method: https://github.com/guino/ppsapp-rtsp/issues/21#issuecomment-918777873 -- this one basically lets the device boot online and then blocks access and disconnects from the tuya servers (basically making it offline).

Please confirm you tried this method and I can still try to make an offline patch if you like.

[sanscorp1]

The time stamp in the video isn't so important so if this ials not needed for RTSP I can live with it.

I have tried blocking internet after boot up but this is not something I'd like to do every time I power down one of the camera's and for sure something I'm going to forget or will causr trouble whenever I'm not home after a power failure.

The intention is to change all camera's in the house so it needs to work on power on every time without interventions. I want to begin with vSphere or Proxmox to virtualize the NVR, opnsense, adguard and domoticz. Still at the bottom of the learning curve.

I have an NTP server running so I will try to edit custom.sh to include this.

I do not like the idea of any data being send or camera's being accessable trough internet. I do have a VPN on my phone so I'm always connected to my local network.

I'd really like the offline patch!

My knownledge currently ends at basic Linux commands and telnetting into a device vi editing files.

[guino]

@sanscorp1 ok, I'll see what I can do. Please notice that the 'pseudo-offline' method is fully automatic (it does NOT require doing anything to the camera every time it reboots), but it does require it to have internet access when booting up.

[sanscorp1]

I understand, but blocking it the right way, via a firewall, would require manual actions on the firewall rules after a power down.

At least, as far as I know you can't just allow a connection once and block it after a few minutes automaticly.

Thanks!

[guino]

@sanscorp1 yes, you're correct -- the pseudo offline method requires leaving the firewall open to the device (so it can block itself automatically within the device after booting).

Here's an offline patch you can try: ppsapp-offline.zip

Please use this instructions to patch it: https://github.com/guino/ppsapp-rtsp/issues/1#issue-759079080 -- you CAN use it on a ppsapp already patched for ONVIF/RTSP or you can use it on the original ppsapp.

Let me know if you have any issues or if it works as expected, And thanks for the Coffee!!

[sanscorp1]

It isn't much but a cup of coffee should be achievable. I really do appreciate your effort! I patched the allready patched ppsapp and the RTSP stream still works even though internet has been blocked.

Seems to be working like a charm!

I put the following line after starting busybox en before starting ppsapp but the time isn't corrected. /mnt/mmc01/busybox ntpd -d -q -n -p 192.168.0.1 #opnsense NTP

I confirmed that the NTP is running and I can check the time trough windows CMD with w32tm on either IP address and hostname.

Telnetting and entering busybox ntpd -d -q -n -p 192.168.0.1 results in an error "applet not found".

[guino]

@sanscorp1 thanks for confirming the offline patch.

for testing, I would remove the line from custom.sh and execute that command by hand (on telnet) to see if you get any error messages that would help figure out the issue. You can execute date before (to confirm the date is wrong) and after the ntpd command to verify it works.

'applet not found' is probably because you're running the built-in busybox instead of the one from the SD card -- make sure you execute /mnt/mmc01/busybox ntpd -d -q -n -p 192.168.0.1 (the path /mnt/mmc01/busybox is what you probably missed).

[sanscorp1]

When I use telnet, /mnt/mmc01/busybox ntpd -d -q -n -p 192.168.0.1 works fine.

When I place it in custom.sh it doesn't work.

#!/bin/sh
if [ ! -e /tmp/customrun ]; then
 echo custom > /tmp/customrun
 cp /mnt/mmc01/passwd /etc/passwd
 /mnt/mmc01/busybox telnetd
 /mnt/mmc01/busybox httpd -c /mnt/mmc01/httpd.conf -h /mnt/mmc01 -p 8080
 /mnt/mmc01/busybox ntpd -d -q -n -p 192.168.0.1
 if [ -e /mnt/mmc01/ppsapp ]; then
  PPSID=$(ps | grep -v grep | grep ppsapp | awk '{print $1}')
  kill $PPSID
  #/mnt/mmc01/set record_enable 0
  #/mnt/mmc01/set enable_event_record 1
  /mnt/mmc01/ppsapp &
 fi
fi
if [ ! -e /tmp/cleanup`date +%Y%m%d` ]; then
 rm -rf /tmp/cleanup*
 touch /tmp/cleanup`date +%Y%m%d`
 /mnt/mmc01/cgi-bin/cleanup.cgi > /tmp/cleanup.log
fi

[guino]

@sanscorp1 if it is working in telnet and not in the script it is likely because the command is running before the wifi is connected. You can try removing the existing ntpd line and try adding a sub-process with a delay right below the /mnt/mmc01/ppsapp &, this is what I would try first: (sleep 120; /mnt/mmc01/busybox ntpd -d -q -n -p 192.168.0.1) &

That basically should wait 2 minutes then run the ntpd command after the wifi is connected (assuming it happens within 120 seconds).

[guino]

@sanscorp1 adding to the above, if you don't have any ppsapp on the root of the SD card, you can use the line I suggested replacing the one you had (I expect it should also work).

[sanscorp1]

The sleep timer worked, the stream runs for roughly two minutes before the time is corrected.

The outdoor camera is now functioning as I had hoped. Now I have to find NVR software, find out how to virtualize it and figure out how to live view the streams on my phone. haha

One last question (for now), how can I disable SD card recording? I have a bunch of 2GB cards that are very suitable for running just the hack.

I assume it can be configured in tuya_config.json, but do I disable "enable_event_record" or "record_enable"? My guess is the latter.

[guino]

@sanscorp1 nice. You should be able to disable recording on the SD card by removing the # in front of the line #/mnt/mmc01/set record_enable 0 in your custom.sh script.

You would have to try using the 2GB chip -- there's a chance it may erase files on your SD card thinking there's not enough space for recordingd (even if they're disabled). To try all you have to do is format a 2GB SD card as FAT32 and copy the files from your current SD card into it -- you don't have to copy the video files obviously. I have heard mixed reports about what is the available space limit before it formats the SD card.

[sanscorp1]

I will experiment with this and will post the result after some time to verify if anything happend due to limited space.

Thank you again.