BazzDoorbell
BazzDoorbell copied to clipboard
guino
Off-cloud research
@guino, I hope you don't mind me creating a seperate issue, but I think it helps to keep the other topics on-topic and easier to read.
So let's discuss here what's what when it comes to off-cloud/offline usage of the doorbell. Currently it uses the Tuya cloud, which means the following, according to @m11tch research
when internet connectivity is blocked:
- you can not view recordings from tuya app, so seems to be streaming directly from SD upon request.
- RTSP is not available. (connection refused) (will check logs later)
- snap.cgi and mjpeg.cgi work fine
- button press does make the "ding dong" sound, but no mqtt message is sent (will check logs later)
- Camera still switches to night mode if dark
@jilleb I was thinking the same as we were taking over the other thread quite a bit :D Doing some more research later, will update this post with new findings.
Current status:
- offline mode is possible(online mode will also work, so use your firewall to block access)
- RTSP stream works, no more crashes.
- snap.cgi and mjpeg.cgi work fine
- logparser can be used to send mqtt messages on motion / button press
- RTSP over TCP consumes much less CPU compared to RTSP over UDP (About 10-20 VS 95) (apps like VLC and mplayer seem to default to UDP) so it is recommend to use RTSP over TCP instead. RTSP over TCP also seems alot more stable. (running without problems for over 12 hours.)
Not possible:
- 2 way audio
offline mode ppsapp: https://github.com/guino/BazzDoorbell/files/5672301/ppsapp-rtsp4.zip NOTE: only for following device/fw version:
| firmware version | hardware version | original ppsapp MD5 | device |
|---|---|---|---|
| ppstrong-c51-tuya2_lcs-2.9.6.20200628 | BE8S_H1_V10_433 | 50ad9c96c65c0e446d8b3d5c8c828957 | Bell 8S (LSC Smart Connect Smart Doorbell) |
Have a different ppsapp version? check out @jandy123 's write up on patching it: https://github.com/guino/BazzDoorbell/issues/4#issuecomment-742596905
logparser: credits to @jandy123 mqtt_log_parser.zip
Modify custom.sh, when about to restart ppsapp, to something like:
# 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 &
Upload log_parser.sh and mosquitto_pub to the root of sdcard; see archive contents. Modify log_parser.sh as needed, i.e., change mqtt server address, etc.
dmesg output when doorbell is pressed while it's not connected to the cloud:
initS (906): drop_caches: 3
door bell press down
Strnio_ioctl
AcShdn,open pwr
CMT211XA_Send size: 68
###cfg gpio OK name:spi1_sdo
cfg gpio ok:spi1_sdo
irq-----
send data:68
initS (906): drop_caches: 3
door bell press up
send data:68
send data:68
send data:68
send data:68
CMT211XA package Send finished!
initS (906): drop_caches: 3
Strnio_ioctl
AcShdn,close pwr
I use while true; do dmesg -c ; sleep 1 ; done to show the scrolling log
I don't see motion detected in dmesg though, perhaps motion detection is happening in tuya cloud or it is part of ppsapp which is not fully started yet?
Good question.. I'm looking for it in Ghidra. Sounds like something that would possibly happen in the cloud. I'll get back on this.
I have been downloading/viewing my .data files for the longest time - they play just fine in VLC when you set the demux to h264 demuxer (in advanced settings). It is kind of a pain having to switch between automatic and h264 but it works - just no audio. I personally like having the tuya app, so I plan to keep it. Just wanted to be able to use RTSP, mjpeg and be able to backup the SD card files as they’re created - and now I can do it all. Also I don’t record everything, only motion events and my camera doesn’t run hot at all. @jandy123 if your camera is running hot, check if you don’t have any left over streamer-arm or other processes running in the background from testing, etc. The mjpeg support I put together is just a jerry rig, so the ideal solution is that an application should be made for that purpose (and to make it more efficient).
The fact that I don’t record everything may also impact if the camera runs hot or not (haven’t tried recording everything) plus I have a 9v transformer at the house doorbell.
I don't see motion detected in dmesg though, perhaps motion detection is happening in tuya cloud or it is part of ppsapp which is not fully started yet?
Good question.. I'm looking for it in Ghidra. Sounds like something that would possibly happen in the cloud. I'll get back on this.
maybe getting ppsapp to run propperly is enough?, i'm no expert in Ghidra 😞 maybe it is enough if we can disable the mqtt connection in ppsapp as it is just constantly trying to reconnect, each time with a longer sleep time.. and not doing much else...
[01-01 01:00:35-- TUYA Debug][mqtt_client.c:1230] mqtt fail_cnt:6 and sleeptime:4756 ms
@guino:
-
Welcome back ! Guess, different timezones, jobs, etc.
-
I have no other apps running, streaming etc. And this is without enabling continuous recording. Just record on event setting in the app. It's also interesting that for you, apparently, 9V AC is enough. I couldn't get it running with anything (apart from USB) but with the supplied 12V DC adapter.
-
If I run it from USB, then it's getting a bit warm on the opposite side of the lens. If I run it from the 12V adapter, it gets quite hot around where the wires are connected. Again, I suspect some LDO and/or diode bridge ? I.e., dropping from 12V AC to 3.3V has to happen somewhere...
For me rtsp streaming still works after blocking outside connection.
Edit: Also, the doorbell push button gets transformed to mqtt event using log_parser. Could you guys confirm this ?
I'll check. Rtsp does work after blocking web access. But upon reboot it's dead.
I just restarted ppsapp from the console by accident.. got a lot of interesting output I will post later when I'm back at the pc.
I would expect recording continuously would make it hotter than recording events only - have not paid attention to be honest. The other doorbell I had (EZVIZ DB1) was hot as hell compared to this one. It may require more current to run at lower voltage (power=voltage * current) so maybe a bigger low voltage transformer would work, just not sure if it’s worth messing with it when it is already working.
If you guys are going to be doing stuff offline using the logs I think we should patch the debug log function to always print the output (there’s some sort of output level setting which I haven’t tried to find yet).
Regarding mqtt are those messages encrypted or require secret keys? Cause if not you could just write a new address in ppsapp and use your own server? Just a thought. It should be possible to ‘patch’ ppsapp into thinking the connection is working but that’s a bunch more work specially to do in multiple ppsapp versions.
In my case I have a guest network that only has internet access where I put these untrusted devices , then I limit what I access with iptables/ebtables, so I don’t mind that they’re online.
@guino connections to the tuya mqtt server are over TLS and require username/password. for internal usage this is ofc not necessary.. I will try redirecting the connection to a internal mqtt server that supports TLS to see if that is enough..
also saw ppsapp print a username and password (and more info) to be used for mqtt connection, but these did not let me connect to the tuya server.. perhaps password is a hash or encrypted?
@guino
It may require more current to run at lower voltage
Nope, this is not the cause for heating, since it's definitely cooler at 5V from USB. It's just some linear regulator which transforms the 12V > 3.3V that dissipates heat, I guess. But then, I didn't even open the device yet...
If you guys are going to be doing stuff offline using the logs I think we should patch the debug log function to always print the output (there’s some sort of output level setting which I haven’t tried to find yet).
As I said, I get same log output from ppsapp, so I can still see the forwarded mqtt events.
Also, in my case, the RTSP server seems to be created on the fly, when a client request (from LAN) is made. This works (as it should !!) without the cloud struff. I can post logs if needed.
@m11tch
I will try redirecting the connection to a internal mqtt server that supports TLS to see if that is enough..
This won't work. I've already looked at the communication in wireshark...
It seems they have made changes from 2.9.6 to 2.9.7 in a number of aspects (ie blocking HD RTSP, changes to log functions, some logging and probably more) -- those are the things I noticed when patching some of the files.
@m11tch
I will try redirecting the connection to a internal mqtt server that supports TLS to see if that is enough..
This won't work. I've already looked at the communication in wireshark...
I don't need the actual data, was just hoping that it would be enough to let ppsap to start up further..
@jandy123 RTSP does not seem to happen for me, what kind of request are you sending?
@guino I belive both me and jandy are running 2.9.6 though..
@m11tch
I belive both me and jandy are running 2.9.6 though..
Well, yes, but then we have different ppsapp...
As noted in the other thread by @adwiraguna, CPU usage in rtsp streaming mode gets to 100%. IS this only with blocked tuya servers ???
@m11tch
what kind of request are you sending?
What exactly you mean ? I just say vlc rtsp://192.168.2.179:8554
As noted in the other thread by @adwiraguna, CPU usage in rtsp streaming mode gets to 100%. IS this only with blocked tuya servers ???
Perhaps this is why they decided to block HD rtsp streams in 2.9.7?
@jandy123 I will try to open rtsp stream again later today when connection to tuya is blocked.. will come back with the results..
Well, CPU usage when streaming over RTSP is not that bad, actually.
Assuming blocked tuya servers, idling is round 3-5% (reported by top). When HD rtsp streaming to one client, it goes up to about 17-20%. The process itself ppsapp does take about 100% CPU, though.
Edit: Pushing the bell button while streaming also works ;)... and even the mqtt event gets forwarded, so it's just fine.
Temperature-wise, hmmm, still too hot, in my opinion (12 V AC).
Also, in my case, the RTSP server seems to be created on the fly, when a client request (from LAN) is made. This works (as it should !!) without the cloud struff. I can post logs if needed.
We have the same doorbell/firmware/ppsapp, but it isn't working
debug log from ppsapp:
The relevant part seems to be: IPC DEFS < ENABLE_ECHO_SHOW:1 ENABLE_CHROMECAST:1 ENABLE_CLOUD_STORAGE:1 >'
if we can influence these definitions.. would be cool
@jilleb I now see what you mean. If start ppsapp without tuya cloud connection, indeed, rtsp streaming does not work. Seems that ppsapp gets stuck on connecting to tuya hosts:
` [01-01 01:01:57-- TUYA Err][mqtt_client.c:1051] resolve mqtt host Fail:m2.tuyaeu.com erro:-100 [18:12:27.766 DEBUG tuya_network_manager.c:535] WIFI[0] Get IP:192.168.2.179 [18:12:28.009 DEBUG pps_net_manager_client.c:189] NETWORK KEEPALIVE [18:12:32.773 DEBUG tuya_network_manager.c:535] WIFI[0] Get IP:192.168.2.179 [18:12:37.782 DEBUG tuya_network_manager.c:535] WIFI[0] Get IP:192.168.2.179 gethostbyname error 0
`
Also, in my case, the RTSP server seems to be created on the fly, when a client request (from LAN) is made. This works (as it should !!) without the cloud struff. I can post logs if needed.
We have the same doorbell/firmware/ppsapp, but it isn't working
debug log from ppsapp:
The relevant part seems to be: IPC DEFS < ENABLE_ECHO_SHOW:1 ENABLE_CHROMECAST:1 ENABLE_CLOUD_STORAGE:1 >'
if we can influence these definitions.. would be cool
I noticed some config files in /home/cfg, maybe we can do something with those to manipulate? although I don't see anything usefull at first glance..
@jilleb
I never get to
IPC DEFS < ENABLE_ECHO_SHOW:1 ENABLE_CHROMECAST:1 ENABLE_CLOUD_STORAGE:1 >
In my case, ppsapp gets stuck looping the bove message.
@jilleb
I never get to
IPC DEFS < ENABLE_ECHO_SHOW:1 ENABLE_CHROMECAST:1 ENABLE_CLOUD_STORAGE:1 >
In my case, ppsapp gets stuck into
[01-01 01:01:57-- TUYA Err][mqtt_client.c:1051] resolve mqtt host Fail:m2.tuyaeu.com erro:-100 [18:12:27.766 DEBUG tuya_network_manager.c:535] WIFI[0] Get IP:192.168.2.179 [18:12:28.009 DEBUG pps_net_manager_client.c:189] NETWORK KEEPALIVE [18:12:32.773 DEBUG tuya_network_manager.c:535] WIFI[0] Get IP:192.168.2.179 [18:12:37.782 DEBUG tuya_network_manager.c:535] WIFI[0] Get IP:192.168.2.179 gethostbyname error 0
I think connection was not blocked during the startup of ppsapp in this debug log, can you confirm @jilleb ?
@m11tch
I noticed some config files in /home/cfg
I did see the stuff in /home/cfg. Tried to modify ota:0 in /home/cfg/capa.info in a hope to quiet the tuya app upgrade banner, but it didn't work....
The connectiong was blocked all the time.
I started ppsapp from sd-card in the console with the --help commandline, hoping it would generate some useful output.But....... after closing it, the doorbell no longer boots 😆
Connection was blocked all the time here too.
@jilleb Hmm, no boot at all ???
@jilleb Hmm, no boot at all ???
Nope.. but I'm confident it can be fixed 😄
edit: LOL, the SD-card is now empty 🤣 🤣 🤣 edit2: fixed it.