I recently got a C1, when I turn it on, ZHA seems to find it (at least it’s finding something…) and gets stuck in the interviewing stage… after about 30 seconds the LED goes out and all buttons are non-functional (i.e the manual feed button, and holding down reset doesn’t do anything unless I recycle the power).
Is this normal behaviour and I’m doing something wrong? Or did I get a dud?
A few things…
You can try keeping the pairing alive by pressing the pairing button (or you might need to hold the pairing button down again until it beeps).
It should show up in the logs as aqara.feeder.acn001. You can also search the logs for the NWK and IEEE to see what information it is providing to the coordinator during pairing.
You could try pairing it through a specific router device.
Occasionally when I have a device that doesn’t seem to finish the interview and configuration while on this screen, but it does finish after a while. I just go back to the device list screen and check on it in a few minutes. I’ve found devices that I thought failed interview and configuration there.
Turns out it was a dud USB A plug connector
Do you use this tho? If so, do you have an automation set up for scheduled feedings you can share? No worries if not…just trying to make my life simple
I do use it. I have two of them.
But I don’t use an automation. I am actually working on a PR to get the on-board schedule working with ZHA.
dev ← iamjoshk:dev
opened 04:34PM - 12 Jun 25 UTC
Add support for local scheduling on-board the Aqara C1 Pet Feeder
## Proposed… change
This enables the handling of the scheduling string "fake" attribute so the on-board schedule can be set on the device.
The scheduling_string can be written to the fake attribute under OppleCluster->scheduling_string in the Manage Zigbee Device UI. It can also be set using the `zha.set_zigbee_cluster_attribute` action.
The format for the string is an integer in format DDHHMMPP where:
- DD is a two digit code:
```
77: everyday
55: workdays
22: weekend
11: mon
12: tue
13: wed
14: thu
15: fri
16: sat
17: sun
44: mon-wed-fri-sun
33: tue-thu-sat
```
- HH is 2 digit hour in 24H format
- MM is 2 digit minute
- PP is 2 digit portions
Example schedule_string would be `77073005` for every day at 7:30am for 5 portions.
Up to 5 schedules can be set in consecutive 8 digit segments: `770730057713000277194505` would be 3 feedings every day at 7:30am for 5 portions, 1:00pm for 2 portions, 7:45pm for 5 portions.
The scheduling_string can be set using Manage Zigbee Device -> OppleCluster -> scheduling_string (0x1393)
Click Write attribute, then you can read the feeder_attr (0xfff1) to review the schedule string. It will be converted to hex in feeder_attr.
The scheduling_string can also be set using the `zha.set_zigbee_cluster_attribute` action under Developer Tools -> Actions.
```
action: zha.set_zigbee_cluster_attribute
data:
ieee: {device ieee}
endpoint_id: 1
cluster_id: 64704
attribute: 5011
value: 7711000577010005
manufacturer: 4447
```
Value must be an integer when submitting the scheduling_string.
Note that the timezone on the device is UTC, so schedules should be adjusted accordingly.
I have tested and am currently using this on my Aqara pet feeder. The manual feeding button, child lock switch, LED indicator switch, portion weight number select, and serving size number select all work.
The feeding mode entity is no longer provided for my device using this quirk. However, using the existing quirk did NOT reenable the feeding mode entity so I am not sure if this is because of the quirk or not. It can still be set through Manage Zigbee Device and through the `zha.set_zigbee_cluster_attribute` action.
Also, while this PR includes a feeding_source option for Schedule, it does not work. It appears that the existing enum_factory in zigpy.types.basic defaults to `undefined_0x00` and this PR does not resolve that.
In my experience, the local schedule has been retained through reboots. The device seemingly delivers food within a 30 second window of about 5 seconds before the designated time to 25 seconds after the designated time.
The device time is reported in the debug log.
## Additional information
Fixes https://github.com/zigpy/zha-device-handlers/issues/4024
- The device time zone is UTC and this PR does NOT change that.
- The feeding_mode entity is broken (can still be set as described above).
- Feeding Source still does not properly report when the schedule has been used to deliver food.
- There is no record of the schedule string once it has been set other than checking via the feeder_attr attribute. However, feeder_attr only returns the most recent attribute changed, so after any other attribute change the feeder_attr will not return the schedule string attribute. It might be helpful to use helpers and a script to set the scheduling string so you have a record of it.
- There are some logging changes that helped debug some specific scenarios, and I felt they were helpful, so I left them in.
This is my first "real" PR, so be gentle, please.
Full disclosure - This ended up being more complicated than I anticipated and I did use GH Copilot to help me when I got stuck in spots beyond my skill. The code may need some human cleanup. I am currently using this version of the quirk and I have not found any issues with it in my production environment.
## Checklist
- [x] The changes are tested and work correctly
- [x] `pre-commit` checks pass / the code has been formatted using Black
- [x] Tests have been added to verify that the new code works
