unable to modify tuya_config.json

[dystechnic]

HI,

My hardware is BE8S_H1_V10_433 and my firmware version is 2.9.7 I used the #13 way to 'hack' the firmware and use the rtsp patched ppsapp for version BE8S_H1_V10_433. I've got rstp video and MQTT working. I tried to enable ONVIF and Motion Detection by setting this in the custom.sh script using the set command. But without result. The tuy_config.json is not modified. I tried to modify it using telnet and VI but after every reboot the file is back to it's original state and my changes are gone.

How can I modify the config file without it getting rewritten at every boot cycle?

[guino]

@dystechnic Not all 2.9.7 versions have onvif. If there is a patch for your ppsapp and it says it has onvif then it should work. If you’re trying without a patching there’s a 50/50 chance it will work but from your description it sounds like there’s no onvif on your ppsapp OR it is downloading the settings from the cloud and overwriting them (doubtful based on your comments).

There is no separate ntp deamon - busybox implements ntpd and that is all you should need to set the time while online. That said: the only reason you should ever need to use busybox ntpd is if you used an offline patch. If have not patched the ppsapp then it will get the time and set it before enabling any kind of streaming support (app/rtsp/onvif).

Without more information that is all I can say, but if you post your /devices/deviceinfo and tell me witch patch you used (if any) I can try to help further. If there was no patch available for your ppsapp then you should post it so I can check what it has or doesn’t have available.

[dystechnic]

Hi Guino,

My device info:

devname "Smart Home Camera"
model   "Bell 8S"
serialno    "061062486"
softwareversion "2.9.7"
hardwareversion "BE8S_H1_V10_433"
firmwareversion "ppstrong-c51-tuya2_lcs-2.9.7.20201020"
authkey "qusU8QyiRGOXrfegmBKBPSncEHBxxpND"
deviceid    "pp0193a19eb92ce8d663"
identity    "MR2005212800901245"
pid "aaa"
WiFi MAC    "d4:d2:d6:d9:ea:d5"

I use the offline mode ppsapp from the Off-cloud research issue https://github.com/guino/BazzDoorbell/issues/4 and have patched according to the #13 issue. As far as I can see evertything works.I have a working RTSP stream to my zoneminder instance and I have MQTT working to my local MQTT server. Ever time someone pushes the doorbell I receive a message. So, that part is working. I tried to change some settings in the tuya_config.jsonbut the changes are overwritten every boot cycle. This is my current custom.sh

#!/bin/sh
if [ ! -e /tmp/customrun ]; then
 echo custom > /tmp/customrun
 cp /mnt/mmc01/passwd /etc/passwd
 /mnt/mmc01/busybox ntpd -d -p xx.xx.xx.xx -q
 /mnt/mmc01/busybox telnetd
 /mnt/mmc01/busybox httpd -c /mnt/mmc01/httpd.conf -h /mnt/mmc01 -p 8080
 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/set onvif_enable 1
  # Original command
  # /mnt/mmc01/ppsapp &
  # debug info from ppsapp  forwarded to output.log
  # /mnt/mmc01/ppsapp  2>&1 | /mnt/mmc01/log_parser.sh /mnt/mmc01/output.log &
  # no debug info  
  /mnt/mmc01/ppsapp 2>&1 | /mnt/mmc01/log_parser.sh /dev/null &
 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

and this is my tuya_config.json (located at /home/cfg)

