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

Activating siren causes Wyze Cam V3 to crash #1051

Closed
teixeluis opened this issue Nov 26, 2023 · 10 comments
Closed

Activating siren causes Wyze Cam V3 to crash #1051

teixeluis opened this issue Nov 26, 2023 · 10 comments
Labels
bug Something isn't working

Comments

@teixeluis
Copy link

teixeluis commented Nov 26, 2023

Hello,

Shortly after updating to docker-wyze-bridge v2.5.2 I went ahead and started testing the new entities created in home assistant. I have two cameras (Wyze Cam V3) running fw 4.36.11.5859.

I tested the infrared and night vision switches without problems, and then tested the siren in one of the cameras. Siren played, and camera continued operating normally. When I tried doing the same for the second camera, I immediately lost contact with it once the siren was activated, never to gain access again. The cameras are in a remote site, and currently I have no way of power cycling these.

The cameras are not physically far from each other. On the camera that is still alive I cannot hear the siren from the other one, which suggests that at least it did not hang with the siren running in a loop.

Can there be some issue with the siren command, causing another behaviour in the camera (e.g. resulting in a shutdown instead of playing the siren)?

When I switched it on, the siren entity toggled to on:

image

Does that suggest that the camera still acknowledged the siren being turned on, prior to going offline?

The state of the entity remains the same in spite of the camera being offline for almost 24 hours.

Looking at hassio logs, there is the following in the moment I have turned on the siren:

2023-11-25 12:30:54.756 ERROR (MainThread) [homeassistant.util.logging] Exception in state_message_received when handling msg on 'alerts/ovalesublime-west-cam/alarm': '0'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/mqtt/debug_info.py", line 44, in wrapper
    msg_callback(msg)
  File "/usr/src/homeassistant/homeassistant/components/mqtt/siren.py", line 240, in state_message_received
    json_payload = json_loads_object(payload)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/util/json.py", line 56, in json_loads_object
    raise ValueError(f"Expected JSON to be parsed as a dict got {type(value)}")
ValueError: Expected JSON to be parsed as a dict got <class 'int'>

2023-11-25 12:30:55.775 ERROR (MainThread) [homeassistant.util.logging] Exception in state_message_received when handling msg on 'alerts/ovalesublime-west-cam/alarm': '0'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/mqtt/debug_info.py", line 44, in wrapper
    msg_callback(msg)
  File "/usr/src/homeassistant/homeassistant/components/mqtt/siren.py", line 240, in state_message_received
    json_payload = json_loads_object(payload)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/util/json.py", line 56, in json_loads_object
    raise ValueError(f"Expected JSON to be parsed as a dict got {type(value)}")
ValueError: Expected JSON to be parsed as a dict got <class 'int'>


2023-11-25 12:31:16.377 ERROR (MainThread) [homeassistant.util.logging] Exception in state_message_received when handling msg on 'alerts/ovalesublime-west-cam/alarm': '0'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/mqtt/debug_info.py", line 44, in wrapper
    msg_callback(msg)
  File "/usr/src/homeassistant/homeassistant/components/mqtt/siren.py", line 240, in state_message_received
    json_payload = json_loads_object(payload)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/util/json.py", line 56, in json_loads_object
    raise ValueError(f"Expected JSON to be parsed as a dict got {type(value)}")
ValueError: Expected JSON to be parsed as a dict got <class 'int'>

Thanks

@teixeluis
Copy link
Author

Meanwhile, as of this writing, the camera is available again after almost 24 hours. Perhaps an internal watchdog kicked in and restarted the camera?

@mrlt8 mrlt8 added the bug Something isn't working label Nov 27, 2023
@mrlt8
Copy link
Owner

mrlt8 commented Nov 27, 2023

Thanks for the logs, I'll try to see what's causing the error.

Can you replicate the error? Does restarting the bridge help?

I still need to update the siren status as it will shut off after 30 but the status doesn't update: #953

@teixeluis
Copy link
Author

Yes, repeated the test and the problem occurred again. I kept listening on the other camera and could confirm that the alarm went on. This time the entity did not change state.

Not much information in the logs this time. Apparently just the result of the camera going offline:

2023-11-27 10:29:48.950 ERROR (stream_worker) [homeassistant.components.stream.stream.camera.west_cam] Error from stream worker: Stream ended; no additional packets
2023-11-27 10:29:58.957 ERROR (stream_worker) [homeassistant.components.stream.stream.camera.west_cam] Error from stream worker: Error opening stream (HTTP_NOT_FOUND, Server returned 404 Not Found) rtsp://192.168.1.64:8554/ovalesublime-west-cam
2023-11-27 10:30:18.964 ERROR (stream_worker) [homeassistant.components.stream.stream.camera.west_cam] Error from stream worker: Error opening stream (HTTP_NOT_FOUND, Server returned 404 Not Found) rtsp://192.168.1.64:8554/ovalesublime-west-cam

