Core: Onvif integration is not picking up your Timezone

[friendodevil]

The problem

Environment

Home Assistant 0.108.3
HassOS 3.13
Onvif integration

Problem-relevant configuration.yaml

  - platform: onvif
    name: Gate
    host: 10.0.1.211
    profile: 0
    username: !secret gbl_pl960_username
    password: !secret gbl_pl960_password
    port: 2000
    extra_arguments: '-pred 1 -q:v 2'

homeassistant:
  latitude: !secret latitude
  longitude: !secret longitude
  unit_system: metric
  time_zone: !secret TZone
  customize: !include customize.yaml



md5-84226badc8eef433dfec13d43b488a17



Logger: homeassistant.components.onvif.camera
Source: components/onvif/camera.py:145
Integration: onvif (documentation, issues)
First occurred: 5:26:01 PM (1 occurrences)
Last logged: 5:26:01 PM

The date/time on the camera (UTC) is '2020-04-21 17:27:39+00:00', which is different from the system '2020-04-21 14:26:01.612970+00:00', this could lead to authentication issues

Additional information

[McGiverGim]

I can confirm I have the same error.

[Xilt]

I have the same error and have had for quite some time.

[friendodevil]

Thanks @Xilt for confirming. Do you use a consistent stream / does it also get stuck after a few hrs?

[hunterjm]

This is a warning. It does utilize the timezone correctly, but converts to UTC when doing a comparison. The solution is to fix the time settings on your camera. The warning is saying your Home Assistant and your cameras have two different system times, which could cause issues with authentication.

[user897943]

I have had this error since March when I bought my first ONVIF cameras and confirm the setting on the cam's webui is correct, homeassistant also has a timezone setup. @hunterjm please clarify, see screenshot:

The camera's time is the exact same as the time in my Windows system (BST - London time under British Summer Time / DST)

HomeAssistant is showing this:

arch | armv7l
-- | --
dev | false
docker | true
hassio | false
installation_type | Home Assistant Core on Docker
os_name | Linux
os_version | 4.19.97-v7l+
python_version | 3.7.7
timezone | Europe/London
version | 0.110.1
virtualenv | false

And I confirm HA is showing the correct time if I create a custom clock card.

[hunterjm]

I noticed that my onvif doorbell camera is off an hour when reported through ONVIF and tracked it down to the firmware doing improper time adjustments when DST is configured. When I manually change the time zone setting and disable DST, it shows correctly. Unfortunately that means I’ll need to reset that clock along with my microwave and oven twice a year 🤣

[user897943]

Rather than relying on useless Chinese vendors that ignore the issue as there is a more serious issue with my cameras about the IR that they are not fixing, so no chance of them fixing this, can the owner of this integration put an option for a manual clock override, or at least an option to match the HA system clock, that way we don't get the errors because they are extremely annoying on the logs, the more cameras you have the more errors you see.

[McGiverGim]

Yes, it will be great. It seems a very common error/bug.

[hunterjm]

This warning should only show up once on Home Assistant starts. I'm not suggesting we rely on "useless Chinese vendors". The warning is there for those that are able to adjust the date/time in the camera's interface. I'm still deciding on what the best way to handle this for cameras that support events are, but that warning will not be going away. If you don't want to see it in your logs, turn it off in your configuration.

[SatWiz]

It is not only a startup warning. Without correct camera time which match system time all camera events will not be enabled.
2020-05-27 01:32:02 WARNING (MainThread) [homeassistant.components.onvif] The system clock on 'achter' is more than 5 minutes off. Although this device supports events, they will be disabled until the device clock is fixed as we will not be able to renew the subscription.

Weird is that system time voor onvif is GMT +00 and my camera time according from onvif intergration think it is GMT +01. While actually my camera and hass system time is GMT +02. See this log line.
2020-05-27 01:32:01 WARNING (MainThread) [homeassistant.components.onvif] The date/time on the device (UTC) is '2020-05-27 00:32:01+00:00', which is different from the system '2020-05-26 23:32:01.755709+00:00', this could lead to authentication issues

I now have to set my camera time to GMT +00 and DST off to have my camera correctly setup using onvif integration with motion detection.

[m-alzahrani]

Same problem here
my camera is Victure 530
I can't even see the stream. although its working well on ONVIF program on Windows
the ONVIF plug-in can find the stream but doesn't work

Uncaught exception
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/util/thread.py", line 20, in run
    run_old(*args, **kwargs)
  File "/usr/local/lib/python3.7/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/src/homeassistant/homeassistant/components/stream/worker.py", line 49, in stream_worker
    container = av.open(stream.source, options=stream.options)
  File "av/container/core.pyx", line 354, in av.container.core.open
  File "av/container/core.pyx", line 225, in av.container.core.Container.__cinit__
  File "av/container/core.pyx", line 257, in av.container.core.Container.err_check
  File "av/error.pyx", line 336, in av.error.err_check
av.error.InvalidDataError: [Errno 1094995529] Invalid data found when processing input: 'rtsp://XXX:[email protected]:554/realmonitor?channel=0&stream=0.sdp'

Logger: homeassistant.components.onvif
Source: components/onvif/device.py:95
Integration: ONVIF (documentation, issues)
First occurred: 10:38:29 PM (1 occurrences)
Last logged: 10:38:29 PM

