Generic HTTP Digest Auth request for Script

I need the ability to make an HTTP request specifically that can do Digest Authentication.

What I’m trying to accomplish is that I have an Amcrest IP cam that I want to expose an On/Off type script to Alexa so that On will go to preset 1 (looking at an area) and Off = preset 2 (looking at a wall).

Here is the request that when I execute from Postman with Digest auth works.
Now I just need to do it from HASSIO, or possibly HA-Bridge.

http://[IP Address]/cgi-bin/ptz.cgi?action=start&channel=1&code=GotoPreset&arg1=0&arg2=1&arg3=0

Does anyone have suggestion on how I can accomplish this?

try the rest component:

Last I checked (although it’s been a while), the RESTful Command uses aiohttp, and aiohttp doesn’t support Digest Authentication. But maybe something has changed recently.

But if that’s still true, and you’re HA is running on Linux, then you can use a Shell Command which then uses curl (which definitely supports Digest Authentication.) I used this for a while with my Amcrest camera, until I wrote a custom component instead.

I don’t know much about the rest sensor, so it probably doesn’t support the authentication that he needs.

Thanks for the info, I’ll look into using the Shell Command tonight.

A few question that come to mind:

  1. What exactly do you mean by custom component? I’m newer to HASSIO.
  2. What is the maintenance cost of a custom component when doing a HASS update. Said differently do you have to manually re-add your component. Perhaps what I really am asking for is a link to documentation about it how one works.
  3. Why did you move away from the Shell Command? The general Pros, Cons VS your custom component.

I really appreciate your help and info.

BTW, let me know if you have any questions about how to use curl with the Amcrest camera. I have some old examples of what I did before switching to my custom component still lying around somewhere.

A custom component is Python code that adds capabilities to the standard install. The files go into a custom_components directory which is in the same directory as your HA configuration file.Therefore, when you upgrade HA, it doesn’t affect these files. Having said that, you do have to make sure nothing changed in HA that would prevent your custom code from still working.

You can find more info here:

I started with the standard Amcrest integration, but discovered it lacked a lot of functionality that I was originally using when I used SmartThings before moving to HA. At first I used things like Shell Commands, but it got a bit cumbersome and still didn’t do everything I wanted. So, since I have Python programming experience, and experience with the HTTP API of my Amcrest camera, I decided to write a custom component that added to the existing integration. It can do things like turn video on and off, turn audio on and off, move the camera to presets, start & stop touring, enable and disable motion detection, turn on and off a mask, start and stop recording, etc. I’m happy to share it, but 1) I haven’t put it in github yet, and 2) I’m still on release 0.69.1, so I have to do some work to make sure it still functions properly with the latest & greatest release. Also, although most of it is pretty generic, there are a few things that are pretty specific to the way I use the camera, so I’d probably want to filter that stuff out before sharing it.

Sharing would be ideal! I really only care about code comments explaining assumptions or not fully implemented stuff compared to pretty and clean code IMHO.

Let me know how you wish to proceed. I am on the latest version, but am also willing to take on the responsibility to find the broken bits to get it working for my needs.


Ok, I put what I have on github.

There are three files, which go here (where <config> is the directory containing your HA config file):


The first and last where copied from a previous release of HA (somewhere around 0.60 or so) and modified to add services. The middle one was added from scratch and adds a binary_sensor for motion detected. These will basically take precedence over the versions shipped with HA. As I mentioned before, I’m currently on 0.69.1, so changes may be required for the latest & greatest HA release.

Let me know if you have any questions.

Thanks pnbruckner,

I have started diffing your scripts against the latest version 0.73.1.

  1. Good news is that ‘custom_components\’ they added motion as switches instead of binary_sensors like you did. I’m already using them for motion.
  2. I believe that #1 means I don’t need ‘binary_sensor/’ at all CORRECT?
  3. ‘camera/’ I think the services are all I really need short term to meet my needs. I feel that the services are generic enough and others would find value in them that they could be added to the existing ‘camera/’ and pull requested

Let me know your thoughts on #2 and #3. With #3 while I haven’t done much research on the effort of the contributing code standards. Is there another reason why you wouldn’t want to add that to the existing feature?

Great work on the scripts and I much appreciate your help and insight. :slight_smile:

So I think I did notice something about new motion switches, but I really haven’t looked into them yet. My binary_sensor indicates whether or not the camera detected motion, not enabling and disabling motion detection in the first place. I’m not sure how a switch would be appropriate for indicating motion was detected. So I’d have to go look at how they work in order to comment intelligently.

Regarding adding some or all of this work to the release via a pull request, I haven’t really tried to do that yet. From what I read there are a lot of requirements one needs to satisfy before being able to do that. I.e., there is a lot of extra infrastructure (for testing, etc.) that needs to be installed and used and I haven’t tried to work through that yet. Hence I’m not really in a position to submit anything for consideration yet.

FYI, I just committed a change that adds a service to change DayNightColor in VideoInOptions[0]. The service is camera.amcrest_set_color_bw and the options are ‘color’, ‘bw’ or ‘auto’.

Background: I’ve been having false video motion detection events overnight and in the morning for quite some time. One of the root causes was, as the sun rises, the default behavior of the camera was to switch from black & white to color. But that automatic switching was causing the video motion detection to trip. So the idea is to add automations that change the camera to black & white before sunset, and to change it back to color after sunrise. And the automation will temporarily turn off motion detection before changing the color_bw mode, and turn it back afterwards (if it was on in the first place.) This should resolve the false alarms due to the automatic color mode.

FYI, I’ve finally updated to a newer HA release (0.75.2.) I’ve updated my custom Amcrest code accordingly. (See my github link above.)

There is a minor API difference. My code originally registered a service named camera.amcrest_set_operation_mode. The standard camera component, however, has new camera.turn_off and camera.turn_on services. My code now uses these new services (and no longer has the camera.amcrest_set_operation_mode service.) But, since these new services are really for enabling & disabling the camera’s video stream, I also added new camera.amcrest_enable_recording and camera.amcrest_disable_recording services. The camera’s state hasn’t changed, though - it is still ‘idle’, ‘streaming’ or ‘recording’.

And to close the loop on the switches, they are for enabling & disabling motion detection and record on motion detection. They do not provide status of motion being detected. So my binary_sensor is still useful.

BTW, I noticed for some time that the Amcrest code was resulting in a lot of communication errors. I finally found (and fixed) the root cause. If you have a camera entity on your frontend, and if you click on it, it will open a larger window with the camera feed which updates more quickly. However, it’s still updating the “thumbnail” on the main page (behind the larger window.) And, there’s still updating going on for the binary_sensor. The standard Amcrest code did not have any coordination of these operations, each of which cause communication to/from the camera. Well, the camera doesn’t like that! So I added thread locking to serialize these accesses and the corresponding communication errors (and slow screen updates) have gone!

Note I’m on 0.82.0

I updated from your latest. I’m working on migrating my UI to Lovelace and the motion sensors return True/False for the state seems to be problematic for the native coloring of the images.

Background: I’m wanting to do a Picture Glance card the the motion icon always shows as illuminated.

I was wondering could I just update your scripts to have the state be on/off instead of True/False? I’m looking for specific instructions on how to accomplish that. What would be the potential harm in that?

As always I appreciate the help