search

icex2 / plaf203

AppDaemon integration for the Petlibro Automatic Feeder Model 203S
The Unlicense
4 stars 2 forks source link
home-assistant

readme

Petlibro Automatic (Cat) Feeder (PLAF) AppDaemon integration/app

This is (currently) a prototype AppDaemon-based application to integrate Petlibro's Automatic Feeder model PLAF203S into home assistant using MQTT. This enables users to control and monitor their device locally without Petlibro's proprietary App and Cloud platform.

Disclaimer and remarks

I am releasing my research and code to the public so interested hackers and home enthusiasts can pick it up and take it to the next level. It would make me glad to see this research serves as a foundation for creating a proper home assistant integration for these devices.

The goal of this project is (currently) NOT to provide a fully working and battle tested integration for the device and it's different models and versions.

I am appreciating any comments/suggestions or contributions to this in the form of issues or pull requests with bugfixes or improvements and I eventually look into these. However, I have no intentions nor capacity to become a maintainer of this.

License

Source code license is the Unlicense; you are permitted to do with this as thou wilt. For details, please refer to the LICENSE file included with the source code.

Status quo

All of my research and implementation is based on a PLAF203S device with:

Done

Not working/not implemented

Known issues/broken

Reverse engineering and research

Differences tuya version (PLAF203) vs. mqtt version (PLAF203S)

Even the feeders look identical from the outside, the hardware and software stack are very different.

More information can be found on the home assistant forums already.

The key difference relevant to kicking off the reverse engineering efforts here were:

Setup

Serial console and debug output

Luckily, the device has three pins on the PCB exposed and easily accessible which are RXD, TXD and GND to hook up a serial console via a serial adapter USB adapter with the baudrate set to 115200. The device outputs all terminal output, from initial bootloaders, the kernel and userspace to the serial console.

For example, using minicom: minicom --capturefile capture.dump --baudrate 115200 --device /dev/tty.usbserial-130

Which also writes all output to a file called capture.dump which was very useful to come back to package dumps that I created while playing around with the official app.

Furthermore, the main application is also very verbose with a lot of useful debug output to understand and debug application and device behavior including full MQTT sent and received message dumps.

Remark: I haven't been able to send keyboard inputs to the device which would have allowed me to interrupt the boot process and probably use the shell that is spawned during the boot process.

Network connection

In order to get the device on-boarded and accessible on my local network, I used the official petlibro app once to pair the device to my local wifi. Once that was finished, I blocked all access to the outside for the device as that's not needed anymore for running it fully local (without using the official app).

MQTT connection

AppDaemon integration configuration

The current project structure is kept as a simple "mono-file" which makes it fairly straight forward to deploy it to AppDaemon:

Feeder configuration

All configuration options of the feeder are exposed as writable configuration entities on the MQTT device such as switches, text, sliders, number boxes or drop-down lists.

Most of these should be self-explanatory, except for the food plans. Currently, up to 10 food plans can be configured. The food plan defines when the feeder is outputting a specific amount of food automatically.

This is currently implemented by providing a json formatted data structure on the available configuration entities. Contributions to make this more user-friendly but also avoiding complexity are very welcome.

Here is an example of one food plan that runs daily at 19:00 with the feeding sound disabled and outputs 3 portions. Just copy-paste into one or multiple food plan slots and make sure the id field differs (just increment it, that's sufficient).

{"id": 1, "execution_time": {"hour": 19, "minute": 0}, "scheduled_days": ["MONDAY", "TUESDAY", "WEDNESDAY", "THURSDAY", "FRIDAY", "SATURDAY", "SUNDAY"], "enable_audio": false, "play_audio_times": 1, "grain_num": 3}

Scheduled days is a set of days when to run the plan.

Some more network communication

Capture the network traffic and also looking into the firmware, I discovered the following hostnames and IP addresses that are either used or potentially used:

The "pet feeder procotol" over MQTT

Video and audio streaming

No actual work has been done on this. It seems to require a re-implementation of the server to talk to the client portion of the device correctly in order to implement local video streaming.

Maybe there is an easier solution to modify the system once it is possible to access it.

Feeding audio playback