You can find a full file system dump which gives a lot of information about how the device works. I would take a look at some of the bash scripts, as they give good insight into how the device functions.
I also mapped out the boot sequence as well.
@tmfinnell could you try something on the newer models? If you have a SD card available could you place a bash script on the root of the SD Card named tmp_test.sh. You can find some test scripts I have which might be of interest to you. I would take the script dump_basic_info.sh and rename it to temp_test.sh and put it on the SD card. Then reboot your device and wait. It should run the script then boot normally. Here is the link to the dump_basic_info.sh.
I am interested if the devices are similar enough to have the same boot sequence.
And yes, I see a bunch of references to IPC in the files. I do not see a process running called IPC. But I see a config for the camera and some other settings. Here is a whole folder called “ipcam”.
I’ve tried this with no success. Admittedly, I probably screwed myself as I updated the firmware on the feeder almost immediately after getting it (firmware v3.0.21). tmp_test.sh does not appear to run (even tried saving it as temp_test.sh, the GitHub mentions both naming conventions). I also tried loading the firmware you had but it didn’t seem to take. Telnet does not appear to be open anymore either. I’m happy to dig into it further but not having much luck yet.
@projectalarum My bad on the naming. The correct name of the script should be tmp_test.sh. Also the SD card needs to be formatted as FAT32. The script should be on the root of the SD card. Then unplug, power off the feeder (remove batteries if you have them), then reboot the machine.
One, reach out to support, and like “My pet feeder is having wifi issues/other issues. Is there away send diagnostic/debug info to you to help troubleshoot?”. That is how I got the documentation on the flashing guide found in my GitHub repo.
Second, would be to open the device like @tmfinnell did and get UART connection. You might be able to see if you can dump the firmware, then use some tools to modify and reflash it with a patch (which opens telnet/ssh). This is a lot harder.
@projectalarum could you confirm the script you ran, the name of it and the format of the SD card?
@tmfinnell BTW, I am making some good progress on compiling some new applications for the pet feeder. There seems to be work done by the communicate for similar chip sets for various over IPC cameras. I am hoping using the same cross tool chain and compilers will allow me to build software I need.
@drcrow I got the non-Tuya PLAF203 version and I tried to run the script you provide. I formatted my SD as FAT32 and renamed the dump_basic_info.sh file to tmp_test.sh and it didn’t work. It looks like my SD was renamed by the feeder and it also created a lot of files that fills the entire SD card available space (I removed the SD card just a few seconds after the feeder turned on). I got nothing related to a finding folder
For users of the PLAF103 v2 (MQTT) and other non Tuya devices I reversed a part of the Petlibro API !
I use Waydroid with mitmproxy in WireGuard mode and patch the latest APK from APKPure with apk-mitm and the mitmproxy’s SSL CA and set it as a system trusted CA.
The API is quite simple, I created a Hoppscotch collection with my firsts findings.
I’m not sure how I can share this, but I might try to create a custom integration, at least for PLAF103 v2.
When you login, you logout your last session (like your phone), this might require another account with share access to the devices.
Something interesting I found while diffing the network requests of the app, the app use MQTT but I haven’t seen any messages go through.
@atomicpapa My feeder (PLA203) is a Tuya device, so I’m using the Tuya Local integration. If you’re not familiar with this integration, there are various guides on there on how to get the device in HA with this integration, I don’t have a particular one I’d recommend. Anyway, this will create a Feeder device in HA with several entities (mine has 21 entities), however the camera entity doesn’t work.
I got the camera working by using the Scrypted Add-on. I already use it get my Unifi cameras to work “natively” with Google Assistant, so I tried adding the Tuya Plugin in Scrypted. The Tuya Plugin takes your Tuya developer credentials and picked up the camera (I think, I set it up a while ago). From there, I was able to create a camera entity using the Generic Camera integration in HA. It takes a second for the camera to connect usually, but it does work decently well.
I have a One RFID Pet Feeder (PLAF301) and a Dockstream Connect PLWF105 that I would be glad to test on, or pull any data you need. Probably not needed for API hacks, but I can take em apart too if needed and interface with the hardware as needed
Hi there. I was wondering if your pet feeder is constantly going unavailable with local tuya integration? I have this problem, and it’s truly annoying.
I do have the same issue as well with the local tuya integration not taking in the camera, and therefore I’m using the cloud tuya integration for this. Might it be that those two integrations at the same time is what is disturbing the availability maybe?
@teachingbirds I’m using the Tuya Local integration (not LocalTuya) for the pet feeder and haven’t noticed the anything going to “Unavailable”. Aside from the camera, far as I know, everything has continued to work well, but full disclosure, I use the Smart Tuya app to set a feeding schedule and the HA integration for info/ad hoc feedings. I do this because just in case the integration does break, I don’t want to risk my cats not getting fed.
For the camera, I never got it working directly using the Tuya Local integration. Since I’m already using the Scrypted addon to pass my Unifi cameras into Google Home, I was able to set up a similar pattern the feeder camera and Home Assistant. In Scrypted, I set up the Tuya integration and added the requisite credentials from the Tuya Cloud developer console. Now the feeder camera loads in Scrypted. Next, I added a generic camera in Home Assistant pointing to the camera URL in Scrypted. Now the feeder camera works in Home Assistant.
Thank you for responding! Since last night everything seems stable, so I don’t know if it was a temporary thing or if it has something to do with me disabling the Tuya cloud integration. Will have it running like this for a while, and then try to activate that again for the camera. Will also look at the scrypted addon! Do you know if the camera has a url to use, or do you just get that in scrypted via the Tuya plugin?
No problem Hopefully that info helps you get things set up and working.
The camera URL comes from Scrypted. Once the feeder camera is set up in Scrypted, you can find the RTSP rebroadcast URL in the camera’s stream settings page. The RTSP path uses this format (at least in my case): rtsp://localhost:<port>/<unique id>. When I added the generic camera to Home Assistant, using localhost wasn’t working, but replacing it with the loopback address (127.0.0.1) worked great.
Example RTSP Rebroadcast URL in Scrypted: rtsp://localhost:12345/1k4667k3k4jh66a3
Example RTSP URL in Home Assistant: rtsp://127.0.0.1:12345/1k4667k3k4jh66a3
One other note–the camera did suddenly stop working recently. Scrypted was complaining about bad credentials, but I hadn’t changed anything. I had to renew my developer license in Tuya and then it started working again shortly thereafter.
Hopefully that info helps you get things set up and working.