What worries me is in the photo there seems to be "adjustments" for focus and zoom, if the Zoom part of PTZ was solid, why would one need screwdriver adjustments? Wishful thinking suggests it might be to support using it without PTZ.
Any one actually used one? At $100 I can "afford" to try it, but the Onvif cameras I've been using, Geovision/USAvision 720p, are ~$25, along with a few "straight from China" Besder 1080p cameras for about the same price that I would not recommend. The Geovision cameras have been rock solid and have built in POE as well as a 12V power pigtail, they have been running since August.
The upside of the Besder cameras is they have allowed me to test and improve my network error handing code
Its cheap enough, but I've been burned in the past with AliExpress, it also is only PT not PTZ and not outdoor rated. But I could justify an indoor PTZ for testing if the price was right
Yours could indeed be PTZ, but what that link offers now is PT no zoom (if you read the specs) despite the title saying PTZ, my main issue with AliExpress re-orders often don't get you the same item if you want another!
Apperently some of the Onvif nodes that I had build last summer, were still based on the node-onvif library instead of the onvif library. Have updated the code, but need to test all commands.
I need to optimize the communication between Node-RED and the camera, to ensure that the number of requests to the camera is minimized. And this makes my code also cleaner. But need to get first some feeback on this issue.
Seems that our friend @wb666greene is looking at PT cameras instead of PTZ. Since I have also PT cameras, I really need to create a pull request for the Onvif library (otherwise e.g. we cannot determine the current position of the camera in both directions): indeed an exception occurs when the camera only returns PT info but no Z(oom) info ...
Like you say it’s a server side motion and low on resources make that it will not work for me plus that my IP camera have built in video analytic:) So if I can communicate via ONVIF to get the event it’s low on the server side plus I will have great detection. Thanks for the suggestion otherwise!
Hi @Klangen82, I will continue with my Onvif nodes in a couple of days. The configuration issue seems to be solved now, so I can start refactoring my code. If all goes well, I should have a first alfa version available next week. Would be nice if you could also do some tests then ...
I promise I will test and provide my feedback! If you could implement the metadata in Onvif I would be happy as then we can receive analytic events, PTZ positions and other fun stuff the device may have:)
Thanks for doing this, I wish I was a programmer and could help but sorry to say I´m not:/
The more I contribute to Node-RED, the more feature requests and issues I receive. Have done lots of stuff meanwhile but most of them not Onvif related ...
I ordered some Onvif camera's last weekend, so I should have my nodes up-and-running soon anyway. Will try to publish next weekend a beta version with limited functionality, so we can at least start discussing it ...
I'm trying your onvif plugin, but for some reason the camera status remains "disconnected".
Onvif discovery works fine, and detects the camera, and returns the Xaddr : "http://192.168.x.x:8899/onvif/device_service"
How do I exactly have to fill in the Xaddr in the nodes ?
with or without http, port and so on?
for the rtsp stream.
But different cameras may have grossly different URLs. My examples are from an Ali Express Besder camera that I wouldn't recommend (it drops off the network for ~3 minutes about every 8 hours for only god knows why). I've made my one thread per camera code sleep and retry until it recovers, which it almost always does (my log files are why I have an idea of the duration and frequency) but on a few occasions its dead until the power is cycled.
If you put the snapshot URL in a browser you should get an image returned. If you put the rtsp URL into VLC you should see the stream.
I do this all the time to check the cameras and adjust the field of view -- cell phone is real convenient if you have good WiFi where your cameras are mounted.
There are Onvif "methods" to return a snapshot etc., but I found the documentation to be poor so it was easier for me to use "normal" web or openCV functions in Python to get jpeg images or grab frames from the rtsp stream.
My experience with the Ali Express or Amazon "straight from China" cameras is if you can complete the Onvif probe to get the URLs and play the rtsp stream in VLC they deem it "compatible". None of mine have worked very will with various Onvif "device managers" I've tried on Windows, Linux, or Android.
So I'm not sure its worth a lot of effort to bring Onvif support into node-red unless you have "real" (read as meaning rather expensive) Onvif PTZ cameras where the Onvif "standardization" of PTZ functions is a major win over adhoc RS422-type control strings over the video transport used by non-Onvif cameras.
To find the correct url's for onvif compatible cameras I really recommend ONVIF Device Manager. It is a free tool for Windows and seems to do the job. A friend of mine just bought some really good and cheap wifi outdoor onvif compatible (well) china cameras that you normally pair with an app. That actually worked great but we wanted to integrate them with Motion. Happily after, we got the urls identified with port number. After this, entering url's in Motion config, live video was there
So now we can do nice AI with Motion and DNN etc etc and use the standard phone app if needed in parallel
I guess this is OK if you have Windows, but I'd expect/hope node-red onvif nodes would find the URLs. Maybe not, node-red seems pretty weak for "dynamic" operations like reading a file and spawning a sub-flow for each camera.
It writes the snapshot URLs to a file that I read in my Python AI code to create one thread per camera to grab snapshots and feed the AI threads.
What I'm finding most disconcerting with all these "cheap" cameras is they all seem to depend on running unsigned ActiveX controls to do things like set timezone, enable/disable overlays, change frame rate, etc. I generally set them up in a Windows 7 Virtual Machine, the exception being the one Besder WiFi camera I tried that lacked the snapshot URL and could only be setup via a cell phone app.
One other nasty is a lot of them default to a fixed IP address like 192.168.1.10 instead of defaulting to DHCP. This is a showstopper for a lot folks who aren't networking savy.
I don't really see the attraction of WiFi cameras, you still need a wire to supply power unless you like changing batteries
POE is IMHO far superior, and inexpensive "passive" inserter/injector pairs are like $5 and let you use the 12V supply that usually comes with the camera. A fair number of the cheap cameras support "normal" 48V (44-57V) POE directly as well as the 12V coaxial power connector (can't mix, use one or the other).
First of all, thank you all for the rapid reply's.
Let me clarify some things; I know how to get the snapshots (wb666greene you were right) and even the streams. The issue is that I would like to get the onvif events, specially the motion alerts.
Now I have a workaround watching het vsftp log file on my rasperry pi to now if the camera has detected some motion. The windows software, does show me this onvif info, but I would like to get this info into node-red
The camera is discovered by the Onvif discovery node. It publishes its info in the msg.payload, but the issue is that I cant do anything further with it.
Just did a small test with ONVIF device manager; it detects the camera, shows me the stream, still image and events, so I guess the camera is outputting correct ONVIF info ?
I have the feeling I make a stupid mistake somewhere, so a working example could be helpfull....
Might I suggest doing what I did and let node-red-contrib-ftp-server accept the images via ftp from the camera instead of using vsftp?
If you can get ftp snapshot images from motion detection events it seems you are pretty much there. What does using "Onvif Events" bring to the party?
I found the Onvif discovery to get the URLs and "embedded passwords" fantastically useful, but beyond that, it seems far too complicated for what it actually does, but I'd certainly dive back in if I had a PTZ camera as one common protocol to control the cameras vs. potentially one set of control commands per camera model would be a huge win and justify the Onvif learning curve.
Hi @prutspapa, don't know if you have seen but in my last post I have written "Will try to publish next weekend a beta version with limited functionality". So you are a bit too early... I will still try to publish a very draft version (with lots of issues and limited functionality), but got some unexpected personal activities that limit my Node-RED time at the moment ...
Anyway it is a good question, since my explanation in the readme is not clear enough. Will need to update that ... You just need to put the IP address into the config node's xAddress field:
No idea. Never seen such a setup before ...
As you can see there is an option to get the snapshot URI, but I have also added an extra option to get a snapshot image: it will get the snapshot URI behind the scenes, and then connect to that URI via http to get the image itself ...
The media node also has an option to get the RTSP url. Caution: The current Github version does contain a bug yet, which I have fixed in my local version already ...
Indeed I have seen that. But hope to be able to offer that functionality in Node-RED soon. So all 'constructive' feedback about the user-friendlyness of my nodes is very welcome. I have just tried to add as much functionality as possible (in the very limited time I have ...), but there are most probably much better ways to offer it to the users. Just let me know ...
Now we are talking
That is 'constructive' feedback
I hope my Discovery-node offers the same results as your txt file. A big difference might be the output: the discovery-node has a lot of output data, from which I currently only use the xAddress . Perhaps we can skip the rest, but I'm not enough Onvif expert yet to determine whether the other data is useless or not ...