You should still be able to use the tapo:// go2rtc stream source even if the camera does not support the rtsp:// via the camera account option. Have a look at my frigate configuration for reference - https://github.com/kennedn/frigate/blob/7c56604e819d2cb1da28...
Hello, as I alluded to in my blog post you should use tapo:// as the main stream source to get two-way audio. You can then optionally use rtsp://.../stream2 as a lower resolution sub stream source for detections. Defining both tapo:// and rtsp:// in a single stream is redundant as go2rtc only picks one or the other. My own configuration is here for reference https://github.com/kennedn/frigate/blob/7c56604e819d2cb1da28...
Groceries and cleaning come to mind. To be honest it is a very minor inconvenience but I have been looking for an excuse to get my hands dirty with reverse engineering a circuit. The problem was just annoying enough to act as a motivator.
I installed the fridge freezer myself a few years back, its inside an integrated unit and fairly complicated to remove. I would need to gut the fridge freezer of items, detach and remove the front unit doors from the fridge, detach the fridge from the side panels and the wall, remove the skirting to get under to remove the wall plug and then physically and delicately lift the fridge freezer to be able to slide it out. This is all without the guarantee that there is even a convenient way to gain access the main board.
My website / blog is at https://kennedn.com/. The website portion is a bit of a weirdo. I deliberately wrote it from scratch to try and learn the basics of web design / JavaScript and evidence of that can be seen in the wacky ways I am achieving state management (sessionStorage) or the fact that the CSS is balanced on a hairpin. I made it just extensible enough that I've not had a need to refactor it to date though.
frida -U \
-f com.tplink.iot