Feature Request: Update Snapshots

[ronaldheft]

Awesome work on adding snapshots! Could snapshot requesting be configurable in some manner? For example, either updating on a set interval or requesting an update via an MQTT message? Thanks!

[tsightler]

One reason why I was hesitant to add snapshot support at all was because I feared the requests that would come. I am considering the possibility to add a simple, "refresh every x minutes" options, but it really opens a big can of worms from my perspective, mainly due to how battery cameras support snapshots.

As far as I understand, battery based Ring cameras will not allow on-demand snapshots to be taken more often than every 10 minutes, while wired cameras support much more frequent updates. Having watched other projects which implemented snapshot support, this has been a significant support burden with users not understanding the limitations of their devices.

Thus, I'm not fundamentally opposed to the idea of refreshing snapshots, but, based on the limitations of the various devices, I think doing something on-demand is definitely out of question. My current thought is to try to figure out how to tell if the "Snapshot Capture" feature is enabled and at what frequency it's set, and then update the image at the same interval. This way, I can easily define how the function behaves by simply documenting that it follows the same behavior of the Ring app.

[ronaldheft]

That's completely fair.

I did not consider the complexity and potential support requests you'll receive if users' camera are not configured correctly for snapshots.

I do like the idea of mirroring the camera's app snapshot setting if you're able to read those values. I think that's the desired effect that both myself and other users would love to see; whatever the latest snapshot Ring has off the camera, that should be the snapshot Home Assistant displays.

[tsightler]

I noticed that the ring-client-api appears to have worked around this issue and can now do snapshots every 10 seconds, however, for battery cameras this is definitely a battery eater. In the Homebridge addon the snapshots are only refreshed when Homekit app is open which mitigates the battery issue, unless you leave the Homekit app open all the time. If you do leave the Homekit app open (like using a dedicated iPad), there's a special option that limits snapshots to every 10 minutes for battery devices.

Unfortunately, with ring-mqtt, I don't have any way to know when someone is looking at the videos or not, and I think Ring wouldn't be too happy with an app that asked for a snapshot from all cameras every 10 seconds 24x7, so I just don't think this option is viable.

I've determined how to tell if the snapshot capture feature is enabled and the configured snapshot frequency. It has different settings for wired vs battery cameras in the app, so I'm thinking this is the best way, however, I'm sure I'll get some complaints because it requires a paid Ring Protect account, but I think this is what I will try first because it's easy.

[ronaldheft]

Interesting findings regarding the battery usage of the snapshot capture feature.

I was aware of the complexity of live streaming killing battery devices, but I didn't realize the snapshot request would have the same considerations. Since the app let's you configure how often snapshots are captured, I assumed ring-client-api would be fetching whatever the latest snapshot captured was, and would have no battery impact as it would be fetching the already captured snapshot from Ring's server. I see, however, ring-client-api is making an on demand request for a new snapshot, hence the extra battery drain.

[broyuken]

subscribing to this. I have 2 wired floodlights and a wired doorbell pro if I can help test anything. I don't have any battery powered devices though.

[tsightler]

@broyuken Don't need any testing yet, but I do have a question. From your perspective, what exactly do you see as the benefit to this feature? I'm trying understand how people might use it. While it was very clear to me why an image on motion would be useful, simply updating with a current snapshot image that is almost guaranteed to be stale by the time you look at it seems significantly less useful overall.

[ronaldheft]

@tsightler My use case is I have activity outside my defined motion trigger range that I want I quickly see within Home Assistant.

For example, my driveway camera has a motion detection area defined for the driveway only. It works great for triggering when a car leaves or returns, but it doesn't trigger, for example, when the garbage is picked up. If I set the motion trigger area to the street, it triggers way too often, but having a snapshot that is 10 minutes or 60 minutes old at least tells me if the garbage has been picked up recently, and I can go outside to bring in the cans.

The other scenario is when there hasn't been motion for a while and it gets dark outside. Seeing my camera showing an image that is bright and sunny outside feels off. I'd rather see a snapshot that is somewhere within the current daylight value vs. something that may be several hours old.

[tsightler]

I've been researching the behavior of the Ring web based and Android app and both seem to refresh their snapshots every 30 seconds when you leave them open, which makes me thing that this frequency should be OK from an API call perspective. However, While I have 5 Ring cameras, they are all wired cameras and I was wondering if the behavior for battery cameras might be different.

My current thought is to use 30 seconds as default for wired cameras, but use 10 minutes by default for battery cameras, unless they have snapshot capture enabled, then I'll use that setting instead (if you choose to enable 5 minute snapshot capture on a battery camera, the Ring app already warns of moderate battery drain so this seems OK).

[tsightler]

OK, I have implemented this in the "dev" branch. If you are using the addon just change the branch option from "addon" to "dev", or if using Docker use the BRANCH="dev" environment options when running the container. This should pull in the 4.3.1 changes.

When running this branch and snapshots are enabled, any non-battery based camera will refresh the snapshots every 30 seconds while battery based cameras will refresh every 10 minutes unless the "Snapshot Capture" feature is enabled and then it will refresh according to the Snapshot Capture schedule.

Also, any time there is a motion event automatic refreshes will pause to allow viewing of the snapshot which created the motion event. Once the motion event expires snapshots will return to refreshing on their original schedule.

This seems to work pretty well, but I only have wired cameras so I'd love to get some testing with battery based devices before releasing this into the wild. I'm also still undecided if I should hide the refresh feature behind yet another config option, but for now, in the dev branch, if snapshots are enabled, they will automatically refresh.

[ronaldheft]

That's a slick implementation of both the snapshot feature and dev testing.

I switched to the dev branch and here's what I'm seeing on startup:

2021-02-09T02:02:23.707Z ring-mqtt --------------------------------------------------------------------------------
2021-02-09T02:02:23.707Z ring-mqtt Found new location Lake Shore with id <removed for security>
(node:6) UnhandledPromiseRejectionWarning: ReferenceError: lite_24x7 is not defined
    at new Camera (/app/ring-mqtt-dev/devices/camera.js:18:58)
    at getDevice (/app/ring-mqtt-dev/ring-mqtt.js:64:16)
    at updateRingData (/app/ring-mqtt-dev/ring-mqtt.js:161:35)
    at async processLocations (/app/ring-mqtt-dev/ring-mqtt.js:216:5)
(node:6) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:6) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I have a battery Ring 3 doorbell and a Stickup Cam in wired mode, powered by a solar charger (so it does use the battery).

[tsightler]

Hmm...thanks for the test! I anticipated this case (i.e. no lite_24x7 property), and tried to trap it, but I guess the trap is not good enough. I made a small tweak and pushed another update so if you restart the addon/docker it should pull in the changes. If it still happens I'll have to get more aggressive on detecting this scenario somehow.

[ronaldheft]

Same error. I just pulled up the code, and I think the issue is the hasOwnProperty(lite_24x7) calls on line 18 and 151 need to be in quotes as so:

hasOwnProperty('lite_24x7')

hasOwnProperty takes a string and the error being thrown appears to be an undefined variable is being used.

[tsightler]

Yeah, stupid mistake. Looked right at it and still didn't notice the obvious error there. Reverted the code back to the original and added the quotes so hopefully it will be good now.

[ronaldheft]

Thanks for all the work on this! I am up and running!

I'll keep an eye on things tomorrow and see how the snapshots hold up throughout the day. I'll report back in the evening.

[ronaldheft]

I can also report back that so far my stick up cam appears to be refreshing every 5 minutes and my doorbell every 10 minutes, which is exactly what I have configured in the app.

[tsightler]

Thanks for the testing, other than the stupid error above implementing snapshots and refresh were quite a bit simpler than I had anticipated. One small enhancement I'm thinking of adding, right now it only checks for the interval settings during startup, so, if you change the interval settings in the app it requires restarting ring-mqtt to pickup those changes. I think I'm going to take a stab at making this dynamic tomorrow.

[broyuken]

Not sure if I'm doing something wrong, but I enabled cameras and snapshots and I now see a camera.front_door_snapshot entity, however it is significantly lower quality than the native ring integration. Also, I noticed that there is no timestamp on the image. Are there any settings I need to tweak to get these options or do they not work with the addon yet?

