Has anyone had success in extracting the JSON values from the webhook response?
If anyone has some working examples that would be great! I am trying to send a Telegram message however it’s not working for me. Any tips would be appreciated Here is my automation however it doesn’t’ extract any of the values…
@mhoogenbosch if you have changed the callback url and still not seeing data coming in, it could happen. Sometimes it may take 5-10 minutes on the Imou side to update it, we have noticed in our tests. Sometimes it is random (some requests sent to the old one, other to the new one). Sometimes I’ve also noticed this change never takes place so just disable push notifications, change the url and enable them again.
ALL, for tracking those good advices consistently, I’ve moved the roadmap page to a more structured Github project (Imou Life HA Roadmap · GitHub) and opened up as issues all the feature requests showing up here during the last few weeks. If I’ve missed something, feel free to add.
My simple automation now works, I made a slight change to use the json object and it sends a nice Telegram notification. In this example I am using variables however you could also access the json values directly using trigger.json
alias: Imou Life Webhook
description: ""
trigger:
- platform: webhook
webhook_id: imou_life_callback_mywebhookID
variables:
camera_name: "{{ trigger.json.cname }}"
event_type: "{{ trigger.json.msgType }}"
condition: []
action:
- service: notify.telegram_group
data:
title: Imou Life
message: Camera {{ camera_name }} has triggered event {{ event_type }}
mode: single
The human detection is a bit weird though… no body in screen but still a human was detected. Well, just have to check a bit more, Thanks for sharing your automation!
@galaxy_explorer thanks for sharing your automation! @mhoogenbosch human detection is far from being perfect, sometimes triggers when the light suddenly changes and of course if my cat walks along. I guess Imou wants to push for their premium service which moves this kind of detection in the cloud
Open question. I was thinking of a blueprint to avoid every user to write down his own automation. But could be tricky since incoming events could match multiple webcams and the mapping could be manual (object in HA can be given a different name) so not sure if a blueprint simplifies or over-complicate things. Also there cannot be more than one automation with the same webhook id so it should be a single, comprehensive and customizable automation which takes care of all the logic. What’s your view with it? (also because my experience with blueprint is limited).
Alternative could be to provide a sort of templated automation which renames the variable in a human readable way and let the user decide what to do with them. Thanks
[quote=“user2684, post:85, topic:462439”]
I was thinking of a blueprint to avoid every user to write down his own automation. But could be tricky since incoming events could match multiple webcams and the mapping could be manual (object in HA can be given a different name) so not sure if a blueprint simplifies or over-complicate things. Also there cannot be more than one automation with the same webhook id so it should be a single, comprehensive and customizable automation which takes care of all the logic.
[/quote]I guess it would over-complicate things. I think it is a good idea to have an example automation like @galaxy_explorer shows. Maybe you could ask him if it is okay to put this on github too. For me, I want to have the movement send to my mobile phone, when I’m not at home, preferably with an image showing what is going on. I don’t use telegram, so the actions are really diverse. My 2 cents.
An alternate approach is to use a template trigger like this however you will need an automation to reset the value after a given time for it to be useful as the event webhook doesn’t provide a clear/normal event.
Another limitation is that you can’t specify a unique webhook for each device. If you could then it would be possible to create sensors (templates) for each camera. I think this is a limitation of the Imou API, I have created an issue on this here
@mhoogenbosch@galaxy_explorer I do agree blueprints would over-complicate things so let’s keep this idea aside. I like the templating approach but would still require creating multiple sensor templates for each camera which is also manual.
What about this: let’s get rid of the lastAlarm sensor which is not very valuable and replace it with a motion detection sensor, like the camera was a PIR of some sort.
This sensor would pull the information in the same way as last alarm, turning on if since the previous update there has been an alarm (not sure still how to do it but let’s image this logic). If you don’t have push notification this will update every 15 mins or less depending on your configuration. We can also add a button or a service to manually refreshing it so a user can drive the refresh through an automation (credits to @snatch7 for this idea). In this way you can force updates every e.g. minute which is a pseudo real time update, acceptable in some situations and still usable for those who don’t have HA exposed to the Internet.
If in addition we configure push notifications, we should have a templated automation of some sort which will update still the same sensor, and dispatching to the right camera. In this way we avoid having additional sensors, we just reuse the same but this time will be realtime. All the other info (msgType, etc.) can be stored as attributes so still accessible in the automation’s logic.
Finally for sending out the telegram notification or anything else your automation would trigger on state change of this motion detection sensor, basically decoupling the incoming event from the action.
What do you think of this design pattern? If feasible, to me seems the cleanest and simplest way.
Thanks
It seems like a sensible idea as the alternatives are somewhat problematic. Would a service call to homeassistant.update_entity force the update? However, I would think that 15 mins could be OK in most scenarios.
Ok, with version 1.0.6 just released I think this is solved in the simplest way I was able to find out
Quick summary:
A motionAlarm binary sensor has been added which is intended to be used for any automations reacting on motion detection events, regardless of the way the sensor is updated (pull or push).
Added a refreshAlarm button which refresh the “motion alarm” sensor. Can be used in automations
Deprecated lastAlarm sensor since the same information is now stored in motionAlarm, as an attribute
Described in the README the three options for configuring motion detection:
Option 1: do nothing, you get updates every 15 minutes by default in polling mode
Option 2: use an automation to periodically push the “refresh alarm” button which refresh the “motion alarm” sensor (sample automation provided)
Option 3: use push notifications to have realtime updates ot the same “motion alarm” sensor. I wrote an automation which automatically request a refresh of the “motion alarm” sensor belonging to the device which sent the event which does not require further configuration. This basically means you add the automation once and there is no need to change it if e.g. you add additional devices.
Last few notes on motion detection:
when the sensor triggers, it will get back to a “Clear” state at the next update cycle (whenever will take place, periodically or through the button)
For push notifications, incoming events and actions have been decoupled so use always the “motion alarm” sensor for building your automations and notifications, when its state changes, like any other motion sensors you are already familiar with, not the “Imou Push Notifications” automations
You don’t need webhook, open ports and reverse proxy for option 1 and 2, you still need all of them for option 3
Difference from previous version is that all the options are now going to update the same sensor so the behavior is consistent and, if using option 3, you have now an automation using the webhook ready to use and which does not need any manual modification or maintenance
ok, thanks!
I’m not going to open ports, I’m using Tailscale or the Fritz VPN to access from outside.
I know that using NGINX might be safe, but I prefer this way…
So sorry about that, but I know it’s will be the only way (I hope, at the moment)!!
Added Reverse proxy sample configuration for custom configuration of push notifications in the README
Added API URL parameter when configuring a new device
@woody4165 no problem in not opening ports, have a look at option 2 which gives you the same capability with just a few seconds of delay, should be acceptable in most of the cases
I will try the first two options.
I’m more interested in switch rather than sensors for Imou cameras, since for motion (also sensor) ai use Frigate.
Fantastic job!
Just a heads up, when upgrading to version 1.0.7, you may get a “Failed to setup” error message on some devices (on those where options have been configured) after restarting HA. I’m working on a fix on this; as a workaround I think if you remove the device and add it back, it should work. But if have not upgraded yet to 1.0.7, just wait for a couple of day. Thanks
Here is my automation however it doesn’t’ extract any of the values…