{
        "version":      0,
        "sleep_mode":   0,
        "alarm_fun_onoff":      0,
        "alarm_fun_sensitivity":        1,
        "alarm_fun_mode_switch":        0,
        "alarm_fun_time_start": 0,
        "alarm_fun_time_end":   0,
        "flip_onoff":   0,
        "light_onoff":  1,
        "night_mode":   0,
        "sound_detect_onoff":   0,
        "sound_detect_sensitivity":     0,
        "watermark_onoff":      1,
        "event_record_time":    60,
        "enable_event_record":  2,
        "record_enable":        0,
        "motion_trace": 1,
        "motion_area_switch":   0,
        "motion_area":  "",
        "motion_tracking":      0,
        "cry_detection_switch": 0,
        "humanoid_filter":      1,
        "jingle_mode":  0,
        "jingle_sound": 1,
        "jingle_volume":        100,
        "jingle_exist": 0,
        "flight_bright_mode":   0,
        "flight_light_brightness":      100,
        "flight_pir_set":       0,
        "flight_pir_one":       0,
        "flight_pir_two":       0,
        "flight_pir_three":     0,
        "flight_pir_sensitivity":       0,
        "flight_alarm_fun_onoff":       0,
        "flight_on_off":        0,
        "flight_pir_light_on_time":     30,
        "flight_warn_switch":   0,
        "flight_dualbrite":     0,
        "flight_ontime":        0,
        "flight_highbrightess": 10,
        "flight_lowbrightess":  10,
        "flight_mode":  0,
        "flight_motion_sens":   0
}

As you can see the set commands from the custom.sh are not enforced. In this case the '/mnt/mmc01/set onvif_enable 1' command. But that is just an example. I don't realy need ONVIF at this moment because the RSTP stream gives me what I need. I would like to enable motion detection and the watermark option for example.

Thank you for your time and effort in this project.

[guino]

@dystechnic

1. I see the ntpd command on your custom.sh but it has xx.xx.xx.xx as parameter - you need to replace that with a valid ntp server ip for it to work.
2. If you want to use motion recording you should change this line #/mnt/mmc01/set enable_event_record 1 to /mnt/mmc01/set enable_event_record 1
3. your tuya config json file doesn’t have the onvif_enable setting which means the set command in the custom.sh will not find the setting to modify the file (and it will NOT add it). You would have yo manually add it in order for it to work. If you said you manually changed it and it did not ‘stay’ then the app must be rebuilding it. You could try to modify the file and set the file permissions so it can’t be modified by ppsapp OR you could try to remount that partition as read only. It is possible that whatever app you used for initial setup may affect how ppsapp is reading/writing that file when it starts. My advice would be to use the tuya app to configure the device as close to what you need as possible (enable montion-only recording) THEN just use the script to adjust whatever else isn’t available in the app. If the /mnt/mmc01/set enable_event_record 1 doesn’t work then it is possible that the ppsapp is behaving differently because of the offline patch you’re using (ie recreating the json file from default settings since it can’t connect to the server).

Again my advice is to configure the settings with the phone app and original ppsapp as close to what you need as possible, then use the patch that gives you what you need and adjust whatever is left last. There are other people with that same firmware what have been able to make it work so it should be possible - the app used for initial setup may also make a diference as that may affect how ppsapp sends/gets data to/from the tuya servers. I use the tuya app and ppsapp has never replaced settings I changed manually, but it could be just luck or the type of my devices.

[dystechnic]

Hi Guino,

1. I see the ntpd command on your custom.sh but it has xx.xx.xx.xx as parameter - you need to replace that with a valid ntp server ip for it to work.

I know. I anonymized the file ;-) Thank you for the info. I now understand why the app is rewriting the file. I do not want to use the Tuya app so I wil try if an other method will work for me. I'm going to try to change the set script so that if the line doesn't exist it will add it. That way I hope to overcome the rewrite issue. If that fails I will make the file read-only after changing it manualy.

Regards.

[guino]

@dystechnic cool, you seem to know your way around it enough to mess with it. If setting the file to read-only doesn't work you may need to add in a line to copy a 'pre-set' json file to the partition and then make it read-only during boot (right before running the patched ppsapp and right after copying the json file.

[dystechnic]

That would also be a valid solution. But I will try modifying the set script first. If that works it can be used by others if it is of use for their use case.

[dystechnic]

I've found a solution and I thought it would be helpfull to share that here. With slightly changed custom.sh and set scripts I now can edit the tuya_config json file. The problem was/is that with the offline version the json script is rewritten at boot with default values. At least that's what's happening in my situation. With the two scripts below I am able to change the values of the file before the restart of my patched ppsapp. All other functionality of the custom script is unchanged.