@mrlt8
Copy link
Owner

mrlt8 commented Nov 27, 2023

Is the lost connection happening with just the one camera? Does the same thing happen in the wyze app? e.g. turning on the siren drops the video on the wyze app?

I'm wondering if its an issue with the camera and/or power supply for that one camera?

@teixeluis
Copy link
Author

@mrlt8 yes so far just with that one camera in particular. The first time I tested the feature was with its sibling camera which didn't crash, but I did not repeat the test on that one because I need it alive. Once the camera (hopefully) reboots tomorrow I will repeat the test with the app and see if the same happens. I don't remember this happening in the past with the app.

In terms of power the two cameras share the same cabling. On the other end I have two USB wall adapters wired in parallel to provide more power for both cameras.

@mrlt8
Copy link
Owner

mrlt8 commented Nov 27, 2023

Is it working in the app? Can you try rebooting the camera via the app or via the webUI or api :5000/api/ovalesublime-west-cam/restart?

@teixeluis
Copy link
Author

@mrlt8 I cannot reboot it remotely, because it becomes offline after triggering the siren. It doesn't respond to pings and it dissociates from the Wifi AP. It looks like a complete crash of the system.

@teixeluis
Copy link
Author

teixeluis commented Nov 29, 2023

@mrlt8 I did a bit more experimentation, and even after multiple tests I was not able to get the "sibling" camera to crash when turning on its siren. So there could be some problem with that camera in particular, or eventually requiring a cold restart..

Another thing that I found is that the siren will not turn on via the iPhone app, but through the Android app it does (even showing the popup with the 30 second limit).

This weekend I will be on site and be able to perform more tests, with special focus on the camera that crashes. For now I need to avoid that 24 hour camera downtime...

@yeahme49
Copy link
Contributor

yeahme49 commented Dec 6, 2023

I used to have this issue with one of my V3 cameras. The issue was I had a couple USB extension cables connected between the camera and the power source, which caused the voltage to drop. When activating the siren the additional current dropped the voltage even further and the camera would crash.

I solved this by switching from a USB power adapter to a 12v power adapter and then using https://www.amazon.com/gp/product/B08H89LTP5/ at the camera to convert the 12v to 5v USB.

@teixeluis
Copy link
Author

I was no longer able to reproduce the problem after the affected camera was power cycled. The problem you mentioned @yeahme49 may indeed be lurking as I have a relatively long run of cable (10 m or so) between the camera and the power supply. I like your suggestion of using a higher voltage on the supply side, and then convert to 5 Volts close to the camera. I will close the ticket as I could not reproduce it any more.

mrlt8 added a commit that referenced this issue Jan 4, 2024
mrlt8 added a commit that referenced this issue Jan 11, 2024
* Drop late audio frames to keep sync #388

* show running architecture

* Don't log failed tutk if stream is down #990

* Use valid FPS for sleep #388

* Refactor

* Adjust sleep_interval #388

* Increase sleep time between frames #388

* Set larger buf size #388

* add SLEEP_INTERVAL_FPS #388

* Adjust sleep interval #388

* use genpts #388

* avoid conflicting names with errno module

* refactor _audio_frame_slow

* LOW_LATENCY mode

* show github SHA on dev build

* substream support and more refactoring #388

* div tag for jittery video in Firefox #1025

* Re-encoding audio for WebRTC/MTX

* reduce sleep time for audio thread #388

* Target firefox for jittery video fix in css #1025

* Use K10050GetVideoParam for FW 4.50.4.x #1070

* Use K10006 for newer doorbell #742 and refactor

* Reduce audio pipe flushing #388

* show gap when audio out of sync #388

* don't include ARCH in version

* Update iotc.py

* reset frame_ts on clock sync

* update auth api

* Restructure and cleanup

* remove unneeded files

* update path

* Forget alarm/siren state #953 #1051

* use addon_config for Home Assistant

* Additional refactoring to auth api

* don't skip keyframes #388

* Update ffmpeg.py

* delay audio when ahead #388

* format iotc logging so we know what cam is late

* drop late video frame and speed up audio #388

* Add Floodlight V2

* Set default sample rate for all cams

* Delay audio by 1 second if ahead of video #388

* tweak ffmpeg buffer #388

* Retain MQTT Discovery Message #920

* Update change log

Special thanks to @carlosnasillo!
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

3 participants