The date/time on the device (UTC) is '2020-06-11 22:38:26+00:00', which is different from the system '2020-06-11 19:38:29.299970+00:00', this could lead to authentication issues

[user897943]

Any news on this?

[friendodevil]

The error persists with HA 0.112.0

On 4 Jul 2020, at 11:02, user897943 [e-mail] wrote:


Any news on this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[McGiverGim]

It's not a problem of Home Assistant. Is a problem of the firmware on the cameras. I tested an Onvif utility and the firmware is ignoring the timezone when returning the hour.

[user897943]

It's not a problem of Home Assistant. Is a problem of the firmware on the cameras. I tested an Onvif utility and the firmware is ignoring the timezone when returning the hour.

I beg to differ. If the camera is reporting time as UTC that's standard behavior of most servers. HA should use its own timezone settings and adjust the behavior accordingly. HA has UTC time as well. Therefore if both the UTC times match (from HA and the IPcam) then HA should use its own timezone settings done by the user to adjust things like logs and movement detection. This is definitely a HA issue.

[McGiverGim]

I don't remember exactly the problem but I think remember that the camera command that must return the UTC hour is being affected by the summer time. I can give you details Monday if you want.

[McGiverGim]

@user897943 Sorry for my late response...

If you want to replicate, install a tool called "ONVIF Device Test Tool", in the Diagnostics tab, System, the first "request" is GetSystemAndDateTime command, if I send it I receive that:

  <SOAP-ENV:Body>
    <tds:GetSystemDateAndTimeResponse>
      <tds:SystemDateAndTime>
        <tt:DateTimeType>Manual</tt:DateTimeType>
        <tt:DaylightSavings>true</tt:DaylightSavings>
        <tt:TimeZone>
          <tt:TZ>CET-1CEST,M3.5.0/3:0,M10.5.0/3:0</tt:TZ>
        </tt:TimeZone>
        <tt:UTCDateTime>
          <tt:Time>
            <tt:Hour>9</tt:Hour>
            <tt:Minute>36</tt:Minute>
            <tt:Second>0</tt:Second>
          </tt:Time>
          <tt:Date>
            <tt:Year>2020</tt:Year>
            <tt:Month>7</tt:Month>
            <tt:Day>10</tt:Day>
          </tt:Date>
        </tt:UTCDateTime>
        <tt:LocalDateTime>
          <tt:Time>
            <tt:Hour>10</tt:Hour>
            <tt:Minute>36</tt:Minute>
            <tt:Second>0</tt:Second>
          </tt:Time>
          <tt:Date>
            <tt:Year>2020</tt:Year>
            <tt:Month>7</tt:Month>
            <tt:Day>10</tt:Day>
          </tt:Date>
        </tt:LocalDateTime>
      </tds:SystemDateAndTime>
    </tds:GetSystemDateAndTimeResponse>
  </SOAP-ENV:Body>

As you see, it shows local time as 10:36, that is correct, but it shows UTC as 9:36. That is not. The real time of the test was 8:36 UTC. I live in a zone with +1 in winter and +2 in summer for the daylight saving (DST). Is like it is adding the +1 of summer to the UTC hour.
I don't know what does internally the firmware to mess with the timezones, the DST and the UTC.

If I deactivate the DST, this is the result:

  <SOAP-ENV:Body>
    <tds:GetSystemDateAndTimeResponse>
      <tds:SystemDateAndTime>
        <tt:DateTimeType>Manual</tt:DateTimeType>
        <tt:DaylightSavings>false</tt:DaylightSavings>
        <tt:TimeZone>
          <tt:TZ>CET-1CEST</tt:TZ>
        </tt:TimeZone>
        <tt:UTCDateTime>
          <tt:Time>
            <tt:Hour>8</tt:Hour>
            <tt:Minute>45</tt:Minute>
            <tt:Second>53</tt:Second>
          </tt:Time>
          <tt:Date>
            <tt:Year>2020</tt:Year>
            <tt:Month>7</tt:Month>
            <tt:Day>10</tt:Day>
          </tt:Date>
        </tt:UTCDateTime>
        <tt:LocalDateTime>
          <tt:Time>
            <tt:Hour>9</tt:Hour>
            <tt:Minute>45</tt:Minute>
            <tt:Second>53</tt:Second>
          </tt:Time>
          <tt:Date>
            <tt:Year>2020</tt:Year>
            <tt:Month>7</tt:Month>
            <tt:Day>10</tt:Day>
          </tt:Date>
        </tt:LocalDateTime>
      </tds:SystemDateAndTime>
    </tds:GetSystemDateAndTimeResponse>
  </SOAP-ENV:Body>

Now the real hour is 1 hour off (as expected) but the UTC hour is correct.

I suspect the major part of cameras share some "open" firmware that had this bug, and nobody has tried to fix it or they are using a very old version. I need to open the interface with an old Internet Explorer so this explain a lot of things...

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[user897943]

Leaving a comment so that this issue isn't closed. There's a ton of chinese cameras with this problem and they will never be fixed if the issue is indeed in the camera's firmware. Daylight savings time is being adjusted correctly in my cameras so I don't understand how the issue can be with them, however the maintainer of this integration says so. If this is the case can the maintainer provide a fix within his own integration, for example by "fooling" home assistant and mimicking the date and time as if it was the camera but using the correct date and time based on the system. This would eliminate the issue for many brands of cameras and many users.