My modified custom.sh

#!/bin/sh
if [ ! -e /tmp/customrun ]; then
 echo custom > /tmp/customrun
 cp /mnt/mmc01/passwd /etc/passwd
 /mnt/mmc01/busybox ntpd -d -p <YOUR IP HERE!> -q
 /mnt/mmc01/busybox telnetd
 /mnt/mmc01/busybox httpd -c /mnt/mmc01/httpd.conf -h /mnt/mmc01 -p 8080
 if [ -e /mnt/mmc01/ppsapp ]; then
  PPSID=$(ps | grep -v grep | grep ppsapp | awk '{print $1}')
  kill $PPSID
  #
  # make sure tuya_conf is writeable
  chmod 666 /home/cfg/tuya_conf.json
  #
  # add or change tuya_conf settings to your liking
  #/mnt/mmc01/set record_enable 0
  #/mnt/mmc01/set enable_event_record 1
  #/mnt/mmc01/set onvif_enable 1
  #
  # Enable or disable logging to file
  # Original command
  #/mnt/mmc01/ppsapp &
  #
  # debug info from ppsapp  forwarded to output.log
  #/mnt/mmc01/ppsapp  2>&1 | /mnt/mmc01/log_parser.sh /mnt/mmc01/output.log &
  #
  # no debug info  
  /mnt/mmc01/ppsapp 2>&1 | /mnt/mmc01/log_parser.sh /dev/null &
 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

and my set script

#/bin/sh

SNAME=$1
NEW=$2

if grep -q $SNAME /home/cfg/tuya_config.json; then
  OLD=$(grep -c $SNAME /home/cfg/tuya_config.json | awk '{sub(",","",$2); print $2}')
  echo statement found!
  if [ "$NEW" == "$OLD" ]; then
    echo "$SNAME is already set to $2"
  fi
  echo changing value
  sed -i '/'$SNAME'/c\  \t"'$SNAME'\" : \'$NEW'\,' /home/cfg/tuya_config.json
#  sed -i 's/"'$SNAME'":\t'$OLD'/"'$SNAME'":\t'$NEW'/g' /home/cfg/tuya_config.json
else
  echo creating new entry
  sed -i '1a\\t"'$SNAME'":\t'$NEW'\,' /home/cfg/tuya_config.json
fi

Thank you for your help. I'm ready for the next hurdle ;-)

Regards.

[guino]

@dystechnic glad you got it working. I would advise against writing changes to the flash on every boot but there may not be an option in your situation so I would suggest avoiding reboots as much as possible. A possible alternative may be to make the tuya_config.json a symbolic link (fixed/unchanged in the /home/cfg partition) to /tmp/tuya_config.json so that ppsapp/you can modify it on every boot without writing changes to the flash itself -- that would prevent unnecessary writing to the flash which could eventually cause it to fail in the future.

[dystechnic]

@Guino You've got a good point. But if the software rewrites the file on every boot then the problem of possible failure is already there.The symbolic link option is something I will pursue a bit further. Thank you.

[guino]

@dystechnic I know for a fact the original ppsapp (unmodified) does not re-write the tuya_config.json file on every boot. If I recall correctly it compares the settings it gets from the server and only writes the file if there's anything different. In you case with an offline patch (and likely access to servers disabled) I can only guess it's thinking the setting on the file are different and trying to re-write on every boot.

I would definitely give the sym link a try as a good pratice measure, but the flash chip is rated for at least 100 thousand writes per block so if you reboot it once every day that would give you: 10000/365=273 years so it's not like it's the end of the world.

[dystechnic]

@guino I agree. I deny all Internet traffic for the doorbell through my Firewall. That probably causes the rewrite. I think that, with a calculated lifespan of over 200 years, the flash chip will survive me. So I guess I'm safe with this solution.

Thank you for your help.