I have had no reports of any issues and normally, with the number of users this addon has at this point, if something this critical was wrong, it would be reported within hours. What does the addon log show?
Is there anything in it I should not share in the open? Maybe I can copy it to pastebin.
Edit: when it references āserial numberā is that a specific device, like the contact sensor? If yes then I think its seeing my device. Says like link quality OK, tamperstatus OK, commstatus OK etc. I assume its all my devices as Iām seeing entries with 10 unique serials which is about rightā¦
Edit 2: had obviously tried restarting HA and it didnt help, but just rebooted the pi4 Iām running it on and that actually seems to have fixed it, seems OK now. Sorry for false alarm.
Sweet Bypass mode is here! Thank you so much for working on this @tsightler!
It does fail for however. If I have a window opened that is connected to the ring alarm via a retrofit kit (it comes into HA fine via MQTT and everything) if I have the bypass switch active and select it, it appears to go down the ādefaultā chain of attempting to arm the alarm 5 times then give up. Is a retrofit kit (the zone shows up as a contact sensor in HA) not bypassable?
2021-03-03T22:40:22.603Z ring-mqtt Error: Failed to set alarm mode to āsomeā. Sensors may require bypass, which can only be done in the Ring app.
at Location. (/app/ring-mqtt-docker/node_modules/ring-client-api/lib/api/location.js:199:23)
at Generator.next ()
at fulfilled (/app/ring-mqtt-docker/node_modules/ring-client-api/lib/api/location.js:5:58)
at runMicrotasks ()
at processTicksAndRejections (internal/process/task_queues.js:97:5)
2021-03-03T22:40:23.404Z ring-mqtt Alarm for location Home failed to enter requested arm/disarm mode!
2021-03-03T22:40:33.415Z ring-mqtt Alarm could not enter proper arming mode after all retriesā¦Giving up!
Right now the code only looks for faulted contact sensors, Iām assuming it would be possible to bypass retrofit zones if the Ring app supports it, but Iād have to add that into the bypass logic. Basically, the code has to detect the list of faulted sensors and bypass the specific ID for each sensors, right now Iām looking for contact sensors specifically.
I guess Iām a little bit concerned about adding Retrofit to that list because a āzoneā can represent significantly more than one sensor, but since it has to be explicitly enabled, I think itās probably OK.
In the future I hope to implement this in a little more advanced way, basically have an attribute for each sensor that you can set whether it is allowed to be bypassed or not, but Iām currently in the middle of another code cleanup to make that easier to implement that will let me store more state information to make that a more usable solution. Maybe one day Iāll have enough time to finish all of that.
Iāll try to add Retrofit zones to the list with a minor update in the near future.
You Rock! Thank you.
And yes - from Ringās point of view, the retrofit zone comes through as just a single sensor that can be either tripped (unsafe) or not tripped (safe). The zone can have multiple windows and doors linked together but the retrofit does not know that as they are all daisy chained together. The kit can have 8 different sensors (zones) plugged into it (and appear as 8 sensors - no matter how many windows/doors are behind each zone), and how you daisy chain all the sensors together to form a zone is up to you.
I guess I am just dense. Most of the time Hassio will show there is an upgrade available. I am running 4.21 now. How do I get 4.4?
Thanks
Grey
It should show up automatically, but you can try clicking on the āAdd-on Storeā tab, then selecting the three dots in the upper right corner and choosing reload, which should force HA to rescan all added repositories and show the upgrade. This is what I do when I upgrade my tested instances immediately after I push a new version just to make sure the process works properly (I always test on both a development 32-bit RPi3 a separate VM based system so that I know at least the two most common architectures work).
FWIW, when I do the 3 dots, Ring shows install 4.40, not upgrade. I will let you know if it works.
Now I have both ? 4.2 is still under dashboard, 4.4 is still under addons but insead of install, start is now an option.
I canāt really say whatās causing that, but you could always just uninstall/remove addon repo and start from scratch. As this doesnāt remove existing entities you shouldnāt lose anything, but youāll have to get a new token via the web interface, but that should be it.
My guess is that, for some reason, your system failed to cleanup an old image or tried to do an autoupgrade and failed for some reason and is now in a weird state. At least something like that, but I really donāt have any other ideas.
From the developer (my) side thereās not much to this. After I push a new version of ring-mqtt and Iām ready for the addon to upgrade users to the new version, I just change the version string in config.json and users start getting the upgrade. HA reads this config.json from the repos and, any time it sees a new version it notifies in the UI or, based on settings, automatically updates and pulls the latest image from Docker hub. Thatās all there is too it.
Thanks,
yes that is what I ended up doing. Uninstall both, add the rep, create a token and up and running
@tsightler Again - wanted to say thank you for looking into the retrofit bypass for me. I had a dumb question that is something I have been thinking about how to do, and wanted to get your thoughts on if it is possible. Right now Ring Alarm only has 3 modes - disarmed, armed, and home. I was in need of a 4th mode that when I have guests over, certain windows can be opened without setting off an alarm. i.e. I donāt want guests to worry about setting it off if they are hot at night and want to open a window. I have the automation available that detects if guests are in the house, so it should be easy for me to have a node red flow that sets this 4th mode instead of the normal āhomeā mode.
Now as there is not actually a 4th mode, would I be able to FORCE bypass some of the windows (even if they are not opened yet) to have the alarm ignore them? I assume this would take a change yet again in your code base
If itās not something you can do in the app, itās probably not something you can do with the addon. Iām not aware of any method in the Ring app to effective force bypass of a non-faulted sensor, but feel free to tell me Iām wrong on that.
Now, what you can do in the Ring app today is tell it what sensors should be monitored for what modes. It seems like exposing these options via API would be the best way deal with this since, in any case, there would have to be some way of explicitly identifying what sensors you are willing to bypass. Using this method, perhaps normally the āGuest Windowā sensor is set to āarmed and monitoredā when in āHomeā mode, but, when a Guest is detected, the automation could set the āGuest Windowā sensor to āIgnoreā for home mode. Iām confident these setting could be expose via the API, although Iām less confident about setting them, but since the app can change this setting it should be possible.
@tsightler Thanks for the insight. I figured it would have been harder to change the mode to ignore some sensors than to bypass some secured sensors. That being said, your solution is the better option.
Hi. So I am still having problems. All my alarm sensors just keep going unavailable and not recovering (now unavailable for 20 hours). I have to restart the ring devices addon, then they suddenly spring back to life. How do I debug this? I know when I mentioned this before you asked if my log shows anythingā¦ I checked this time and all the sensors went unavailable 20 hours ago but the log doesnāt go back that far, is it saving to file somewhere? Thanks.
You can get the logs from the command line via docker logs, or by using a tool like Portainer (also available as an addon). Is there any chance you have an old MQTT integration without birth/last_will messages enabled? Without logs from the time of the event thereās precious little chance to determine the cause.
So I have Home Assistant OS installed on an rPi 4, Iām not really sure how to do that. As far as MQTT, I see Mosquitto broker as v5.1.1 and then use the MQTT integration from the integrations page and I apply every update for everything HA brings up so
I think Iām up-to-date right. I am not sure if itās relevant but I also have the core Ring integration installed to for my Ringdoor bell. I see that is complaining a lot about and this is routinely being reported on my dashboard as āunknownā:
[homeassistant.components.ring] Error fetching Ring active dings data: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
I assume I do need to run both of these right (yours and the core integration) for my doorbell and alarm system? The door bell apart from ālast dingā seems to continue working via the Ring integration when the alarm devices via the MQTT integration go unavailable - I still see the door bells battery level, motion indicator and last motion time on my dashboard, but all the MQTT devices are unavailable.
I do have a few sonoff miniās with tasmota which are connecting via MQTT, I guess I should test those switches are still working in HA when these devices are going offline. But I did just resolve this - got the alarm devices to show up again - by restarting specifically only the Ring addon, I didnāt restart HA.
Whether you need to run them both is based on what you want to use the integration for. The native integration provides more functionality for Ring cameras, especially around video functions, since ring-mqtt is limited by the Home Assistant MQTT camera implementation. But other functions such as motion and dings, lights and siren support are roughly equivalent, although the native integration provides more useful metadata.
Still, Iād guess most people run both, which is why camera support is optional and disabled by default in my addon. I wouldnāt expect any issues with this.
However, itās interesting that you are seeing those messages from the native Ring addon as well. What speed is your internet link and how reliable do you consider it? Is your RPi connected via wifi or wired connection? Perhaps you are simply seeing more intermittent connectivity than most users and thatās tickling some bug. Logs from around the time would help to identify the issue.
Probably you should open an issue on Github so we can work through it there, vs attempting to troubleshoot it here on this forum.
Just FYI, I had one other report similar to this so I spent some time troubleshooting and I believe it is a bug in the underlying node version as I can reproduce the bad behavior on the latest node v12 in a number of cases, but never when using the latest node v14. Iāll try to bump the node version in the next push and we can see if that helps.
OK great. I was going to put an issue on git once it happens again but hasnāt happened again yet. Maybe I should raise it anyway.
Just to answer your other questions. My connection is 380 / 40 Mbps. I do consider it solid, havenāt had any problems. The Pi is wired to my router. Nevertheless I am seeing a constrant trickle of these errors from the Ring addon:
2021-03-23 14:08:16 WARNING (MainThread) [homeassistant.components.ring] Error fetching Ring active dings data: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
2021-03-23 15:19:20 WARNING (MainThread) [homeassistant.components.ring] Error fetching Ring active dings data: 504 Server Error: Gateway Time-out for url: https://api.ring.com/clients_api/dings/active?api_version=9
2021-03-23 15:46:16 WARNING (SyncWorker_11) [homeassistant.components.ring] Error fetching Ring history data for device a8108724096a: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
F
Definitely something a miss. I hadnāt noticed the different 504 message before.
But this is the native ring addon for my doorbell, not yours I am using for my alarm right? Out of interest, the addon is getting its data from the base station or its all coming down over the internet?