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
s6-supervise amcrest2mqtt (child): fatal: unable to exec run: Permission denied #14
Comments
Seconded here, same issue
|
I have the same problem s6-rc: info: service s6rc-oneshot-runner: starting Add-on: amcrest2mqtt Add-on version: 2023.3.0 Please, share the above information when looking for help s6-rc: info: service base-addon-banner successfully started |
I'm also encountering the same problem (my log matches the above). After upgrading, all of my AD410 sensors also became unavailable:
Video continued to stream. Reverting back to 2022.5.1 restored everything to normal. I tried upgrading my firmware to the latest version (Lexus_SDB61i-Lexus2_Eng_N_32M_nonCA_V1.000.00AC001.0.R.20230221.bin from https://amcrest.com/firmware-ash). A second attempt at upgrading to 2023.3.0 was the same as the first (only the video streaming was working - no sensors), so I reverted back to 2022.5.1 of the add-on again. Everything started working for me again. Edit: Added information about reverts to for clarity. |
Alright I will look into this tomorrow I think I know what is causing this. |
Thank you for all the effort you're putting into maintaining this! I really appreciate it. It can't be easy with the maintainer of the underlying project disappearing and having to switch to a different fork. |
Alright, 2023.3.2 is out, let me know if the issue is solved |
That fixed the permissions issues, but the sensors are still not coming up for me, and it crashed. Here's the log:
Edit: Sorry about the formatting issues. |
Please try 2023.3.3 and let me know how it goes |
Thank you for the update and all your work on this. At first things were looking good. The binary sensors came up and everything just after the update. But then I tried testing out the doorbell and the human detection on the AD410, and not only was nothing detected by the binary sensors (for both the ringing of the doorbell and the human detection), but the doorbell streaming stopped. Also, different lights were displaying on the doorbell that I had never seen before. I'm going to restore a backup again. Here's the log:
The human detection and ringing of the doorbell showed up in the log for the add on at least. |
For what it's worth, the video came back up before I restored my backup, so I re-tested the doorbell and human detection again, but those still didn't work. I checked into the doorbell lights, and they blink repeatedly when the doorbell can't connect to the WAN. So I created an automation that turns that off, since I keep the Internet blocked on the doorbell. I run that through the integration, so it wasn't able to turn the blinking lights off, either. Here's what that looks like, in case it's helpful:
And here's the shell command:
Edit: Added that I re-tested when video stream came back up and clarified a bit on the automation. |
One more quick note: for the lights, since I'm calling the service on the doorbell itself, bypassing the add-on, I'm wondering if the reason that the automation wouldn't run is because of the state condition checking to see if that online light sensor is false was failing. which is the part that would have come from the add-on. |
Alright so this new fork has a bunch of changes, take a look here for all the changes: |
You're right about there being a lot of changes in carefulcomputer/amcrest2mqtt@67d4cb8. I'm not sure what might be breaking things, but based on my experience and the experience in this issue, it seems as though it isn't working correctly. https://github.com/dchesterton/amcrest2mqtt isn't supported anymore, but it does work for me as part of 2022.5.1 of the add-on, even with me running the latest firmware on my AD410. So is there a way to update that application only as necessary to make it work with the updated dependencies? It seems like sticking with the dchesterton version as closely as possible, at least as a starting point, might be the route to take. Even carefulcomputer/amcrest2mqtt@013e138 changes the data structure, and I'm not sure what that would be fixing, at least in my situation. There may be a different story for other Amcrest devices. |
Something interesting I noticed is that it seems like some of the 2022 Amcrest FW updates may have been problematic. For example, there's this thread from November 2022 on their forum (see the last comment in particular):
The firmware I'm using was released a little over a month ago: 2023/02/21. Could some of the updates in https://github.com/dchesterton/amcrest2mqtt/pulls and carefulcomputer/amcrest2mqtt@67d4cb8. which date from around this time, been attempts to work around this bugginess and potentially incorrect data structures? |
Not sure but I know I thought this change would solve #10 however, I have not heard any update from that issue. I asked in the issue #91 and @unixorn said the patch-1 branch solved his issue, although I do not know what version of the firmware he is running (hopefully he sees this) |
Sorry it took so long for me to see this, it got lost in my notifications. I'm running |
The human detection works. Well works in that I see it in HA when I get notifications of human detection. It doesn't always recognize humans coming to my door, though that's a doorbell firmware problem and not a problem with the mqtt gateway. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I updated to 2023.03.0 and now I'm getting this error. If I leave it running, the error loops every 10 seconds or so forever.
The text was updated successfully, but these errors were encountered: