Send Synology Surveillance motion events to HA switch

Third party integrations
1

Hi everyone,

I use Synology SS to record my cameras and these are streamed into HA using the Synology component. I’m now looking to send motion detected events into HA using this guide as a starting point. That will allow me to create and send notification snapshots based on those incoming events.

The plan is to set up a RESTful switch (?) in HA and then have SS turn this on when motion is detected using the ‘action rule wizard’ which is capable of making POST requests to an external device.

I’ve used the excellent Chrome extension called POSTMAN to test HA api calls before and had the following working before retiring my wemo.

http://ipofhass:8123/api/services/switch/turn_on

{
    "entity_id": "switch.wemo_switch"
}

Those that know me know I’m a hardware guy and apart from coding in DOS back in the 70’s, I’m no software guru :smile: so figuring out the ‘endpoint’ URL I’d need to create in HA to turn the RESTful switch on and off using POSTMAN is a bit beyond me.

If someone can point me in the right direction in regards the URL required to test this in POSTMAN and the body content required to control the HA switch, I’m sure I can figure the rest out.

2 Likes
2

Seems I’ve gone off on a tangent! Oh my jelly brain. The Rest switch is for a remote endpoint. What I need is a way to control an input boolean from an api call.

3

OK, making some progress. Now have an API controlled input_boolean.

http://ipofhass:8123/api/services/input_boolean/turn_on
{
    "entity_id": "input_boolean.motion_entrance"
}

Can someone help me format that into a string I can use with the Synology action rule wizard?

4

OK, an update.

I have created both an input_boolean and a script to fire (and reset) the input_boolean under hass.io 0.73.0 and I can test both successfully using the following API calls using POSTMAN in Chrome without API passwords. I do have internal calls whitelisted though under my HTTP configuration (trusted_networks:)

http://10.0.x.x:8123/api/services/input_boolean/turn_on?entity_id=input_boolean.motion_entrance (works)

http://10.0.x.x:8123/api/services/script/trigger_ss_entrance_boolean (works)

Trying to call this from Synology Surveillance Station however does not seem to work despite the forum chatter saying that the Synology action rule wizard defaults to sending POST requests (mandatory). More head scratching required. :sweat:

1 Like
5

Hi,

Did you make any progress with this?

6

Yes. There was a bug in SS that I logged with Synology and they made me a patch.

7

Do you mind sharing the patch since I’m having the same problem? Working with Adanced REST client, not working from SS Action Rule.

8

The patch is processor dependant so it might break something? Best flick a support request from inside your NAS. I’m sure they’ll come back pretty quick now they know about it.

9

I’ve been trying to get this going as well and submitted a case to Synology last night in hopes of getting a magical patch too. I recieved the response and it wasn’t helpful. Basically they just told me to make sure my network isn’t having any problems. Not to be discouraged I went digging into the logs myself and tinkering around and here is what I’ve found:

  • The Surveillance Station bug appears to be in reading the query params out of the url. When I include the “?entity_id=input_boolean.something” it causes an error to be dumped to the log Failed to send POST external command with error [5]. Without the parameters it makes the call.

  • The /api/services/ endpoint doesn’t support query params! For the layman, that means the key=value that goes at the end of the URL after the “?” symbol. Using Postman I discovered that HA would gladly accept the POST however it would ignore the entity_id filter I supplied and apply the input_boolean turn_on call to all input_boolean entities! That is a really big problem. I didn’t notice it at first which I’m guessing @xbmcnut didn’t either. Just to make sure I wasn’t missing anything I double checked the source code for the api on both 0.73.0 (xbmcnut’s version) and 0.78.1 which is what I’m running. There is no change. Only json in the POST body will be read out. The same goes for all the api endpoints, they only read the body for entity ids.

To that end I was able to come up with a solution that works for what I’m trying to do and as a bonus it doesn’t require Surveillance Station to be patched! Just as a note, this doesn’t set a boolean, though you could have that be the result of your automation. Instead it leverages the motion as an event.

  1. configuration.yaml - Add the IP address of your NAS to the trusted networks. Synology doesn’t currently support sending form or url parameters so this is a must if you have authentication or an api password.

    http:
  trusted_networks:
    - 1.1.1.1

  2. Set the Action Rule up in Surveillance Station - You get to pick your own event name. I’m using motion_front_porch_camera for mine making the URL: http://1.1.1.1:8123/api/events/motion_front_porch_camera

    image
    image731×520 11.4 KB

  3. Hook up your automation (2 options here)

    • AppDaemon (This is what I use) - listen for the event using listen_event() (docs here)
      self.listen_event(self.motion_on, "motion_front_porch_camera")
    • Automation Trigger (docs here)
      automation:
  trigger:
    platform: event
    event_type: motion_front_porch_camera
