You might want to try again with the latest 5.0.2 version. It has only very minor updates, but one of the key updates is in the dependencies as there were some fixes in ring-client-api for some specific cameras that only supported PCMU audio vs Opus.
If it still doesn’t work, please consider opening a support issue on the Github project page and we’ll try to work through it, if you are able to commit the time.
I wouldn’t say that is nothing, that’s quite a bit different from the log you posted previously. You can see that the peer connection is made and the stream actually gets to activated state, but no RTP streams ever make it from Ring to the RTSP servers so the connection times out after 10 seconds. The activation actually happens within the first 2 seconds, which is pretty normal. Based on that, you need to check if anything in your network might be blocking the RDP streams, which require UDP for the WebRTC connection.
hi,
i forwarded my router port to 8554, and webrtc port on 8554, but still nothing
The 8554 ports are only used for the local RTSP connection, they don’t have anything to do with the WebRTC connection being established to Ring as WebRTC is an entirely different protocol. The RTP ports used for the WebRTC channels use dynamic UDP port assignments. You should not have to explicitly forward any ports, but if you have anything in the path that might block UDP, then it will most likely not work. Most of the issues I’ve seen with this involve complex network setup (i.e. more than one NAT or very restrictive firewall rules).
Since the WebRTC peer connection appears to be established, but the stream itself did not start, I’m assuming something might be blocking the dynamic UDP connections, but this is not really the best forum to dig into something like that. It could be something else of course, but as I have no other reports of similar issues, I suspect it must be unique to the environment. That does not mean the environment is at fault, only that something is interacting in an unexpected way.
hi, thx for reply,
i use dd-wrt maby there is a setting nog good, i will check it 
thx
the weird thing is the event stream is working good,
As noted previously, the event stream works completely differently, at least with regards to how to the stream is retrieved from Ring, as it’s simply a recording that is streamed via HTTPS from an S3 bucket so no WebRTC, no RTP streams to Ring servers or the cameras, etc.
So basically, the event stream working simply reenforces the theory that the problem is with the RTP stream in WebRTC streams since event stream doesn’t use those but the live stream absolutely requires them.
hi, i checked everything i can, disabled the firewall of my router to see if this is the problem, but it keeps the same problem :s is it maby the model of the bell? i got this Video Doorbell Wired – Ring
I wouldn’t think so, I know there are users with this particular model. There’s one reported issue with ring-client-api that is at least similar and the maintainer of that project has reproduced it, so perhaps he will find a fix for that soon. Basically, with some cameras, for reasons that are currently unknown, there is no audio stream and this currently causes stream startup to hang.
I don’t know what you feel about it, but if you are comfortable sharing the camera (if it’s in a place that would not be a security issue) I could give you an account to share it with and could troubleshoot it myself to see if this is the issue. I certainly understand if this is not something you’d want to do, but, if you are open to it, feel free to email me directly, same username at gmail. This would at least help me see if it is the same issue. If not, we can just wait and see if he comes up with a fix. I wouldn’t have time to look at this until sometime next week anyway as I’m travelling for the next few days.
I just upgrade my docker container from 4.x. I followed the instructions, I believe. I have my config and token set correctly, but I’m getting this error in the logs:
ring-mqtt | 2022-06-10T19:46:10.155Z ring-mqtt Attempting to reconnect to MQTT broker...
ring-mqtt | 2022-06-10T19:46:10.157Z ring-mqtt Unable to connect to MQTT broker connect ECONNREFUSED 127.0.0.1:1883
Prior to that,
ring-mqtt | ring-mqtt.js version: 5.0.2
ring-mqtt | Node version v16.14.2
ring-mqtt | NPM version 8.1.3
ring-mqtt | git version 2.34.2
ring-mqtt | -------------------------------------------------------
ring-mqtt | Running ring-mqtt...
ring-mqtt | 2022-06-10T17:59:05.867Z ring-mqtt Detected runmode: docker
ring-mqtt | 2022-06-10T17:59:05.874Z ring-mqtt Configuration file: /data/config.json
ring-mqtt | 2022-06-10T17:59:05.880Z ring-mqtt MQTT URL: mqtt://localhost:1883
ring-mqtt | 2022-06-10T17:59:09.981Z ring-mqtt Reading latest data from state file: /data/ring-state.json
ring-mqtt | 2022-06-10T17:59:10.169Z ring-mqtt Attempting connection to Ring API using saved refresh token...
ring-mqtt | 2022-06-10T17:59:11.351Z ring-mqtt Successfully established connection to Ring API using saved token
ring-mqtt | 2022-06-10T17:59:12.388Z ring-mqtt Successfully saved updated state file: /data/ring-state.json
ring-mqtt | 2022-06-10T17:59:13.352Z ring-mqtt Attempting connection to MQTT broker...
My configuration.json:
{
"mqtt_url": "mqtt://localhost:1883",
"mqtt_options": "",
"livestream_user": "",
"livestream_pass": "",
"disarm_code": "",
"enable_cameras": false,
"enable_modes": false,
"enable_panic": false,
"hass_topic": "hass/status",
"ring_topic": "ring",
"location_ids": [
""
]
}
I’m using mosquitto and here is that config:
persistence true
persistence_location /mosquitto/data/
allow_anonymous true
# Port to use for the default listener.
#port 1883
listener 1883
log_dest stdout
connection dte
address 192.168.1.13:2883
try_private false
start_type automatic
topic # in 0
I do see other topics streaming through MQTT in home assistant and the mosquitto command line.
Any ideas of what I’m missing?
Try replace the local host with the .13 ip address
Does anyone have a decent example to use webrtc-camera?
And:
Any thoughts why my image is like this:
It is only like this with the RTSP stream, when viewing on my Ring app on mobile phone it is just fine. On my mobile phone it is like this through the companion app too only with green bars instead of the scruble. Oh and btw, my other Ring camera is just fine.
This both through VLC play as through the HA gui.
The video quality issue is already covered in the ring-mqtt FAQ. Basically, NodeJS struggles to keep up with the packet rate of the RTP streams when running on lower-end hardware, especially like an RPi 3/4. This is not helped by the fact that Linux has a really small default/maximum UDP buffer size (<200K), so, when NodeJS can’t keep up during a burst, the packets get dropped off of the end of the stream, causing exactly the video artifacts you are seeing.
The solution is to increase the size of the default UDP buffer in Linux, but this has to be done on the host, because the container does not have permissions to request beyond the maximum size. For users running Home Assistant OS, this is really difficult as it requires accessing the developer mode SSH console and dropping a file into /etc/udev/rules.d which will increase the buffer during boot. The example is in the FAQ. For Docker/standard install users, it’s a lot easier as you can just use sysctl.conf to increase the default/max size.
Fortunately, with the release of HAOS 8.2, which was just about a week ago, the maintainers significantly increase the allowed maximum UDP buffer size in the host OS, but not the default size. I think this means I will be able to request a larger size for connections made from within the addon, but I haven’t had time to research this yet.
I’m running everything on a pi 4 but on normal raspbian. So I’m able to increase this. When I do this wil this take imidiate effect?
As long as you increase both rmem_default and rmem_max, it will take effect on the next stream. My testing shows that increasing the buffer to 2MB supports 4-5 streams pretty well on an RPi4 (my production setup), with only the very occasional smearing artifacts during initial startup, assuming that the RPi isn’t using CPU resources for anything else.
Increasing more than 2MB didn’t show a lot of improvement overall, and will increase the lag of the video stream if the RPi can’t keep up. For example, I increased the buffer from 2MB to 8MB and was able to mostly support 6 concurrent streams, but the lag increased by a couple of seconds for all streams because it was just barely keeping up, while using 80-90% of the CPU on the RPi.
And to report back; it works great. Let’s see if this helps the error messages too i have been seeing to connect to the stream lately. My Pi4 is getting it more busy every week 
Anyone running into token expiration issues?
After several months of no issues I noticed my ring devices were all unavailable this morning and saw this in the logs:
Refresh token is not valid. Unable to authenticate with Ring servers. See Refresh Tokens · dgreif/ring Wiki · GitHub
I went to the add on and opened webui and successfully authenticated with 2FA. I then went to the logs and it shows:
ring-mqtt Successfully established connection to Ring API using generated token
2022-06-21T11:49:17.413Z ring-mqtt Successfully saved updated state file: /data/ring-state.json
Unfortunately, none of my devices still get discovered and shown within HA. I try a reboot 30 min later and now see the error message about the token again.
Any ideas?
Of course I stumble upon the fix after posting the above message
For others who run into problems it appears the solution is to restart the MQTT Ring add on (a reboot of HA doesn’t do it)
I discovered this via this post:
https://m.facebook.com/groups/HomeAssistant/posts/3107889956149020/
Others ran into token issues not being refreshed and leveraged properly until the add on was restarted. Sure enough solved it for me too.
@tsightler would it be helpful for me to file an issue report for this? Or already on your radar? (Very appreciative for all your contributions with this amazing add on - HA wouldn’t be the same without it!)
