This is what I did to receive events in Hubitat when someone pressed the doorbell button. If I have missed out any details, or if I have made any mistakes, please tell me.
Motivation: My other half doesn't always have her phone with her so would not always hear the notifications when someone pushed the doorbell button. She wanted some kind of noise or "ding dong" in the house.
I think that "phone notifications" require internet access - if true, I would prefer to have a solution which does not require this.
The door bell is situated about 80 metres from the house so the supplied Reolink chime will not activate.
Procedure: I used the Reolink app to set up the doorbell's ONVIF server.
I installed Scrypted via Docker on my Synology NAS.
Scrypted found the doorbell and I could see BinarySensor events whenever the button was pushed.
On Hubitat I installed a Virtual Button device, and a Maker API with the doorbell Virtual Button as a "Selected Device" so that it could receive HTTP messages.
I set up a Scrypted automation to run the Shell Script "curl http://(Hub address)/apps/api/7/devices/4/push/1?access_token=(your access token)" whenever "BinarySensor eventData===true"
And it seems to work. I set up a Rule to use the event to call the Chromecast app to make my Google Home Mini say "There is someone at the gate"
I will be happy when they do.
My excuse is that I want to have a working doorbell asap. And maybe because, once the thought "there must be a way of doing this" enters my head, I get a bit single-minded and don't like giving up.
Now if I could just get 2-way audio working.......
Just an update...
I now use the Reolink Camera plugin in Scrypted instead of the ONVIF plugin as it has been updated to support 2-way audio.
I have also added a 2nd automation in Scrypted (in addition to the button push one) which is activated whenever movement is detected. I have added a corresponding Virtual Motion Sensor in Hubitat which when activated via Maker API uses another rule to send a different audio message to the speaker.
Now I just need a free app which supports RTSP/RTMP streaming AND 2-way audio.
As before, I have tried to keep this description short, so feel free to ask for any clarifications.
Dummy here. Trying to get this to work but scrypted console is saying bad URL. I have replaced hub IP and maker token where appropriate but honestly I’m not super familiar with maker API. Any help is appreciated
In Scrypted I put an automation trigger of eventData===true for event Reolink Doorbell (BinarySensor) and an Action of Run Shell Script.
The single line of the script is... curl http://%Hubitat IP address%/apps/api/%Maker API app number%/devices/%Virtual button device number%/push/%Number of button to push%?access_token=%Maker API access token%
Replace all %% with your data (you will need a Maker API app and a Virtual Button device).
Another update... My Synology NAS now supports the Reolink doorbell directly (no need to use ONVIF) so I have stopped using Scrypted to send an http message to Hubitat and just use a Synology Action Rule to send the message whenever someone pushes the doorbell button.
It has a list of cameras that it knows how to communicate with. Each entry in the list has a bunch of parameters telling the NAS how to handle the camera and what functions it provides. This has included ONVIF for a long time so in the past it could record the Reolink doorbell but not much else.
Recently it added "Reolink Doorbell" to its list. It talks to the doorbell with HTTPS via the doorbell's API so now it handles button pushes, 2-way audio, and person detection.
I think the problem is that, currently, the doorbell cannot be configured to send an HTTP message when an event (button pushed, etc) occurs. I think the NAS uses some other aspect of the API to receive events. I've looked at the API and it looks complicated. Maybe I'm wrong, but I think the manufacturers (e.g. Reolink) are responsible for providing Synology with info (maybe including drivers) for adding a device to their list of supported cameras.
Clearly the doorbell can sent event messages, but the mechanism does not appear to be publicly visible.
Here is what I did (I have tried to include all the steps - apologies if it is unnecessarily detailed or if I have omitted something)....
Go to Devices, Add device, select Virtual, give the device a name and type and number of physical buttons (I chose "Virtual Doorbell Button" and Virtual Button and 1). Make a note of the device ID number (one way of doing this is by looking at the address bar of your browser - the last number in the address will be the device ID)
Go to Apps, Add built-in app, select and install Maker API. Open Maker API and under "Allow Endpoint to Control These Devices" select your virtual device. Under Local URLS, Send Device Command, copy the http.... command.
In your Synology, Edit Action Rule, Action, paste the http... command. Replace [Device ID] with the device ID number of your virtual button, replace [Command] with push, replace [Secondary value] with 1.
That's it. Do a test send. In my case I used the button push events to trigger actions in Rule Machine.....
Can I ask for some help here? I've had a Synology NAS for some years, and recently installed a Reolink PoE doorbell. Initially I was just using the Synology to record doorbell video via ONVIF, but after seeing your post and finding the doorbell was a fully supported Surveillance Station device decided to put the button press detection in.
I'm pretty sure I've got the HE virtual button + MakerAPI/SurvStation Action Event link in and working correctly - press the "Test Send" button in Action Events and the HE button gets a pressed event and fires off a test RM rule.
But the Action Event isn't firing at the Surveillance Station end when the physical doorbell button's pressed. This is the event configuration for the button press:
All the config that you showed here in your posting looks correct - i.e. it is identical to my config. Is it possible that there is something wrong in the actual doorbell configuration? Do your doorbell visitor events get sent to your NAS? I imagine that there are many ways of checking this - in my case I can see doorbell visitor events when I look at the NAS Monitor Centre - a list of recent visitor events are shown to the right of the live image.
Thanks for getting back to me Richard. it looks like the doorbell events aren't getting through to the NAS - assuming I'm looking in the right place here's what I see a minute or so after a doorbell button press:
When the button's pressed the chime does ring, and a notification gets sent to the Reolink phone app, so things seem to be working at a Reolink level.
Looking at the Reolink app there don't seem to be any settings at all related to sending doorbell press events. In Surveillance Station the only potentially relevent one I could find was under Recording::Stream:
This looked promising, and was initially unchecked, but after checking it, saving settings and retrying the button presses still aren't showing up in SS.
Random thought - you're using https for doorbell/SS communication?
Advanced Continuous Recording - Event detection - mine is unchecked, so I don't think this is the problem. And yes, I use HTTPS like you and the same port,
Do you have 'Intercom' in your camera edit window?
(I'd taken these to be related to audible notifications at the PC when the doorbell rights, but in any event it was enabled when I checked.)
I think deleting and re-adding is the next thing to try; the current instance was originally a general camera/ONVIF thing, then changed to be a Reolink Doorbell once that was added to the list, so perhaps a few bits of initialisation got skipped.
Will post an update on how that goes here, and thanks for your help.
Update: Sadly, not a roaring success; deleted the existing entry for my doorbell camera in Surveillance Station, added a new one from scratch (specifying the camera type from the start this time), and...got exactly the same behaviour as before.
Surveillance Station gets the video feed without issue, but just isn't seeing the doorbell button presses at all.
I've also tries power cycling the doorbell itself to see if that would make a difference - nope.
Will think on things and poke around for possible solutions.
