Trouble migrating webcams from REST to HTTP API

Hi all,

I have Vivotek webcams that don't support custom headers. Previously, I was triggering action groups like this when motion is detected:

http://[local IP]:8176/actions/Cam1Motion?_method=execute

I see from the API documentation that it is possible to pass the API key as a URL query argument (versus using an Authorization header) but I'm not seeing a way to construct a request to trigger an action group without utilizing custom request headers.

Any suggestions or workarounds?

Many thanks!
-Jim

It's not possible to execute an action group from a simple URL. Can your cameras send curl commands?

https://wiki.indigodomo.com/doku.php?id=indigo_2022.2_documentation:rest_to_http_api_conversion_examples&#action_group_commands

Set a variable from the URL and use that to trigger the Action Group.

It's not possible to execute an action group from a simple URL. Can your cameras send curl commands?

https://wiki.indigodomo.com/doku.php?id=indigo_2022.2_documentation:rest_to_http_api_conversion_examples&#action_group_commands

Unfortunately, the Vivotek cameras only support a basic url with basic or digest authentication.

Set a variable from the URL and use that to trigger the Action Group.

That would work fine but I also don't see a way of doing so without custom http headers. Same goes for device commands.

Alternatively, the cameras can send email or ftp, but I'm trying to avoid the extra work of implementing a totally new means of getting the cameras talking to Indigo.

Joe, I'm surprised you don't have a plugin to solve my problem.

Cheers,
-Jim

Set a variable from the URL and use that to trigger the Action Group.

That would work fine but I also don't see a way of doing so without custom http headers. Same goes for device commands.

Alternatively, the cameras can send email or ftp, but I'm trying to avoid the extra work of implementing a totally new means of getting the cameras talking to Indigo.

Joe, I'm surprised you don't have a plugin to solve my problem.

Cheers,
-Jim

What custom headers do you need to send?

OTOH, you could probably use the HTTPd plugin.

Set a variable from the URL and use that to trigger the Action Group.

That would work fine but I also don't see a way of doing so without custom http headers. Same goes for device commands.

Alternatively, the cameras can send email or ftp, but I'm trying to avoid the extra work of implementing a totally new means of getting the cameras talking to Indigo.

Joe, I'm surprised you don't have a plugin to solve my problem.

Cheers,
-Jim

What custom headers do you need to send?

OTOH, you could probably use the HTTPd plugin.

I gave the plugin a shot. The doc doesn't mention it, but it looks like it also requires an Authorization Header, which the cameras don't provide:

MyRequestHandler: POST to port 8276 from [internal IP] for /setvar?deviceTest=FALSE
MyRequestHandler: Request has no Authorization header
MyRequestHandler: Authorization failed

Did you put a username/password in the config?

Did you put a username/password in the config?

Ah, turns out I made a typo in the password during testing.

I almost have this working now. The daemon is parsing the request url but not creating or updating variables:

Code: Select all

   HTTPd 2 Debug                   HTTP Daemon on port 8276: MyRequestHandler: updating device
   HTTPd 2 Debug                   HTTP Daemon on port 8276: MyRequestHandler: saved_states = {'foo': 'bar'}
   HTTPd 2 Debug                   HTTP Daemon on port 8276: MyRequestHandler: new_states = {'foo': 'new'}
   HTTPd 2 Debug                   HTTP Daemon on port 8276: getDeviceStateList, base state_list = States : (list)
   HTTPd 2 Debug                   HTTP Daemon on port 8276: didDeviceCommPropertyChange no changes
   HTTPd 2 Debug                   HTTP Daemon on port 8276: getDeviceStateList, adding String state foo, value new
   HTTPd 2 Debug                   HTTP Daemon on port 8276: getDeviceStateList, final state_list = States : (list)
     Item : (dict)
          Disabled : false (bool)
          Key : foo (string)
          StateLabel : foo (string)
          TriggerLabel : foo (string)
          Type : 150 (integer)
     Item : (dict)
          Disabled : false (bool)
          Key : foo (string)
          StateLabel : foo (string)
          TriggerLabel : foo (string)
          Type : 150 (integer)
   HTTPd 2 Debug                   HTTP Daemon on port 8276: didDeviceCommPropertyChange no changes
   HTTPd 2 Debug                   HTTP Daemon on port 8276: didDeviceCommPropertyChange no changes


Same behavior whether the variable http_foo exists or not. Am I just missing something silly?

Thanks again,
-Jim

No, my bad. It doesn't update variables anymore. That was the behavior in the original plugin, which only supported one HTTP port target. Now the update is made to a custom state in the device. So trigger on the custom state of that name, not a variable.

Alternatively, the cameras can send email or ftp, but I'm trying to avoid the extra work of implementing a totally new means of getting the cameras talking to Indigo.

For a while I lost motion alerts with my cameras.... I don't remember why. I ended up using email notifications with the SMTPd plugin. I liked my setup because it was instant and I could configure the dwell time (how long your virtual camera says "motion" with timer devices. I did a small write up on how I configured it. https://forums.indigodomo.com/viewtopic.php?f=216&t=16348&hilit=SMTPd#p179054

Full disclosure.... I wanted flexibility to add cameras outside my NVR ecosystem and took the plunge to add a Blue Iris machine into the mix. Comparatively, it was cheeper than upgrading one of my NVRs which were getting a little old.... so it worked out and the blue iris plugin is rock solid and I get a lot more data from the same cameras coming into indigo.

But the method I used previously (SMTPd) will work with any device on your network that uses email notifications.

No, my bad. It doesn't update variables anymore. That was the behavior in the original plugin, which only supported one HTTP port target. Now the update is made to a custom state in the device. So trigger on the custom state of that name, not a variable.

No worries Joe. I think I can still build a workaround using that functionality.

Many thanks again!
-Jim

Alternatively, the cameras can send email or ftp, but I'm trying to avoid the extra work of implementing a totally new means of getting the cameras talking to Indigo.

For a while I lost motion alerts with my cameras.... I don't remember why. I ended up using email notifications with the SMTPd plugin. I liked my setup because it was instant and I could configure the dwell time (how long your virtual camera says "motion" with timer devices. I did a small write up on how I configured it. https://forums.indigodomo.com/viewtopic.php?f=216&t=16348&hilit=SMTPd#p179054

Full disclosure.... I wanted flexibility to add cameras outside my NVR ecosystem and took the plunge to add a Blue Iris machine into the mix. Comparatively, it was cheeper than upgrading one of my NVRs which were getting a little old.... so it worked out and the blue iris plugin is rock solid and I get a lot more data from the same cameras coming into indigo.

But the method I used previously (SMTPd) will work with any device on your network that uses email notifications.

Thanks Bill. I read your great write-up and don't see any reason this approach wouldn't work with my Vivotek cameras. Will try if I hit a roadblock with the HTTPd plugin.

-Jim