home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
73.55k stars 30.73k forks source link

Hard-coded UTC timezone in Zigbee entity #125938

Closed ruffson closed 1 month ago

ruffson commented 1 month ago

The problem

I am using a Zigbee-enabled pet feeder from Aquara for feeding my pet. I am also retrieving the amount of portions fed.

After I dispense food via the HA action or pressing the button on the device, the feeder must send back to Zigbee that food was dispensed, because it keeps track of the portions e.g. by tracking how many were dispensed "today".

The issue is that the entity sensor.cat_feeder_portions_dispensed_today resets at the new day in UTC time and not the time of the configured home assistant or local server time. You can see that in the screenshot below, the dispensed portions goes to 0 at 17:00 local time.

image

Now, I know this may not be a bug in Zigbee itself but I have a hard time understanding where to find and solve the issue. The pet feeder most likely will not have a clock and if it does, it would be synchronized with Zigbee itself. So something resets this counter at the wrong time. If this is a generic Zigbee entity (and not any specific Aquara integration), then the hard-coded timezone issue must be somewhere in the configuration of the integration or my Zigbee dongle?

If anyone can point me into the right direction, that would be amazing. The data is all there but it is just resetting at the wrong time.

I am using the SONOFF Zigbee 3.0 dongle.

What version of Home Assistant Core has the issue?

core-2024.9.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Zigbee

Link to integration documentation on our website

https://www.home-assistant.io/integrations/zha

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

My docker-compose.yml is quite simple:

version: '3'
services:
  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/home-assistant:stable"
    volumes:
      - /home/user/docker/homeassistant/config:/config
      - /etc/localtime:/etc/localtime:ro
    restart: unless-stopped
    devices:
      - "/dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20231120200719-if00:/dev/ttyUSB0"
    privileged: true
    network_mode: host

I can verify that localtime is accurate with zdump:

> zdump /etc/localtime
/etc/localtime  Fri Sep 13 22:35:06 2024 PDT
home-assistant[bot] commented 1 month ago

Hey there @dmulcahey, @adminiuga, @puddly, @thejulianjes, mind taking a look at this issue as it has been labeled with an integration (zha) you are listed as a code owner for? Thanks!

Code owner commands Code owners of `zha` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign zha` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

(message by CodeOwnersMention)


zha documentation zha source (message by IssueLinks)

puddly commented 1 month ago

The device is likely reading from the Time cluster. I recently fixed a bug with it where the local time zone was not used but it's possible the value isn't read very often.

Can you enable ZHA debug logging and try to re-join the device? You don't need to remove it from ZHA, just allow joins and factory reset it. When you disable debug logging hopefully the log will show what the device is trying to read.

ruffson commented 1 month ago

The device is likely reading from the Time cluster. I recently fixed a bug with it where the local time zone was not used but it's possible the value isn't read very often.

Hey @puddly thanks a lot for the fast response!

I assumed that re-joining the device is done with the reconfigure button in HA but that did not seem to do much even though it was successful so I went ahead and deleted and re-added it after all. Here is the log:

home-assistant_zha_2024-09-14T19-21-40.987Z.log

puddly commented 1 month ago

I believe this is a device bug:

2024-09-14 12:09:29.790 DEBUG (MainThread) [zigpy.zcl] [0x5481:1:0x000a] Decoded ZCL frame: Time:Read_Attributes(attribute_ids=[0])
2024-09-14 12:09:29.791 DEBUG (MainThread) [zigpy.zcl] [0x5481:1:0x000a] Sending reply: Read_Attributes_rsp(status_records=[ReadAttributeRecord(attrid=0, status=<Status.SUCCESS: 0>, value=TypeValue(type=UTCTime, value=779656169))])

The device reads the time attribute of the coordinator's Time cluster, which is the UTC time. It does not read the time_zone or local_time attributes. This should be fixed in https://github.com/zigpy/zha-device-handlers/ and the quirk should lie to the device and send the local_time when the device tries to read time.

ruffson commented 1 month ago

Oh okay, thanks @puddly I will bring this up over there in the other repo then. Really appreciate your help narrowing this down!