10

@kdex. The patch I had was related to SS 8.1.xxxx. I worked with Synology and used Wireshark to show that post requests were in fact not being sent at all from SS. I then updated to the SS 8.2 beta and the API post action rule broke again. The 8.2 final release is out now and Synology confirmed that post sending has been fixed in 8.2.0-5761. I’ve just tested it and it’s working again with the the following action rule.

http://10.0.x.xxx:8123/api/services/script/trigger_ss_entrance_boolean

I’m connecting this to Hassio running 0.78.1 that has an API password set and trusted networks defined.

11

Awesome to here you have this working. I am running the same version 5761, but I am not having luck getting an event to post. api/events/front_door_motion the action rule history shows finished, but I don’t see the event show up in HA. Any ideas?

12

Are you sending a POST request to a HA service? Not sure what the ‘events’ is you’re sending to. Try sending an API request to a service like I have /api/services/script/xxxx

13

Not sure what I did wrong but I was able to get it working by posting to the events API.

Thanks.

1 Like
14

Interested to know if this method is still working for you or if you now use an alternative?

15

Still working for me by firing a script using the following:
http://ha_ip_address:8123/api/services/script/trigger_ss_entrance_boolean

1 Like
16

This has now broken in 0.83.x. I’m assuming I’ll now need to use a webhooks link to my script. Anyone help with how to do that?

17

Wow. It is actually super simple now. Just create an automation that defines a webhook ID thus:

automation:
  - alias: 'Webhook endpoint to entry motion' ## http://hassio_ip:8123/api/webhook/motion_entrance ##
    hide_entity: true
    trigger:
      - platform: webhook
        webhook_id: motion_entrance
    action:
      - service: script.turn_on
        entity_id: script.trigger_ss_entrance_boolean
      - service: notify.hass_synochat
        data:
          message: "Entry motion webhook fired"

Mine is then calling this script which in turn fires an input boolean for 5s. I also have a notifier in my automation purely for testing purposes.

script:
  trigger_ss_entrance_boolean:
    alias: Trigger input boolean for motion from API
    sequence:
      - service: input_boolean.turn_on
        entity_id: input_boolean.motion_entrance
      - delay: 00:00:05
      - service: input_boolean.turn_off
        entity_id: input_boolean.motion_entrance
1 Like
18

Buggar. Seems all is not well in Synology. Although I can fire that webhook event using Postman or the Android HTTP app using a POST request, it does not work as a SS action rule. Back to the drawing board. Looks like I’m going to have to break out Wireshark again.

1 Like
19

This is as far as I got, Postman works great for both the webhook and the event trigger. Unfourtuently SS doesn’t and I struggled to find any further information on what SS does with the action URL. I’ll keep my fingers crossed you can sniff something with Wireshark.

20

I’ve had the same issue with webhooks not working from SS. I came to find out that SS only sends a GET request and does not set the content-type in header appropriately (HA expect application/json). As such, I created a Node-red flow to proxy the request to HA in the proper format.

So route the information takes is:
SS via the motion action sends HTTP GET request towards node-red listening on url. I used /synology_flows/:webhook, eg http://node.red.host/synology_flows/WEBHOOKID-devicename

Node red maps the provided webhook parameter towards the new POST request towards HASS and sets the content-type in header and also provides an empty (but defined) payload, eg, “{}”

This gets the motion events from synology into HA triggers, where you can do whatever you would want to set input_boolean, etc to act as a switch. I also have all my webhook IDs in this case start with a randomly generated string but also end with a “-devicename” so it can be referenced in automations.

- id: security_motion_events
  alias: Surveillance Motion event
  trigger:
    - platform: webhook
      webhook_id: !secret ss_camera_front_door_motion
    - platform: webhook
      webhook_id: !secret ss_camera_back_door_motion
    - platform: webhook
      webhook_id: !secret ss_camera_driveway_motion
    - platform: webhook
      webhook_id: !secret ss_camera_house_front_motion

  action:
  - service: notify.hass_notify_group
  data_template: >
    message: "Device {{ trigger.webhook_id.split('-')[1] }} just registered motion"