Nearly identical as well, both run on docker on a QNAP NAS. Same CPU and Memory, slightly different model but pretty close. Possible something on the underlying OS maybe? I keep them configured nearly identical and I wouldn’t think it would matter much on a docker container.
I’ve definitely ruled out the cameras themselves. I just tested adding one from the secondary site into my primary site and it worked without issue. I have site to site VPNs setup between all 3 camera locations so I can access them locally.
I removed the docker container, pulled the container down again, same thing.
The only thing that is slightly off is the amount of devices and the some of the automations. The devices I do have at the secondary site, the one that doesn’t work, are all the same ones I use at the primary site.
If I’m one thing I’m methodical and constant in my configurations.
Only errors I see in the logs when I try to launch a stream:
It’d be interesting to see if adding one of the working cameras from site A to the Home Assistant instance on site B still works. If so, it might be a configuration difference in the cloud key on how the streams are produced?
Wyze you can’t( you can but it’s not easy, and to me worth it, you need to proxy it via a android app) . Not yet. but they have said they will be adding RTSP in future releases/.
There is another gotcha though that similar to the problem with TTS streaming to the chromecasts in that the base_url would need to be changed to an internal one in my case. I put in a github issue to mention the case asit stops streaming to Google Home Hubs (and I assume chromecasts too) in my particular config.
I would like to say thanks for such a great stream component!
I have an issue for Wyze V2 with custom firmware which enabling rtsp.
RTSP works great via VLC/HA camera generic platform (at least I can see it w/o any issues), but doesn’t when I try to use camera.play_stream service (it’s connecting to the chromecast device, trying to load stream and then just stop activity, so I can’t see stream/loading).
In logs I’ve something like:
Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1162679 >= 1128842
17:17 components/stream/worker.py (ERROR)
error while decoding MB 74 6, bytestream 15439
17:16 components/stream/worker.py (ERROR)
cabac decode of qscale diff failed at 74 6
17:16 components/stream/worker.py (ERROR)
error while decoding MB 20 24, bytestream -15
17:16 components/stream/worker.py (ERROR)
I have a few hikvision cameras which are streaming fine via sub-stream (low resolution) and are failing with similar errors via main streams. I’m sure 0.90.1 should fix that. I have also noticed a rather strange behaviour with the very same cameras connected remotely via VPN, which are streaming OK via VLC and are all failing with the following error message:
VLC falls back to TCP if UDP fails. This component only streams via UDP for now. We will have to design a way to configure stream options to allow you to view those remote streams.
The low-res vs high-res stream probably has more to do with the hardware Home Assistant runs on. What hardware are you running?