Support for app open gate function

...Would you like to be able to control an action group or device when pressing open doorlock in the DoorBird app? thought to control my Yale Doorman lock...

I can't say I have the exact answer to Jens' request. But, what I did do was create an Indigo device that is a Door Open Button. Not that it was very complicated.
I created a virtual device that executes an Action that in turn executes a shell script with contains...

Code: Select all

#! /bin/sh
/usr/bin/curl -digest -u <user_ID>:<password> http://<IP_ADDRESS>/bha-api/open-door.cgi?

Works like a charm. What it does not do, is track the state of the "door." In my case my "door" is actually a gate and I track it's state by other means and maintain a variable with the gate's state. I then use that as the state of the virtual device.

So now I can add an open the gate button to a control page. (Actually, I already had one, but it used a separate relay connected to the gate controller).

But, this for me to thinking (Pete, you reading?) Maybe the main plugin device could be instantiated as a "door" or "lock" and then operating it would send the open-door-cgi command. Since there is no known state for the "door" the default state could change momentarily to indicate the command had been sent... or better, that an ack* had been received.

*

Code: Select all

{
"BHA": {
"RETURNCODE": "1"
 }

Maybe the main plugin device could be instantiated as a "door" or "lock" and then operating it would send the open-door-cgi command. Since there is no known state for the "door" the default state could change momentarily to indicate the command had been sent... or better, that an ack* had been received.

I was thinking something very similar but was waiting for the "door opened" command to be supported in the API. I was thinking that the lock device (when triggered) could remain open for the "Duration" setting that's set in the DoorBird App (Administration -> Relays). Very similar to how the plugin currently handles the motion timeout (Motion Device ->Edit Device Settings -> Advanced Options -> Pause between alarms). I can't read that setting from the device so it needs to be a manual entry unfortunately.

Happy to create the lock device within the plugin before the "door opened" API command is supported. I was actually thinking of doing this with an option to add an external Indigo device as a sensor for detecting the strike being opened (as you say, like a Virtual Device)... I'm going to connect a Z-Wave Fibaro universal sensor to the really so I know when the strike has been activated (until API support is added).

Regarding making the primary device a lock; I like this approach but does every Doorbird model include a door strike? I thought some didn't?

I really need to write up some documentation but just to clarify, the plugin's Doorbird device has actions to energise the relays and the IR light as an interim solution.

[Regarding making the primary device a lock; I like this approach but does every Doorbird model include a door strike? I thought some didn't?

The API door open command is generalized and can take optional arguments to define a device or relay. Those arguments could be optional fields in the Device config. So, in that sense, the answer to your question is yes. Of course, if someone doesn’t hook their DoorBird up to anything, “door open” would be a no op. But, so it goes.

Some models support two relays, so it would be necessary to spawn additional lock devices anyhow?

I've found visibility of the device connection state really handy (a couple of times the plugin or DoorBird has needed a restart).

Some models support two relays, so it would be necessary to spawn additional lock devices anyhow? .

Good point.

Some models support two relays, so it would be necessary to spawn additional lock devices anyhow? .

Good point.

That’s why you let the user set the arguments. If they want to control more than one relay, they can create another device.

...That’s why you let the user set the arguments. If they want to control more than one relay, they can create another device.

A little time for a more complete response. The API states:

Code: Select all

Syntax:
http://<device-ip>/bha-api/open-door.cgi?<parameter>=<value>

Where <parameter> = r and for our purposes, <value> = 1 or 2. For example:
http://<device-ip>/bha-api/open-door.cgi?r=1

Note if r=1 then the parameter and value may be omitted (I.e. r=1 is the default).

So, if the plugin is hard-coded to send http://<device-ip>/bha-api/open-door.cgi?r=
Then the user just needs to supply the value, 1 or 2. With 1 being the default.

Sorry if I am explaining something that is already well understood. But, I wanted to be sure the idea was clear.

Sorry if I am explaining something that is already well understood. But, I wanted to be sure the idea was clear.

All good This is the method already used in the plugin to energise the relays.

I Just released an update to the plugin (0.4.0). I'll look at including the changes discussed here in the next update.

Pete

I can't say I have the exact answer to Jens' request. But, what I did do was create an Indigo device that is a Door Open Button. Not that it was very complicated.
I created a virtual device that executes an Action that in turn executes a shell script with contains...

Not exactly Berkinet,

I want Doorbird's own app to send an input pulse to a trigger so I can control a Z-wave switch...

But you are near

//Jens