Ok I can confirm that after a bit of testing all my Reolinks have the same issue. After installing them from fresh (factory reset, register to LAN via reolink app then turn on ONVIF) they are all found as new IPCams by your driver during the ST discovery process (scan nearby). I can then enter there username and password and after a Refresh on your new device page everything looks good; I can subscribe to motion events just fine. But the new camera does not appear on the Select Cameras page when trying to either create a new Camera Group, or add to existing. But using Advanced Web App to send startstream for that cam immediately shows it in the Select Cameras list. This is perfectly reproducible and repeateable.
However! There is a curve ball, I believe due to Reolink rather than your driver, that complicated matters. It is related to the cams being dual band WiFi for 2.4GHz and 5GHz. This foxed me for a while. Forgetting about ST for a moment, what seems to happen is that if a device is in dual mode, and it’s connected on, say, 5GHz but the signal gets weak, it auto-switches to 2.4 but at thAt moment it gets a new IP address. So each camera ends up with 2 IP addreses one for 2.4 and a different one for 5.
This obviously has an impact on your driver which I’m guessing would only find one active IP during the discover process. If at a later time the user’s cam switched WiFi band, your driver would think the cam was disconnected. And assuming the discovery process wasn’t run a second time, the “new” cam would not be found.
The way I fixed this was to assign a static address on my LAN with DHCP on the router (ie. Keep set as dynamic in the Reolink app and let DHCP do the work), also taking the opportunity to disable the dual band in Reolink (as the range is better at the lower frequency and I wanted to set up a separate segregated network for security anyway)
As did the startStream thing, is this a difference in the way ST have implemented the Edge drivers as compared to a previous release? (E.g. maybe originally an Init also ran startstream command, but they’ve separated their responsibilities so they are independent?)
That’s really interesting. Thanks for reporting that. I don’t know if something has changed in the hub firmware to have possibly affected this behavior. Devices that dynamically change IP addresses can definitely give SmartThings some trouble. As I understand things, there is no DNS server or table maintained in the SmartThings hub, so anything that messes with IP addresses of devices it is talking to - be it something like your experience or with mesh routers - it IS known to cause issues.
The only way for drivers to manage these situations would be to rediscover the device whenever the IP address changes, which is not very convenient…
You also have to ensure that the devices and SmartThings hub are on the same subnet.
To @TAustin or other users of TAustin’s ONVIF driver with Reolink cams, are there specific settings or tweaks necessary either in the ONVIF device or Reolink app to limit motion detection based on Reolink’s smart ‘person’ detection? Right now motion is being triggered by snow or rain falling in front of my cams and I’m seeking to create a more reliable routine that will notify me when someone is at the front door. Any insight is appreciated. I am using RLC511WA and RLC810A cams
for your Reolink issue, try changing (in the Reolink app, not available in this Edge driver) the Detection Alarm → Alarm Delay → Person Motion setting for that camera to a value of 1 second or more. In other words, 0s is a bad idea. This seems to be because anything in the field of view will trigger the alarm instantly, no matter how transient. It’s not clear that 0s is a great default. Once you’ve set it in Reolink app, it will take effect in motion detection events if you subscribed to them in SmartThings using this Edge driver, and you can forget about it.
e.g. A snowflake falling that’s only captured on 2 consecutive frames before going out of the field of view (which could total less than 1/10th sec depending on your settings) may trigger the alarm - hence lots of false positives
For clarity, the snowflakes I’m referring to are of the frozen water variety, rather than the human variety.
Hi @TAustin it’s been a bit quiet on this thread for a while. But in the background I’ve been doing some testing. I’ll pass on the results later in the month when I get some time.
But… It looks like the recent Android update has shot your driver’s presentation in the foot, as the raw html code is now coming out instead of your beautifully formatted table. See attached photo. Presumably they introduced this as a measure to prevent cross-site scripting and other potential nasties from the world wide web circa 1998.
As an aside. What’s your plan for getting this out of Beta? It seems that certainly for my Reolink cams, everything is roughly working on, and even the live stream is working if you’re gentle with it. Even the live stream outside of a Camera group - that’s right, I see a live stream on a camera page now too. I believe the ST Dev team have fixed up a few long standing idiosyncrasies that emerged post Groovy.
Another question, maybe for the philosophers: will any Edge drivers ever get out of Beta; and does it Matter? And will Matter ever matter and get beaten back to Beta?
Sadly my playback has now partly broken, the cam group still shows live footage but if i tap the arrow top right to go to the devices own playback screen the live panel where footage should be displayed just shows this and as Phil points out, ST have removed the ability to display more than 2 lines of formated text for security reasons which not unusually has broken many driver presentations, i am still amazed developers have the patience for Smartthings as they continue to destroy peoples hard hard work
It’s true @fido I’m noticing it elsewhere now, it appears to be a blanket change across the whole of the Android app (didn’t check iphone to see if it has the same issue)
The broken info panels are a move from ST to stop … (as far as i know) malicious code injection ! Or something similary sinister, however i thought all drivers were sandboxed and that wasent posiible ? Anyway no doubt i am way off the mark but the upshot is, all info panels that are custom are now DOA
There is also a strong possibility that ST want to standardise the device pages, allowing fridges, hairdryers, shoes, spoons etc to show the same device panels
Indeed @fido it’s to prevent a cross-site scripting attack (XSS) - the html is rendered using a real browser engine but equally that engine will run raw javascript too, basically allowing a bad actor potential access enough to cause all kinds of havoc on the client machine.
Such was the risk that a whole html element (tag) called < iframe > was deprecated from the html standard (can’t remember exactly when or the version offhand)
This type of attack was commonplace in early days of the web in the 1990"s (I know, I was there!) to the extent that most modern UI frameworks such as Angular and React have defence against in baked into the cake. Therefore I’m left reeling with amazement that these kind of vulnerabilities still exist in production-grade software in the year 2024 released by one of the world’s biggest tech companies.
EDIT bizarrely my reference above to the iframe tag actually tried to render a real iframe in my chat window! Edited it with additional spaces to neutralise the evil. I’m sure someone has it in a support backlog ticket somewhere…
@fido regarding the point about a potential impending standardisation of the device pages - Samsung and ST in particular seem to have a sublime-to-ridiculous rollercoaster relationship with the app’s Ux design. Just when im starting to think my Android app is half- reasonable and is easy on the eye, BLAM!!! Without warning, another apoplectic morass of ill conceived and inexplicable buttons and broken controls is thrust my way.
Sometimes I feel fortunate to be colourblind …
A little user research wouldn’t go astray, methinks,
Recently got a few reolink cams (and NVR) so I thought I’d give this a try.
Had zero luck with the v3 driver. I could get some the devices found and motion events working, but they refused to act as cameras, wouldn’t show up to be selected in the camera groups.
Many hub reboots and camera reboots etc, no luck. All cams have static IP’s.
Tried adding them with the manual ONVIF creator and the driver change to V3 would not stick.
Came across the other test channel and noticed V2 driver is active there. I’ve found that if I manually create them, then do the driver change to V2, the change sticks and they function as cam/can get them to stream.
I have found that the device info on these manually created devices doesn’t update to enable the tampering function after the driver change.
I don’t have CLI or logs sorry, but I hope that helps someone.
Can I ask what the difference between the motion rule selections are please?
Morning. I have 5 Reolink E1 Outdoor PoE connected via LAN. All seem to be working well using the ONVIF Video Camera V2 Drivers from Channel TAustin Driver Tests Alt.
I can’t recall, but for some reason, I thought the process of manually adding the cameras were replaced by “Scanning” for new devices, at which point it would pick up the IP address and fold the Cameras into SmartThings
Perhaps try removing the manually installed Devices/Cameras, then trying method above.
As well, a couple other things come to mind:
Use a static/fixed (and/or DHCP-Reserved) IP Address
Yes I mentioned above this seems to be a problem with dual band devices, e.g. the E1Pro Reolink ipcams. What happens is that each WiFi band has a separate network interface and hence different IP address. So discovery runs when you pair the device and it’s picked up by nature of it’s unique IP address. So far so good. But later that day a small bird coughs on your WiFi router and the 5GHz the ipcam was connected to drops, causing the cam to fallback to 2.4GHz. Whoops! Now your device shows as offline in SmartThings. If you then run discovery again, it’ll pair with the same cam as though it’s a completely new device. So you have 2 copies, one offline and the other awaiting configuration
This is not solved by DHCP as the two NICs have different MAC addresses as well as IP addresses - your DHCP can’t lease a single static IP addresses to more than one MAC.
Many thanks @TAustin for this Driver, i already using Wake On LAN SW for My Samsung TV working like a charm!
SO I have same but newer Foscam R2 V5!
There was little “confusion” on Camera Setting like HTTP Port was 88 which is to login to the camera GUI via Browser & ONVIF Port was 888 & Auth OFF, but when i connected with ODM i come to know the RSTP Port IS the HTTP Port 88 so i changed to 888, i can stream via ODM/VLC, but not even getting connected via ST Driver V2 i got it once “connected/responding” but not anymore! Ofc, I given User/Passwd on the Settings in driver, there is ONVIF Auth ON/OFF in Camera GUI, even if is OFF is still asking AUTH, for example ODM Events i get this even i already logged in
I just got Tapo C220 Camera even as I seen is working for everyone but NOT for me it’s just syas NOT Responding
I can view with IP CAM viewer Android App
Please any suggestion
Thanks
