[APP][Pro] Support for ONVIF compatible cameras (Release 2.0.70, Test 2.0.70)

Apps
2211

Thnx buddy, but went for a Reolink. Had a nice offer at joybuy for 90€.

2212

Hi all,

I’m trying to get motion detection working reliably with the ONVIF Camera app and a Hikvision NVR. The camera streams and snapshots work, ONVIF events clearly arrive in Homey, and the channel tokens are correct. The problem is that Homey receives the correct motion event but does not use it.

Setup:

  • Homey Pro
  • Hikvision DS-7716NI-K4/16P
  • Firmware V4.74.210 build 240108
  • 4 camera channels added separately
  • Each channel has the correct token:
    • Ch1 → VideoSourceToken001
    • Ch2 → VideoSourceToken002
    • Ch3 → VideoSourceToken003
    • Ch4 → VideoSourceToken004
  • PullPoint events are supported by the NVR and are being received by Homey.

The NVR sends two different motion events. For example, when there is motion on channel 2:

tns1:VideoSource/MotionAlarm
Source = VideoSourceToken002
State = true

and:

tns1:RuleEngine/CellMotionDetector/Motion
VideoSourceConfigurationToken = VideoSourceConfigurationToken002
IsMotion = true

So the NVR definitely detects motion and sends it over ONVIF.

The most important log entry is this one from the correct Homey channel:

Event token VideoSourceToken002, channel token VideoSourceToken002

Event data:
VideoSource/MotionAlarm: State = true

Ignoring event type:
VideoSource/MotionAlarm: State = true

So:

  • the event reaches Homey;
  • the event belongs to the correct channel;
  • the token matches exactly;
  • the event is MotionAlarm;
  • State = true;

but Homey still ignores it.

Based on the event itself, I would expect the correct Homey setting to be:

ONVIF Motion Notification to use:
MOTIONALARM (State)

However, this is exactly where I get stuck.

When I try to select/save MOTIONALARM (State), Homey gives:

Sorry the notification method you have chosen to use is not supported by this camera.

So I cannot actually configure Homey to use the exact motion event that the NVR is demonstrably sending.

That seems to be the main problem.

There is also a secondary oddity in the PullPoint communication. Homey creates the subscription successfully:

CreatePullPointSubscriptionResponse
/onvif/Events/PullSubManager_...

but subsequent requests in the debug log contain:

/onvif/Events/PullSubManager_...null

The NVR nevertheless responds to many of those requests and Homey receives events. Occasionally I also see:

pullMessage error: Wrong ONVIF SOAP response

after which the PullPoint subscription appears to be recreated.

But despite that, the motion event itself clearly arrives, so my main question is about the motion-event selection.

What should I do from here?

Is this a bug in the ONVIF Camera app where MOTIONALARM (State) is incorrectly rejected during validation, even though the NVR actually sends VideoSource/MotionAlarm: State?

And is there a workaround to force Homey to use:

VideoSource/MotionAlarm
State = true / false

instead of rejecting that option?

If the developer needs a specific part of the debug log, I can provide it.

2213

I have the log.

It seems the motion events that are in the log are for channel 3, but only channels 1 and 4 seem to be enabled.

Also the camera is returning VideoSourceConfigurationToken003 but the app expects VideoSourceToken003. You could allow for that by changing the Token field in the Advance settings - Motion Trigger - Token to VideoSourceConfigurationToken003

image
image516×668 21.9 KB

2214

Hi Adrian,

Thanks. I have now changed the Token field for all four channels to VideoSourceConfigurationToken001 through 004.

What I still don’t understand is why this suddenly became necessary. Motion detection is definitely enabled on all four camera channels, and more importantly, motion detection in Homey was working perfectly on all four channels before.

The problem only started after I rebooted my Homey Pro. After that reboot, all four motion sensors stopped responding at the same time. I did not change anything on the NVR or cameras.

So I’m wondering if the log shows something that explains what happens after a Homey reboot. Could the ONVIF event subscription or listeners not be restored correctly after rebooting Homey? It seems strange that all four channels worked before, then all four stopped immediately after a reboot.

I have now applied your token suggestion to all four channels but it’s not working.

Extra info: 1 and 4 just started working suddenly

Extra 2: removed and added all devices again and it’s working now.

2215

Hi @Adrian_Rockall,

Thanks for a great app! I’ve been testing a Reolink E331 (FW v3.1.0.5714_2511271356) with app v2.0.70. Two suggestions came out of it that would probably help with other newer Reolink models too.

Background: Reolink has removed the HTTP/HTTPS server from the E331 firmware, so port 80/443 are closed and the official Reolink app can’t add it. ONVIF on port 8000 and RTSP on 554 still work fine.

What works: With Prefer Pull Events on, motion triggers reliably. In the log I can see that the app already handles PeopleDetect (“Person Detected”).

1. Snapshots fail

GetSnapshotUri (both Media and Media2) returns http://:80/cgi-bin/api.cgi?cmd=onvifSnapPic&channel=0, but port 80 is closed, so every event image fails with ECONNREFUSED.

Would it be possible to fall back to grabbing a frame from the RTSP stream when the snapshot URL can’t be reached? Or to allow an rtsp:// URL in USER Snapshot URL?

2. Reolink’s AI events aren’t advertised

GetEventProperties only advertises CellMotionDetector/Motion, VideoSource/MotionAlarm, ImageTooDark and ProfileChanged/ConfigurationChanged. But the PullPoint subscription actually delivers these too:

tns1:RuleEngine/MyRuleDetector/PeopleDetect State=true/false

tns1:RuleEngine/MyRuleDetector/VehicleDetect State=true/false

tns1:RuleEngine/MyRuleDetector/DogCatDetect State=true/false

tns1:RuleEngine/MyRuleDetector/FaceDetect State=true/false

tns1:RuleEngine/MyRuleDetector/Visitor State=true/false

tns1:RuleEngine/MyRuleDetector/Package State=true/false

They show up as [Initialized] right after the subscription is created, so they could be detected that way. Since the dropdown is built from the advertised list, they can’t be selected today. It would be great if they could be chosen as the notification type, or used as separate flow triggers (person / vehicle / animal). Filtering out false positives is the main reason to buy a camera with AI detection.

Small detail: The camera only allows MaxPullPoints=2.

I’m happy to test a build. Diagnostic logs are available on request.

Thanks!