enable_cameras: true
enable_snapshots: true
enable_modes: false
enable_panic: false
enable_volume: false
mqtt_host: <auto_detect>
mqtt_port: <auto_detect>
mqtt_user: <auto_detect>
mqtt_password: <auto_detect>
branch: dev
ring_token: ''
location_ids:
  - ''
  - ```

[tsightler]

@broyuken I think you might have unrealistic expectations of what we are doing here. The native Ring integration is a proper camera integration for Home Assistant. As far as I can tell, it appears to use ffmpeg to convert the Ring video stream into a motion JPEG output stream and basically just grabs a frame from that for the still image. That's a native 1080p video image so you get a full resolution still image as well.

Ring cameras can also take "snapshots", but these are actually just 640x360 images. These are the same images you see when you open the Ring app or the Ring web app, or if you get "rich notifications" that include a still image on motion events. They are not full resolution images, but are generally good enough for monitoring and seeing things like cars or recognizing people, etc. The code simply takes those snapshot images, triggers a new one at a scheduled interval, downloads this snapshot image directly from Ring, and dumps it to the MQTT topic, where the Home Assistant MQTT camera addon processes it as an image.

There's no processing of the image at all being done by ring-mqtt (which I'd have to do to add timestamps and other data) and I have no plans to do so going forward because, really, if you want this more complete functionality, the Home Assistant Ring integration already does it, why duplicate that effort? It's why camera support is disabled by default in the addon anyway, because there's nearly zero reason to use ring-mqtt for cameras with Home Assistant as the native integration is so much better and can be so much more capable since it's not encumbered with the limitations of MQTT.

These days, the only reason cameras are supported at all is because lots of people use ring-mqtt for things other than Home Assistant, and they like being able to interface with all their Ring components in a single integration.

[ronaldheft]

@broyuken I just compared the snapshots from my cameras.

The snapshot from the native Ring integration is higher quality (1080p vs 360p) and includes a timestamp and Ring logo in the top left.

I believe this is due to the source of where the image is coming from. The native integration grabs a motion triggered video from the website and selects the first frame, while this integration uses the mobile app's API to grab a snapshot. If you look at the mobile app, the snapshot quality is the same without the timestamp.

For my use case, this integration grabs a better snapshot. Not only can it grab a snapshot more frequently than just motion events, it's actually taking a picture vs. using the first frame of a video. For my Doorbell, the first frame was always a blurry, black and white frame, because I have pre-roll enabled and the pre-roll shows in the video from the website.

The nice thing is you're not losing the snapshot from the native integration. So if that works better for you, you can use that, or combine it with the more up-to-date lower resolution snapshot in your interface.

[broyuken]

Gotcha, thanks for the explanation. The native integration is nice and does a good job. The main drawback is that it does not support snapshots. I think for the purpose that I'm using this for (just to get a quick glance of my house) this addon does what I want better. My use cases are almost exactly the same as @ronaldheft 's. Checking if the trash has come, or if the car is in the garage, how much snow is outside, etc.

[tsightler]

I have been considering adding a timestamp to the image. It would be "approximate" because I don't think I can know exactly when the image was taken (ring-client-api appears to hide the timestamp from consuming users, although maybe I could request a small enhancement, and I guess, worst case, I could always go get the actual time directly). But I thought that it might be good enough to simply show the most recent "refresh time" for the snapshot and I think it would be fairly easy to do if I pull in something like jimp as a dependency.

Feedback on if this would be valuable or not would be welcome.

[ronaldheft]

@tsightler That might be helpful to include the refresh time in an attribute, but I disagree with adding it to the image directly.

It's nice to have a "clean" image, and if you provide the refresh time, someone could always add it themselves if they want it. The picture glance card could even display it if it's in an attribute.

I'm already estimating the refresh time in my install by updating an input_text with the current timestamp whenever the binary data changes on the camera.

[tsightler]

OK, good feedback. I had also thought of including it as an attribute but didn't realize that the glance card could display attributes. Now that you've pointed that out it definitely looks like the best place to add it.

[broyuken]

That seems like the best of both worlds. The option is there if you want it, but it's not forced on the users.

[ronaldheft]

Yeah, the picture glance card is pretty slick. I was able to customize it further with using a template entity behind-the-scenes to show relative time, and then was able to display the text on the right with card-mod.

[tsightler]

Nice! Maybe I'd figure out some of that stuff too if I ever actually bothered to use the UI. For me, Home Assistant is an automation platform, I barely care that it has a UI. About 6 months ago I spent some time to build a nice card with some add-ons that put all of my alarm and sensors, grouped by zones and with details like last change, battery level, power/tamper status, wifi strength, etc. Not being a visual guy at all, I was so proud of it. As you posted this I realized that the last time I looked at it was probably 6 months ago! :-)

[broyuken]

If you do home automation correctly you don't need a UI, it all just takes care of itself.

[tsightler]

I've come to the conclusion that I could replace Home Assistant with a bunch of Node-Red flows, and it would probably be easier to maintain vs YAML based automations.

[broyuken]

Any chance you'd want to post your automations for inspiration?

[tsightler]

I don't think any of my automations are special, there are plenty of much better and more sane examples out there. I have one or two that are a little "smart" with how they recognize the pattern of leaving home vs arriving home (basically the order of doors and motion, etc), but overall, they are really simple. I just find describing automation behavior in YAML very non-intuitive. I mean, I've adjusted to it, but it seems like there had to be a better way from the start. I much prefer the flow based model for automations.

[ronaldheft]

So about 24 hours in and everything appears to be working great. Both cameras batteries have held up great, kept to their refresh schedule, and don't appear to be draining any faster than normal.

Happy to continue testing any additional functionality you'd like to add, but the base functionality is working perfectly. Thank you @tsightler!

[tsightler]

I didn't get a chance to work on this tonight but over the next few days I'll try to clean it up and push an official 4.3.1 out the door. Thanks for the testing!

[ronaldheft]

So I believe I've found a bug, but I'm not sure exactly what's going on.

I've noticed that whenever Home Assistant is restarted, for the first few minutes after a restart, it appears the snapshot is updating every few seconds.

I've verified that a new snapshot is actually taken every few seconds during that window, as I can watch things on my camera slowly move with each frame addition coming in.

I've read through the code and it's not immediately apparent to me how this could happen. I am suspecting it has something to do with Home Assistant subscribing to MQTT for the camera, triggerring the initial snapshot but I'm unsure.

The refresh schedule follows the expected schedule a few minutes after Home Assistant is running, so eventually it does sort it self out, but for frequent Home Assistant restarts during configuration tweaking, etc, I'm thinking this could be a battery killer.

Any initial ideas @tsightler on why I might see this behavior? I can reproduce it after every Home Assistant restart.

[tsightler]

When you say "every few seconds" can you be more specific? It would be normal if it refreshed every 30 seconds for the first 5 minutes as that's a hack I implemented ages ago to do with a specific Home Assistant issue where it would send it's "online" message in some cases minutes before it was really ready to accept new devices. After a Home Assistant restart the code sends discovery data and state updates every 30 seconds for 10 times (5 minutes total).

I'm not even sure if this is really needed with modern Home Assistant as MQTT discovery has come a long way in the last 3 years and it's far more refined, with birth messages even enabled by default sometime last year, but no one has ever complained about it and it eliminated tons of annoying bug reports about discovery failing on restarts back in the day, so I've never removed this logic.

Now, if you're seeing it refresh more often than every 30 seconds, that's going to be a different issue, but I'm not sure how it's possible to be less than every 10 seconds or so since ring-client-api doesn't even appear to allow new snapshots more often than every 10 seconds.

[ronaldheft]

Thank you for the detailed explanation. It is every 30 seconds for 5 minutes, and that would make sense how it's happening.

I'm of mixed opinion if it's something that does need a fix. The only issue I foresee is someone who restarts Home Assistant frequently might drain their batteries faster.

[tsightler]

I'd think they'd have to really restart a lot to have an impact in most normal circumstances. I mean, a restart a day would only increase the total number of snapshots from 144 to 154 per day for the default 10 minute case, which is probably not enough to tell the difference.

That being said, the current implementation was just a proof of concept, I implemented it quickly to make sure it would work, every interval it just grabs a new snapshot and sends it this, during a republish event, it also grabs new images. However, in the final implementation, I plan to cache the snapshot image as a property of the camera and only refresh it on the scheduled interval, so any republish events will just send the cached image, thus it won't use any more battery.

Somewhere along the way I need to test if this republish hack is even required anymore. It's just really difficult when you don't really have any view of the status of Home Assistant to make sure that Home Assistant has the current state of the device. There are several ways to address it, but none of them are perfect. I found this option to be the cleanest way that caused the fewest number of issues to be opened, and that is the critical metric for me as I never expected this little side project to be used by so many people. The only possible way I can support it is if it works for 99.999% of the cases without issue.

[ronaldheft]

Ah cool, that makes sense. I agree, caching the image and keeping the republish logic sounds like the best of both worlds and a solid plan. Thanks.

[timota]

Got this error

(node:8) UnhandledPromiseRejectionWarning: Error: Motion detection is disabled for Garden, which prevents snapshots from this camera.  This can be caused by Modes settings or by turning off the Record Motion setting.
    at RingCamera.checkIfSnapshotsAreBlocked (/app/ring-mqtt-dev/node_modules/ring-client-api/lib/api/ring-camera.js:317:19)
    at RingCamera.<anonymous> (/app/ring-mqtt-dev/node_modules/ring-client-api/lib/api/ring-camera.js:336:18)
    at Generator.next (<anonymous>)
    at /app/ring-mqtt-dev/node_modules/ring-client-api/lib/api/ring-camera.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (/app/ring-mqtt-dev/node_modules/ring-client-api/lib/api/ring-camera.js:4:12)
    at RingCamera.refreshSnapshot (/app/ring-mqtt-dev/node_modules/ring-client-api/lib/api/ring-camera.js:331:16)
    at RingCamera.<anonymous> (/app/ring-mqtt-dev/node_modules/ring-client-api/lib/api/ring-camera.js:363:26)
    at Generator.next (<anonymous>)
    at /app/ring-mqtt-dev/node_modules/ring-client-api/lib/api/ring-camera.js:8:71
(node:8) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:8) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

as i understand - no possible to get snapshots from those devices that configured with Modes and have motion detection switched off as part of Mode. Is any workaround for this ?

[tsightler]

Indeed I should trap this error, however, to answer your question, no there is no workaround that I'm aware of as it's not possible to take snapshots if motion detection is switched off so, during the time when motion detection is disabled, there will be no snapshot image updates. The workaround we be to not disable motion detection.

[tsightler]

Hi all, I published a new dev version tonight which implements this in the way that I believe is "final". It has the following changes from the earlier proof-of-concept code:

• Snapshots are now cached for their interval instead of being retrieved on every publish/republish cycle
• Multiple snapshot refresh modes are implemented (vs previous true/flase) a) "motion" - Refreshes snapshots only on motion events (same as 4.3.0 behavior) b) "interval" - Refreshes snapshots only on scheduled interval (30 seconds for wired cameras or battery cameras in wired power mode, 10 minutes for cameras in battery power mode unless the Snapshot Capture feature is enabled in the Ring app, then use same interval as configured there c) "all" - Refreshes for both interval and motion events (interval refresh is automatically paused during active motion events)
• Allows manual override of default refresh interval by posting new interval in seconds to 'snapshot/interval' topic of camera (minimum 10 seconds)
• Timestamps are sent as part of JSON attributes topic
• Hopefully trap any errors when snapshots cannot be taken (for example, cameras with Modes set to disable motion events, which also blocks snapshots). Will simply publish previously cached snapshot.

I'm running this now on my own setup and it seems OK, but additional testing would be appreciated as it was a little more intrusive than I had hoped.

[broyuken]

Couple silly questions.

1. Where do I select those new options? Is it something like enable_cameras: motion instead of enable_cameras: true?
2. How do I add an attribute to the picture glance card? Is there a way to do it without creating a template entity or do I just make one with the attributes info?

[tsightler]

1. Documented in the readme of the dev branch, but if you are using the current addon, probably no way to test, only if you use Docker or standalone. Summary version: enable_snapshots is no longer true/false, but now accepts "none", "motion", "interval", or "all".

2. I believe this is possible but I doubt you'd actually want it as the timestamp is currently send in epoch format so you probably want to translate it into something friendly with a template entity.

[tsightler]

Although you do bring up a good point, I could make it so that enable_cameras is the only parameter and have a value of "sensors", "motion", "interval", or "all". That's actually a good idea I think because I hate having so many config options and I think it's more clear vs having to enable cameras and then also enable snapshots. Previous versions already confused people by having an "enable_cameras" option that only enable the various camera capabilities, but not the camera imaging functions.

I'll try to implement that before I push the dev branch to main.

[broyuken]

I am running HA Core OS, so I have no way to test this yet until it gets published to the dev addon branch?

Could I just update the config.json file in your addon to "enable_snapshots": "str", This should allow me to set enable snapshots to "motion" and then the addon should pull the dev branch correct?

[tsightler]

Yes, you can, that's really the only issue. Of course, right now it still accepts "true/false", with "true" simply turning into "all" for enable_snapshots. But if you change it to "str" it should be enough to set any value you like.

[broyuken]

So just tried to figure out how to do that but I couldn't find the file on my box where the schema is set. It looks like I might need to clone your addon repo, change the setting then install my modified addon instead of yours. That sound about right, or is there file on my system already where that schema is set that I can just easily modify?

[ballakers]

@tsightler I've said this before (when you helped me get up and running), YOU ARE THE MAN!!!! So prompt with answering questions and implementing requests. Just want to say thanks again and give yourself a pat on the back!
Trying dev mode right now. I have 3 wired (doorbell pro and 2 floodlights) and just the one battery powered spotlight with 2 batteries and a solar panel (got a good deal on marketplace or would've avoided batteries like you). Also here in Saskatoon Saskatchewan it's been really cold lately so I think the battery cam has only been online like 2 days out of the last 45 haha since it goes offline as soon as -20C comes haha.
Will let you know how the battery goes and just to confirm (I know you mentioned it) for the battery cam snapshot interval within the Ring app it is 1hr, 14mins or 5mins. I have it set to 1hr since wyze or aqara are watching too. Won't be able to report much back about the battery until the warmer weather comes and the thing actually stays online haha

[tsightler]

I have no idea if the file is local and could be changed locally or not. Believe it or not, I don't use the addon at all. I only agreed to maintain it because other people started making addons for ring-mqtt but users kept opening cases about those addons on this project and it was just a mess, so it was either kill the project completely or attempt to maintain the addon myself. I learned just enough to create a functional addon and that's where my knowledge ends.

But indeed forking it would work. I previously maintained a dev branch of the addon where I could publish little changes like this when required, but I stopped because the benefit of the feedback was proving to be limited as the skillset of addon users tended to skew toward the less technical and I was spending more time supporting people trying to use the dev addon than actually getting feedback.

That's when I implemented the BRANCH feature, which makes testing code in the dev branch super easy in most cases, but it doesn't happen to work in this case since the feature needs changes to config options. If you can fork it and test it, great, if not, I'll probably just push it anyway. It's a new feature that will likely be used by a limited subset of users, so the risk isn't that high, and I'm already running it in my setup so I know it mostly works. Just a few little things to clean up. I'll probably push it to the main branch tomorrow regardless.

[ballakers]

Dev branch is working fine but when I try to change the "enable_snapshots:" to motion, interval or all it says not a valid value.
here is the full error message: Failed to save addon configuration, not a valid value for dictionary value @ data['options']. Got {'enable_cameras': True, 'enable_snapshots': 'motion', 'enable_modes': True, 'enable_panic': False, 'enable_volume': True, 'mqtt_host': '', 'mqtt_port': '', 'mqtt_user': '', 'mqtt_password': '', 'branch': 'dev', 'ring_token': '', 'location_ids': ['']}

end of error message and below is my start-up showing cloning into dev branch

logs:"Updating ring-mqtt to the development version... Cloning into 'ring-mqtt-dev'... Installing node module dependencies, please wait...

ring-mqtt.js version 4.3.1 Node version v12.20.1 NPM version 6.14.10 git version 2.26.2"

referring to these notes below... just trying to replace the true/false for enable snapshots with "all" but getting the error mentioned above.

Multiple snapshot refresh modes are implemented (vs previous true/flase) a) "motion" - Refreshes snapshots only on motion events (same as 4.3.0 behavior) b) "interval" - Refreshes snapshots only on scheduled interval (30 seconds for wired cameras or battery cameras in wired power mode, 10 minutes for cameras in battery power mode unless the Snapshot Capture feature is enabled in the Ring app, then use same interval as configured there c) "all" - Refreshes for both interval and motion events (interval refresh is automatically paused during active motion events)

[tsightler]

Yes, as noted above, you can't set the mode options via the addon right now because the addon has to be updated to accept the new configuration values. This is expected for now as I probably won't publish a dev version of the addon. When using the current dev code with the addon you only have "true/false", so you either get no snapshots, or "all" snapshots.