Send Synology Surveillance motion events to HA switch

xbmcnut · July 9, 2018, 1:30am

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.

abaksa1 · August 10, 2018, 9:04am

Hi,

Did you make any progress with this?

xbmcnut · August 10, 2018, 10:04am

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

cyberd3vil · August 21, 2018, 1:45pm

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

xbmcnut · August 22, 2018, 8:49am

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.

kdex · September 21, 2018, 9:37pm

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.

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
```
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

image731×520 11.4 KB
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
```

xbmcnut · September 22, 2018, 12:37am

@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.

w1ll1am23 · September 28, 2018, 2:19am

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?

xbmcnut · September 28, 2018, 4:04am

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

w1ll1am23 · September 28, 2018, 12:04pm

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

Thanks.

J_IO_B · November 22, 2018, 12:59pm

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

xbmcnut · November 24, 2018, 1:09am

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

xbmcnut · November 30, 2018, 9:34pm

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?

xbmcnut · November 30, 2018, 10:50pm

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

xbmcnut · November 30, 2018, 11:16pm

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.

J_IO_B · December 1, 2018, 5:56am

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.

WhichWayWazzit · December 2, 2018, 6:10pm

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"

J_IO_B · December 2, 2018, 6:32pm

Amazing! Don’t suppose you’d mind sharing your Node-Red flow? What kind of latency do you get from this?

WhichWayWazzit · December 2, 2018, 6:46pm

It’s pretty much instant as far as I can tell. Obviously limited by how quickly your camera signals the event and how loaded your system is, etc but it comes through very fast in my testing.

Here’s my node flow: click

J_IO_B · December 2, 2018, 7:16pm

Thanks! You’ve just saved me heaps of headaches!