Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to use camera_time mqtt topic? #916

Open
DennisGarvey opened this issue Jul 14, 2023 · 15 comments
Open

How to use camera_time mqtt topic? #916

DennisGarvey opened this issue Jul 14, 2023 · 15 comments
Labels
bug Something isn't working

Comments

@DennisGarvey
Copy link

I can retrieve the unix timestamp from camera_time over mqtt, but cannot seem to change the time on the camera over mqtt. When changing /camera_time/set, /camera_time will change but the timestamp on the camera will not update. Is there something I am doing wrong here?

@mrlt8
Copy link
Owner

mrlt8 commented Jul 15, 2023

You're right, the camera doesn't seem to be responding to the 10092 tutk command.

camera_time/set is supposed to ignore any inputs and just use the current unix timestamp from the host +1 as the timestamp to send to the camera. This is what the app seems to do to keep the camera's clock in sync.

@mrlt8 mrlt8 added the bug Something isn't working label Jul 15, 2023
@DennisGarvey
Copy link
Author

You're right, the camera doesn't seem to be responding to the 10092 tutk command.

camera_time/set is supposed to ignore any inputs and just use the current unix timestamp from the host +1 as the timestamp to send to the camera. This is what the app seems to do to keep the camera's clock in sync.

the time stamp also takes into account the time zone right? it can't just be a unix time stamp

@mrlt8
Copy link
Owner

mrlt8 commented Jul 15, 2023

ok after some more debugging, it seems like the command is working, but it's setting the timestamp that the tutk AV server is using to send the audio/video frames which seems different from the timestamp that the camera uses for the system time and OSD timestamp.

were you looking to replicate the 'sync time' function from the app?

@DennisGarvey
Copy link
Author

ok after some more debugging, it seems like the command is working, but it's setting the timestamp that the tutk AV server is using to send the audio/video frames which seems different from the timestamp that the camera uses for the system time and OSD timestamp.

were you looking to replicate the 'sync time' function from the app?

yes I was trying to automate sync time. I have cameras in multiple time zones under one account. Sometimes the app will sync the camera to the phone time unprompted and is really annoying. It's baffling how they don't have ntp syncing support on the cameras.

mrlt8 added a commit that referenced this issue Jul 15, 2023
@mrlt8
Copy link
Owner

mrlt8 commented Jul 15, 2023

I added the tutk command to set the timezone, but it seems like we still need to send the command over the webAPI..?

mrlt8 added a commit that referenced this issue Jul 15, 2023
@mrlt8
Copy link
Owner

mrlt8 commented Jul 15, 2023

@DennisGarvey Could you try the dev branch? It should be able to set device_info values using the wyze web api now.

Topic: time_zone/set
Payload: America/New_York (https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)

The official app seems to be setting the TZ using tutk AND the web api, but the K10302 tutk command doesn't seem to do anything, so skipping that for now..?

FYI, the time zone info in the bridge's web UI won't update, but you should be able to see the change in the video or the time zone offset with the time_zone/get topic.

@DennisGarvey
Copy link
Author

How do I pull the dev branch docker image?

@DennisGarvey
Copy link
Author

Also, since you are using the web API for setting device_info values, does this mean controlling aspects of wyze cam OGs would be possible? Not streaming video but changing things such as the time zone and time.

@mrlt8
Copy link
Owner

mrlt8 commented Jul 16, 2023

you can use the dev tag - e.g. mrlt8/wyze-bridge:dev.

The GET command will probably fail with the OG since that is pulling the TZ data over tutk, but the SET command should theoretically work with the OG since set_device_info only requires the MAC address of the cam.

@DennisGarvey
Copy link
Author

is it possible to get the info over the web api if the camera is incompatible with the tutk sdk

@DennisGarvey
Copy link
Author

DennisGarvey commented Jul 16, 2023

Here is what I got after calling /camera/time_zone/get

Traceback (most recent call last):
File "/usr/local/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
self.run()
File "/usr/local/lib/python3.11/threading.py", line 975, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python3.11/site-packages/paho/mqtt/client.py", line 3591, in _thread_main
self.loop_forever(retry_first_connection=True)
File "/usr/local/lib/python3.11/site-packages/paho/mqtt/client.py", line 1756, in loop_forever
rc = self._loop(timeout)
^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/paho/mqtt/client.py", line 1164, in _loop
rc = self.loop_read()
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/paho/mqtt/client.py", line 1556, in loop_read
rc = self._packet_read()
^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/paho/mqtt/client.py", line 2439, in _packet_read
rc = self._packet_handle()
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/paho/mqtt/client.py", line 3033, in _packet_handle
return self._handle_publish()
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/paho/mqtt/client.py", line 3327, in _handle_publish
self._handle_on_message(message)
File "/usr/local/lib/python3.11/site-packages/paho/mqtt/client.py", line 3570, in _handle_on_message
on_message(self, self._userdata, message)
File "/app/wyzebridge/mqtt.py", line 177, in _on_message
resp = callback(cam, topic, payload if include_payload else "")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/wyzebridge/stream.py", line 171, in send_cmd
if cam_resp := stream.send_cmd(cmd, payload):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/wyzebridge/wyze_stream.py", line 277, in send_cmd
zone = {"device_timezone_city": zoneinfo.ZoneInfo(payload).key}
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/zoneinfo/_tzpath.py", line 67, in find_tzfile
_validate_tzfile_path(key)
File "/usr/local/lib/python3.11/zoneinfo/_tzpath.py", line 91, in _validate_tzfile_path
raise ValueError(
ValueError: ZoneInfo keys must be normalized relative paths, got:

@DennisGarvey
Copy link
Author

DennisGarvey commented Jul 16, 2023

camera/time_zone/set works properly

edit: changing time zone doesnt work for wyze cam OGs

mrlt8 added a commit that referenced this issue Jul 17, 2023
@mrlt8
Copy link
Owner

mrlt8 commented Jul 17, 2023

Thanks, /time_zone/get should be fixed now.

@DennisGarvey
Copy link
Author

camera/time_zone no longer updates correctly when changing the time zone with camera/time_zone/set, it still changes the timestamp on the camera though. Cam OGs still don't work

mrlt8 added a commit that referenced this issue Jul 17, 2023
@mrlt8
Copy link
Owner

mrlt8 commented Jul 17, 2023

whoops, should return just the hour now.

Unfortunately, OG is probably using a different method to sync time and won't be supported right now.

mrlt8 added a commit that referenced this issue Jul 20, 2023
* cache build

* Catch and disable MQTT on name resolution error

* Doorbell quick response

* Set camera time zone #916

* Set timezone on camera #916

* OSD toggle for logo/timestamp

* Add K10006 auth #742

* Fix /time_zone/get and return offset #916

* convert TZ offset to hours #916

* custom video filter #919

* Resend discovery message on HA online #907 #920

* Revert K10006 for WYZEDB3 #742

* Add more MQTT entities #921 #922

* Return json response/value for commands #835

* Fix threading issue on restart #902

* Fix SET cruise_points over MQTT

* SET cruise_point #835

* split into multiple jobs

* changelog
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants